Devys, Emmanuel (Institut National de l'information geographique et forestiere (IGN))
The GeoTIFF format has been used for sharing coverage data successfully for years across many platforms and software environments. It is an important de facto standard used primarily for geolocated images. The current GeoTIFF specification (Version 1.8.2) was developed during the 1990’s by a group of interested individuals and has served the community very well since then. The purpose of this SWG is to incorporate the GeoTIFF specification into the OGC standards suite by updating the specification to bring it into conformance with current OGC practices and to provide a forum for evolving the standard in the future, if need be. The resulting candidate standard will strive to maintain compatibility with existing geoTIFF community implementations and practices and future evolution would be done in close cooperation with the existing geoTIFF community.
The GeoTIFF format is ubiquitous in the geospatial community and is currently used and supported in its ad hoc form by many OCG members. The format forms the basis for sharing a large existing collection of geospatial images and coverage data, it clearly benefits those members to have the standard managed by the OGC membership.
This SWG will focus on updating the current specification and aligning it with current practice. We expect this activity to take one year.
The current geoTIFF specification is available at http://trac.osgeo.org/geotiff/. A preliminary discussion of potential refinements to the specification by Frank Warmerdam is available at http://trac.osgeo.org/geotiff/wiki/RefiningGeoTIFF and attached as Annex A.
4.1 Statement of relationship of planned work to the current OGC standards baseline
The GeoTIFF format is currently included in extensions the OGC GML Coverages (GMLCOV) 1.0 Standard to the OGC Web Coverage Service (WCS) 2.0 Standard. Standardization of the format will solidify these existing standards.
4.2 What is Out of Scope?
The SWG will not work on any change requests or other issues beyond those submitted during the 30 day public comment period.
4.3 Specific Contribution of Existing Work as a Starting Point
The current GeoTIFF Specification (Version 1.8.2) is available at http://trac.osgeo.org/geotiff/ . It will serve as the starting point for this SWG.
4.4 Determination of SWG Completion
The GeoTIFF SWG will dissolve after the following three milestones have been achieved:
- The SWG has completed evaluation and incorporation into the candidate standard of all comments received during the public comment period.
- Approval by the SWG membership of a recommendation to submit the document to the TC for consideration as an OGC Adopted Standard.
- The candidate standard has been approved by the OGC Technical and Planning Committees as an Adopted OGC standard.
4.5 Is this a persistent SWG?
Yes X No
The GeoTIFF Working Group will deliver a candidate standard to be considered by the TC. The final document will be available in HTML. The details of the schedule will be determined in a discussion during the March 2014 TC.
The HDF Group, NASA, NOAA, DGIWG, ESRI, OGP
a. Similar or Applicable Standards Work (OGC and Elsewhere).
The GeoTIFF Specification has been developed and maintained on the http://trac.osgeo.org website. This SWG will stay in touch with that group and with Frank Warmerdam as this work progresses. An outline of potential geoTIFF refinements is included as Annex A.
b. Details of the First Meeting
c. Projected On-going Meeting Schedule
d. Supporters of the Proposal
The following people support this proposal and are committed to the Charter and projected meeting schedule. These members are known as SWG Founding or Charter members. Once the SWG is officially activated, this group is immediately “opted-into” the SWG and have voting rights from the first day the SWG is officially formed. Extend the table as necessary.
The HDF Group
Jeff Walter, Karen Moe
Jeff de La Beaujardiere
Ted Habermann, the HDF Group
Jeff Walter, NASA
Emmanuel Davys, DGIWG
Notes on suggested refinements to the GeoTIFF 1.0 specification as part of a GeoTIFF standards refinement and publication process at NASA.
9.1 Projection Parameters
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.
9.2 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.
9.3 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.
9.4 PixelAsPoint vs. PixelAsArea
The original GeoTIFF specification was somewhat vague on the implications of using PixelIsPoint? and PixelIsArea? in 126.96.36.199. 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:
9.5 Vertical Coordinate Systems
The information on vertical coordinate systems in the GeoTIFF specification was pretty slim (see 188.8.131.52 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.
9.7 Axis Order
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.