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 [email protected] and/or [email protected] 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Geospatial professional services http://even.rouault.free.fr/services.html _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
