Problem decoding polyline

openrouteservice
1

To create a polyline, I go to
…/dev/#/api-docs/v2/directions/{profile}/json/post
(directions in JSON format on openrouteservice dot org but as a new user I can post only 2 links)
in PATH PARAMETERS, I set profile to foot-walking
in Body, I set elevation to true
I click on call action
I download the response
in the response there is this geometry:

ghrlHkr~s@ogU?D?IC?qEL?I??IA?y@O[yAYsAICSKAIuA_@Og@G?A??SA?K@?C??_@PMuBp@@AIHCQ?q@uH}FC?IG?KC@MC?MAEO?GSAGS?EIoARQA?EC@Eg@uIp@AM??MI[mGwBAMUC?WK@yH?C??C?K@?AY?Eq@??W?AI?_BLtA]BTQoDjA

When I debug decoding using Swift Polyline, it fails with an uneven number of coordinates:
pairs of (lat,lon), the last is only a lat, then the data ends. Apart from the ending, the data appears to be correct.

When I use this tool Interaktives Hilfsprogramm für die Polyliniencodierung  |  Google Maps Platform  |  Google Developers
to decode, it shows something in Africa and coordinate pairs that also appear to be broken.

Am I doing something wrong or is Openrouteservice returning a broken polyline?

Best regards
Gerd
P.S. parameters:

{
  "metadata": {
    "attribution": "openrouteservice dot org | OpenStreetMap contributors",
    "service": "routing",
    "timestamp": 1677275357969,
    "query": {
      "coordinates": [
        [
          8.681495,
          49.41461
        ],
        [
          8.686507,
          49.41943
        ],
        [
          8.687872,
          49.420318
        ]
      ],
      "profile": "foot-walking",
      "format": "json",
      "elevation": true
    },
    "engine": {
      "version": "6.8.0",
      "build_date": "2022-10-21T14:34:31Z",
      "graph_date": "2023-02-07T11:34:20Z"
    }
  }
}
2

You are asking to return elevation (“elevation”: true), so there will be 3 ordinates per location (lat lon elevation) in the response, not just two. So the number of ordinates will always be uneven.
I don’t know Swift Polyline, but either you’ll need to tell it that you’re giving it a polyline including elevation, or in your request you’ll need to set elevation to false.

3

Do you have a hint about the format used? Any reference where it is defined?

Googles polyline tool doesn’t recognise it Interaktives Hilfsprogramm für die Polyliniencodierung  |  Google Maps Platform  |  Google Developers

I also tried the 3 component polyline format defined by HERE before asking the question. Doesn’t work.

I also did’t find anything on the interactive API documentation page.

P.S.
I found it in the source code: a Shapely LineString.
That should be enough information for me to find something.

4

Hmmmm… I may have been too quick with my previous reply. It seems that an encoded polyline can’t really deal with an elevation. If I use your request, with elevation set to true, the polyline ends up quite far north, not at all where it should be:

result: ghrlHkr~s@ogU?D?IC?qEL?I??IA?y@O[yAYsAICSKAIuA_@Og@G?A??SA?K@?C??_@PMuBp@@AIHCQ?q@uH}FC?IG?KC@MC?MAEO?GSAGS?EIoARQA?EC@Eg@uIp@AM??MI[mGwBAMUC?WK@yH?C??C?K@?AY?Eq@??W?AI?_BLtA]BTQoDjA

image
image741×442 164 KB

However, if I set elevation to false, this is the result:
ghrlHkr~s@?DICqELI?IAy@OyAYICKAuA_@g@GA?SAK@C?_@PuBp@AICQq@uHC?G?C@C?AE?GAG?EoARA?C@g@uIAM?M[mGAMC?K@?C?CK@AYEq@?WAI_BL]BQoD

image
image747×453 194 KB

I suspect that google never took elevation into account, and that therefore encoded polyline does not support it, but I’m not sure about that. If you need the elevation, it seems geojson is your best bet. That’s what I would use anyway, since it is human readable, so much, much easier when debugging unexpected results like this for example. And on the plus side, it avoids being dependent on google-invented stuff (which never works properly except for google itself, it seems to me).

5

For the record, HERE has defined a compressed polyline format with elevation and libraries in many languages:

And there is a Swift version that I translated from their Java implementation:
ios - Decoding HERE REST API polyline in Swift? - Stack Overflow (eiprol has improved my version)

For the original problem, I switched to GeoJSON format which doesn’t compress coordinates and elevation at all for now.

6

And why would that be a problem? If I generate a request for a route from the North of the Netherlands to the south of France (1100 km), that generates a geojson with 8710 waypoints. On disk that is 218Kb, but thanks to gzipped communication between my browser and the server, only 68Kb is transferred. Copied from the headers of the request:

Transferred             68.65 KB (217.64 KB size)

content-encoding	gzip
content-length	        69599
content-type	        application/geo+json;charset=UTF-8

So in my opinion there’s no need to worry about data transfer size, which eliminates the need for converting an encoded polyline. Which saves another computing step on the client as well (as I said, I feed these kinds of geojson straight into Openlayers - which handles it beautifully).

7

Hey,

as mentioned, elevation data may be included in the polyline.

For decoding, have a look at our backend documentation and note the “includeElevation” or “is3d” parameters on the function calls.

Best regards

2 Likes
8

I think we should always worry about data transfer size. Depending on what tool you are using (PC, Phone, …) and the Bandwidth that is available to you (LAN 1000 mbit/s, Wifi 8 mbit/s with additional GB limitation per month) it definitely makes sense to lower the transferred data to a minimum.
E.g. if your API should be callable from a phone in a remote area with very volatile internet connection the transfer size definitely is an issue.
So i guess it depends on the user group you are developing for, whether this is a problem or not.

Further rant

Of course you might not need it if you have a fine LAN connection in the office, and only use the tools there, but i think developers should make an effort to keep tools small and tidy.
I see this a lot with desktop programs needing a lot more space due to people just putting code “on top” without refactoring. I mean, yes we do have 1 TB SSDs for less then 100 Euros now a days, so you “have” the resources for hundreds of bloatware programs on your machine, but other people might just want to run stuff on older machines or don’t have the money to buy the latest sh!t.
So i don’t like the trend of developers just not caring about size of their programs. Because if “everyone did it like this” half the code you have on your machines or half the data transferred is just wasted bandwidth or storage.
Don’t have the time to rant further :sweat_smile: but i hope you can see what problem i have with this.

Best regards

9

I agree with you - up to a point.

First: Using encoded polygons requires decoding that data, which requires extra code, which requires extra transfer of data (in the form of javascript code in my case) BEFORE I even send the actual request that causes the data transfer we’re talking about, whether I need that or not. If minimizing the data being transferred requires more code/computing power on the client side, I think your minimization efforts defeat their own purpose.
Second: especially when developing and thus debugging a lot, it is much easier if the data you receive is human readable. Which geojson is, but encode polyline is not. So in cases like this, where something goes wrong with vertices, it makes it rather inconvenient that you can’t actually see what has been sent. So if you are so worried about a few Kb, develop using geojson, then switch your production code to something more optimized (encoded polygon), if you have that possibility (which in this case you have).

While I fully agree that developers should care more about the size of their programs, I also think that we are waaay pas the time of the old dial-up connections (yes, I started out with one of those - giving my age away now), and if your data transfer is still measured in kilobytes, not megabytes, you have nothing to worry about. So again: I fully agree, but at the same time: overdoing it causes it’s own issues and problems.

Oh, and for the record: I DO use geojson over my mobile data connection, even when roaming - especially when roaming, because I’m somewhere where I am not familiar - and thus need route descriptions :wink: It’s no problem at all.

10

That’s what I was searching for.
I have now a working Swift version. I will test it for a while.
How could I contribute it?

Best regards
Gerd

11

Hey,

the backend documentation is live on github, so if you want feel free to open a PR to add the swift code

Please remember to give maintainers push access to your branch on your fork, that makes it much easier to work together :slight_smile:

Best regards