[WCS.swg] [gdal-dev] NetCDF and datum handling suggestion

Thu Sep 8 09:36:57 EDT 2011

Matt,

interesting discussions going on indeed. My perspective, having to model CRS request parameters for transformation etc and to establish a CRS URL resolver, is to understand a sufficiently general slate of concepts. Some of the issues of representation do not directly apply for my task (my - possibly wrong - understanding is that it also addresses redundant short-hand information), however this still is interesting for me in the sense that I can get the gist of CRS handling in the communities' practice.

-Peter

________________________________________
From: wcs.swg-bounces+p.baumann=jacobs-university.de at lists.opengeospatial.org [wcs.swg-bounces+p.baumann=jacobs-university.de at lists.opengeospatial.org] on behalf of Matthew Austin [Matthew.Austin at noaa.gov]
Sent: Thursday, September 08, 2011 3:20 PM
To: wcs.swg at lists.opengeospatial.org; cf-metadata at cgd.ucar.edu; gdal-dev at lists.osgeo.org
Subject: Re: [WCS.swg] [gdal-dev] NetCDF and datum handling suggestion

Peter,

There has been much discussion about projections in the CF-Community
recently.  I'm following up with Etienne's recommendation to engage the
CF-Community in this discussion of how to handle projection information
in CF.

Matt

On 9/8/2011 2:17 AM, Peter Baumann wrote:
> Hi WCSers,
>
> this is to inform you about some interesting discussion going on in
> the GDAL community. It directly relates to our current work on
> redesigning OGC's CRS handling for coverages (and beyond).
>
> cheers,
> Peter
>
>
> On 09/07/2011 10:49 PM, Etienne Tourigny wrote:
>> Thanks for the info Even
>>
>> I can see that there is not yet "One standard to rule them all"...
>> Correct me if I am wrong: is WKT the preferred way GDAL stores the
>> information?
>>
>> There was a proposal some time ago in the CF trac to add descriptive
>> variables such as crs_id (EPSG code),  crs_name and crs_wkt.
>> https://cf-pcmdi.llnl.gov/trac/ticket/18 (pointed out by Patrick)
>> https://cf-pcmdi.llnl.gov/trac/ticket/9
>> https://cf-pcmdi.llnl.gov/trac/ticket/27
>>
>> However, these were dropped because of disagreement between the
>> participants and the simpler and current approach was adopted (specify
>> the numeric values of the projection and datum).
>> Unfortunately, the issue has not been discussed since.
>>
>>
>> I think our solution should address the following
>>
>> 1) Storing projection and datum in the netcdf file with 100% CF
>> compliance.
>> 2) Storing complete information so that it can be retrieved later by
>> GDAL, This is already done by writing and reading the WKT.
>> 3) Making sure that the CF and WKT are not contradictory, in the case
>> that the projection was modified by another program, but left the WKT
>> intact.
>> 4) Reading CF-compliant projection information and translating that
>> into WKT (this could eliminate the need for 2 and 3)
>>
>> Perhaps 4 can be achieved with another tool external to GDAL (as
>> suggested in the CF discussions).
>>
>>
>> Is there anyone who would be inclined to engage in a discussion within
>> the CF community so that any or all of proj4, epsg and wkt be included
>> as a CF standard?
>>
>> Regards, Etienne
>>
>> On Wed, Sep 7, 2011 at 4:54 PM, Even Rouault
>> <even.rouault at mines-paris.org>  wrote:
>>>> How important is this information?  Assuming we drop all the citation
>>>> strings, or authority names and codes, but retain the important
>>>> parameters of each projection (in CF and proj format), are we missing
>>>> anything important numerically?
>>>>
>>>> In other words, are there any show-stopper issues that would keep us
>>>> from using proj4 instead of wkt?
>>> Generally not. You indeed mentionned a significant word,
>>> "numerically", which
>>> indicates that you are interested more in the information for
>>> reprojection
>>> purposes, than strict (not to say pedantic ;-)) identification of
>>> the SRS. If
>>> the software that process the dataset all use proj4 and the proj4
>>> string is an
>>> adequate representation of the SRS, then it is a perfect fit.
>>>
>>> There are situations where 2 distincts SRS from the EPSG database will
>>> translate into identical proj4 string. For example, just looking at
>>> the very
>>> beginning of the epsg file provided with proj4, I can see :
>>>
>>> # TWD97
>>> <3824>  +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs<>
>>>
>>> # IGRS
>>> <3889>  +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs<>
>>>
>>> The corresponding WKT (given by using gdal utility 'testepsg
>>> EPSG:XXXX') are :
>>>
>>> GEOGCS["TWD97",
>>>     DATUM["Taiwan_Datum_1997",
>>>         SPHEROID["GRS 1980",6378137,298.257222101,
>>>             AUTHORITY["EPSG","7019"]],
>>>         TOWGS84[0,0,0,0,0,0,0],
>>>         AUTHORITY["EPSG","1026"]],
>>>     PRIMEM["Greenwich",0,
>>>         AUTHORITY["EPSG","8901"]],
>>>     UNIT["degree",0.0174532925199433,
>>>         AUTHORITY["EPSG","9122"]],
>>>     AUTHORITY["EPSG","3824"]]
>>>
>>> GEOGCS["IGRS",
>>>     DATUM["Iraqi_Geospatial_Reference_System",
>>>         SPHEROID["GRS 1980",6378137,298.257222101,
>>>             AUTHORITY["EPSG","7019"]],
>>>         TOWGS84[0,0,0,0,0,0,0],
>>>         AUTHORITY["EPSG","1029"]],
>>>     PRIMEM["Greenwich",0,
>>>         AUTHORITY["EPSG","8901"]],
>>>     UNIT["degree",0.0174532925199433,
>>>         AUTHORITY["EPSG","9122"]],
>>>     AUTHORITY["EPSG","3889"]]
>>>
>>> Are the Taiwan_Datum_1997 and Iraqi_Geospatial_Reference_System
>>> really the
>>> same, or is it because we haven't captured the difference, or it is
>>> too subtle
>>> to be modelled with proj4, or it would require some grids that are not
>>> available, etc... I have no idea.
>>>
>>> Also you should be aware that some SRS have no translation into
>>> proj4 strings
>>> due to unsupported projection methods for example.
>>>
>>> Using proj4 strings is not a total heresy however. Postgis is a
>>> famous and
>>> widespread example of the use of proj4 strings. Although in the
>>> Postgis case,
>>> the spatial_ref_sys table includes authority names and code columns,
>>> and the
>>> SRID is used as a key in the geometry_columns table. So you can fix
>>> proj4
>>> strings in a centralized way if needed.
>>>
>>> Another point to have in mind is that the proj4 strings (at least
>>> the ones
>>> provided in the epsg file that comes with proj4) are generally
>>> derived from the
>>> EPSG database, and there can be imperfections in the way they are
>>> translated,
>>> or later improvements. A recent proj4 change has added for example
>>> TOWGS84
>>> statements in a lot of cases where they were missing before.
>>>
>>> You can look at the following page which gives details on how GDAL,
>>> proj4,
>>> libtiff and postgis SRS databases are built from the EPSG database :
>>>
>>> http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/README
>>>
>>> Some could also say that proj4 strings are not a very formal
>>> definition, and
>>> that WKT has a better potential to act as a standard. However, reading
>>> http://home.gdal.org/projects/opengis/wktproblems.html might be
>>> enlightning.
>>> (Note : apparently the page has been written quite some time ago,
>>> and some
>>> statements do no longer apply, for example the one about PostGIS.
>>> PostGIS has
>>> used proj4 strings and not WKT for a long time. But most of the rest
>>> still
>>> apply however.)
>>>
>>> Not sure to really have helped you. There are issues with either
>>> using WKT or
>>> proj4 strings.
>>>
>>>
>>>> _______________________________________________
>>>> gdal-dev mailing list
>>>> gdal-dev at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
_______________________________________________
WCS.swg mailing list
WCS.swg at lists.opengeospatial.org
https://lists.opengeospatial.org/mailman/listinfo/wcs.swg