Iain, adding new features to GeoTools is a question for the geotools-devel list. A descriptive title is essential to attract attention. Something like: "Support multidimensional NetCDF coordinate variables".
Kind regards, Ben. On 20/06/16 09:40, Iain Matcham wrote: > Hi Ben, > > The plot thickens! > > Firstly thanks for that run-down. Glad to see that I am not the only > one struggling with the CF-convention > > Secondly, after reading your email and more reading of the convention > (and not doing it late on a Sunday night) I realise what you probably > knew from the start that what I have is not rotated-pole at all, but > multidimensional NetCDF coordinate variables (ala the link you supplied > and also > http://cfconventions.org/cf-conventions/cf-conventions.html#_two_dimensional_latitude_longitude_coordinate_variables > ) which as your have confirmed aren't supported. > > So I guess we're back to the first question which is is there interest > in supporting these and/or any reason political or otherwise that I > shouldn't dive in and try and make gt-netcdf support them? > > Thanks! > > Iain > > > On 20/06/2016 12:21 a.m., Ben Caradoc-Davies wrote: >> Iain, >> >> the GeoTools NetCDF reader does not support multidimensional NetCDF >> coordinate variables. You can use one-dimensional rlon and rlat like >> these here (lon/lat are ignored): >> http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/build/ch05s06.html >> >> >> Support was merged onto master and 15.x ten days ago (GEOT-5428 as you >> noted): >> https://github.com/geotools/geotools/pull/1205 >> >> Now the tricky question (and developer rant): >> >> Is this for the northern or southern hemisphere? If northern, stop >> here, and enjoy the working implementation. >> >> The GeoTools NetCDF reader CF rotated pole implementation does not >> support grid origins in the southern hemisphere because the CF >> attribute used for the third rotation angle is poorly defined and not >> even implemented in, for example, NetCDF-Java projections. >> >> Without a well-defined third angle, the CF rotated pole is ambiguous. >> A grid with origin at longitude -106 degrees East and latitude 54 >> degrees North is a CF rotated pole grid with north pole at longitude >> 74 degrees East and latitude 36 degrees North. Unfortunately, so is a >> grid with origin at 74 degrees East and -54 degrees North. How can any >> client consuming NetCDF files resolve this ambiguity when all it has >> is the north pole? >> >> See the Rotated Pole section: >> http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/build/apf.html >> >> >> ****** >> >> Map parameters: >> >> grid_north_pole_latitude >> >> grid_north_pole_longitude >> >> north_pole_grid_longitude - This parameter is option (default >> is 0). >> >> ****** >> >> That is all the documentation there is. We have to guess the rotation >> order, but are not even told the rotation sense of the last angle. The >> name does not make sense to me. I have never seen it used. Reading >> that documentation, would you know what to include in a southern >> hemisphere CF rotated pole NetCDF file? >> >> Now see, for example, the lack of support for a third angle in the >> NetCDF-Java RotatedPole class: >> https://github.com/Unidata/thredds/blob/master/cdm/src/main/java/ucar/unidata/geoloc/projection/RotatedPole.java >> >> >> Thirdly note that the author of this class is also an author of the CF >> Conventions. >> >> This poor definition even causes unresolved confusion on the mailing >> list for the CF maintainers (the aforementioned author seeking >> information on even the first two angles): >> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2012/055525.html >> >> To get southern hemisphere CF rotated pole support in the GeoTools >> NetCDF reader requires an attribute to define the third angle of >> rotation. This attribute needs to be defined with both documentation >> and examples, not to mention widely used by implementations. >> >> Note that the GeoTools RotatedPole implementation does not suffer from >> these problems because it defines the projection in terms of the >> latitude and longitude of the origin, not the north pole: >> https://github.com/geotools/geotools/blob/master/modules/library/referencing/src/main/java/org/geotools/referencing/operation/projection/RotatedPole.java >> >> >> This does not help resolve the ambiguity in the CF conventions. I wish >> CF would drop the north pole representation of rotated pole and >> support a grid origin representation, that is, the same projection >> specified with the grid origin latitude/longitude and an implied third >> rotation angle of zero (or show me one use case where is it not zero). >> In my opinion, the GeoTools RotatedPole implementation does it right >> by choosing this representation. >> >> Kind regards, >> Ben. >> >> On 19/06/16 22:42, Iain Matcham wrote: >>> Just found [GEOT-5428] Support NetCDF rotated pole projection... I think >>> this answers my question. Thanks >>> >>> >>> On 19/06/2016 10:11 p.m., Iain Matcham wrote: >>>> Hi all >>>> >>>> We've got a bunch of netcdf files that we are trying to read with >>>> geotools following the instructions here: >>>> http://docs.geotools.org/latest/userguide/library/coverage/multidim.html >>>> >>>> >>>> Most of the files cause an exception in the NetCDFReader constructor >>>> (java.lang.IllegalStateException: Unable to create envelope for this >>>> dataset). We have tracked this down to the netCDF files using a >>>> rotated >>>> grid instead of a cartesian grid. The upshot of this is that the files >>>> define lat/lon as a secondary lookup (2-d) instead of as a linear (1-d) >>>> variable. However NetCDFGeoreferenceManager reports these as >>>> "unsupported axes", with the result being that NetCDFReader finds no >>>> lat/lon axis and throws the above exception. >>>> >>>> I'm assuming that this is by design but wondered if am I missing >>>> something obvious? >>>> >>>> Assuming that I am not, the methodology of creating a rotated grid >>>> appears to conform to the CF-convention specs and we have examples of >>>> these files from at least two different software origins - all of which >>>> implies that they are being created correctly to spec. Bearing this in >>>> mind is there any interest if we were to extend gt-netcdf to handle >>>> these files? And/or is there a good reason why we shouldn't try to do >>>> this that anyone knows of? >>>> >>>> Thanks :) >>>> >>>> Iain >> > -- Ben Caradoc-Davies <[email protected]> Director Transient Software Limited <http://transient.nz/> New Zealand ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohomanageengine _______________________________________________ GeoTools-GT2-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
