Make PointSeries CoverageJSON spec-compliant

[andreas-grafberger]

Is your feature request related to a problem? Please describe.

While reading the OGC CoverageJSON standard I noticed a few places where the
current PointSeries output seems to diverge from it. I might be misreading the spec, so treat
the following as questions rather than findings.

Current output:

"domain": {
    "type": "Domain",
    "axes": {
        "latitude": {"values": [47.44]},
        "longitude": {"values": [9.65]},
        "levelist": {"values": [0]},
        "t": {"values": ["1992-01-02T06:00:00Z"]}
    }
},
"ranges": {
    "dis06": {
        "type": "NdArray", "dataType": "float",
        "shape": [1], "axisNames": ["dis06"], "values": [137.87]
    }
}

• The collection declares "domainType": "PointSeries", which per the spec is inherited by
  all contained coverages. For domains stating conformance to a declared domain type, the spec
  seems strict about axis names: a PointSeries domain "MUST have the axes x, y, and t" (x =
  longitude, y = latitude) and "MUST only contain axes defined by the domain type:
  additional axes are not allowed". If that reading is right, the
  latitude/longitude/levelist axis names would be at odds with the declared domain type.
  (Without the domainType declaration the names would be fine at the base-spec level, but
  generic clients key on the common domain types, so I assume we want to keep it.)
• Independent of the domain type, the base spec requires that "the shape and axis names of
  each NdArray ... MUST correspond to the domain axes defined by domain".
  axisNames: ["dis06"] (the parameter name) does not refer to any domain axis; should this
  be ["t"] with shape = [len(t)]? The same [str(param)] pattern appears in 8 of 10
  encoders, so this may have been a deliberate choice I am not aware of.
• The domain-type requirements also say t "MUST ... be referenced by a temporal reference
  system", but no TemporalRS is emitted at the moment. The only referencing object is a
  GeographicCRS whose coordinates include levelist (CRS84 is a 2D lon/lat CRS) and
  differ between from_polytope (["latitude", "longitude", "levelist"]) and
  from_polytope_step (["x", "y", "z"]).
• levelist: [0] is added even when no level exists (surface fields). Since z is optional
  for PointSeries, could it simply be omitted in that case?
  If the reading above is correct, output following the spec would look like:

"domain": {
    "type": "Domain",
    "axes": {
        "x": {"values": [9.65]},
        "y": {"values": [47.44]},
        "t": {"values": ["1992-01-01T06:00:00Z", "1992-01-02T06:00:00Z", "1992-01-03T06:00:00Z"]}
    }
},
"referencing": [
    {"coordinates": ["x", "y"], "system": {"type": "GeographicCRS", "id": ".../CRS84"}},
    {"coordinates": ["t"], "system": {"type": "TemporalRS", "calendar": "Gregorian"}}
],
"ranges": {
    "dis06": {
        "type": "NdArray", "dataType": "float",
        "shape": [3], "axisNames": ["t"], "values": [...]
    }
}

The currently unused pydantic_coverage (covjson-pydantic) attribute in Encoder.__init__
could be revived so output is validated instead of built from hand-assembled dicts.
covjsonkit's own decoders would need to be updated in lockstep.

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional context

No response

Organisation

No response