osrm-backend
osrm-backend copied to clipboard
Project-OSRM
Api parameters
Hi, In API service, is there any restriction to pass number of coordinates (parameters) for getting the result. for example if i want to solve travel salesperson problem with more than 20 points, i have to pass the those point coordinates as parameter in trip service api to get the result.
so i want to know to is there any other way to pass the n number of coordinates as parameter or is it possible to customize the api in the backend??
all clients have some limitation on the URL length, usually around 8000 characters which translates to like 400 coordinates or so (unencoded). unless you put in a lot of work there's no POST endpoint, it's all GET.
@ayrus96 For solving "larger" TSP instances, you might want to look at a specialized TSP engine - I see @jcoupey tagged this, his https://github.com/VROOM-Project/ would be something you could look at.
OSRMs /trip plugin is not particularly sophisticated. It uses brute force up to 10 coordinates, then a heuristic called "farthest insertion" for coordinate counts above that. It will probably not give very optimal solutions for larger problems.
The osrm-routed service has some default limits - do osrm-routed --help to see the options. By default --max-trip-size is 100 coordinates, but you can increase that yourself.
osrm-routed only supports HTTP GET requests, but it has no intrinsic limit. If you need to send a lot of coordinates, you will need to use a client HTTP library that supports sending very long GET requests (the curl command-line tool is one example that has no limit, https://curl.se/mail/lib-2011-01/0205.html - you would be limited by your shell, e.g. bash in how large parameters it supports passing, which I think, by default, is 16MB).
I did initially also try to respond upon tagging this issue, mentioning the various --max-* options, but it seems like my comment never made it through.
On the TSP side, I'd also expect VROOM to provide better solutions especially for larger instances. The computing times may be a bit longer than the simple heuristic implemented in OSRM, but it should not be a problem unless targeting somewhat huge instances.
