search

opengeospatial / ogcapi-environmental-data-retrieval

A Web API that provides a family of lightweight interfaces for accessing Environmental Data resources.
https://ogcapi.ogc.org/edr
Other
59 stars 26 forks source link

PublicComment 1.1: Variables in channel? #530

Closed m-mohr closed 5 months ago

m-mohr commented 6 months ago

I'm currently reading through https://docs.ogc.org/DRAFTS/23-057.html as part of the RFC.

In section 8.2.4 I'm wondering how the variables in the channel properties work. There's an example that uses {collectionId}, but I'm unsure where the variables are defined etc. Or are these channels somehow defined externally and are "hardcoded" values that e.g. refer back to specific endpoints? I think this should be explained better. There's not a lot of info on channels in 8.2 (seems to come in 9, but that's after 8.2 so leaves the reader confused).

Looking a bit into the future: I think this would also be great extension for STAC API, which could be built on top of EDR PubSub. Does the specification allow extensions, e.g. that a potential channel in STAC could be a specific search query such as /search?collections=A,B,C&datetime=2020-01-01/..?

chris-little commented 6 months ago

@tomkralidis @m-burgoyne For your info.

ilkkarinne commented 6 months ago

As requested by Steve Olson at the OGC MM Delft meeting, I'm providing a quick use case for spatial filtering functionality at PubSub API provider side. Note that this is not a request to make any changes in the current specification. I'm aware that due to varying technical capabilities in the underlying implementation protocols it may not be feasible to specify a general solution to this issue:

It would be very useful in some use cases to be able to attach a simple BBOX filter to the collection item subscription. Let's say that there is a collection for point weather forecasts of cities globally. Living in Europe I would like to be able to receive new forecast updates of only the cities located in Europe. I can of course filter the results at client side, but this may result in a majority on subscribed notifications to be sent over just to be immediately discarded at the client side.

I'm also aware that implementing a subscription filters at the provider side would require allocating additional computing and memory resources at the provider side.

m-burgoyne commented 6 months ago

@m-mohr @ilkkarinne @tomkralidis @chris-little Digging into the AsyncAPI spec the Operations Bindings object supports the definition of protocol specific capabilities. The AWS SNS definition is an example of how filtering would be defined

chris-little commented 6 months ago

EDR API SWG 115 discussed this. The issue is that most use of variables and filtering is protocol specific and has to be addressed through the AsyncAPI schemas. General filtering of resources is not really a PubSub functionality.

Client side filtering is possible, but again not a function of the PubSub approach.

@m-mohr We do not propose to alter the specification in response to this issue.

m-mohr commented 6 months ago

I don't think this issue needs a functional change, but a bit of either restructuring, or better linking, or better descriptions. Something that is occuring in 8 is only introduced in 9, that's not ideal and confusing.

tomkralidis commented 6 months ago

@m-mohr I've added some explanation around the link channel in #539. The variables in the examples have been replaced with proper examples (because the channel property should not have tokens; they were only there for example purposes). As well, Permission 2B provides some guidance for a link channel.

chris-little commented 5 months ago

@m-mohr Are you happy to close this issue once @tomkralidis PR #539 merged?

m-mohr commented 5 months ago

Looks good, thanks.