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é
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
