[gdal-dev] NetCDF and datum handling suggestion

Even Rouault even.rouault at mines-paris.org
Wed Sep 7 15:54:59 EDT 2011


> 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


More information about the gdal-dev mailing list