TSML - covJSON alignment and covJSON - ISO19123-1 alignment (email thread)
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
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).
- 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.)
- 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
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus opengeospatial/CoverageJSON
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 45/100
opengeospatial/CoverageJSON#233 ·
-
New CovJson LibraryOffenImplementations
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
opengeospatial/CoverageJSON#229 · 3 Kommentare ·
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
opengeospatial/CoverageJSON#227 · 3 Kommentare · 1 Reaktion ·
-
enhancement
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 30/100
opengeospatial/CoverageJSON#218 · 4 Kommentare ·
-
V1.1
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100
opengeospatial/CoverageJSON#216 · 9 Kommentare · 3 Reaktionen ·
Alle Issues in opengeospatial/CoverageJSON
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
vaccfr/Sector-Files#225 ·
-
pandas stats: a nullable Float64/Int64 column loses mean, median and std when its std is pd.NAOffenHistograms
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
buckaroo-data/buckaroo#1074 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
FireDynamics/fdsreader#123 ·
-
Missing: Aircall for StartupsEvtl. vergeben Ein verknüpfter Pull Request ist offen oder bereits gemergt. Offen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 85/100
sourcey/startup-credits#1633 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 10 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Sienna-Platform/PowerSystemCaseBuilder.jl#239 ·
Maintainer antworten meist innerhalb von 1 Tag