Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
#189 7 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Bereich
data

Rechercherichtung

Beginne mit dem covJSON Overview und der Specification, insbesondere mit Abschnitt 9.7 zu Erweiterungen, und vergleiche dann das covJSON-Mapping mit dem aktuellen konzeptionellen Modell ISO 19123-1 und dem im Issue verlinkten TSML 2.0-Modell. Die Aufgabe ist abgeschlossen, wenn die vereinbarten Mapping-Probleme dokumentiert sind und feststeht, ob eine optionale Erweiterung für tiefergehende TSML-Beobachtungssemantik angemessen ist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

comparison work Cross-SWG Priority 3

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

  1. 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

Vorherrschende Sprache
HTML
Sterne
15
Forks
9
Ø Merge
6 Std. 1 Min.
Gemergte PRs (30 T.)
3

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus opengeospatial/CoverageJSON

Alle Issues in opengeospatial/CoverageJSON

Ähnliche Issues

Weitere Issues zu Data Engineering

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.