prushforth
commented
1 year ago There's some debate whether a TCRS is a TileMatrixSet or a CRS.
The decision was made early on that TCRS had more in common with CRS than WMTS Tile Matrix Sets, and while one of the authors of that specification was kind enough to create a whole new specification, OGC TMS v1.0.0, in order to provide stable identifiers for TileMatrixSets, that specification has diverged from the intent of TCRS. Even in version 1.0.0, it specified WebMercatorQuad to be based on the EPSG:4326 CRS, with its latitude,longitude axis order. This put it at odds with the OSMTILE definition, which relies on the CRS:84 CRS with its longitude,latitude axis order requirement.
However, TMS v2 has diverged from usefulness even further, because it allows different CRS codes for any given TileMatrixSet, even within an overall "well known" TMS e.g. WebMercatorQuad, which must be determined at run time through metadata obtained from an HTTP API. This makes processing instances of TileMatrixSet too unpredictable.
In consequence, TCRS instances should be an instance of a Compound CRS. In processing coordinates of spatial information, it is vital, essential, paramount to know unequivocally the semantics of the axis values used is. To know this, programs rely on the axes values being passed to functions as named parameters. To know which axis value to put into which parameter, the programs must know how to parse the axis values from input coordinates commonly represented as strings.
Axis order of CRS are determined by the CRS definition by standards decree aka widespread inviolable cultural convention. A CRS definition is generally/often communicated by reference, via passing of well known CRS identifiers e.g. "EPSG:4326", that are used to look up local functions for coordinate transformations when appropriate. The function definitions often have two (or more) axis values as arguments. The meaning of the arguments is determined by the function (parameter) definitions: sometimes the programmer will have specified that latitude is the first argument and longitude is the second argument. When parsing the axis values from inputs, it's vital for the program that invokes the above function definition to KNOW which value it is passing to the function, so that it puts the correct axis in the appropriate argument position. It KNOWS this fact from the definition of the EPSG:4326 CRS, which (in the particular case of EPSG:4326) specifies that latitude shall come before longitude in parsing otherwise un-marked up coordinate strings, bytes or however that data is encoded.
In other words, the axis order of EPSG:4326, or any other well-known coordinate system definition never changes. So it should be too, with the axis order of coordinates in MapML TCRS, which is defined by the specification.
The suggestion of this comment is to create Compound CRS to represent the TCRS coordinate systems. Compound CRS seem to be supported by WKT2.
It may also be necessary to consider the coordinate systems 'inside' a TCRS as Derived Projected CRS, TBD.
cc @aaime
Background
MapML TCRS (“Tiled Coordinate Reference System”) are notionally a union of a GeoWebCache GridSet definition and a (GeoTools) projected CRS, such that each zoom level in the grid definition can be treated as derived projected CRS. In the current GeoServer MapML extension, there are four defined GridSets, named after the four TCRS defined by the MapML specification: OSMTILE, CBMTILE, WGS84, and APSTILE. Each of these defined GridSets is defined in an XML file supplied with the MapML extension. The predefined GridSets in the distributed file have parameter values defined by the MapML specification to create a GeoWebCache grid that can be used by a system administrator to configure GeoServer to serve layer content tiled by GeoWebCache as MapML responses. With the MapML extension installed, newly created (tiled) layers are automatically configured to be tiled according to these definitions by default (and thus accessible via the GeoServer WMTS interface), with the administrator having the option to remove GridSets from the layer configuration (potentially conserving tile storage resources, should they decide to serve the layer content via tiled requests). The Java implementation of TCRS in the GeoServer extension module wraps and augments a GeoTools CRS (for an underlying EPSG CRS) but does not implement any GeoTools CRS interface or class definition itself; it is a custom class otherwise unrelated to any GeoTools CRS.
Requirement
Re-define MapML TCRS as GeoTools custom projected CRS class definition, such that TCRS’ root abstract class or interface (perhaps: org.geotools.referencing.crs.TiledCoordinateReferenceSystem) defines and/or implements the “contract” of a GeoTools projected CRS, if possible. This is a preliminary essential task required to perform subsequent tasks (including making MapML available via GetMap); subsequent tasks are dependent on successful completion of this task. Document the procedure required to add additional TCRS instances as GeoTools custom projected CRS. Document the procedure required to add such GeoTools TCRS instances to the GetCapabilities response document.
Add all standard TCRS instances to the GeoServer MapML extension, so that they appear in Capabilities response documents as legal
crs/srsparameter values.The objective of the org.geotools.referencing.crs.TiledCoordinateReferenceSystem class would be to obtain the benefits of formal CRS handling with the simplicity of creating actual tile caches via the GWC API. Enable use of a TCRS to automatically define a GWC Gridset, using the enclosed tilematrixset coordinate systems definitions to create the Gridset.