Open koebi opened 3 years ago
This would be an API-breaking change, but another idea could be to reconsider the concept of locations
in IsochroneRequests
.
It's nice that the API supports multiple locations, but correlating two request parameters (i.e. knowing that location
at index 0 corresponds to range
at index 0) could be a little fragile or confusing for clients.
One suggestion to make the connection more explicit would be to bundle the range
and location
into the same object. In that case they'd become more like a queryLocation
.
# IsochronesRequest
{
"queryLocations": [
{
"location": [8.681495,49.41461],[8.686507,49.41943],
"range": [200,300]
},
{
"location": [7.681495,49.41461],[7.686507,49.41943],
"range": [100,200]
},
...
]
}
(if so, there could be practical implementation details -- and performance / resource consumption considerations -- as a result of allowing varied combinations of queries in a single request, but perhaps they're better handled generically at a lower level using per-request resource governance or something along those lines)
This results from the original documentation of the
range
parameter mentioned in #882.Currently isochrone endpoint supports multiple locations, but will apply the same range(s) to all of them. It might be useful to be able to specify ranges for each location separately.
Possible implementations are
range
parameter accepts an array of arrays of range values if multiple locations are given. Each array specifies the ranges for one of the locations, in orderrange
parameter sets a maximum range for each location separately. Theinterval
parameter could be used to specify intermediate ranges.