Upper limits in input destination in Computing the Distance Matrix

[Anran0716]

Does any one know how many destinations at most should be set in Computing the Distance Matrix? I set 300 candidate destinations and 33 origins. Then the error shows like this:

JSONDecodeError: Expecting value: line 1 column 1 (char 0)

My code: all_locations = demand + cand source_indices = [i for i in range(n_demand)] target_indices = [i for i in range(n_demand, len(all_locations))]

client = OSRM(base_url="https://router.project-osrm.org") osrm_routing_matrix = client.matrix( dry_run=False, locations=all_locations, sources=source_indices, destinations=target_indices, profile="car", ) cost_matrix = np.array(osrm_routing_matrix.durations)

If I set at about 200, everything goes fine. So I guess this has reached the maximum of API port. Does anyone know how to change the upper limits? Looking forward to the reply! Thx!

[chrstnbwnkl]

I think the maximum table size the OSRM demo server allows is 10k, which should be fine for your example, as you'd be generating a table of size 9900. The actual issue is that the URL is larger than what the demo server allows (see this issue).

You could run your own OSRM instance using e.g. Docker (see OSRM image and instructions here), then connect to it using routingpy, or skip HTTP entirely and try the Node.js bindings (we have a tutorial about to go about that here).

If your use case doesn't get much bigger than your example, you could also simply split the request in two parts and merge them afterwards :smile:

Anyway, I'm closing this because it's technically not an issue with routingpy itself. Good luck!

[nilsnolde]

Totally agree, though would be better if we could catch that and throw more sensibly. I can’t remember, do we do a catch-all for anything else than 200 code? Seems it tries to deserialize the JSON too early in our client no?

[chrstnbwnkl]

The server responds with html containing the error details, so we would need to parse that specifically. The message does show up in the Traceback as a raw html string. As far as I'm concerned that's just poor API design from the OSRM demo server, I don't see why we should handle this specifically.

[nilsnolde]

And it's a 2xx HTTP response status?

[nilsnolde]

From the issues in OSRM it seems it's a 400 status. I'm not saying we should parse that HTML, but we shouldn't let json throw on invalid stuff either IMO.

Yes, poor API design.. JSON APIs shouldn't return HTML, that's weird..