[gdal-dev] NetCDF and datum handling suggestion

Tue Sep 6 20:10:08 EDT 2011

On Tue, Sep 6, 2011 at 8:31 PM, Patrick Sunter <patdevelop at gmail.com> wrote:

> On Mon, Sep 5, 2011 at 11:23 PM, Etienne Tourigny
> <etiennesky.dev at gmail.com> wrote:
> > Patrick,
> >
> > A)
> > your suggestion does make sense, it is imperial that basic datum
> > information be saved as to adhere to CF-x standard.   Are those CF
> > variables (radius, flattening etc) really sufficient for software such
> > as THREDDS?
>
> Yes, tests I did showed it was able to project correctly after adding
> these (whereas beforehand the WMS layers were "off" - presumably TDS
> assumes a spherical earth by default).
>

good

>
> The datum attributes are highlighted in color at CF conventions
> website, in the table at the end of the page:
> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/apf.html
>
> >
> > B)
> > The other aspect (to save projection_ref so that GDAL can import it)
> > also makes sense, however I have the following concern:
> >
> > If another software changes the datum and or projection information of
> > a netcdf file created by GDAL, but keeps the GDAL 'spatial_ref' tag
> > intact, then GDAL would import the wrong projection.  I don't think
> > that this should happen, as a program would be expected to write a new
> > grid_mapping variable, without the GDAL tags.
> >
> > Can you think of possible software which does this and make a test?  I
> > can only think of CDO, and I do know that it discards anything from a
> > previous projection definition.
>
> I can't think of any software that does this off the top of my head
> either ... though we've been looking into a NetCDF driver for the
> Geotoolkit project, which may be able to reproject existing NetCDF
> datasets.
>
> In any case GDAL should probably print a warning if the 2 get 'out of
> sync' when it imports?
>

How could we know if it is 'out of sync'?  My feeling is that it's ok to
assume that any software that messes with the projection info will delete
any custom tags, but still safer to use as much standard information as
possible, and stay away from GDAL tags when possible.

> >
> > C)
> > With that concern in mind,I was wondering if we can do one of the
> > following instead:
> >
> > 1) import the standard CF variables and guess the WKT from that
> > 2) just be content with the basic DATUM values from the CF variables
> >
> > for example, here is what a wkt looks like when importing a CF netcdf
> > file wich a WGS84 datum:
> >
> > GEOGCS["unknown",
> >    DATUM["unknown",
> >        SPHEROID["Spheroid",6378137,298.257223563]],
> >    PRIMEM["Greenwich",0],
> >    UNIT["degree",0.0174532925199433]]
> >
> > and here is the full WGS84 WKT generated by GDAL
> >
> > GEOGCS["WGS 84",
> >    DATUM["WGS_1984",
> >        SPHEROID["WGS 84",6378137,298.257223563,
> >            AUTHORITY["EPSG","7030"]],
> >        AUTHORITY["EPSG","6326"]],
> >    PRIMEM["Greenwich",0],
> >    UNIT["degree",0.0174532925199433],
> >    AUTHORITY["EPSG","4326"]]
> >
> >
> > As you can see, the important values are there, but there are no
> > descriptive names and EPSG authority.  This is not strictly identified
> > as WGS84 EPSG datum, but the important stuff is there.
> >
>
> I thought about this too ... it does seem a bit concerning though to
> try and recognise the named datums from the values - possibly you'd
> have issues of the accuracy they are stored at determining whether
> GDAL could recognise them correctly or not?
>
> I've heard there may be a 'dynamic datum' in development that has its
> values adjusted more frequently - in this case referencing a standard
> name would likely be necessary.
>
> Having checked the GDAL NetCDF format page though, it does check the
> CF encoded projection before it's own WKT, so it'd be good if we could
> consistently use CF as first reference for the datum too.
>
>
agreed, I propose we stay away from WKT/PROJ.4  when a suitable CF
representation exists, and if not fall back to WKT / PROJ.4 - unless it
becomes a standard in later CF conventions, which could take time IMHO.

>
> > D)
> > I doubt that the CF conventions have plans to support PROJ.4/WKT in
> > the near future.  Have a look at the draft for CF-1.6, nothing new
> > about PROJ.4 or WKT :
> >
> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#grid-mappings-and-projections
> >
> > However, I would suggest to discuss this on the CF mailing list. They
> > might be receptive, as they already make references to PROJ.4 in their
> > projection definitions. BUT it would be better in this case to use
> > PROJ.4 strings instead of WKT, as (I think) that PROJ.4 strings are
> > better supported than WKT (including Proj.4 itself).  For example, the
> > folks that work on CDO have plans to support PROJ.4 strings, but now
> > WKT.
>
> Thanks, I'll need to read up a bit more on Proj.4 strings but sounds
> like it could be a good way to go.
>
> I just had a bit more of a look around the CF webpages and they did
> consider putting more CRS information in the specs, e.g. a "crs_id"
> attribute that could contain an EPSG code, but it didn't make it
> through as yet:
> https://cf-pcmdi.llnl.gov/trac/wiki/GridMappingAndCrs
> https://cf-pcmdi.llnl.gov/trac/ticket/18
>
> So yes discussing this on their mailing list again sounds like a good idea.
>

It would be nice to revive the discussion, as it seems to have stalled a few
years ago.

I am honestly a little too busy to devote time to initiate this discussion
in a concise manner, could you take care of that? I also feel your knowledge
of the different projections is better than mine. I would like to take part,
though.

> >
> > Am I correct in thinking that GDAL could output a PROJ.4 string and
> > import it in the same manner that it currently does with WKT?
>
> Not sure - clearly you can specify Proj4 from the command line to
> commands, but not sure you can ask it to store this, will do some
> checking.
>

In case you feel like testing it, the functions needed are
 OGRSpatialReference::importFromProj4() and exportToProj4(), the later which
is not documented.

Perhaps others can comment on the suitability of exporttoProj4() ???

Regards, Etiene

>
> >
> > BTW, there is a "CF-NetCDF 1.0 Standards Working Group" part of OGC,
> > perhaps we can discuss with someone from that group?
> > http://www.opengeospatial.org/projects/groups/cf-netcdf1.0swg
>
> Yes, sounds like a good idea.
>
> We actually read through the OGC standards on NetCDF recently, the
> basic standard already accepted really just in a nutshell states that
> 'netCDF is a valid file format for use in OGC services'.  They are
> aiming to define 'extensions' to cover things like recommended use of
> CF, so this could be good.
>
> cheers, Patrick.
>
> >
> > Regards,
> > Etienne
> >
> >
> >
> > On Mon, Sep 5, 2011 at 6:40 AM, Patrick Sunter <patdevelop at gmail.com>
> wrote:
> >> Hi Etienne and others interested in NetCDF driver,
> >>
> >> I did some work on WMS display of NetCDF files generated by GDAL
> >> today, and it gave me a chance to play around with & think about how
> >> to handle the Datum issue as described at
> >> http://trac.osgeo.org/gdal/wiki/NetCDF_Improvements#Datumissues .
> >>
> >> Here's a first cut suggestion of how GDAL should behave when writing a
> >> new NetCDF file using gdal_translate:
> >>  * Keep saving the current datum info, with names e.g. WGS84, as part
> >> of the WKT that GDAL saves in it's special "spatial_ref" attribute.
> >>  * But _also_ save the actual spheroid parameters for the datum in use
> >> in attributes CF-1 can read, e.g. semi_major_axis, semi_minor_axis,
> >> and inverse_flattening.
> >>
> >> Then on import, GDAL would look for its "spatial_ref" by default as
> >> authoritative for datum info, but could use the CF-1 as a backup.
> >>
> >> This would parallel the way projection parameters are handled in the
> >> NetCDF driver, i.e. writing WKT in the 'spatial_ref' attribute, but
> >> also writes duplicate CF-1 convention ones if possible to help with
> >> display of the file in NetCDF tools and things like THREDDS.
> >>
> >> Perhaps this could be a passable option to the driver whether you
> >> write the duplicate CF-1 datum info or not, with default to on.
> >>
> >> (That is, unless the CF conventions have plan to support named datums
> >> coming up imminently?)
> >>
> >> cheers, Patrick.
> >> _______________________________________________
> >> gdal-dev mailing list
> >> gdal-dev at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110906/030eeb0e/attachment-0001.html