How to indicate a Coverage/Data using (r,theta) coordinates

[chris-little]

This issue is separated from #187. Could the Coverages API documentation have an example of how radar data from a single scan would be representated and scaled using spatial-resolution?

The GeoDCAT vocabulary has three horizontal resolution terms and the first one seems to be not represented:

gdcat:spatialResolutionAsAngularDistance a dqv:Metric ;
gdcat:spatialResolutionAsDistance a dqv:Metric ;
gdcat:spatialResolutionAsScale a dqv:Metric   

I do not have any examples of readily available (r,theta) geospatial definitions. One that the WMO uses for globally transmitting radar data in GRIB messages is at:
https://library.wmo.int/assets/javascripts/library/treeview/images/treeview-default-line.gif , pasted below for convenience. It assumes a tangent plane at the centre point, and ignores the declination/elevation of the radar beam. It can define a non-360 degree sector. The machinable version is at https://codes.wmo.int/_grib2

Grid definition template 3.120 – azimuth–range projection
Octet No. Contents
15–18 Nb – number of data bins along radials (see Note)
19–22 Nr – number of radials
23–26 La1 – latitude of centre point
27–30 Lo1 – longitude of centre point
31–34 Dx – spacing of bins along radials
35–38 Dstart – offset from origin to inner bound
39 Scanning mode (flags – see Flag table 3.4)
40–(39+4Nr) For each of Nr radials
(40+4(X–1))–(41+4(X–1)) Azi – starting azimuth, degrees x 10 (degrees as north)
(42+4(X–1))–(43+4(X–1)) Adelta – azimuthal width, degrees x 100 (+ clockwise,
– counterclockwise), with X = 1 to Nr

HTH

[jerstlouis]

SWG 2025-06-04:

We found an example in WKT2 CRS described using CS[polar, 2]:

7.5.8.5 Coordinate systems for engineering CRSs
https://docs.ogc.org/is/18-010r11/18-010r11.pdf

Reviewing the possibilities to deal with such CRSs these are the options we see:

A) Treating these types of CRSs as a 3rd type of spatial CRS (polar) specifically for radar-like polar coordinates (in addition to geographic and projected/cartesian with 2 or 3 orthogonal axes), and prescribing specific axis names (e.g., U and r).

B) Treating the two dimensions of such CRSs like any other "additional dimension", not fitting the "spatial subsetting/scaling" requirements classes, and relying on specific semantic definitions (e.g., http://qudt.org/vocab/quantitykind/Azimuth and http://qudt.org/vocab/quantitykind/RadialDistance), and then allowing any name to be used as for any other additional dimensions

Pros of A): These dimensions essentially being a polar spatial coordinates are treated like other "spatial" dimensions
Cons of A): This requires the definition of an Engineering CRS for the specific point of origin of the polar CRS

Pros of B): Servers to not have to do any special handling for these -- they are treated like any other additional dimensions
Cons of B): We would need to define specific additional fields for the dimension to specify the point of origin (e.g. position of the radar) and the 0 Azimuth (e.g. North) to specify the coordinates and origin of the "reference system"

Looking at WKT2 CRS, there may also be some other types of spatial CRSs that we overlooked in section "7.5.8 Examples of WKT describing coordinate systems". e.g. spherical CRS in particular, is the Elevation essentially 90 deg - latitude? ordinal inline/crossline?

The spatial-resolution was proposed specifically for handling point clouds in particular in 3D Cartesian CRS scenarios, and is not applicable to either of these solutions. The regular resolutions parameter approach would work with either of these solutions: resolutions=Azimuth(0.5),RadialDistance(2.0).

We are leaning towards solution A, adding requirements specific to polar spatial CRSs in both the Spatial Subsetting and Spatial Scaling requirements classes.

[jerstlouis]

SWG 2026-02-18: We discussed this issue again today, and came to the conclusion that there are already two alternative ways to handle such use cases (leaning towards solution B in previous post instead):

• In most scenarios, radar data will first be re-projected into a 2D CRS using e.g., an azimuthal equidistante projection centered on the radar, which incorporates the spatial location and orientation of the radar and facilitates integration with other spatial datasets. In this case, the data will already be in a projected or geographic CRS and there is no need for azimuthal or distance axes.
• As an alternative, the "General Subsetting/Scaling" requirements class could be used to define a collection with specific axes for the azimuth and radial distance (Option B).

Also going back to your original post @chris-little

gdcat:spatialResolutionAsAngularDistance

We actually do have this already, as this is typically the resolution for a geographic CRS where the angles are decimal degrees of latitude or longitude on the Earth surface, and has nothing to do with polar coordinates or the radar scenario.

As a result, we think nothing needs to be changed in the draft.