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

propose new standard names in CF table #17

Closed
larsbuntemeyer opened this issue Feb 15, 2024 · 9 comments · Fixed by #22
Closed

propose new standard names in CF table #17

larsbuntemeyer opened this issue Feb 15, 2024 · 9 comments · Fixed by #22

Comments

@larsbuntemeyer
Copy link
Contributor

larsbuntemeyer commented Feb 15, 2024

we should propose and discuss the new standard names that we have in the data request here. If i do:

import pandas as pd
from cf_xarray.utils import parse_cf_standard_name_table

table = parse_cf_standard_name_table()[1]
cf_standard_names = list(table.keys())
cf_standard_names.sort()

dr = pd.read_csv(
    "https://raw.githubusercontent.com/WCRP-CORDEX/data-request-table/main/CORDEX-CMIP6/data-request.csv"
)
cx_standard_names = list(dr.standard_name.unique())
cx_standard_names.sort()

missing = [name for name in cx_standard_names if name not in cf_standard_names]
missing

i get:

['bedrock_depth', 'lake_area_fraction', 'urban_area_fraction']
@larsbuntemeyer
Copy link
Contributor Author

I think according to the discussion in cf-convention/vocabularies#24 we should not introduce new area_fraction standard names but change the standard names of the area_fraction variables to area_fraction with cell_methods area: mean where lake and area: mean where city (at least for the lake variables)...

@larsbuntemeyer
Copy link
Contributor Author

@gnikulin
If there is any doubt about those variable standard names, i would maybe remove them from the data request for now until this issue is resolved...

@gnikulin
Copy link

It took time to read all long discussions in the CF issues mentioned. It seems that the right way is indeed to use area_fractionas the standard name with cell methods area: mean where lake and area: mean where city for sftlafand sfturf. The variable (sftlafand sfturf) and long names (Percentage of the Grid Cell Occupied by Lakeand Percentage of the Grid Cell Occupied by City) should be enough to distinguish them. We have similar cases for mrfsos and mrsfl with the same standard name frozen_water_content_of_soil_layer but different long names Frozen Water Content in Upper Portion of Soil Columnand Frozen Water Content of Soil Layer.

@gnikulin
Copy link

What to do with dtb (Depth to Bedrock) is still a question.

@larsbuntemeyer
Copy link
Contributor Author

Agreed, we can be more precise in the long names which are not controlled.

@larsbuntemeyer
Copy link
Contributor Author

I opened a PR to close this issue (#22). I'll assume we'll use bedrock_depth_below_ground_level instead of bedrock_depth as discussed in cf-convention/vocabularies#205.

Should we use the term urban instead of city? I think Percentage of the Grid Cell Occupied by Urban Area and area where urban is more precisely what we want, right?

@gnikulin
Copy link

gnikulin commented Apr 3, 2024

Yes, bedrock_depth_below_ground_level has been agreed and I just formally proposed it.

We should use urban instead of city as defined in CF Area Type Table

We still need to check what can be used for lakes. There is area type fresh_free_water but nothing like lake.

@larsbuntemeyer
Copy link
Contributor Author

Ok, i think fresh_free_water is supposed to also describe lakes. I would go for that for now, it seems that urban and lake modelling domains are still somewhat under discussion. I would close that PR and make a new isse so we keep it in mind.

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

Successfully merging a pull request may close this issue.

2 participants