provide guidance for observational network data

[tomkralidis]

During the May 2022 OGC Space Partitions Code Sprint, a particular focus of EDR was demonstrating vector data implementations.

A common environmental data use case is monitoring station data, the idea being observations being measured within a network of stations/observing facilities. Such monitoring data can also be represented as vector data.

Experimentation at the sprint demonstrated the ability to provide observations via EDR queries by way of .../items, a building block from OGC API - Features. While this capability can be realized via OGC API - Features, EDR adds value in that an EDR collection can provide .../items as well as .../locations, the latter being associated monitoring stations. This relationship seems more natural in EDR vs. having distinct collections and having some sort of hypermedia association between them.

It would make sense to promote this ability more formally, given the importance of monitoring data and applicability to EDR so as to help guide monitoring programs accordingly ("here's my EDR monitoring data server"). Options discussed included:

1. addition to EDR FAQ
2. EDR profile
3. EDR Conformance class (i.e. monitoring data uses shall provide .../items and .../locations)

It also goes saying that collaboration/feedback with/from the STA SWG would be valuable here.

cc @solson-nws @ShaneMill1 @chris-little @m-burgoyne

[dblodgett-usgs]

Are your findings in line with this? https://github.com/opengeospatial/ogcapi-environmental-data-retrieval/wiki/Examples#monitoring-station-data

[tomkralidis]

Yes, exactly.

[chris-little]

Discussed at EDR API SWG76. Awaiting some implementation experience.

[chris-little]

@tomkralidis @dblodgett-usgs I changed the name of the issue to stop it confusing me. I keep thinking it is about monitoring APIs, GitHub and IT infrastructure.

And I added some initial text to the FAQ

[KoalaGeo]

Just to link up these threads - opengeospatial/sensorthings#135

[dblodgett-usgs]

It strikes me that it would be useful to put together an analysis of the relationship between EDR and OMS from the perspective of sensor or sample data where there is a proximate and ultimate feature of interest involved. We have some long-in-the-tooth issues related to this topic and stepping back to some more basic concepts rather than focusing on interfaces and technology might be helpful to get us unstuck?

The thought on the topic here: https://github.com/opengeospatial/ogcapi-environmental-data-retrieval/wiki/Examples#monitoring-station-data is a place to start?

Either way, it will take some effort. It would be really nice to have someone volunteer to move the topic forward. Anyone interested in pushing on it?

[chris-little]

@dblodgett-usgs Unless someone new volunteers, I think the mileage is going to be made by cooperating with the other APIs, such as Connected Systems and others interested in constructing end-user/specific use case services from combined/chained APIs. Then it should be obvious that more alignment is needed.

[dblodgett-usgs]

OK -- I think having some of this information to clarify how EDR could/should relate to those other efforts would be worth while either way. @tomkralidis -- as things have evolved since your OP, what are you thinking on this front?

[KoalaGeo]

In one imagined future, they'd be a plug and play sensor data to EDR from PostGIS provider in pygeoapi.

There is already the STA to Features option. But we got a bit lost discussing STA to EDR mapping.

There's so many potential variables in a sensor DB maybe it's too complex to make a generic mapping for which could be done in a straight yml config

[dblodgett-usgs]

What is the STA to Features option mapping of STA to features?

Setting that question aside for a moment, in general, I totally agree.

The question is, if you were to craft such a thing, how would you map sensor data to EDR? And how can we abstract that from STA to the more general observational network use case?

My take is that:

(using sensor-network as a generic placeholder for the holdings of a sensor network of some kind)

.../collections/sensor-network/items would be a catalog of monitoring locations according to the EDRFeatureCollectionGeoJSON JSON Schema from 8.2.8 represented as OGC API Features.
.../collections/sensor-network/locations would be the same collection of locations but represented with parameter and datetime filters per 8.9.2
.../collections/sensor-network/locations/{locationID} would return the results of observations at the specified location per 8.9.2

Now, how this maps to STA is more complicated because people have implemented STA in various opinionated ways. I feel like we need a sprint and a best practice doc on this topic or something to get it over the hump.

[KoalaGeo]

STA > Features made by @webb-ben

https://docs.pygeoapi.io/en/latest/data-publishing/ogcapi-features.html#sensorthings-api

[ksonda]

Yes here is an example of @webb-ben 's plugin operating on 3 separate STA endpoints https://sta.geoconnex.dev/collections

I think something like you've outlined here is actually fairly doable, because date time in STA is pretty unambiguously a property of a Datastream and parameter unambiguously is an ObservedProperty which, excepting multiDataStreams, is 1:m with Datastreams. The /locations EDR endpoint and query parameters could be constructed from STA expansions that combine Thing, Location, ObservedProperty, Datastream (and Observations for the result responses). For example, this STA->OAF of Things includes links to Datastreams: https://ornl-demo.geoconnex.dev/oapi/collections/things/items?f=json&limit=2 . The datastreams could be expanded to include the datastream properties, and observed property and you'd have what you need to implement date time and parameter queries.

Sensor and FoI I think are going to be unnecessary but optional for an STA->EDR implementation.

[dblodgett-usgs]

Should we plow this content into https://github.com/opengeospatial/ogcapi-environmental-data-retrieval/tree/master/best_practice ??

[tomkralidis]

OK -- I think having some of this information to clarify how EDR could/should relate to those other efforts would be worth while either way. @tomkralidis -- as things have evolved since your OP, what are you thinking on this front?

@dblodgett-usgs perhaps a best practice as you mention on the overall approach, as well as a section on harmonizing from/with STA.

[dblodgett-usgs]

Related to opengeospatial/CoverageJSON#174 -- should we add something about using id of a ceverage for a locationId when the response is a pointSeries?

[ksonda]

Any vector series really.