GeoTIFF v2 proposal: embed WKT

[rouault]

Of course not to be considered for the current work, but perhaps worth considering for a GeoTIFF v2.0:

A lot of the issues we have to face with the myriad of GeoTIFF keys could be solved easily by having one single GeoKey which would be a ASCII GeoKey "WKTCitation" and just rely on the wkt-crs standard

[rouault]

Note: there is a prior art in GeoTIFF regarding using WKT in ESRI implementations where PCSCitationGeoKey might have as value "ESRI PE String = "

[schwehr]

Support for GOES would be helpful:

As noted here: https://lists.osgeo.org/pipermail/proj/2019-June/008675.html

gsutil cp
gs://gcp-public-data-goes-17/ABI-L1b-RadC/2019/151/21/OR_ABI-L1b-RadC-*_G17_s20191512131197_*.nc .

gdalinfo NETCDF:OR_ABI-L1b-RadC-M6C02_G17_s20191512131197_e20191512133570_c20191512133595.nc:Rad
Driver: netCDF/Network Common Data Format
Files: OR_ABI-L1b-RadC-M6C02_G17_s20191512131197_e20191512133570_c20191512133595.nc
Size is 10000, 6000
Coordinate System is:
PROJCS["unnamed",
    GEOGCS["unknown",
        DATUM["unknown",
            SPHEROID["Spheroid",6378137,298.2572221]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Geostationary_Satellite"],
    PARAMETER["central_meridian",-137],
    PARAMETER["satellite_height",35786023],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    EXTENSION["PROJ4","+proj=geos +lon_0=-137 +h=35786023 +x_0=0 +y_0=0 +ellps=GRS80 +units=m +no_defs  +sweep=x"]]
Origin = (-2505021.493779813405126,1583173.639055640902370)
Pixel Size = (501.004328871885207,501.004328871885264)
Metadata:
  goes_imager_projection#grid_mapping_name=geostationary
  goes_imager_projection#inverse_flattening=298.2572221
  goes_imager_projection#latitude_of_projection_origin=0
  goes_imager_projection#longitude_of_projection_origin=-137
  goes_imager_projection#long_name=GOES-R ABI fixed grid projection
  goes_imager_projection#perspective_point_height=35786023
  goes_imager_projection#semi_major_axis=6378137
  goes_imager_projection#semi_minor_axis=6356752.31414
  goes_imager_projection#sweep_angle_axis=x
[SNIP]

gdalinfo --version
GDAL 2.2.4, released 2018/03/19

[joanma747]

I would like to emphasize that a the georeference of a geostacionary satellite image cannot be express with the current keys and there are (at least) two solutions:

• Adopt WKT
• Extend the geokeys with the necessary parameters

[jerstlouis]

The current situation to figure out a CRS from a myriad of GeoTIFF keys is a real nightmare. Embedding an AS Topic 2 CRS encoding (whether CRS/PROJ-JSON or WKT-CRS) is the sane solution. Should be at the top of the list for 2.0! :)

[joanma747]

Does this imply removing support for the GeoKeys that result redundant?. It could be good to have a clean start with no conflicting ways to express the same.

[desruisseaux]

Note that GeoKeys are already redundant with EPSG codes in the GeoTIFF 1 specification. Introducing WKT in GeoTIFF would not really change the redundancy situation. This redundancy can be a useful fallback when the GeoTIFF is read with a software having no connection to the EPSG database and no capability to parse WKT. In geospatial communities (OGC, OSGeo…), using a geospatial library such as GDAL or Apache SIS may seem an evidence. But in other communities (Apache, big-data, etc.), developers sometime want to stick to the non-geospatial library they are used to.

[rouault]

But in other communities (Apache, big-data, etc.), developers sometime want to stick to the non-geospatial library they are used to.

I'm not sure how you can make sense of the geokeys of GeoTIFF 1.0 or 1.1 that would be obsoleted by a WKT/JSON CRS encoding, without serious CRS understanding capabilities. The only capability which doesn't require too advance knowledge I can think of, and that can be done relatively easily with GeoTIFF 1.x, is perhaps to extract the CRS EPSG code, and hand it over to something else. That would actually be an argument in favoring a JSON CRS encoding, which would make it easy to extract it. cf the hints at https://github.com/opengeospatial/geoparquet/blob/main/format-specs/geoparquet.md#ogccrs84-details aimed at non super CRS savy users to extract the CRS code. But figuring out datum, projection method, projection parameters already require a pretty advanced knowledge of the CRS business. IMHO having a GeoTIFF 2.0 keeping all the geokeys defining datum, units, projection method&parameters, etc + allowing WKT/JSON would be the worse outcome, since it would require readers to know both worlds.

[hobu]

IMHO having a GeoTIFF 2.0 keeping all the geokeys defining datum, units, projection method&parameters, etc + allowing WKT/JSON would be the worse outcome, since it would require readers to know both worlds.

💯 concur. Especially because it is not always possible to express equivalent definitions and you inevitably end up with downstream consumers having to decide which definition is the "most correct" given their circumstances.

[rouault]

Coming from a remark posted at https://lists.osgeo.org/pipermail/proj/2024-April/011351.html, if we allow WKT or JSON CRS encoding, we should be careful about the text encoding. Current GeoTIFF keys are limited to ASCII, whereas WKT allows for Latin-1 character set (encoded as UTF-8) for thing like CRS names, and possibly full Unicode for other auxiliary metadata. So a GeoTIFF key holding a WKT or JSON CRS should support UTF-8

[rouault]

https://lists.osgeo.org/pipermail/proj/2024-April/011353.html: """let me point out that the root of the problem is the TIFF6.0 standard that continues to define field type 2 as ASCII. Their exact wording is: "8-bit byte that contains a 7-bit ASCII code; the last byte must be NUL (binary zero)" (page 15)

IMO everything would work just fine if this would be replaced with "8-bit byte that contains UTF8 code units; the last byte must be NUL (binary zero)". Given that UTF-8 is an extension of ASCII, backwards compatibility wouldn't be so bad. """