Projection Parameters

[tedhabermann]

This problem is described by Frank Warmerdam on the Refining GeoTIFF page.

While the original GeoTIFF Specification specification offers some example coordinate systems with projection parameters (ie. 3.1.3 Lamber Conformal Conic Aeronotical Chart), and provides a list of general projection parameters (6.2.3) it does not generally indicate what projection parameters are used for which projection methods, nor does it attempt to relate them to any other well known definitions such as EPSG. I feel it is important to collect a list of projection parameters for each support projection method, and where possible to relate them back to EPSG method and parameter codes for clarity.

To some extent I have attempted to do so at http://www.remotesensing.org/geotiff/proj_list/ in a way relate connects GeoTIFF?, PROJ.4, EPSG and OGC Well Known Text. For the purposes of the GeoTIFF? specification I would suggest we stick to offering the GeoTIFF? codes, and relating them back to EPSG while enumerating some projection methods and parameters support in GeoTIFF and not in EPSG and clarifying some situations that match poorly between GeoTIFF and EPSG.

[rouault]

Update: remotesensing.org is dead. The list can be found at http://geotiff.maptools.org/proj_list/

[max-martinez]

The recent discussion on the confusion between the documented key id for ProjFalseOriginNorthingGeoKey vs ProjCenterNorthingGeoKey is relevant here. I don't know how this has been implemented at other locations, but because of the confusion alluded to here, our implementation accepts ProjFalseOriginNorthingGeoKey whereever ProjCenterNorthingGeoKey is accepted and vice versa so it doesn't actually matter to our implementation (for a 1.0 file) if you inadvertently used the key id 3091 for ProjFalseOriginNorhingGeoKey (when you should have used 3087).

[EmDevys]

This issue has been (hopefully) fixed in revision 1.1 seee requirement http://www.opengis.net/spec/GeoTIFF/0.0/ProjLinearParameters

[rouault]

This issue has been (hopefully) fixed in revision 1.1

I don't think so. In the current state of https://github.com/opengeospatial/geotiff/blob/master/GeoTIFF_Standard/standard/requirements/Projection_Definition_Keys/requirements_class_ProjLinearParameters.adoc , it only lists the GeoKeys. This issue is much more involved. It is about binding GeoTIFF projection methods to EPSG projection methods, and for each GeoTIFF projection method, listing the relevant GeoTIFF projection parameter geokeys and binding them to their EPSG equivalent.

[EmDevys]

I'm not sure I understand what is the proposal which would clarify / solve this. Is it a mapping table? Would it make sense?

[EmDevys]

Even, Roger, and all I added the following comment under this issue : I'm not sure I understand what is the proposal which would clarify / solve this. Is it a mapping table? Would it make sense?

Any opinion or proposal to try and solve this issue?

De : Even Rouault [mailto:notifications@github.com] Envoyé : mardi 15 janvier 2019 11:42 À : opengeospatial/geotiff Cc : Emmanuel Devys; Comment Objet : Re: [opengeospatial/geotiff] Projection Parameters (#5)

This issue has been (hopefully) fixed in revision 1.1

I don't think so. In the current state of https://github.com/opengeospatial/geotiff/blob/master/GeoTIFF_Standard/standard/requirements/Projection_Definition_Keys/requirements_class_ProjLinearParameters.adoc , it only lists the GeoKeys. This issue is much more involved. It is about binding GeoTIFF projection methods to EPSG projection methods, and for each GeoTIFF projection method, listing the relevant GeoTIFF projection parameter geokeys and binding them to their EPSG equivalent.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/opengeospatial/geotiff/issues/5#issuecomment-454347041, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIZzav7Ii74ot6oHMLZZHjHYy3VJudBqks5vDbB3gaJpZM4DCPka.

[rouault]

Is it a mapping table?

Yes, for each projection method, one should list the allowed parameters, and provide their EPSG equivalent. http://geotiff.maptools.org/proj_list/ could be a starting point (note: that's based on what is implemented in libgeotiff and GDAL)

[avautour]

I agree that this is really important. The GeoTIFF issue that keeps coming back in terms of CRS is how to write a Mercator projection, to which we really need to find an unambiguous solution.

In practice, I've seen three things done for CT_Mercator.

1. Write it as Mercator (variant A) aka 1SP:

   Projection Method: CT_Mercator
   ProjNatOriginLatGeoKey: 0.000000 (  0d 0' 0.00"N)
   ProjNatOriginLongGeoKey: -71.598333 ( 71d35'54.00"W)
   ProjScaleAtNatOriginGeoKey: 0.83937032007599788
   ProjFalseEastingGeoKey: 0.000000 m
   ProjFalseNorthingGeoKey: 0.000000 m

2. Write it as Mercator (variant B) aka 2SP:

   Projection Method: CT_Mercator
   ProjNatOriginLatGeoKey: 0.000000 (  0d 0' 0.00"N)
   ProjNatOriginLongGeoKey: -71.598333 ( 71d35'54.00"W)
   ProjStdParallel1GeoKey: -33.014167 ( 33d 0'51.00"S)
   ProjFalseEastingGeoKey: 0.000000 m
   ProjFalseNorthingGeoKey: 0.000000 m

3. Write it as Mercator (variant A) aka 1SP using the Mercator (variant B) aka 2SP values:

   Projection Method: CT_Mercator
   ProjNatOriginLatGeoKey: -33.014167 ( 33d 0'51.00"S)
   ProjNatOriginLongGeoKey: -71.598333 ( 71d35'54.00"W)
   ProjScaleAtNatOriginGeoKey: 1.000000
   ProjFalseEastingGeoKey: 0.000000 m
   ProjFalseNorthingGeoKey: 0.000000 m

As it stands, ESRI writes 3, and reads 2 and 3. They do not read the ProjScaleAtNatOriginGeoKey key at all, so it can't read 1. GlobalMapper doesn't read the ProjStdParallel1GeoKey key, so it cannot read 2. QGIS/GDAL reads all 3, and writes 2.

In other words, it is a mess. Everyone is convinced that their way is the right way, and there is no definitive answer in the specification. In the wild, 3 is definitely what I see being the most supported, which is unfortunate, because it is also wrong. The latitude of natural origin is supposed to be where the false northing is applied, which is not what ESRI does, They apply the false northing at the Equator, even though the ProjNatOriginLatGeoKey is not zero. It looks like they had the 2SP values, and saw they had to write the 1SP tags, so they made it fit by incorrectly writing the ProjStdParallel1GeoKey as the ProjNatOriginLatGeoKey, instead of calculating the ProjScaleAtNatOriginGeoKey from the standard parallel to convert from their 2SP to GeoTIFF's 1SP.

This is the type of ambiguity this issue would resolve. At is stands, I consider Mercator GeoTIFF to have no interoperability, because various software packages write different things, and read a subset of those options. It has been a recurring problem for like the last 10 years.

Given how long this has been sitting here, I don't think you fully realize how much of an issue this is in practice. Please prioritize this. At the very least, clarify the tags to use for Mercator, and add two different tags, one for 1SP and one for 2SP. This makes GeoTIFF a really annoying format to use for interoperability.