[gdal-dev] NetCDF and datum handling suggestion

[Patrick Sunter]

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).

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?

>
> 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.

>
> 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.

>
> 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.

>
> 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
>>
>