[gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

[Andre Vautour]

On 2015-04-16 07:08, Even Rouault wrote:
> Le mercredi 15 avril 2015 22:48:45, Even Rouault a écrit :
>>> The way I see it, there are two different ways to model Google Mercator:
>>> 1. As a WGS84 datum/ellipsoid with a custom Mercator-based projection
>>> which uses only the semi-major axis, as seems to be currently done in
>>> EPSG: http://epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::3857
>>> 2. As the Google spheroid with Mercator 1SP and no transformation when
>>> going to WGS 84.
>>>
>>> I don't think #1 is currently an option given the list of coordinate
>>> transformation codes available in the GeoTIFF specification.
>> Right, there's no such coordinate transformation for GeoTIFF
> Thinking a bit more about this issue, a dedicated coordinate transformation
> would be the cleanest way, both in GeoTIFF and proj.4 (or a flag in proj.4 to
> indicate that the spherical version of the projection method, if it exists and
> that's the case for mercator, must be used even if the ellipsoid definition is
> not spherical)
> The fact that we manage currently to do WebMercator with proj.4 is due to
> WebMercator being based on WGS84 datum, and WGS84 being the "pivot" datum used
> by proj.4 when doing datum transformations. The +nadgrids=@null basically
> means that the transform from the datum defined with ellipsoid parameters
> +a=6378137 +b=6378137 and grid @null to datum WGS84 is the identity (for that
> part the values of +a and +b are completely ignored. They are only used when
> going from (long,lat) to (x,y)).
> If we ever wanted to do spherical mercator on another datum than WGS84,
> there's currently no way to express that with proj.4 (except through a grid
> from the datum to WGS84 perhaps)
>
> All that said, that doesn't really help me solving my issue, but makes me
> believe that with what currently exists in the GeoTIFF spec, there's no clean
> to express WebMercator.
> - ProjectedCSTypeGeoKey = 3857 is probably the best one, although it is an
> extension of the original GeoTIFF spec, and that isn't understood properly by
> some readers
> - All formulations that try to expand the definition with ProjCoordTransGeoKey
> =  CT_Mercator, its projection parameters and GCS parameters aren't really
> appropriate, since there's no way of capturing that its a spherical mercator
> that must be used.
Well, I agree that most readers probably won't be able to handle it, 
that being said, if the de facto convention is to fall-back to EPSG for 
codes that are not understood, setting that key might be your best option.

Setting the ProjCoordTransGeoKey to 1024 as well might be a good idea 
(with WGS 84 as the ellipsoid). The EPSG operation methods, which 
currently fall in the [1000-10000] range, are in the range of the 
supported transformation codes:

6.3.3.3 Coordinate Transformation Codes
Ranges:
    0 = undefined
    [    1, 16383] = GeoTIFF Coordinate Transformation codes
    [16384, 32766] = Reserved by GeoTIFF
    32767          = user-defined
    [32768, 65535] = Private User Implementations

That is, fallback to an EPSG code for the projection if the projection 
does not map to one that is defined in the specification. Of course, 
current readers probably will not handle it correctly. Then again, I 
cannot see how any readers other than the ones who lookup the 
ProjectedCSTypeGeoKey in the EPSG registry could realistically work 
correctly at the moment.

Based on the outcome of 
http://lists.osgeo.org/pipermail/gdal-dev/2015-April/041532.html, WKT 
readers should be able to handle a WKT string with a projection that is 
named "Popular Visualisation Pseudo Mercator" if they do in fact support 
it, so the WKT string for 3857 could also be updated to be modeled the 
same way.

>
>>> For #2, I would think/hope that if you specified the identity
>>> 7-parameter transformation in the GeoTIFF header, ArcGIS would properly
>>> reproject the image:
>> Hum, this will not work I'm afraid. See my response to Dmitry's to see why
>> +towgs84=0,0,0,0,0,0,0 is not appropriate.
>> (Plus the fact that the +towgs84 in geotiff is probably not very widely
>> supported.)
Right, from some reason, I my mind towgs84=0,0,0,0,0,0,0 was the 
identity transformation yesterday as I wrote my reply, but obviously it 
still would need to go to/from geocentric which would cause problems.

André