Usage of comma (,) or semicolon (;) for specifying lists in query strings

[caspervdw]

In the /coverages/{coverageId}/data description it is mentioned that:

Meerdere quantities worden opgegeven door een puntkomma-gescheiden string.

This is not compatible with the RFC on query parameters https://tools.ietf.org/html/rfc6570#section-3.2.8 . There exist two acceptable options:

• quantityID=a&quantityID=b
• quantityID=a,b

I would prefer the second one, because the & sign in the first one is misleading for our application (it is not AND, but OR).

So I propose changing it to:

Meerdere quantities worden opgegeven door een ~punt~komma-gescheiden string.

[GeriWolters]

How the parameters are parsed, also depends on the framework used, not only the application. It may be considered ambiguous therefore. The comma version is more intuitive. It also looks somewhat like the filter syntax as used in the DD-ECO-API. Example: filter=quantity:in:['Q1','Q2']

[gerritsj]

Note that for the Point filter parameter both , and ; are used as separators, the former to distinguish x- and y-coordinates, the latter to distinguish multiple points.

[stefhummel]

The web service API's offered by FEWS use the first option: quantityID=a&quantityID=b Indeed the '&' can confusing, but in case of the /coverages/{coverageId}/data end point it actually is meant to be an AND, e.g.: return data for waterlevel and temperature, on point 12.14,36.11 and on point 11.21,38.71.

[stefhummel]

(During team discussion) No duplication of query parameters. No ';' (semicolon) in the url quantityID=a,b leads to a conflict with x,y. Options:

• WKT string approach: point=2.0 3.1,5.6 7.2
• pointx=2.0,5.6&pointy=3.1,7.2

[caspervdw]

Do we really need to support multiple points in one call? In my experience, all-in-one queries lead to complexity very fast.

In my opinion, users may fire multiple requests if they need multiple point crossections.

Also, the term point is obsolete as it is already in the url path (see #10).

I'd propose something like:

data-point/?x=2.0&y=3.1

Note that the WKT string approach will lead to urls like point=2.0%203.1,5.6%207.2 or (if newer urlencoding is used) point=2.0+3.1,5.6+7.2. Therefore I would go for option 2 if multiple points are required.

[stefhummel]

(During team discussion) We will use ../data-point?projection=EPSG:4326&x=2,5,1&y=5,1,2 Depending on the projection, x/y need to be interpreted as lon/lat