[gdal-dev] NetCDF and datum handling suggestion

[Etienne Tourigny]

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?

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.

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.


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.

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?

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

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
>