search

opengeospatial / CRS-JSON-Encoding

0 stars 2 forks source link

Definition of "Cartesian_cs" (missing) #8

Open KRyden opened 2 months ago

KRyden commented 2 months ago

NOTE: Markdown does not support highlighting in color, so bold/italic has been used to highlight the material being discussed. This issue is extracted from the document submitted by Roger Lott at https://github.com/opengeospatial/CRS-JSON-Encoding/blob/main/ProjJson%20v0-7%20RL%202024-06-16.docx for discussion at the CRS SWG meeting OGC held during the Montreal June 2024 TC meeting.

_"Cartesiancs": { }

"$comment": "[RL] Definition to be completed. The definition should constrain a Cartesian CS to have 2 or 3 axes. In 19111/Topic 2 Cartesian is a specialization of affine CS (perpendicular axes in same units).

When a Cartesian CS is used in a geodetic CRS, 19111/Topic 2 constrains axis names to "geocentric X, geocentric Y, geocentric Z". This is erroneous (incomplete) as it covers only the geocentric Cartesian CS case: topocentric coordinates referenced to a geodetic reference frame would normally have names relevant to directions on the earth's surface (e.g. north, east, up). For a geocentric Cartesian CS WKT2 forbids axis names and requires axis abbreviations ‘X’, 'Y' and ‘Z’.

When a Cartesian CS is used in a projected CRS, 19111/Topic 2 and WKT2 constrains axis names to "northing or southing, easting or westing, [ellipsoidal height (if 3D)]". In the 3D case WKT2 requires axis abbreviation for the ellipsoidal height axis to be 'h'. See vertical_cs for a possible template for adding these constraints."

desruisseaux commented 1 month ago

Depends on #63: may need a change of approach, replacing subtype by type (as in the rest of PROJJSON) or by entityType (as in OGC 24-017).