You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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".
The text was updated successfully, but these errors were encountered:
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 theproposals_to_keep
is > 1 and the other path is whenproposals_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".
The text was updated successfully, but these errors were encountered: