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