Open tomkralidis opened 2 years ago
There is already a requirement to identify the stations as being part of GBON for a country. Not sure if this will be accessible through the API in a convenient way. @kurt-hectic can you give some info on this?
The OSCAR/Surface API is a non-standard API, so in principle, parameterized endpoints can be defined ad libitum. The present API supports direct access
to a single station, viz.
https://oscar.wmo.int/surface//rest/api/wmd/download/<WIGOS_ID>
to a whole country, viz.
https://oscar.wmo.int/surface/rest/api/search/station/?territoryName=<notation from http://codes.wmo.int/wmdr/TerritoryName>
to all stations affiliated with a program/network, viz.
https://oscar.wmo.int/surface/rest/api/search/station/?programAffiliation=<notation from http://codes.wmo.int/wmdr/ProgramAffiliation>
combinations are possible, e.g.
https://oscar.wmo.int/surface/rest/api/search/station/?programAffiliation=GAW&territoryName=CHE
See User Manual for reference.
I believe, the endpoint to expose station sets is going to be available later in 2022.
The question could be if an OGC standard API like STA should be supported in future.
Thanks @joergklausen. It would be valuable to have the facility set use case realized in the API. As an aside, we would be interested in discussions around OSCAR API future plans, and would suggest that the OGC API suite of standards is considered.
To summarize an option:
Whether to choose option i or ii above depends on the number of stations that a given dataset is based on. For example, for ~800 surface stations in Canada, we would use option 2.
In both cases:
TT-WISMD 2023-05-05: ACTION @wmo-im/tt-wismd to review and provide comments.
@tomkralidis your summary matches what we have discussed earlier and there is little I can add to it. Clearly, option 2 will be a great help and the only open question is if the existing OSCAR API station filtering capability is able to cover all cases. And if not, whether the right way is to ask for its extension or whether it is then the task of the publisher to provide an API (possibly a facade over OSCAR) that will return the right list of stations.
@tomkralidis I have nothing to add to what you commented on. Although I doubt that station metadata are managed in OSCAR/Surface I would assume many provide a copy to OSCAR where it is published and made available. But that is not the major issue here. As long as both options for linking WIS and WIGOS are possible it is positive although I find the option of direct relation between station dataset (WIS) and station metadata the most useful for services targeting decision support through integration in decision support systems at various levels. It will be interesting to see if WMO information services will be embraced in this context.
Thanks for the feedback. At this point we'll add an example WCMP2 record to this effect that will become a curated example as part of an Annex in WCMP2.
For station sets, given implementation in OSCAR/Surface is pending next generation discussions, perhaps an additional option can be to point to a list of stations in any format:
{
"rel": "related",
"type": "text/csv",
"title": "Dataset station list",
"href": "https://dd.weather.gc.ca/observations/doc/swob-xml_station_list.csv"
}
Or:
{
"rel": "related",
"type": "application/json",
"title": "Dataset station list",
"href": "https://example.org/oapi/collections/stations/items?f=json"
}
Note: we could (in WCMP2) perscribe a dedicated link relation (e.g. http://wis.wmo.int/metadata/stations
) for tighter integration with WIS2 tooling, at the cost of broader interoperability.
Even the current implementation of station clusters / station ets / FacilitySet in OSCAR/Surface exposes a URL, e.g., https://oscar.wmo.int/surface/#/search/stationClusterReport/5. Since there is no WMO/WIGOS identifier for this, the identifier used (here: 5) will probably not survive the current OSCAR/Surface implementation, though. The requirement has been noted for OSCAR NextGen.
https://github.com/wmo-im/tt-wismd/wiki/Meeting-2023-08-14 notes:
Tom: should we include a section in the Guide for this or should this be a part of best practices?
TT-WISMD 2023-08-14
Initial link relations put forth in https://github.com/wmo-im/wcmp2-codelists/pull/4
We will need to discuss whether this is the best approach (would this be better managed in WMO Common Code Tables?), as well as the publication to codes.wmo.int (which would then be the canonical reference via infrastructure).
cc @david-i-berry
Notes following discussion with ET-WTR (cc Cristina Prates @thineshsornalingam):
We want to reduce duplication between WIS2 and OSCAR. Notes:
The result would be a requirement or recommendation on GDCs to augment WCMP2 on ingest per the above.
Considerations:
Updated examples based on new link relations:
Single facility:
{
"rel": " http://def.wmo.int/def/rel/wmdr/-/EnvironmentalMonitoringFacility",
"type": "application/xml",
"title": "Station report for Thessaloniki (Greece)",
"href": "https://oscar.wmo.int/surface/rest/api/wmd/download/0-20008-0-THE"
}
Facility Set
{
"rel": "http://def.wmo.int/def/rel/wmdr/-/FacilitySet",
"type": "application/xml",
"title": "Station report for facility set 123",
"href": " https://oscar.wmo.int/surface/rest/api/facilityset/123"
}
TT-WISMD 2023-09-13:
TT-WISMD 2023-10-06:
WMDR codes currently only has codes for Facility Type, should there be a request to expand this code list or create a new codes list in WMDR to support this type of linkage?
We will need to discuss whether this is the best approach (would this be better managed in WMO Common Code Tables?), as well as the publication to codes.wmo.int (which would then be the canonical reference via infrastructure).
Alternatively, I like the idea of using common code tables, but it's currently linked to WMO-No. 306, vI.2 https://codes.wmo.int/common
Current list in https://github.com/wmo-im/wcmp2-codelists/blob/main/codelists/link-type.csv
Options:
Note that WMO 306 (https://github.com/wmo-im/cct) is for data specific code tables, whereas we are trying to describe higher level things.
@joergklausen may have ideas on how to manage shared vocabularies across WIS and WIGOS metadata....
WIGOS was born to cover common topics of interest, specifically for observations. So, I am fully in support of sharing common vocabularies. In fact, we should clarify what we mean by common ... between whom? The respective metadata models shold refer to the correct name space, which for WIGOS doesn't always have to be wmdr. Of course, we need clean governance structures.
https://github.com/wmo-im/tt-wismd/wiki/Meeting-2023-10-23 notes:
I started drafting a section in WCMP2 (clause "stations/observations"), and I'm conflicted. If we add a specific section for "stations/observations", does this introduce precedent to add more sections for NWP, Hydrology, Cryosphere, etc.?
Options:
Thoughts? cc @antje-s @jsieland @josusky @Amienshxq @solson-nws @gaubert @amilan17 @masato-f29 @McDonald-Ian
TT-WISMD 2023-11-16: add similar example from OceanOPS, for example.
@wmo-im/tt-wismd @wmo-im/tt-wigosmd @joergklausen @steingod @thineshsornalingam
Consider a WCMP2 record describing, say, surface weather observations from a network of stations/facilities. In WCMP2, we are able to enumerate 1..n links, i.e:
(NOTE: relation types are examples/for brainstorming)
In the above, a user can discover a dataset collection and determine from the link relation (
rel
) the association station(s) providing the dataset. Now imagine a observing network with 800 stations.WCMP2 requires an approach whereby a data provider can provide a facility set as a single link in order to scale.
Questions:
Aside: while the above examples use the OSCAR/Surface API, in theory the value of the
href
is opaque here, so long as a WMDR facility set is provided in the response.Looking forward to this important discussion.