TSML/covJSON alignment and covJSON/19123-1 alignment

[phersh2]

From: Paul Hershberg - NOAA Federal <[email protected]>
Date: Thursday, 26 September 2024 at 17:49
To: Jon Blower <[email protected]>
Cc: Kathi Schleidt <[email protected]>
Subject: Re: Question on covJson handling multiple parameters for TimeseriesML

Hi Jon,

As I mentioned last year in the below email exchange, the TimeseriesML conceptual model was
slated to undergo a revision to Version 2.0 following the recent updates to both the Observation & Measurements (ISO 19156, now OMS) update and also the Coverages (ISO 19123-1) update. Updates to the TSML conceptual model are nearing completion.

I've read thru the covJSON docs (covJSON Overview and covJSON Spec) and would like to ask a few questions concerning harmonization between covJSON and the new TSML conceptual model. The new model is here: New TSML 2.0 Conceptual Model in WebEA

We're looking at covJSON to use as the encoding for TSML to fit the less voluminous, and less detailed use cases of transport for encoding TSML over the web (a tsmljson encoding if you will).

We have two methods of TSML encodings in the standard, Domain-Range, and Time-Value Pair. We would like to map TSML's Domain-Range to covJSON (and eventually could serve up this data via the API-EDR spec).

1. In the covJSON domainType of PointSeries (below in bold text), I wanted to ask where we may begin to think about adding new TSML 2.0 conceptual model classes (the new classes derived specifically from the new OMS standard) such as observedProperty, observer, procedure, host, etc, into covJSON. This will of course affect our tsmljson encoding.

I'm looking at the parameters section in covJSON. Ideally we'd like to extend via the OMS ObservationCharacteristics there. We're wondering if there's interest in providing deeper semantics, i.e., creating an optional CovJSON extension with the aforementioned ObservationCharacteristics class. To comply with the intended simplicity of covJSON for web users, we'd make this optional in the cardinalities.

(Note, section 9.7 in covJSON doc deals with extensions, but looks to be about just adding custom members and types)
(Note, observedProperty is already in covJSON and is pretty straightforward.)

2. I also wanted to note that work has been done to align covJSON with the new Coverage update ISO 19123-1
   to begin to bring this into the OGC building blocks methodology which could aid in the solution to provide standardized and testable interfaces. As we know, each OGC API standard is made of a set of requirements/building blocks, which can be reused beyond their original context.

We want to provide a covJSON encoding but are formalizing the TSML conceptual model as UML. Thus, we need a UML representation of covJSON aligned with ISO 19123-1 so we can derive an implementation model from the TSML conceptual model. Kathi Schleidt has put in this work, below.

Could you possibly take a look and check the covJSON mapping to 19123-1 and let us know of any issues?:
covJSON mapped to latest ISO 19123-1 conceptual model

Note, and was started with the covJSON UML diagram found at
covJSON simple UML without Collections

Thanks for any assistance,
Paul Hershberg
chair TSML SWG
NOAA/NWS

{
"type" : "Coverage",
"domain" : {
"type" : "Domain",
"domainType" : "PointSeries",
"axes": {
"x" : { "values": [-10.1] },
"y" : { "values": [ -40.2] },
"t" : { "values": ["2013-01-01","2013-01-02","2013-01-03",
"2013-01-04","2013-01-05","2013-01-06"] }
},
"referencing": [{
"coordinates": ["x","y"],
"system": {
"type": "GeographicCRS",
"id": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
}
}, {
"coordinates": ["t"],
"system": {
"type": "TemporalRS",
"calendar": "Gregorian"
}
}]
},
"parameters" : {
"PSAL": {
"type" : "Parameter",
"description" : {
"en": "The measured salinity, in practical salinity units (psu) of the sea water "
},
"unit" : {
"symbol" : "psu"
},
"observedProperty" : {
"id" : "http://vocab.nerc.ac.uk/standard_name/sea_water_salinity/",
"label" : {
"en": "Sea Water Salinity"
}
}
},
"POTM": {
"type" : "Parameter",
"description" : {
"en": "The potential temperature, in degrees celcius, of the sea water"
},
"unit" : {
"label": {
"en": "Degree Celsius"
},
"symbol": {
"value": "Cel",
"type": "http://www.opengis.net/def/uom/UCUM/"
}
},
"observedProperty" : {
"id" : "http://vocab.nerc.ac.uk/standard_name/sea_water_potential_temperature/",
"label" : {
"en": "Sea Water Potential Temperature"
}
}
}
},
"ranges" : {
"PSAL" : {
"type" : "NdArray",
"dataType": "float",
"axisNames": ["t"],
"shape": [6],
"values" : [ 43.9599, 43.9599, 43.9640, 43.9640, 43.9679, 43.9879 ]
},
"POTM" : {
"type" : "NdArray",
"dataType": "float",
"axisNames": ["t"],
"shape": [6],
"values" : [ 23.8, 23.7, 23.9, 23.4, 23.2, 22.4 ]
}
}
}

---

---

On Fri, Sep 27, 2024 at 4:28 AM Jon Blower <[email protected]> wrote:
Hi Paul,

It would be great to harmonise CovJSON and TSML, so thanks very much for getting in touch. If you wouldn’t mind, could you please transfer your questions to the GitHub (https://github.com/opengeospatial/CoverageJSON/issues)?

Sadly I don’t have a lot of time to devote to CovJSON but there are others who can comment (e.g. Chris Little at the Met Office. I’m also trying to see if I can get some dedicated resource here at NOC to help move things forward, and I think we would have a strong interest in timeseries data.

I think having optional “extras” to introduce the deeper semantics of TimeseriesML sounds good, so very happy to explore this.

Many thanks to Kathi for the mapping work! My head is not sufficiently “into” the ISO19123 stuff anymore so I’m going to find it hard to comment on this, but others (e.g. Chris) might be better placed.

Best wishes,

Jon