[gdal-dev] Differences between OSRImportFromEPSG and OSRImportFromProj4

[Sean Gillies]

Hi Even,

On Thu, Feb 7, 2019 at 2:13 AM Even Rouault <even.rouault at spatialys.com>
wrote:

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

Thank you for the explanation and the fix. Thanks, too, for the details in
https://trac.osgeo.org/gdal/wiki/rfc73_proj6_wkt2_srsbarn#OGRCoordinateTransformationchanges
and
https://trac.osgeo.org/gdal/wiki/rfc73_proj6_wkt2_srsbarn#Axisorderissues
which make a lot of sense to me and answer all of the follow up questions
that came to my mind.

-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190207/0d018f74/attachment.html>