-
Notifications
You must be signed in to change notification settings - Fork 38
Scorecard configuration #553
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
base: main
Are you sure you want to change the base?
Conversation
…f .ghsci_version; this should make things more straight forward for docker compose files that are set to read env variables from .env; it means we don't have to do anything fancy to insert the variable there. Hopefully it will make development in a dev container easier in vscode.
…stics to example configuration file and JSON-schema file, with validation ranges for expected inputs. Unfortunately Python JSON Schema is unable to reliable validate floating point precison, so requirement for number of decimal points has not been specified (i.e. the option 'multipleOf' does not work as it would be expected to).
… and scores for Region objects that should make it easier to prepare scorecard info, but also can be used to simplify code elsewhere when retrieving these items
…ing and summarising specific groups of 1 or more policies, as required for scorecards)
…od r.get_scorecard_statistics that returns the required fields; now just to check, and to export in a meaningful format
…ted text with unicode characters and no quotation marks
The functional test workflow failed! I have implemented changes to the JSON schema, and a bit more tweaking is required for this to work before merging. However, it probably will work for your test purposes Eugen, if you still want to check it out. |
…ile to address failed test in online run test_0_0_valid_yaml (interestingly, this test passed when invoked locally...)
There is more work to do to ensure the configuration of optional parameters works as intended and is robust; please hold off on reviewing until I let you know I've made updates Eugen. Sorry for prematurely looping you in here. |
… occurs when a configuration file is loaded (previously, file was only checked with YAML lint, it is now actually evaluated against the schema); this implements type checking specifically to support #544 to ensure valid inputs are provided that allow parsing (eg numbers for population and area that can optionally be evaluated as a fraction for density)
…ld relax the test linter for comments, towards #544
…ld relax the test linter for comments, towards #544
The latest update is now much more robust, as is validation in general for configuration files (this ties in with #506). Because users can now supply optional parameters, and a couple of these in particular (population and urban area) require numeric formatting to be able to successfully be evaluated as a proportion (population density), I had to implement stricter type checking on these. And because of the work done towards #506, I was able to do this by doing proper schema validation when loading a region. I had to run through and update our schema definition to provide more flexibility due to optional fields, and some flexibility with some input formats for dates, but this works now with our example along with a whole load of other region files I have to hand to test with. Now, if a user's configuration file is not meeting the required schema (for example, if they enter "380,000" instead of "380000" for population, where we have directed for the whole optional statistics section "For values, please only use numbers and decimal points; do not use commas or other punctuation.", there will be a more or less clear warning about this provided to the user. For example, with the above example, when attempting to load a region (in this case the example, which I malformatted for test purposes):
However, if the comma is removed, we can do the following (noting the optional statistics values run here for Las Palmas are completely fictious, just for test purpoes -- not true!):
The output file
The density value of 5287.54 is the produce of the unrounded statistics 333051/62.98789962182564 = 5287.539384542298. Worth noting because if you evaluate with the rounded numbers the result would be slightly different (333051/62.99=5287.36307350373). Just pre-empting the question why there is a slight difference when evaluating with the rounded numbers that would be on the scorecard. The unrounded statistics can be viewed by invoking
(incidentally, the most recent test fail was due to a connection interuption when retrieving map tiles; the error is obscure though and may be confusing for our users; I lodged an issue at #554 . When the test run was retriggered due to my renaming of the output file to include region code name, it passed) |
@eugenrb this is good for your review and feedback now if you like! |
…d itself, towards #544
I just updated the output to use the labels for policy indicators present in the scorecard --- I think this should be good now:
|
This pull request addresses #544
It introduces a new
r.get_scorecard_statistics()
function, which a user that has completed policy and spatial indicator reviews can invoke to get a summary of indicators, and optionally export these to a human readable formatted text file (scorecard_statistics.yml
) in the study region output folder.Usage is demonstrated as follows for a study region that has had spatial analysis successfully completed and policy review configured (but not all optional policy statistics configured):
So, the first time the function was run, we just retrieved the statistics in a Python dictionary with values unrounded that can be reviewed by the user on screen or saved for use in their own analyses.
The second time the funciton is run, the following text is exported to
scorecard_statistics.yml
in the study region folder, with this file path echoed back to the user:The optional user statistics can be completed in the study region configuration file (feedback on user directions/formatting here also welcome):
global-indicators/process/configuration/regions/example_ES_Las_Palmas_2023.yml
Lines 497 to 532 in 0f608b8
A user can 'uncomment' this easily if using an IDE like VSCode or notepad++ (i.e. just remove the first # marks, but there are shortcuts to uncomment selected lines in IDEs), then add entries as required. There is some input validation implemented for this, so if the wrong format is provided feedback on the error should be provided to a user.
Do you think this could meet your needs @eugenrb ? I'll lodge this pull request now so the automated testing can be launched and mark you as a reviewer --- you're welcome to checkout the
scorecard_configuration
branch and give it a go with your existing regions. Tests, and any feedback welcome.