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

Add converter for Luxembourg, Sweden and Denmark - FieldScapes #42

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

snehalchaudhari98
Copy link
Contributor

@snehalchaudhari98 snehalchaudhari98 commented Jun 5, 2024

@m-mohr m-mohr self-requested a review June 5, 2024 21:37
@snehalchaudhari98 snehalchaudhari98 changed the title Add converter for Luxembourg - FieldScapes Add converter for Luxembourg and Sweden - FieldScapes Jun 6, 2024
@snehalchaudhari98 snehalchaudhari98 changed the title Add converter for Luxembourg and Sweden - FieldScapes Add converter for Luxembourg, Sweden and Denmark - FieldScapes Jun 10, 2024
Copy link
Contributor

@m-mohr m-mohr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I did only check the dk.py file for now, the changes requested for DK in many cases also apply to lu and se though and should be updated accordingly. I'll re-review fully afterwards.

URI = "/mnt/c/kerner-lab/fieldscapes/denmark/all_parcels.gpkg" # data seubset for FieldScapes

# Unique identifier for the collection
ID = "dk"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should prefix the fieldscapes converters with fs_ as done in #43

# Unique identifier for the collection
ID = "dk"
# Title of the collection
TITLE = "Field boundaries for Denmark"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
TITLE = "Field boundaries for Denmark"
TITLE = "Field boundaries for Denmark (FieldScapes)"

# Supported protcols: HTTP(S), GCS, S3, or the local file system

# data original source : https://landbrugsgeodata.fvm.dk/
URI = "/mnt/c/kerner-lab/fieldscapes/denmark/all_parcels.gpkg" # data seubset for FieldScapes
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as in #43: I'm not sure how to proceed with this. It's not really useful for the general public if there's no way to get the source data. Any thoughts from the fieldscapes members?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The core idea here is to get the converter code out asap, but the first goal is to get the resulting files into fiboa on source cooperative. The hope is that @eddiechoi00 will be able to help with adapting the converters to work with the original source data, and then putting the full datasets (instead of the subsets fieldscapes is focused on) in source cooperative.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I was thinking the same. We should make it so that the source data can get converted and then there could be an option that people can enable to run on fieldscapes data.

# Add columns with constant values.
# The key is the column name, the value is a constant value that's used for all rows.
ADD_COLUMNS = {
"determination_datetime": "2021-01-01T00:00:00Z"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a leftover from the template?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, so the dataset doesn't have any date attributes for individual parcels but from the metadata, it is possible to identify the year in which the data was collected. So for simplicity, we thought we could choose the template date 01.01.XXXX .

Because in the actual fieldscapes dataset, we have the harvest and plantation season's data from the seasonal crop calendar for the given year.

'STOETPROC' : 'support_proc', # fiboa custom field - translated. Supported Scheme. Currently all values are NaN
'GB_FRADRAG' : 'deduction', # fiboa custom field - translated
'MB_TYPE' : 'block_type', #fiboa custom field
'GB_AREAL': 'eligible_area', # fiboa core field i.e. eligible area
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not a core field

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, will fix this.

'MARKBLOKNR' : 'id', # fiboa core field , TODO MARKBLOKNR-id conversion is needed.
'GEOMETRISK' : 'area',#fiboa custom field i.e total area = eligible area + ineligible area
'TARAAREAL': 'ineligible_area', #fiboa custom field
'STOETPROC' : 'support_proc', # fiboa custom field - translated. Supported Scheme. Currently all values are NaN
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If all values are NaN, it whould probably be removed for now?

# You also need to list any column that you may have added in the MIGRATION function (see below).
COLUMNS = {
'MARKBLOKNR' : 'id', # fiboa core field , TODO MARKBLOKNR-id conversion is needed.
'GEOMETRISK' : 'area',#fiboa custom field i.e total area = eligible area + ineligible area
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a core field

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I changed the description in the end thus there was a mixup with the actual area and eligible area.

# Map original column names to fiboa property names
# You also need to list any column that you may have added in the MIGRATION function (see below).
COLUMNS = {
'MARKBLOKNR' : 'id', # fiboa core field , TODO MARKBLOKNR-id conversion is needed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's an open todo here.

'type': 'float'
},
'block_type': {
'type': 'string'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be an enum?

# Schemas for the fields that are not defined in fiboa
# Keys must be the values from the COLUMNS dict, not the keys
MISSING_SCHEMAS = {
"properties": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should some of the float fields be have a minimum: 0 constraint?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, good suggestion. We'll add the required constraints to the properties.

@m-mohr
Copy link
Contributor

m-mohr commented Jun 17, 2024

Please rebase the PR to the latest CLI version, including renaming the URI constant to SOURCES and renaming the parameter cache_file to cache. I tried to push it upstream, but you didn't permit changes to this PR so you need to do these changes yourself. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Progress
Development

Successfully merging this pull request may close these issues.

4 participants