Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
I think you could do what you want just using netcdf-java. Don On 8/13/14 10:26 AM, Jon Blower wrote:
Hi James, I understand not wanting too many 3rd-party dependencies, but time handling is tricky and you will just end up finding the same issues as everyone else has found. Unless your data have very specific metadata that meets your code’s expectations, you will sooner or later find that a perfectly CF-compliant file doesn’t work with your code. This is the trade-off I guess! ;-) A few comments on your code: 1. It relies on the time variable being called “time”. The correct way (for the CF conventions) to identify a time variable is to look at its units. (Alternatively the NetCDF-Java libraries can do this for you, I think). 2. It doesn’t appear to parse the units string correctly, assuming that the units string is UDUNITS-compliant. Maybe it’s pseudocode though, in which case fine. 3. It would only work for Gregorian dates, no other calendar systems. 4. No time zone support, as you point out (By the way, if it makes you feel any better, the ncWMS code is mature and has been used for years without change, so it would seem to work OK. If you didn’t want the whole JAR, you could just factor out the classes you need, or cannibalise the code. It’s all open source.) Cheers, Jon -- Dr Jon Blower, Technical Director, Reading e-Science Centre, MELODIES project coordinator, School of Mathematical and Physical Sciences, University of Reading Tel: +44 118 378 5213 Email: j.d.blower@xxxxxxxxxxxxx <mailto:j.d.blower@xxxxxxxxxxxxx> On 13 Aug 2014, at 15:41, James Adams - NOAA Affiliate <james.adams@xxxxxxxx <mailto:james.adams@xxxxxxxx>> wrote:Thanks for your help, Jon. I'm reticent to cook third-party JAR dependencies into my code for a number of reasons if I can avoid it. It's looking like there's no real best practice for this sort of thing and everyone just rolls their own, so maybe I should just follow suit? The NetCDF-Java API is all over the place, at least based on what I can see in the Javadoc. (For example there's a CalendarDateUnit class with no constructor and flotsam comments from you and Bob Simon included within the main description section -- is this class useful at all or recommended?) For now the below is what I've cooked up -- does this look reasonable? It seems less than bulletproof (for example how do you best account for time zone, etc.?) but maybe it's good enough for now, this code isn't going to be part of a nuclear reactor control system. ;) Variable timeCoordinateVariable = netcdfDataset.findVariable("time"); String timeUnits = timeCoordinateVariable.findAttribute("units").toString(); ArrayInt timeArray = (ArrayInt) timeCoordinateVariable.read(); DateUnit dateUnit = new DateUnit(timeUnits); Date initialDate = dateUnit.makeDate(timeArray.getInt(0)); DateTime initialDateTime = new DateTime(initialDate.getTime(), GregorianChronology.getInstanceUTC()); int initialYear = dateTime.getYear(); --James On Wed, Aug 13, 2014 at 3:02 AM, Jon Blower <j.d.blower@xxxxxxxxxxxxx <mailto:j.d.blower@xxxxxxxxxxxxx>> wrote: Hi James, The ncWMS libraries contain some high-level calls that might help here. The uk.ac.rdg.resc.edal.cdm.CdmUtils class is the one you want: NetcdfDataset nc = NetcdfDataset.open(“/path/to/my/netcdf/file”); GridDatatype grid = CdmUtils.getGridDatatype(nc, “myvar”); CoverageMetadata cm = CdmUtils.readCoverageMetadata(grid); List<DateTime> dateTimes = cm.getTimeValues(); This gives a list of all the DateTime objects (these are from the joda-time library) in the time axis of the variable “myvar”. They will be referenced to a given Chronology (i.e. calendar system), which you can find through cm.getChronology(). The main snag is that your variable has to be fully georeferenced, otherwise readCoverageMetadata() won’t work. A common problem here is that the vertical axis isn’t always well defined in NetCDF files. If you’re interested in this solution you can build a jar containing the above code: svn checkout svn://svn.code.sf.net/p/ncwms/code/trunk <http://svn.code.sf.net/p/ncwms/code/trunk> ncwms cd ncwms ant jar-for-THREDDS Hope this helps, Jon -- Dr Jon Blower, Technical Director, Reading e-Science Centre, MELODIES project coordinator, School of Mathematical and Physical Sciences, University of Reading Tel: +44 118 378 5213 <tel:%2B44%20118%20378%205213> Email: j.d.blower@xxxxxxxxxxxxx <mailto:j.d.blower@xxxxxxxxxxxxx>_______________________________________________ netcdf-java mailing list netcdf-java@xxxxxxxxxxxxxxxx For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
-- Don Murray NOAA/ESRL/PSD and CU-CIRES 303-497-3596 http://www.esrl.noaa.gov/psd/people/don.murray/
netcdf-java archives: