Skip to content

Definition of "vertical_extent" #58

@KRyden

Description

@KRyden

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)."

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions