Closed cmheazel closed 5 years ago
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:
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
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
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)
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
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
Pull request #65 (merged 1/11/19) should address all comments and changes discussed in this issue.
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?
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.
Inputs from Word document (provided by Roger Lott) have been incorportated, after review of draft GeoTIFF 2019-01-20 RLcomment.docx
Check the EPSG code ranges in the GeoTIFF requirements against the EPSC registry.