-
Notifications
You must be signed in to change notification settings - Fork 30
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
Problems with repeated standard_names in file #132
Comments
Hi - thanks very much for this report and your detailed description, which is very helpful indeed. I think your analysis is correct. The solution you propose sounds reasonable, but I'll leave @guygriffiths to comment on how easy this may be to implement. On a side note, I think you're right that the CF conventions technically permit duplicated standard names, although personally I think these should be strongly discouraged in favour of creating new, more specific, standard names. For example, there could be However, your point about ERA5 is also valid - if the standard name does not contain the height coordinate then they cannot be distinguished. I know there have been a lot of conversations in the CF community about how to handle this, but I don't know what the latest thinking is. In any case, I know that you're not able to change the CMEMS data so it's useful to find a practical solution. Do the fields in the CMEMS data have different long_names? |
Hello @jonblower, thank you for the prompt reply. Answering your question:
Yes, I forgot to include the long_names in my question, but all the variables in the file have different long_names. I think the "string similarity" check could be applied to the variables names (e.g.:
Regarding specifically the tides variables, actually I suggested adding the standard_names
in the Regarding repeated standard_names in files, I agree with you that the ideal solution would be individual standard_names but I think completely avoiding repeated standard_names in a file is difficult because the Standard Names Guideline says
so using the ERA5 example again, the model can have an output file with the 3d wind field in the original vertical coordinates, and several other interpolated to z levels (e.g. 10m, 50m, 100m) all having the same standard_name (e.g. Thank you. |
@marceloandrioni Thanks for reporting this. I've fixed it in commit 1c76ba7. It's not released yet, so you'll need to build it from the |
Hi @guygriffiths, thank you very much for this fix. I am glad the option of using string similarity worked. I am not really sure how to build from the |
Hello @guygriffiths, I was trying to deploy the new version (ncWMS v2.5) but even after removing the $HOME/.ncWMS2 to get rid of cache the applet fails to start with tomcat message: I am using Thank you. |
Ah yes, apologies, I should have made that clear. Supporting both Java 8 and Java 11 (which are the only two long-term support releases at the moment) turned out to be much more of a headache than I'd first anticipated, so I went with Java 11 for this release. |
Got it, I will try with SDK 11 then. Thank you. |
Just to leave here the information that using |
Hello,
I was trying to use ncWMS2 to visualize current data from CMEMS but there were some problems with the automatically created layers
-group
,-mag
and-dir
.The dataset that gave me problems is the
global-analysis-forecast-phy-001-024-hourly-merged-uv
. This dataset has 4 "types" of currents. Tidal currents (utide
:vtide
), Stokes Drift (vsdx
:vsdy
), Eulerian currents (uo
:vo
) and Total currents (utotal
:vtotal
), that is the sum of all other currents.I think the cause of the problem is that several of these variables use the same standard_name attribute:
As far as I know, there is no rule in the CF Convetions against multiple variables in the same file using the same standard_name, so I would say that the file is semantically correct.
As shown in the image bellow, only 2 velocity groups were created instead of 4. Besides, only the Stokes Drift (
vsdx
:vsdy
) is correct, the second group used theu
component from the Tide (utide
) with thev
component of the Total current (vtotal
), resulting in incorrect values.I tried to think of a solution for this problem but could not find a definitive answer. Maybe an extra strep in the code to check for repeated standard_names and if found, try to match
u
:v
variables using some string similarity between the variable or long names, e.g.:uo
,utide
andutotal
are alleastward_sea_water_velocity
, bututide
has a greater similarity withvtide
than withvo
orvtotal
, so the pair should beutide
:vtide
.But I am just guessing here since I am not even sure that there is a string similarity Java library (Python and JS have it).
Also, I don't think this problem is restricted to this specific dataset. Another example would be ERA5 data from ECMWF where a file could have wind components for 10m height and 100m height that would also use the same standard_names, as there is no specific standard_names depending of the height.
The file I used in the test is here.
Thank you very much.
The text was updated successfully, but these errors were encountered: