EURODEO / rodeo-edr-profile

This is a repository to make EDR profiles used in EURODEO visible for all use
https://rodeo-project.eu/rodeo-edr-profile
Creative Commons Attribution 4.0 International
2 stars 0 forks source link

Additional query string parameters allowed? #6

Open geira opened 1 month ago

geira commented 1 month ago

This is an issue that came up under the RODEO WP5 meeting in Helsinki this summer regarding weather alerts. Our prototype includes the following collections:

With typical requests like these:

/collections/current/locations/56                # alerts for Finnmark county
/collections/test/position?coords=POINT(10+60)   # somewhere northeast of Oslo

The problem occurs when we need to add additional parameters to the query, e.g. to filter on event type or language:

/collections/current/position?coords=POINT(10+60)&lang=no&event=lightning

From a presentation at FOSS4G in Kosovo last year I got the impression that this was legal in OGC API Common Core:

Selection_049

However delegates from KNMI argued that this was probably not allowed in EDR since it is not defined in the Position query spec (even though it is trivial to add to the OpenAPI definition). So the question is:

  1. Is it legal to add custom parameters to EDR queries?
  2. If not, is there any way to filter non-geospatial requests apart from making every permutation of variables a separate collection?
tomkralidis commented 1 month ago

Options:

  1. do not allow any "foreign" query parameters
  2. do not allows any "foreign" query parameters that are NOT defined in the API definition (OpenAPI)
  3. allow for any vendor specific query parameter whether it is explicitly defined or not (this would follow the same pattern defined by OGC API - Features.)
  4. other options?

The question then becomes:

  1. whether this is RODEO specific or upstream in EDR Part 1 and
  2. whether we want RODEO to simply follow this pattern or REQUIRE very specific "foreign" parameter names in a RODEO EDR Profile.

My vote is for option 3. This means an EDR endpoint can OPTIONALLY encode "foreign" parameters. RODEO EDR Profile then simply inherits. If RODEO then requires additional parameters, this would be defined/specified in the RODEO EDR Profile and made explicitly available in the API definition.

mrauhala commented 1 month ago

Wouldn't these be handled as custom dimensions? So it would be allowed in the EDR, but how to deal with the custom dimensions for EDR profile. Propably we would need to agree on set vocabulary for different data types, like radar, warnings and so on.

havardf commented 1 month ago

As I interpret the spec a custom dimension ( and then the corresponding custom parameter in the query), are defined for a collection, and hence should be allowed for all query types specified for that collection?

@tomkralidis I think 3 also. As in, any custom dimension not mentioned in the profile is allowed, but ignored for compliance with the profile. A profile however could add a mandatory custom dimension, but then its explicit in the requirement, openapi and validation tools.

geira commented 1 month ago

2. do not allows any "foreign" query parameters that are NOT defined in the API definition (OpenAPI)

By "API definition", do you mean the canonical EDR OpenAPI schema, or the specific OpenAPI definition for each site linked from the landing page as "service-desc"?

We expect most services will want to write their own API definition, not necessarily to add more query parameters but also to remove unused functionality (e.g. "trajectory") or enumerate values for variables like collectionId, locationId et al.

tomkralidis commented 1 month ago

The API definition would be the OpenAPI document, as per #3.

geira commented 1 month ago

I take it that this is what I meant by "the specific OpenAPI definition for each site linked from the landing page as "service-desc"".

My original question was whether it was actually legal according to the EDR standard, but from the discussion I gather as much. Not sure if I understand what is meant by options 2 and 3 though – I would presume any service using "foreign" parameters would specify them in their own OpenAPI definition (otherwise users wouldn't know it was available). I think the profile should allow this practice as long as the "foreign" parameters are defined somewhere in OpenAPI.

tomkralidis commented 1 month ago

I think we need to confirm whether this is allowed in EDR (as it is in Features), and if not, then whether it should be (by EDR SWG). cc @m-burgoyne

geira commented 3 weeks ago

Consensus seems to be that it is allows as described under custom dimensions (even by some who thought it was illegal previously).