Closed docgregt closed 5 years ago
I think the issue is the longitude going from -180 to 180.
@docgregt - Yes, that could do it, if the axis values went (for example) ...178, 179, 180, -179, -178...
. CF conventions define that coordinate variables must be monotonic (http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#terminology). If you can link to the data I can investigate and check what's happening.
@guygriffiths Can you reach it at this site? https://i4insightcom-my.sharepoint.com/:f:/g/personal/greg_turner_i4-insight_com/EhuYWw9e9tFNqTFOzkH9M0sB5hYHI09zQVdoJ2tvjEhgaA?e=HcSjIt
The augdump.txt file is an ncdump -c of the file. I did not see anything that was incorrect there.
Yes, I've downloaded that. The problem is that the time axis is non-monotonic. It goes from 2018-08-01T00:00:00.000Z up to 2018-08-31T18:00:00.000Z in 6 hour increments, back down to 2018-08-01T03:00:00.000Z, and then up to 2018-09-01T00:00:00.000Z n 6 hour increments.
You can see the transition at line 157 of augdump.txt
:
1040178, 1040184, 1040190, 1040196, 1040202, 1039467, 1039473, 1039479,
No sure what the issue is. That file has forecast in it so maybe it is mixing forecast times in somehow. This is standard file from ECMWF and I have no control over how they add the data in. It is CF1.6 compliant.
Can you tell me more about where you got the file from? It might be worth contacting ECMWF about it, because time
is certainly a coordinate variable, and the CF conventions explicitly state that a coordinate variable "is defined as a numeric data type with values that are ordered monotonically".
You have to have an account there but the accounts are free. This issue only seems to happen on datasets with forecasts in them. Their datasets annotate they are following CF 1.6.
Thanks, I've sent them a message. We work with ECMWF data quite a lot in other projects and I suspect they won't be willing to change their data, but they may be able to remove the CF-1.6
flag to try and prevent such issues in future.
FYI, I've spoken to ECMWF and they suggested that if you retrieve the analyses and the forecasts separately then this issue won't occur. However, the person I spoke to agreed that the file should have a monotonic time coordinate and will raise the issue with their developers.
Ok. Thanks!
Gregory Turner Chief Architect
i4 Insight, Inc.
cell: +1.720.335.1744 greg.turner@i4-insight.commailto:greg.turner@i4-insight.com
A member of the Lloyd’s Register Group
From: Guy Griffiths notifications@github.com Sent: Wednesday, February 6, 2019 2:49 AM To: Reading-eScience-Centre/edal-java edal-java@noreply.github.com Cc: Greg Turner greg.turner@i4-insight.com; State change state_change@noreply.github.com Subject: Re: [Reading-eScience-Centre/edal-java] ECMWF error - Coordinate values must increase or decrease monotonically (#114)
FYI, I've spoken to ECMWF and they suggested that if you retrieve the analyses and the forecasts separately then this issue won't occur. However, the person I spoke to agreed that the file should have a monotonic time coordinate and will raise the issue with their developers.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/Reading-eScience-Centre/edal-java/issues/114#issuecomment-460961699, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ApVpH2hS5TSC4LMVhTnq8Bx-Sk-Z7fY_ks5vKqUOgaJpZM4aCV0D.
Hi, I just downloaded the latest ncWMS server (2.4.1)...just ran it with java to test it. All ECMWF files I try get this error (java.lang.IllegalArgumentException: Coordinate values must increase or decrease monotonically). These files load up into geoserver with no problem. However, geoserver has a bug in rendering wind vectors or barbs at global scale with wrapx so I cant use it. Is there something I need to configure to get ncWMS to work with the ECMWF files out of the box? Or some transform to get them to work? I can certainly post a file but they are 150MB in size. I ran a compliance checker and got 1 error as follows: Checking variable: mwd
ERROR (3.1): Invalid units: Degree true
I can live without that layer, but would that cause this java error? This is data and not a coordinate. Greg