Skip to content

format of feasibility table different on different proposals_to_keep #34

@cvanoli

Description

@cvanoli

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".

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions