Street processing has all coordinates multiplied by 10

[sergiyprotsiv]

Hi, I was using the functionality to create the polyline-encoded OSM street export for use in Pelias and realized that at least in my output all the coordinates in polylines were multiplied by 10 (e.g. 120.5 451.1 instead of 12.05 45.51). Maybe something is off with the script, but I could not easily find it in the code. Sergiy

[missinglink]

Hi, can you please provide more information.

I cut the extracts listed in the pelias/polylines readme using this tool (and no-one complained yet) so I suspect it's working fine.

Could you please let me know the command you are running and the PBF extract you are using.

Are the coordinates also wrong when using another format such as json?

[sergiyprotsiv]

Sure, I am using the standard extract for Sweden by Geofabrik. I create the polylines using the command:

./pbf streets sweden-latest.osm.pbf > sweden-latest.polylines

It seems to work fine, but then here is a sample of the generated polylines: qswzoBs{bua@aEfJmZtt@Ramsdalsvägen iuvzoBcaaua@_GhKkYnr@Ramsdalsvägen _bwzoBg}aua@pYuq@lHwIbM{DRamsdalsvägen

The first one decodes to 'LINESTRING(181.88234 591.7524,181.88054 591.75336,181.87196 591.75776)', whereas it should be 'LINESTRING(18.188234 59.17524,18.188054 59.175336,18.187196 59.175776)'.

Using JSON (./pbf json sweden-latest.osm.pbf | head -10) gives correct coordinates.

This is all done on a fairly standard local Ubuntu 16.04, go1.6.2 linux/amd64.

[missinglink]

The issue might be in the decoding tool you are using.

The polylines format allows for a variable floating point precision.

At mapzen we use 6 decimal points of precision, however most other tools such as osrm only use 5.

This additional precision when decoded with a tool expecting 5 will result in unexpected values.

• https://github.com/pelias/polylines/blob/master/stream/parser.js#L8
• https://github.com/missinglink/pbf/blob/master/command/street_graph.go#L51

[missinglink]

Try pasting them in this demo, it decodes using precision 6.

http://valhalla.github.io/demos/polyline/

[missinglink]

Hmm... I'm not actually at my computer yet, I tried it on my phone and it looks like you are correct, the encoded polyline you supplied does not decode well in the demo.

[missinglink]

I'll have a look at it later today. If you would like to move on with your work you can use an alternate strategy to produce the polylines:

https://github.com/pelias/polylines/wiki/Generating-polylines-from-Valhalla

This process is a bit more involved as it requires installing the mapzen routing engine and using it to produce the extract.

Once installed the process is pretty quick. Be aware changes are frequently made to Valhalla and so it's possible that the wiki entry has become out of date since I wrote it over a year ago.

The https://github.com/valhalla/valhalla readme has the most up-to-date instructions on how to build and configure Valhalla

[missinglink]

hey @sergiyprotsiv, on closer inspection I think it's working as expected?

I think I just had a copy->paste error on my phone (you pasted 3 extracts on 2 lines), I tried all the following encoded polylines in the demo and they worked fine (I just needed to ensure the null byte and name was removed)

$ grep -a Ramsdalsvägen sweden-latest.polylines | tr '\000' ' '
q}uzoBsc_ua@kA}JmDkP}Ne_@uKc[qPk]iJaWaY_TeUaPgWqQuNmWaw@o~AgRca@mTqZ}KaVkKyYaKcWuFwPyDqNs@kL?_NbBySvBoKbC{KhEsHrEcH Ramsdalsvägen
qswzoBs{bua@aEfJmZtt@ Ramsdalsvägen
iuvzoBcaaua@_GhKkYnr@ Ramsdalsvägen
_bwzoBg}aua@pYuq@lHwIbM{D Ramsdalsvägen
ghz|lBsqkmU|B{C~BqE~BuFtDmIdDsDtGgB|@WhCMtC|CbBfDxCrF~GtG|FdGxLoAnCc@jC\~FzBtDrCdErD Ramsdalsvägen
y_|cpByfhpb@oDkGgGsUgCmRwBiU}NcgB}PucBo@cMGqHXiHp@{E|AeGlCeHtDsGjBoFfAkFb@{HIeIa@wEi@_EuAeFuQo\uB{HiBqKsHy|@wAwJ_B}FkC}GuY{d@iCeIiBaKyAsWg@krAs@cSqBwNcGuScHuPaOk^sCgEcDeD}DeA_ENsH`EgHbF_GbKyEjMcK|]wElKgCzCsCxBoPxEsPrDiQhCqQbBaJl@as@TwI\wFv@}SzKkd@tXgVtNcVdL??wJ~@eMo@gEpAmGfEmOdIiGnC{GvAkNHmN{CuDB}CzAgDjDmGzLkG|MeZnf@_Zpe@}o@ncAcMhKmMtIo\xRuTxQ{RtU??mG~FsGhC{GlBgNlDsC|AoCpC}a@bv@}`@bv@gGdPyFzPoFdLwOxGgH|EuHpQkQvl@uF`OyFzIkEdGaDxHuHvYyIp[{F|Om@fHcOn]c]~y@sGxiAs\po@kZlT Ramsdalsvägen

I tried copying each of those encoded polylines (not including the space or name) in to the demo app and they appear correct?

[missinglink]

Moving on to other tasks, please let me know how you get on

[sergiyprotsiv]

Thanks, this explains a lot. Somehow from Google's description of the polyline encoding I took the impression that 5-digit precision is the only option. I noticed this issue only since the Pelias polyline importer created some unreasonable values in the streets.db when I tried using two different sources of polylines (one apparently with 5-digit precision and one with 6-digit precision). Will investigate and post it at Pelias. Would be great to document the 6-digit precision somewhere, since this is not standard (I tired both Google's decoder and Postgis before posting here). Otherwise it should be safe to close this issue. Thanks!

[missinglink]

Yea, going with the 6 digit precision is something Pelias inherited from Valhalla, we could probably do better to document it because it's not 'standard'.

If you wouldn't mind taking the time to open a PR on pelias/polylines to add better documentation, I will have time today to review and merge it.

[missinglink]

Can we mark this one closed?