TSML - covJSON alignment and covJSON - ISO19123-1 alignment (email thread)

[phersh2]

From: Paul Hershberg - NOAA Federal
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, etc.

• 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 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

[chris-little]

@phersh2 To align CoverageJSON and TSML via UML and ISO19123-1 seems desirable, though I suspect it is a substantial effort to do so. One approach would be to have the OSM detailed attributes outside of the CoverageJSON object, linked with the JSON-LD functionality of CoverageJSON.

But, firstly, which version of ISO19123-1: the old, superceded 2005 version or the newer 2023 version? They have differing scopes.

This repo has some comparisons between CoverageJSON and ISO19123-1 (2005) and CoverageJSON and an early draft of ISO19123-1 (2023) as a basis for those prepared to do the further work.

[phersh2]

Thanks Chris for those two comparisons. The version we are exploring is the latest, ISO19123-1:2023.