Validate EPSG codes

[cmheazel]

Check the EPSG code ranges in the GeoTIFF requirements against the EPSC registry.

[RogerLott]

This post covers not only this issue but also several others including #7 (Vertical) and #52 (EPSG codes).

I attach 3 documents which collectively address the description of Model CRS and EPSG codes:

1. 2018-12-18 pdf annotated with corrections and edits using highlight and sticky notes. In general highlighted text should be replaced by that in the adjacent sticky note.
2. Model CRS requirements (clause 7) completely re-written.
3. Description of Model CRS (Annex B.5.3) and EPSG codes (Annex B.5.4) both completely re-written, together with three new suggested Annexes (Map projection codes, recommendations for describing compound and geographic 3D CRSs, and a summary list of all key codes and names).

The re-writes I believe improve the description of CRS stuff, which in the 1995 doc was (in my view) somwhat confusing, but I believe retains the spirit of this 'minimum change' port.

GeoTiff 2018-12-18 RL CRS and EPSG edits.pdf GeoTIFF 2018-12-18 RL clause 7 CRS edits.docx GeoTIFF 2018-12-18 RL annex CRS edits.docx

[rouault]

My comments on @RogerLott 's documents: GeoTIFF.2018-12-18.RL.annex.CRS.edits_remarks_ERO.docx GeoTIFF.2018-12-18.RL.clause.7.CRS.edits_remarks_ERO.docx

[EmDevys]

Even, all I focus on your comment ER4 on GeoTIFF.2018-12-18.RL.clause.7.CRS.edits_remarks_ERO.docx: "There are “GeoTIFF” files which have only ModelTiepointTag and ModelPixelScaleTag without any CRS indication; do we want to exclude them from being valid GeoTIFF files ? Same remark for GTModelTypeGeoKey". My view of geoTIFF is (was) to associate Raster space to Model space, therefore (implicitly) to specify the ModelSpace (by means of CRS documentation). The 1995 specification was not constraining to this, but I can't understand the use case of any Transformation without the Model space definition. If there are such GeoTIFF files, do you know for which usage / use case such GeoTIFF files could help? Would probably help to decide whether to allow this (in version 1.1) or not, as well as inversion 1.0 (for backward compatibility reason)

[rouault]

do you know for which usage / use case such GeoTIFF files could help?

I'm not sure how widespread it is, but typically with GDAL utilities, such GeoTIFF files could come from converting into GeoTIFF from a PNG or JPEG with a side-car world-file (.wld, .pgw, .jgw files) that defines the raster to CRS transformation. But worldfiles do not allow to define the CRS which is assumed to be known by other means (free form metadata, etc). I don't care much if GeoTIFF 1.1 declares such files to be non-conformant. Software are free to read and produce non conformant files in some circumstances

[RogerLott]

GeoTIFF.2018-12-18.RL.clause.7.CRS.edits_remarks_ERO_RLcomment.docx

Some further comments on @rouault comments in GeoTIFF.2018-12-18.RL.clause.7.CRS.edits_remarks_ERO.docx

[cmheazel]

Pull request #65 (merged 1/11/19) should address all comments and changes discussed in this issue.

[cmheazel]

Pull request #67 completes the tables in Annex B, C, D, and E. Note that Annex E used a different format for emphasis text (red text in Word). It also uses the built-in AsciiText table titling capability. Do we want to use these conventions across the document?

[EmDevys]

Inputs from Word documents (provided by Roger Lott) have been incorportated after adjustments (clause 7 and Annexes B-E). Resulting draft is to be checked. For conventions in Annex E and their generalisation, to be discussed before final decision and closing.

[EmDevys]

Inputs from Word document (provided by Roger Lott) have been incorportated, after review of draft GeoTIFF 2019-01-20 RLcomment.docx