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

[Michael Rosen]

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