Support Multiple Locations in the /nearest API

[muteebali]

Description:

Currently, the OSRM /nearest API supports querying the nearest routable node for a single location at a time. This limitation results in increased overhead and slower performance when multiple locations need to be processed, as each location requires a separate API call.

Feature Request:

Add support for multiple locations in a single /nearest request, similar to how other OSRM APIs (like /route, /table, etc.) accept multiple coordinates via a semicolon-separated list.

Proposed Usage:

GET /nearest/v1/driving/13.388860,52.517037;13.397634,52.529407?number=1

Expected Behavior:

The response should return the nearest node(s) for each of the provided coordinates in the order they are specified. This would significantly improve the efficiency of nearest-node queries when working with batch data.

Benefits:

Reduced number of HTTP requests.

Improved performance and lower latency.

Better alignment with batch processing use cases.

Consistent API design with other OSRM endpoints

[DennisOSRM]

Interesting idea. Thanks for sharing.

[jcoupey]

similar to how other OSRM APIs (like /route, /table, etc.) accept multiple coordinates

The fundamental difference though is that when providing multiple coordinates to other endpoints, they're part of a single coherent request, answering an atomic question like finding a route through a number of waypoints or matching a trace.

In the case of nearest, the multiple coordinates would be totally independent so that sounds more like a batch treatment.

[muteebali]

@jcoupey You're absolutely right — each location is an independent entity. It would be great to process multiple locations in a single api call and return one result per location. This approach helps minimize round-trip overhead and improves overall efficiency at caller end.