combine bboxes, bcircles and bpolys to single parameter?

[SlowMo24]

All three properties request the same information. As far as I see it they also are distinguishable in terms of input

• bboxes: ...4*numeric separated by , |...
• bcicles: ... 3*numeric separated by , |
• bpolys: ... >=5*numeric seperated by ,|... OR ... JSON |...

I don't know how parsing is done but a regex could distinguish between them. Wouldn't it therefore be possible to provide (maybe additionally) one parameter (e.g. 'targetRegion') that accepts any (but only one) of the three types and then proceeds based on the type given?

This would enhance code re-usability of clients.

[FabiKo117]

Can you shortly elaborate a bit more on what the advantages would be of combining all supported formats into one parameter?

We've initially made this differentiation into 3 boundary parameters with the thinking that it's then more clear in which different formats the user can define the area of interest. So that the name of the boundary parameter gives already some description on the supported format.

[SlowMo24]

yes, having three parameters adds some documentation (and there might be no need to drop them). But having a parameter that accepts all three types would make code more flexible. The user would not have to adapt her code based on the input but could rather concentrate on providing the correct input.

Also from a structural point of view the three seem redundant but that is not my strongest subject ;-) (rather @sfendrich )

[tyrasd]

But having a parameter that accepts all three types would make code more flexible.

One could argue that the bpolys parameter is already the one you're looking for: as it accepts arbitrary polygons you can feed in any bbox (as a rectangular polygon with 4 vertices) or circle (as a regular polygon with sufficiently many vertices to approximate a circle) via the bpolys parameter. The bboxes and bcircles parameters are – so to speak – just shorthand notations for the more powerfull bpolys parameter, saving you the input of a few redundant coordinates in these special cases, which is especially nice when hand crafting ohsome API requests.

[sfendrich]

I don't think that the implicit typing through the number of parameters would be a good idea. If the API is to be extended by further types in the future, these types might have the same number of parameters. The proposed solution could not distinguish the new types from the already existing ones. Examples of such potential extensions are: ellipses (5 parameters), various types of grid cells such as ISEA3H (varying number parameters, clashes with bpoly).

[SlowMo24]

One could argue that the bpolys parameter is already the one you're looking for: as it accepts arbitrary polygons you can feed in any bbox (as a rectangular polygon with 4 vertices) or circle (as a regular polygon with sufficiently many vertices to approximate a circle) via the bpolys parameter.

is there a performance difference betwen bbox and bpoly or are they transformed internally anyway?

[tyrasd]

no, they are no optimizations that "convert" a rectangular polygon to a bbox to make benefit of the (slightly) faster path with bbox-clipping. But the difference in performance should be "small" anyway, and if you have more than one bbox, then the slower path would be used internally anyway.