[gdal-dev] NetCDF and datum handling suggestion

[Etienne Tourigny]

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
>