Additional query string parameters allowed?

[geira]

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:

• current: currently active alerts
• archive: alerts for the period 2017-2023
• test: fictitious alerts for development purposes

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:

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]

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]

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]

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]

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]

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

[geira]

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]

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]

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