[gdal-dev] Patch for GDAL Web Mercator Issue / trac 3962

[Even Rouault]

Hi Michael,

My main question is : how sure are we about the projection name 
"Mercator_Auxiliary_Sphere" to be the appropriate one for "standard" WKT ? Is 
there some reference from that ? The fact that ESRI uses it doesn't make it 
necesserarily a standard (although it can serve as a base if there's no 
alternative).

I did a quick search, and in the Java world, I've found :
- GeoTools ( 
http://docs.geotools.org/latest/userguide/library/referencing/crs.html ) : 
also seems to use Mercator_1SP (but the example is the hackish 900913). 
* GeoToolkit, fork of GeoTools, would also use Mercator_1SP ( 
http://www.geotoolkit.org/modules/referencing/faq.html#Google )
- GeoServer ( according to a openlayer doc at 
http://trac.osgeo.org/openlayers/wiki/SphericalMercator ) would use 
"Mercator_1SP_Google". Seem to be confirmed by 
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geotools/referencing/operation/projection/Mercator1SPGoogle.java  
, but the comment in the file suggests this custom projection is no longer used 
and that it now relies on GeoTools support, hence Mercator_1SP.

Perhaps the issue could be pushed to some generalist list, like 
standards at list.osgeo.org and/or metacrs at lists.osgeo.org lists to see if 
there's some concencus on the appropriate WKT for EPSG:3857

You mention that "applications which depend on the WKT (e.g. MrSID) to expose 
the SRS will see improved recognition". But which format are you refering too 
? There are not so many raster formats where you encode WKT itself.

Best regards,

Even

Le jeudi 29 août 2013 19:37:42, Michael Rosen a écrit :
> A long standing (2011) issue with GDAL's CRS support is its awkward support
> for the Web Mercator projection.  In short, when gdal internally
> represents this CRS (EPSG code 3857), it does so using the Mercator_1SP
> projection on the WGS84 datum (not a sphere).  Since that's not quite
> right, it provides the right math to Proj4 via an "Extension."  Some
> widely used GIS applications won't recognize the resulting output  as Web
> Mercator leading to projection / alignment problems. 
> http://trac.osgeo.org/gdal/ticket/3962 describes the issue more fully.
> 
> I've submitted a patch (attached to above ticket) that implements proper
> support for this very widely used projection.  It's seen limited testing
> here at LizardTech and I can confirm that both ERDAS and ArcGIS (and QGIS,
> but I think they were ok to begin with) recognize the resulting
> representation.  We at LT discussed this internally and decided that
> because it is a fairly wide-reaching change, we would provide the patch
> but not to commit it ourselves -- at least not without some discussion
> from the community.
> 
> I should say that the extent of the change is mostly confined to the way it
> creates a WKT representing Web Mercator.  In particular, it does not
> change the way the tiff driver writes tags.  I think the current
> implementation is non-standard (*) but has the weight of history on its
> side, so I left that alone.  However, the change does read (non-standard)
> tif files that say "epsg 3857" as Web Mercator.
> 
> (*) Perhaps necessarily non-standard.  AFAICT, there is  no
> standard-compliant way to represent this in GeoTiff.  the specification
> seems to preclude referencing an EPSG code outside the range of 20000 –
> 32760.  Note that the existing implementation in libGeoTiff writes ‘3857’
> in the ProjectedCSTypeGeoKey and notes it is ‘unknown.’  It appears that
> everyone just assumes that if there’s an epsg code there then it must be
> authoritative.
> 
> 
> msr
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html