I'd like to process some netCDF 4 files with arcpy (ArcGIS 10.3.1). The original data comes from NCEP/NCAR project and contains wind vectors (uwnd/vwnd) for world-wide points (lon/lat) at certain time stamps. The dimension "time" is given as relative time in
hours since 1800年01月01日 00:00:0.0
If I have a look at the data with CDO (Climate Data Operators), the first four time stamps of the uwnd.10m.gauss.2016.nc are the following:
cdo sinfo uwnd.10m.gauss.2016.nc
2016年01月01日 00:00:00
2016年01月01日 06:00:00
2016年01月01日 12:00:00
2016年01月01日 18:00:00
...
Unfortunately arcpy has a problem understanding the relative time stamp and the following code
inNetCDF = r"\C:\temp\uwnd.10m.gauss.2016.nc"
ncFP = arcpy.NetCDFFileProperties(inNetCDF)
ncDim = ncFP.getDimensions()
for dim in ncDim:
print "%s (%s)" % (dim, ncFP.getFieldType(dim))
top = ncFP.getDimensionSize(dim)
for i in range(0,top):
print ncFP.getDimensionValue(dim,i)
delivers this as output for the dimension "time":
07.03.1800 17:50:24
07.03.1800 17:50:42
07.03.1800 17:51:00
07.03.1800 17:51:18
...
So instead of one time stamp every 6 hours ArcGIS calculates one time stamp every 18 seconds?!
It's not a big problem to recalculate the correct date within python, but I was wondering if there is a parameter I can set so that arcpy delivers directly the correct date and time. I've had the same problem with wrong date and time by using the MakeNetCDFFeatureLayer toolbox tool directly within ArcMap, and there I can't do any python calculations.
-
I cannot test this but it looks like an easy one to submit to Esri support as a suspected bug. Have you done so? If they verify it and give you a bug number, can you then write up a brief answer on the outcome, please?PolyGeo– PolyGeo ♦2016年09月26日 22:34:17 +00:00Commented Sep 26, 2016 at 22:34
-
After a few days without any response from this forum I've had the suspision that it might be a bug, so I've already reported this to ESRI support. I will post the answer as soon as I'll receive it...ateko– ateko2016年09月27日 06:00:39 +00:00Commented Sep 27, 2016 at 6:00
-
I recommend not thinking of this site as being a forum because its focussed Q&A format is very different and I think far superior to what discussion forums offer. Some users take a while to appreciate the difference but once you get it, the site and its protocols make a lot more sense. The lack of response on this question reflects the tiny percentage of NetCDF users and questions we see (201/73,607 = 0.27%).PolyGeo– PolyGeo ♦2016年09月27日 06:11:45 +00:00Commented Sep 27, 2016 at 6:11
-
Sorry for naming this a forum - I'm aware of the differences but as a non-native english speaker I've had no better name for it.ateko– ateko2016年09月28日 05:48:42 +00:00Commented Sep 28, 2016 at 5:48
1 Answer 1
From ESRI I received the answer that this has been a bug in 10.3.1 for operating systems that have a comma as decimal seperator (like in Germany). If changing the decimal seperator from comma to point everything works fine. In Version 10.4.1 the time stamps will be calculated correctly.
Explore related questions
See similar questions with these tags.