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

[Andre Vautour]

On 2015-04-16 12:07, Even Rouault wrote:
>>> - 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
Yeah, I was probably overreaching with that. Probably better to just 
make sure the next version of the specification has a transformation 
code available for Google Mercator as a coordinate transformation.

I just don't like having a file with information that will not transform 
correctly in the event the client does not lookup that projected CRS 
code in EPSG. Having the spheroid as the datum with the Mercator 1SP 
projection leads to way too many special cases. I'd rather have a 
projection that some readers might not understand. Seems safer and more 
explicit.

>> 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.
Trying to import from EPSG first makes a lot of sense to me.

Cheers,
André