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

Enable different datasets as input to OQT #4

Closed
matthiasschaub opened this issue May 11, 2021 · 1 comment · Fixed by #37
Closed

Enable different datasets as input to OQT #4

matthiasschaub opened this issue May 11, 2021 · 1 comment · Fixed by #37
Assignees
Labels
enhancement New feature or request priority:high Should be addressed as soon as possible (next release)
Milestone

Comments

@matthiasschaub
Copy link
Collaborator

Currently it is only possible to use the custom regions as input dataset. For those regions the feature ids is the unique identifier and also the parameter name. E.g. oqt create-indicator --dataset regions --feature-id 1

Expected is that it should be possible to choose a different dataset like GADM or ISEA (hexagonal cells).
For GADM there are multiple unique IDs such as country ISO3 codes (https://gadm.org/metadata.html). In addition it would be quite nice to be able to use english country names as identifier as well.

Solution: I propose to use the parameters 'dataset' and 'id' to identify single features of a specific dataset. Every dataset will have a default unique id field associated with it (fid in case of the oqt-regions, GID_0 (ISO3) in case of GADM). This mapping could be defined as dictionary in definitions.py. E.g. oqt create-indicator --dataset gadm --id deu

In addition we could provide a way to change the id field which is used by OQT (E.g. to NAME_0 in case of GADM). This could be archived by either adding a new option to CLI (oqt create-indicator --dataset gadm --id-field NAME_0 --id Germany) or changing the syntax of the given id (create-indicator --dataset gadm -id "NAME_0:Germany").

@matthiasschaub matthiasschaub added enhancement New feature or request priority:high Should be addressed as soon as possible (next release) labels May 11, 2021
@matthiasschaub matthiasschaub self-assigned this May 11, 2021
@matthiasschaub matthiasschaub changed the title Enable the use of different datasets as input to OQT Enable different datasets as input to OQT May 12, 2021
joker234 pushed a commit that referenced this issue May 17, 2021
joker234 pushed a commit that referenced this issue May 17, 2021
# This is the 1st commit message:

Rewrite database setup for development

# This is the commit message #2:

Add raster constraints and index

# This is the commit message #3:

Move to scripts

# This is the commit message #4:

Delete old dev db setup and data

# This is the commit message #5:

Remove admin-schema because it is internal project

# The commit message #6 will be skipped:

# Remove admin-schema because it is internal project

# This is the commit message #7:

Add scripts for creating db dump for dev
joker234 pushed a commit that referenced this issue May 17, 2021
# This is the 1st commit message:

Rewrite database setup for development

# This is the commit message #2:

Add raster constraints and index

# This is the commit message #3:

Move to scripts

# This is the commit message #4:

Delete old dev db setup and data

# This is the commit message #5:

Remove admin-schema because it is internal project

# The commit message #6 will be skipped:

# Remove admin-schema because it is internal project

# This is the commit message #7:

Add scripts for creating db dump for dev
@matthiasschaub
Copy link
Collaborator Author

As implemented currently it is possible to get an valid response from OQT when specifying a "valid" dataset, as defined in definitions.py, (e.g. GADM) which is in fact not present in the database and therefor an exception should be raised. The reason for this is that OQT's internal logic will, if dataset is specified, compute an indicator for the dataset regions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request priority:high Should be addressed as soon as possible (next release)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant