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

format of feasibility table different on different proposals_to_keep #34

Open
cvanoli opened this issue Dec 16, 2020 · 0 comments
Open
Assignees

Comments

@cvanoli
Copy link
Contributor

cvanoli commented Dec 16, 2020

The proposals_to_keep parameter is set in the proforma.yaml configs file. It can take the value 1 or more than 1.
This parameter affects how the feasibility table is built. The lookup_by_form function builds the feasibility table using the forms passed to the function (e.g. "residential") and the allowed function to check the feasibility of each form for each parcel.
Then, before returning the feasibility table, the lookup_results dictionary is used to create the feasibility data frame, but there are two ways of creating it, one path is when the proposals_to_keep is > 1 and the other path is when proposals_to_keep is 1. These are the lines.
When the proposals_to_keep is more than 1, the feasibility table gets all the correct columns, plus the "form" column filled with the corresponding form ('residential', 'office', etc). A one-level set of columns.
The issue comes when the proposals_to_keep is equal to 1, the data frame that is created get multiindex columns with the (form/column). This creates an issue, later on when running the developer and calling the feasibility table and calling a specific column, in this case "max_profit_far", because the column is there but in level 1. So the correct way to call that column would be ('residential', 'max_profit_far').
Solution:
I think that the feasibility table, with one or more proposals to keep should have the same format to be used in the latter functions such as the developers. Therefore I suggest changing these lines, to have a one-level index of columns and a column called "form".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants