[gdal-dev] OGRSpatialReference::IsSame returning TRUE unexpectedly

Matthew Amato matt.amato at gmail.com
Tue Sep 5 17:21:17 PDT 2017


Thanks for the detailed write up and quick fix!

Just to clarify your last sentence, are you saying there are still
potential cases where IsSame returns TRUE when it shouldn't?  Or were you
just emphasizing that this is a very tricky check to get right in all
cases?  I'm just wondering if I should ditch my optimization of checking
the spatial reference and always do a reproject (via VRT) even if it
results in a no-op in some cases.  I assume the overhead of a no-op VRT is
fairly small and I'm concerned with correctness more than anything else.

Thanks again.

On Tue, Sep 5, 2017 at 5:02 PM, Even Rouault <even.rouault at spatialys.com>
wrote:

> > I assume my understanding of IsSame is flawed so any clarification would
> be
>
> > a big help.
>
> >
>
>
>
> Matt,
>
>
>
> Your understanding of IsSame() is correct. You just hit a bug. I've fixed
> it per https://trac.osgeo.org/gdal/ticket/7029. You can see the changeset
> code as a workaround to add in your own code if you need.
>
>
>
> IsSame() is a "smart" comparison, ie it tries to abstract away
> unsignificant differences like the PROJCS text value that don't participate
> really to the SRS and can vary over formats, data producers, etc... The
> issue here is that web-mercator (EPSG:3857) and WGS84-mercator (EPSG:3395)
> are represented the same way at the GEOGCS and projection levels. The only
> difference is that GDAL creates a EXTENSION["PROJ4", ...] node in the
> web-mercator case to really use the spherical definition. And IsSame()
> before my fix neglected to compare that extension node. So you were a bit
> unlucky since that must be pretty much the only pair of EPSG entries in
> that situation.
>
>
>
> My initial tought was to compare the authority codes/nodes when they exist
> on both sides, but I was wondering if there are not cases where you'd have
> the same SRS registered in 2 different catalogs. Presumably within the same
> catalog, a different code should mean a different CRS, but I'm not even
> completely sure you couldn't find oddities. I was thinking to EPSG:3857 vs
> the deprecated EPSG:3785, but this isn't a good example, since they differ
> on the DATUM. So currently IsSame() returns FALSE on that pair, although I
> guess one might consider them as equivalent (the deprecated version is just
> a buggy expression on the current EPSG:3857). Or not...
>
> You also have the situation where really different CRS (IsSame() == FALSE)
> ends up being translated the same way as proj.4 strings...
>
>
>
> So it is actually not obvious to define the semantics of IsSame(). It
> should at least return FALSE for CRS that are clearly different (coordinate
> transformation results in differences).
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170905/6ae3a2c5/attachment-0001.html>


More information about the gdal-dev mailing list