[gdal-dev] Differences between OSRImportFromEPSG and OSRImportFromProj4

Even Rouault even.rouault at spatialys.com
Thu Feb 7 01:13:29 PST 2019


Hi Sean,

> 
> I observe a difference between the WKT exports of OSRImportFromEPSG(osr,
> 3857) and OSRImportFromProj4(osr, "+init=epsg:3857"). The former gives a
> named coordinate system, the latter gives an unnamed coordinate system.
> 
>
> Am I wrong to understand the semantics of "+init=epsg:3857" as "open the
> epsg database, get entry 3857, and use that"? Is this different from
> specifying the entry directly?

That's an case where my recent work will help reducing the confusion 
(hopefully)
In current released versions, OSRImportFromEPSG() read in the GDAL data/*.csv 
files a fully-fledged description of the geodetic object.
OSRImportromProj4("+init=epsg:XXXX") goes to PROJ which opens the $prefix/
share/proj/epsg file, identifies the PROJ string in it that corresponds to the 
code, returns it to GDAL, and GDAL reconstructs a OGRSpatialReference by 
analysing the PROJ4 string, which has no names.

With the RFC73 related work, now there's a single database. The 
+init=epsg:XXXX syntax is still supported as a legacy mechanism by PROJ, but 
it no longer opens a 'epsg' file but rather goes to the proj.db database. Note 
that for backward compatibility purposes, if you use the +init=epsg:XXXX 
syntax, PROJ will return CRS objects with possibly a non-EPSG compliant axis 
order (for example it will return longitude-latitude for geographic CRS, 
whereas EPSG mandates latitude-longitude). GDAL (with the commit I just pushed 
since the +init=epsg:XXXX case was actually broken in master) will now emit a 
warning if you use that legacy syntax.

$ gdalsrsinfo EPSG:4326 -o WKT2

GEOGCRS["WGS 84",
    DATUM["World Geodetic System 1984",
        ELLIPSOID["WGS 84",6378137,298.257223563,
            LENGTHUNIT["metre",1]]],
    PRIMEM["Greenwich",0,
        ANGLEUNIT["degree",0.0174532925199433]],
    CS[ellipsoidal,2],
        AXIS["geodetic latitude (Lat)",north,
            ORDER[1],
            ANGLEUNIT["degree",0.0174532925199433]],
        AXIS["geodetic longitude (Lon)",east,
            ORDER[2],
            ANGLEUNIT["degree",0.0174532925199433]],
    USAGE[
        SCOPE["unknown"],
        AREA["World"],
        BBOX[-90,-180,90,180]],
    ID["EPSG",4326]]

vs

$ gdalsrsinfo +init=epsg:4326 -o WKT2
Warning 1: +init=epsg:XXXX syntax is deprecated. It might return "
a CRS with a non-EPSG compliant axis order.

GEOGCRS["WGS 84",
    DATUM["World Geodetic System 1984",
        ELLIPSOID["WGS 84",6378137,298.257223563,
            LENGTHUNIT["metre",1]],
        ID["EPSG",6326]],
    PRIMEM["Greenwich",0,
        ANGLEUNIT["degree",0.0174532925199433],
        ID["EPSG",8901]],
    CS[ellipsoidal,2],
        AXIS["longitude",east,
            ORDER[1],
            ANGLEUNIT["degree",0.0174532925199433,
                ID["EPSG",9122]]],
        AXIS["latitude",north,
            ORDER[2],
            ANGLEUNIT["degree",0.0174532925199433,
                ID["EPSG",9122]]],
    USAGE[
        SCOPE["unknown"],
        AREA["World"],
        BBOX[-90,-180,90,180]]]

In the later, the axis roder is long/lat and the ID["EPSG",4326] node has been 
stripped off since the object is not conformant with EPSG.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list