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
Refactoring our 25-city study code to work for generalised application with other cities, we removed the between-city walkability index from processing (as per #136). This was done because to calculate relative to 'all cities' wasn't a stable comparison.
However, when integrating the generate reports functionality into the generalised workflow, to make the previous template work without modification the 25-city comparator was used as a fixed reference standard for walkability comparisons --- using the mean and standard deviation for walkability sub-indicators from the 25-city study to create z-scores for new cities. Long term, this may not be the ideal comparator, but it was an easy approach for retaining a stable walkability index that could be judged against a fixed standard and mapped.
It was implemented by providing a configurable entry in the indicators.yml file to define plug-in parameters for a reference standard
Then, these parameters were retrieved in the generate_report_for_language() function to create the required derived indicators so they could be mapped and included in the reports:
That will then make it easier for the report generation functions to be more generic and true to purpose --ie. they could be used for preparing validation reports using the already generated data (rather than generating new data themselves, which isn't saved anywhere other than the report). Importantly, it would mean the fixed-standard comparative walkability measure would be saved in the actual dataset so others could use it for analysis or mapping as required.
The text was updated successfully, but these errors were encountered:
Refactoring our 25-city study code to work for generalised application with other cities, we removed the between-city walkability index from processing (as per #136). This was done because to calculate relative to 'all cities' wasn't a stable comparison.
However, when integrating the generate reports functionality into the generalised workflow, to make the previous template work without modification the 25-city comparator was used as a fixed reference standard for walkability comparisons --- using the mean and standard deviation for walkability sub-indicators from the 25-city study to create z-scores for new cities. Long term, this may not be the ideal comparator, but it was an easy approach for retaining a stable walkability index that could be judged against a fixed standard and mapped.
It was implemented by providing a configurable entry in the indicators.yml file to define plug-in parameters for a reference standard
https://github.com/global-healthy-liveable-cities/global-indicators/blob/6d5c2f010c755f91356d948054e8cbf7fb6e9102/process/configuration/templates/indicators.yml#L183-L191)
Then, these parameters were retrieved in the generate_report_for_language() function to create the required derived indicators so they could be mapped and included in the reports:
https://github.com/global-healthy-liveable-cities/global-indicators/blob/6d5c2f010c755f91356d948054e8cbf7fb6e9102/process/pre_process/_report_functions.py#L68-L88
But really, this is the wrong place for this to be done. It should be done in the 03_aggregation.py script, at about this location
https://github.com/global-healthy-liveable-cities/global-indicators/blob/6d5c2f010c755f91356d948054e8cbf7fb6e9102/process/03_aggregation.py#L36
That will then make it easier for the report generation functions to be more generic and true to purpose --ie. they could be used for preparing validation reports using the already generated data (rather than generating new data themselves, which isn't saved anywhere other than the report). Importantly, it would mean the fixed-standard comparative walkability measure would be saved in the actual dataset so others could use it for analysis or mapping as required.
The text was updated successfully, but these errors were encountered: