Standardizing API Parameter Syntax

[cmheazel]

Action to the OGC NA

Establish rules for encoding parameters for use in URIs.
For example, how should you encode a bounding polygon?

• What is the delimiter to be used between the coordinates?
• What is the delimiter to be used between the two or three axis values within each coordinate?

[pebau]

WKT?

[cmheazel]

API Features cites RFC 3339 as the authority for the datetime parameter format.
I also like the WKT option.
And I'm sure there are other relevant standards we can leverage.

[nmtoken]

WKT does seem a better option, considering OGC has already identified a range of communities who use time representations based on calendars which are not the Gregorian calendar as recognised by the International Standards Organisation (ISO) in ISO8601

[jerstlouis]

Is geometry description within scope of Coverages - Part 1?
As mentioned in #52 this may be the focus of the EDR API instead.

[ghobona]

Related to opengeospatial/ogcapi-common#34

[ghobona]

2020-12-02 OGC-NA meeting today did not reach agreement on this issue being out of scope of the OGC-NA. As a result, the next step will be to establish rules for encoding parameters for use in URIs.

[KathiSchleidt]

an additional spatial query option we've been pushing around in STA is filter by external geometry reference, saves you the mess of transferring a geometry via URL (or having to POST), just point to a URL that returns a geometry within the feature:

opengeospatial/sensorthings#110

[chris-little]

@KathiSchleidt @ghobona One option that we considered in API-EDR, and can support, though not really thoroughly tested, is storing the query (which is a geometry) as a feature, for re-use.

[pebau]

indeed an option. In WCS we have not brought this on the agenda because

• this opens a can of worms in access control (updating queries including transaction support for those who just use a query during update, granting/revoking access, ...)
• the service of stored queries as such is domain and data independent, so should be a generic service which works the same over all specs. And OWS Common was far from getting to discuss that kind of problems...

[jerstlouis]

Is this issue focused on geometry parameters? Adding the extension label based on that assumption.
Could we update the name of the issue to better reflect this?
Also related to #52 ?

[cmheazel]

API-Common Part 1 provides instructions for query parameter encoding including capitalization, delimiters, escape characters, internationalization, handling of nulls, boolean encoding, integer encoding, decimal encoding, double encoding, and the encoding of special characters.

One could argue that WKT is a string and not subject to the numeric encoding rules.

[jerstlouis]

SWG 2021-08-11: The geometry encoding is discussed in #52; general concerns about query parameters are addressed by Common - Part 1. Agreed to close.