Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Affordability KPI "income" column & Total Monetary Cost #72

Open
divyasharma-arup opened this issue Mar 15, 2024 · 2 comments
Open

Affordability KPI "income" column & Total Monetary Cost #72

divyasharma-arup opened this issue Mar 15, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@divyasharma-arup
Copy link
Contributor

Looking at the implementation for writing this KPI, I think it's looking for a column name income, but in the Paris East sim, it is actually labelled householdIncome. Is there a standard MATSim input column for income? Perhaps we should use that, or ask the user to enter what the column should be. Because it is householdIncome in the Paris East sim, the user only receives intermediate outputs by subpopulation, so we can't validate the percentile income functionality.

@divyasharma-arup divyasharma-arup added the bug Something isn't working label Mar 15, 2024
@divyasharma-arup
Copy link
Contributor Author

Also, a note that when trying this on the leg_logs from: gelato alpha 0.03, with outputs saved here: /mnt/efs/analysis/ds/gelato_outputs/baseline_30pct, I get a total_daily_monetary_cost of €523,450 as a straight sum from the legs table, which I think is what Gelato is doing too. But Gelato returns €4,711,058, so there's some sort of discrepancy here in method that makes the average daily cost in Gelato outputs much higher than what I'm calculating from legs table.

@divyasharma-arup divyasharma-arup changed the title Affordability KPI "income" column Affordability KPI "income" column & Total Monetary Cost Mar 15, 2024
@KasiaKoz
Copy link
Contributor

Some notes after a chat on slack:

  • for the income column, we could just look to find a column that has a mention of income in the name, so it could be income, householdIncome, hhld_income etc.
  • I think the second point might be the same problem as here: GHG KPI per capita calculations consider more people than are actually there #73. I think we should have a separate table for people, their attributes, income etc. and then a separate ones for their scoring params.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants