Elevation API not returning same number of points as sent to it


You can track progress there.

Can you tell me which library you used to decode the polyline? Encoding shouldn’t have any rounding issues as it’s basically just doing an integer out of your float coordinates by multiplying it with 10**5. Decoding however can have rounding problems, esp in Python, where rounding behaviour changed from v2.x to v3.x. So more likely it’s an issue with your decoder.

Hey @nils,

Thank you. I’ll be following the issue.

I’m using the code I found on Graphhopper’s repo to decode the polyline with the elevation. I code with Kotlin/Java.

Its from an old commit though. Lemme try and use the code from their latest commit.

I tried the code from the latest commit. Its the same. Hasn’t changed.
Also, I tried setting the format_out for elevation/line to ‘geojson’ and it too is retuning only 1980 points in a list.

Ah yes, that’s where I ported my implementation from too;) FYI, my question was more targeting the rounding issue.

I’ll look at this today actually, found some free time:)

Actually I don’t understand how the encoding and decoding is working, so I didn’t really understand what you mentioned about the rounding. Is that something I should look into?

Oh thats awesome! :slight_smile:

In a nutshell:


It could make a rounding error in encoding too though (thought it wouldn’t…), if you specify floats with a precision of > 5. So likely that’s where that error comes from. openelevationservice runs in Py3, which did some changes in rounding behaviour compared to Py2.

I think this is more on my side. I recently implemented a slightly different decoding lib into another project, which also allows you to encode precision > 5. Useful for openelevationservice too, so I might just add this today.

This encoding algorithm is really genius stuff. I didn’t understand anything after the first step. I wonder how they came up with it.

Ah I see. So points sent with precision>5 are probably causing the issue.

Thanks for taking this up so soon and working on it. :slight_smile:

Yeah it is! Someday I might try to understand the bit shifting stuff as well;) I got the rounding issue sorted (cross-checked with other decoding libs):

Now, the precision shouldn’t matter anymore. I’ll also implement polyline6, so you can get precision=6 encoded. A fairly easy implementation of the decoding is here:

Just got to your real issue:)

I didn’t touch this service in ages, so it’s good practice really! Should be all live on our servers tonight, the lastest early next week.

1 Like

Awesome!! :metal:

Does this also fix the missing points?

Just got to it. But yes, that’ll be fixed for sure! Hope until tonight.

1 Like

Two questions here -

  1. In an ideal scenario, this wouldn’t really happen right? As in, a polyline returned by the direction api containing multiple consecutive points which are the same.

  2. This only applies when location[n] == location[n-1] and not location[n] == location[x], right?

Oh, I see. Didn’t think you’d have done that to an ORS route. In fact, you can use elevation=true to get the elevation directly in the route response.

  1. You’re right, it shouldn’t IMO. I first thought it might have smth to do with via points, i.e. more than 2 waypoints. I tried around a little, didn’t seem to be the case normally. However, I found a case where I observed the behavior loc[n] == loc[n-1]. Didn’t save the URL though (immediately tried another example…) and can’t reproduce anymore… What I saw was: when there’s via points, there can be the case of a middle leg that only routes from one point to the same point, i.e. duration & distance are zero for that leg. In that case it doubled the coordinate in the coordinate LineString. Hmpf, just can’t reproduce it…

Long story, short: @abhiank can you please share a (preferably small) example where you observed that behaviour? I.e. the query body/URL? Maybe the one with the 50 waypoints would be ideal.

  1. Correct. Think I might just issue a warning in that case, instead of supporting things like that. After all, the endpoint is called line, where consecutive waypoints shouldn’t be the same inherently (I believe). Need the routing response to be fixed though…

Nope, I’m not. I’m indeed using the elevation = true flag. Its great to have the elevation data along with the points itself encoded in the same string.

The elevation requests I’m using to convert old routes with polylines received from Google’s API to be saved in the same format as the responses received from ORS with elevation data.
The polyline with 50 points which I’d shared in a previous reply and my original 2000 points are all polylines received from Google which seem to have consecutive points with the same value.

  1. So, I’m not sure if that same behaviour/error exists in ORS directions api.

A question here - is it a loss or incorrect to simply send back the same points as received in the polyline, regardless of whether they have same consecutive points or not, in the elevation api?

Also, didnt understand -

doubled the coordinate in the coordinate LineString

  1. A polyline could be encoded with random points too, right? (I’m not aware if that technically possible). In case it is, it wouldn’t be a line and would be just a collection of points needing elevation data…

Ok, got ya.

  1. Yes, it did, but like I said, didn’t document the exact query and was unable to reproduce. Not a biggie though generally. Seems to be very rare.

  2. Right. The encoding is not spatially aware, you could throw any integers at it.

See my latest commit, I fixed the behavior returning less coordinates. Now, I wanna include polyline6 as well. And currently struggling with travis, which can take an indeterminable amount of time;) Should be online early next week still I hope.

Awesome. Sounds great!

Cool. I’ll test that out again and report back on the same thread if I see any issues.

Thanks @nils! :slight_smile:

Ok, just updated the servers with the latest version, including polyline6 support:) Careful though with polyline6, there’s no implementation I know which considers elevation. However, it’s not far away from GH’s encoding code. You can try to port my code, if you feel you’d like to have 6 decimal points precision on coordinates:

BTW, I found a bug in my previous decoding, which swapped X,Y… So, best re-do what you’ve done before.

1 Like


i am using openstreetmap with ajax,javascript code with C#.Net code

i am calling service and getting positive responce

after getting responce how to show route instead of polylines

I am able to show lines between 2 points but i need to show route not lines.

Vamsi krishna

Guess you want openrouteservice, not openelevationservice…



i am using direction service. Please below code which service i am using it.

i need to show the directions please le me know.

                 var baseAddress = new Uri("https://api.openrouteservice.org");
                 var response = httpClient.PostAsync("/v2/directions/driving-car", content).Result;
                responseData = await response.Content.ReadAsStringAsync();

Wait, I remember you now from this one

Sorry man, can’t help you.