OSRM client.direction return lat, lon list instead of lon lat like ORS service

[vutle]

Hi Chris, Thanks for this nice library. I can use it on a number of offline routing engines. I think there is a discrepancy in the returning geometry.

The OSRM return lat, lon pair inside the route.geometry instead of lon, lat. Not the same to OSR...

route = client.directions( locations = lnglats, profile='car' )

By the way, is it possible to get the speed and altitude at each coordinate in the geometry?

Best regards

[nilsnolde]

Can you please post an actual request (e.g. with dry_run=True and the raw response and its geometry?

By the way, is it possible to get the speed and altitude at each coordinate in the geometry?

altitude yes, speed depends what you want exactly. refer to the documentation of the actual routing engine for details.

[vutle]

You mean this below?

http://localhost:5700/route/v1/car/144.834014,-37.826133;144.826412,-37.848053?overview=full Parameters: { "headers": { "User-Agent": "routingpy/v0.3.3", "Content-Type": "application/json" }, "timeout": 60 }

when I set dry_run=True, no result is returned.
When I don't set dry_run, the results returned is as follow:

[(-37.82582, 144.83398), (-37.82583, 144.83382), (-37.82585, 144.83338), (-37.82587, 144.83304), (-37.82593, 144.83236), (-37.82596, 144.83049), (-37.82604, 144.83002)....

[nilsnolde]

jep, perfect. you're right there's smth wrong with the coord order. that's a (long-standing) bug indeed. in this line here we should reverse each coord, since the way we implemented decoding polylines (the google standard way) we return lat,long order. While we're fixing this, we should modify the decoding methods to take a order parameter defaulting to latlng which can determine in which way we want the coords to be, instead of reversing smth we could have avoided.

anyways, thanks @vutle , weird it went unnoticed for so long.. if you have an interest fixing this, I can review a PR.