Open KathiSchleidt opened 3 years ago
Cc: @chris-little @liangsteve
@ghobona @KathiSchleidt The underlying abstract model is probably best thought of as a W3C RDF DataCube specialised so that some dimensions, at least one, are geospatial coordinates, as in W3C QB4ST from Rob Atkinson. I do not think that we need to specialise any more than that. See Use cases in the EDR repo. The EDR API provides for the server to supply to the client whatever metadata and schema are needed to make the data useful.
@KathiSchleidt @Liangsteve What do you think the EDR API is missing and should include from O&M or STA?
TimeSeriesML is probably relevant here as well.
DataCube is a data representation model, related to Coverages. O&M is more of a provenance model.
EDR API appears to be an alternative or successor to SOS, SensorThings + a limited profile of WCS.
This is good, since EDR API uses a more modern API model, and JSON payload, which is much closer to the contemporary mainstream than the XML/SOAP/POST based systems.
The legacy is acknowledged in section 1. and 7.1, but only in-passing. What would be helpful would be a proper explanation of how the EDR API implements the OGC baseline (O&M and Coverages are both part of the Abstract Specification). Then users who are already tooled up for those could more easily be able to connect to EDR APIs and consume EDR payloads.
@KathiSchleidt @dr-shorthair I propose that, as the EDR API spec is now going out for public comment, that as part of the reponses, we cold add a couple of examples of how a EDR API server could expose O&M or Coverage metadata if it is available.
Coverages should be straightforward, as there is an EDR API implementation that sits on a WCS server. Unfortunately, I do not know of any implementation that has an underlying SOS server.
A useful starting point would be side-by-side example requests,
which get essentially the same response.
@sgrellet @arne-broering @simonjirka might be able to help with the former.
@dr-shorthair Excellent suggestion. I'll put it on the agenda and ask for volunteers at today's EDR API standard WG.
One we have some text for both examples, we can close the issue.
@chris-little if you need a simple SOS source, I would suggest the one I set up for AT air quality at the Austrian Environment Agency: http://luft.umweltbundesamt.at/inspire/sos?service=SOS&version=2.0.0&request=getCapabilities Should be quite similar to meteo data, but all point based, air quality time series with hourly values :)
@KathiSchleidt Thanks. Had a quick look. Where are the locations?
Schooling OAB member @chris-little on OGC interface standards. Well done @KathiSchleidt ;-)
If you prefer getting the same data over the SensorThings API, you can use https://airquality-frost.docker01.ilt-dmz.iosb.fraunhofer.de/v1.1 Comparing EDR with SOS is nice, but the future of SOS is SensorThings...
FYI - same Dataset as the SOS/WFS one I mentioned above. As we're well aware of the issues in accessing SOS, we did a quick ad-hoc harvest and reprovisioning via STA when we caught all the news on correlation between Covid outbreak intensity and ambient air quality. This exercise also nicely highlighted the power of underlying standards - transfer from SOS to STA was trivial :)
EDR vs O&M vs STA - shouldn’t this all be coordinated under the SWE DWG?