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

[Even Rouault]

> > - 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. 

Hum, the issue is that the values currently defined by GeoTIFF in the [1, 
16383] range has nothing to do with the EPSG conversion methods. Your proposal 
might be reasonable, but it is AFAIK not at all a current industry practice. 
This would also imply definiing if it is allowed to use the EPSG conversion 
method when there are corresponding  existing GeoTIFF enumerated values

> 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.

True. That's more or less what GDAL does currently.

In fact, it is more complicated than that. GDAL relies on the libgeotiff 
function GTIFGetDefn() which, from the raw GeoTIFF keys and the EPSG 
dictionnaries as .csv files, tries to build a fully expanded SRS definition 
using GeoTIFF enumerations. Which explains why GDAL can write some PCS codes 
but not read a correct SRS back, because there might be no GeoTIFF projection 
method corresponding.

GDAL could (should) likely just use its importFromEPSG() method in those 
cases. Not sure why we don't do that already.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com