Definition of "vertical_extent"

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.

"vertical_extent": {
  "type": "object",
  "properties": {
    "minimum": { "type": "number" },
    "maximum": { "type": "number" },

"unit": { "$ref": "#/definitions/unit" } STRIKE THIS LINE
"vertical_extent_id": { "$ref": "#/definitions/vertical_crs" }

  },
  "required" : [ "minimum", "maximum", "vertical_extent_id" ],
  "additionalProperties": false
},

"$comment": "In ISO 19115 [OGC Abstract Spec Topic 11] a vertical_extent must contain at least one of either a vertical CRS full definition or a vertical CRS ID. Above insert allows for only an ID.

If vertical CRS [ID] is given, it defines the CRS units and the unit member would conflict with this.

ISO 19115 [OGC Abstract Spec Topic 11] also has both minimum and maximum required. This seems odd to me. The absence of one of these would imply that the vertical extent is unlimited in that direction, e.g. height below [maximum =] 500m, so should be allowed as long as at least one of minimum and maximum are present.

"$comment": "[RL] If both minimum and maximum are required, how does one express an unboundedg height range e.g. 'above minimum = H' or 'below maximum = H'? (Here 'above' and 'below' are in context of a vertical height CRS, need reversing for a vertical depth CRS)."

Start with the vertical_extent schema shown in this issue and the linked ProjJson v0-7 RL 2024-06-16.docx document. Resolve whether the unit member, vertical CRS identifier, and minimum/maximum bounds should be required, then update the agreed schema so its fields and constraints match the decision.