fix(openrouteservice): handle empty summary for identical source/destination points

[Mutlaq10]

Fixes KeyError when ORS returns empty summary for directions with same or very close source/destination points by defaulting distance and duration to 0.
This resolves #158

[mthh]

Thanks for the PR!
Given what other routers (such as OSRM) return when the starting point and destination are the same, it seems appropriate to do this as a way to correct this edge case.

Can you just run black (by installing and running pre-commit hooks, as described in https://github.com/mthh/routingpy/blob/master/CONTRIBUTING.md#setup) so that the code gets formatted correctly?

[nilsnolde]

defaulting distance and duration to 0.

is the empty summary the only clue? IMO that's more a ORS bug, it should server-side do exactly what you're doing here, just like valhalla & osrm. might be worth to raise an issue in their repo @Mutlaq10 .

[mthh]

You're probably right, @nilsnolde. I'll take another look tonight (I can't right now) at what ORS returns in this kind of case (and see if this hack is really necessary).

[Mutlaq10]

defaulting distance and duration to 0.

is the empty summary the only clue? IMO that's more a ORS bug, it should server-side do exactly what you're doing here, just like valhalla & osrm. might be worth to raise an issue in their repo @Mutlaq10 .

it's worth a raise. While I don't know if there is a minimum distance between points to return directions between them, tried random close location and (source==destenation) locations, and I got for the following request:

curl -X POST http://localhost:8082/ors/v2/directions/driving-car   -H "Content-Type: application/json"   -d '{
    "coordinates": [
      [35.0325, 32.4268],
      [35.0325, 32.4268]
    ]
  }'

the following response (which I understand it as (no path between the two locations) :

{"bbox":[35.032517,32.426817,35.032517,32.426817],"routes":[{"summary":{},"segments":[{"distance":0.0,"duration":0.0,"steps":[{"distance":0.0,"duration":0.0,"type":11,"instruction":"Head east","name":"-","way_points":[0,0]}]}],"bbox":[35.032517,32.426817,35.032517,32.426817],"geometry":"sj|dEghytE","way_points":[0,0]}],"metadata":{"attribution":"openrouteservice.org, OpenStreetMap contributors, tmc - BASt","service":"routing","timestamp":1767619339288,"query":{"coordinates":[[35.0325,32.4268],[35.0325,32.4268]],"profile":"driving-car","profileName":"driving-car","format":"json"},"engine":{"version":"9.6.0","build_date":"2025-12-17T16:22:25Z","graph_date":"2025-12-18T18:59:31Z","osm_date":"2025-12-17T21:21:30Z"}

@mthh

[nilsnolde]

the summary should be filled with 0 values, just like the segments.distance/duration. definitely worth raising IMO (and I'm sure it's a very quick fix too). you should only get this behavior for the exact same points (within 6-7 decimals), I'm sure they only exit early when there's no discernible difference between the 2 points given their floating point resolution, everything else should trigger a route, even if just a 1 m.

[nilsnolde]

we can of course still merge this, it won't hurt, even when fixed.

[Mutlaq10]

@nilsnolde @mthh I reported the issue in ORS repo:

GIScience/openrouteservice#2233

[mthh]

Thanks @Mutlaq10!

[mthh]

Great, the upstream issue is now fixed thanks to your report @Mutlaq10!