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

Merging accessibilities onto person_merged table #853

Open
dhensle opened this issue Apr 18, 2024 · 0 comments
Open

Merging accessibilities onto person_merged table #853

dhensle opened this issue Apr 18, 2024 · 0 comments
Labels
Feature New feature or request

Comments

@dhensle
Copy link
Contributor

dhensle commented Apr 18, 2024

Is your feature request related to a problem? Please describe.
The auto_ownership model passes in the persons_merged table in the auto_ownership_simulate() call even though the person_merged table is not actually used in the code.

The reason why this is included is because it causes the persons_merged function to be called here which joins the disaggregate accessibility columns that get used in the model preprocessor. Generally this wouldn't be needed, but is in this case because auto_ownership is the first actual model run after reading in the households and persons data.

This is a pretty sneaky way for the data to get merged in and should probably be more explicit in the code.

Describe the solution you'd like
To have persons_merged contain the disaggregate_accessibility values when it gets called in the preprocessor without having to include the table call in the main workflow.step function.

Additional context
This arose in the context of #834 PR review.

@dhensle dhensle added the Feature New feature or request label Apr 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant