Polyline Precision

When you send a request to the Mapzen Mobility APIs, part of the response you receive may appear to be nothing more than a jumble of characters. However, this is actually something known as an encoded polyline that stores a series of latitude, longitude coordinates as a single string, and greatly reduces the size of the shape.

This polyline…


…encodes these points:


What you see when the precision is off

One of our most common technical support requests is from users attempting to encode or decode a route response with fewer than six digits of precision. Doing this can result in nonsensical coordinates, negative elevations values, or points showing up in the ocean—far away from potential route paths.

For example, a user working with Map Matching recently noticed, “I always get error 171: No suitable edges near location, and some weird positions like [378.07744, -1224.19701], [378.07744, -1224.19756]…” It turned out the user had decoded with a polyline utility from Google, and the problems were fixed by switching to Mapzen’s code.

Why six digits of decimal degree precision?

A key distinction of how Mapzen APIs integrate encoded polylines is that they use six digits of decimal degree precision. This is an enhancement of the algorithms from Google and the APIs from other mapping providers that use five digits of precision. That additional digit gives you extra detail and can return more accurate results along a path — at the equator, six digits gives you 10cm of precision, while five digits yields about a meter. This can make a significant difference in the placement of a route on a road. Also, GeoJSON recently standardized on 6 digits of precision.

The requirement for using six digits applies to any API that accepts inputs of or returns encoded polylines, including Mapzen Turn-by-Turn, Isochrone, Optimized Route, Map Matching, and Elevation. These use calculations from Valhalla, the open-source routing project.

Why does a difference in precision cause issues? The last step in decoding a polyline involves converting an integer into a decimal coordinate, with the presumption that it will be a certain number of digits long. Using five digits of decimal precision instead of six in this last step will lead to the decimal point being placed in the wrong location.

If you have trouble remembering the number of digits with Mapzen APIs, these rhymes can help:

Fewer than six, you need a fix.

With only five, results take a dive.

Use five plus one, you are done.

Decode with our tools for test, results are best.

Tools for decoding with six digits

When you are working with Mapzen’s APIs, only use our tools to decode polylines. In the Mobility documentation, you can find sample code to decode shapes in JavaScript, C++, and Python. We also built this handy tool where you can paste an encoded polyline string, decode it, and see the locations on a map (and save to GeoJSON).