GIScience
allow for batches of pairwise routing requests
Is there an existing issue for this?
- [x] I have searched the existing issues
Feature/Enhancement Proposal
it would be really handy if there was an option to batch requests for routing, where i want the routes between individual pairs of origins and destinations, but don't need the n by m matrix between all destinations and origins
Additional context
Let's say i have locations A, B, C, D, E, F, G and I want routing between the pairs (A, B), (A, C), (C, B), (D, E), (F, G), (G, A).
At the moment there's two options in the ors request to handle this.
Option 1: Directions Endpoint
requesting directions i have to make 6 individual requests. One for each of the origin-destination-pairs i'm interested in. Depending on the number of pairs this might become a large number of requests quite quickly that all need to be handled individually.
Or if my pairs have some overlap, I can route through multiple segments here for example F to G to A to C to B could be one request, or if i'm willing to drop some unnecessary results later, i can also chain them further.
Option 2: Matrix Endpoint
requesting a matrix, i have to supply a list of locations, here [A, B, C, D, E, F, G].
Then I need to supply the origin destination pairs i'm interested in, by index, so i would supply src=[0, 2, 3, 5, 6] to mark A, C, D, F, G as origins and destinations=[0, 1, 2, 4, 6] to mark A, B, C, E, G as origins.
This only takes one request, but the result will look like the following table where d(XY) is the distance between X and Y, where i'm only interested in the results marked in italics:
| A | B | C | E | G | |
|---|---|---|---|---|---|
| A | d(AA) | d(AB) | d(AC) | d(AE) | d(AG) |
| C | d(CA | d(CB) | d(CC) | d(CE) | d(CG) |
| D | d(DA) | d(DB) | d(DC) | d(DE) | d(DG) |
| F | d(FA) | d(FB) | d(FC) | d(FE) | d(FG) |
| G | d(GA) | d(GB) | d(GC) | d(GE) | d(GF) |
As there are 5 unique origins and 5 unique destinations, I recieve 25 results, while i'm only interested in 6 of these results, which means in the end if have to throw out 76% of this example result, that the ors also spent resources on calculating. Depending of course on the exact combinatorics of the pairs i'm interested in this might be better or worse.
Summary
Both of these options seem somewhat ineffecient and are not exactly intended use for either endpoint
Possible Implementation
I see 3 potential implementations
Expand the Directions Endpoint
At the moment this endpoint takes a list of coordinates A, B, C where it sequentially routes through A, B, C. There could be an option to make the locations a list of lists of coordinates there, so you could request [[A, B], [A, C], ...] to.
This might slightly complicate the structure of this request but would make some sense
Expand the Matrix Endpoint
At the moment this endpoint takes a list of locations, and the two index-referenced lists of sources and destinations for which a matrix is calculated. If you could supply a list of list of coordinate pairs, potentially index referenced to locations that might be a sensible option as well
Seperate Batch Routing Endpoint
A dedicated endpoint for routing through a list of pairs
Maybe even a grid endpoint, where you can pass the the grid coordinates (with option of snapping radius) and can define the neighborhood (4, 8, 16, or 6 for hex) that should be calculated for either hex grid or normal raster.
That way you wouldn't need additional logic for handling the pairs or snapping.
