Notes on suggested refinements to the GeoTIFF 1.0 specification as part of a GeoTIFF standards refinement and publication process at NASA.
While the original 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.
New Projection Methods and Projection Parameters
Since the original GeoTIFF specification a number of GeoTIFF projection methods and parameters have been added. These should also be reviewed, and if they seem reasonable and in somewhat well understood and common use they should be captured in the specification.
Relationship to Newer EPSG Releases
The original GeoTIFF specification was based on the EPSG database in release at the time. Since then the EPSG database has grown and to a limited extent been refactored. While it was not exactly clear how this related to GeoTIFF the accepted industry practice has been to accept newer EPSG PCS and GCS codes even though they are not explicitly listed in the GeoTIFF specification (ie. sections 6.3.2, 6.3.3 and 6.3.4). It is suggested that this be codified into the GeoTIFF specification. We should also likely update sections 6.3.x to reflect a current set of codes or alternatively remove them in favor of a reference to EPSG with a few examples for clarification.
PixelAsPoint vs. PixelAsArea
The original GeoTIFF specification was somewhat vague on the implications of using PixelIsPoint? and PixelIsArea? in 220.127.116.11. Some users fell into the trap of thinking that these were only a sampling technique clue and did not affect the real coordinate system. This is not the evolved industry consensus, and the specification needs to make this very clear. Some detail on this issue is capture in:
Vertical Coordinate Systems
The information on vertical coordinate systems in the GeoTIFF specification was pretty slim (see 18.104.22.168 and 6.3.4) and and it has taken a long time to establish industry practice on this topic. An effort has been made to suggest best practice at VerticalCS and after review I suggest this make it's way into the specification in some form.
One area the original specification left undefined (perhaps deliberately to reflect handling within EPSG) was how transformation between datums should be accomplished. For the most part this is currently accomplished by applications corresponding GCS/Datum codes with the corresponding EPSG definitions and then selecting among the EPSG provided transformations between datums. However, in the area of projected coordinate systems GeoTIFF took the positions that users could either use an existing EPSG PCS/GCS code *or* define details of the coordinate system themselves in the GeoTIFF file. This ability is not available for datums.
As one step towards improved self-defining capability in GeoTIFF that captures much existing industry practice it has been suggested a TOWGS84GeoKey be added essentially corresponding to the OGC WKT TOWGS84 keyword. A proposal in this regard is written up at TOWGS84GeoKey and is in use in at least GDAL based applications.
The GeoTIFF spec is vague on axis order issues. Some suggestions on this are made in the FAQ and some conclusion should likely be codified in the specification - hopefully not in a way that flies in the face of actual industry practice.