Drawing Thousands of Polylines via Google Maps API V3

My team is working on an Electron app built with Node that allows route plotting via Google Maps API V3. The goal was to display routes on a nationwide view, drawing more than 500,000 polylines.

At the beginning of this task, the app would run out of memory trying to plot lines in a view of multiple counties. We found that by streamlining polylines (making them thinner and more compact) and adding some zoom logic, we were able to paint a clear picture without sacrificing the value of the program.

1. Simplify Polyline Points

The coordinates in our database were set to the standard 12 decimal degrees of precision, and not all of them were needed. We were able to reduce those decimal degrees based on zoom levels.

We then filtered out duplicate coordinates, thus reducing some memory usage. There are many ways to remove duplicates from an object. Below is a great example by Adam DeHaven on how to filter out duplicates with multiple key properties:

function getUniqueArray(arr, keyProps) {
  return Object.values(
  arr.reduce((uniqueMap, entry) => {
  const key = keyProps.map((k) => entry[k]).join('|')
  if (!(key in uniqueMap)) uniqueMap[key] = entry
    return uniqueMap
  }, {}),

Parameter keyProps is an array of all the key properties that are being used to find distinct values.

2. Encode and Decode Path

Google API V3 has a handy encoding method that will translate a 2D array of coordinates into a string. A call of decodePath will translate that string back into an array to be the path in making a polyline. As the documentation indicates, passing around arrays can become bulky. A simple string is significantly more lightweight, especially when we are processing thousands of them at a time.

Using the two methods described so far allowed us to plot the view of multiple states. But we hadn’t yet reached our goal of plotting routes across the whole nation.

3. Reduce Polyline Quantity Without Distortion

Our next attempt was to reduce the actual number of polylines drawn without distortion. To come up with the right polylines to filter or reduce, we needed to ask what mattered to our users at a nationwide level. If a user zooms out to see the whole nation, they most likely want a broader picture of the routes and won’t notice very short polylines.

The actual length of polylines to be filtered out depends on how many polylines there are to begin with. We adjusted the length to see what gave us the closest accurate picture without distortion and found that filtering out all polylines less than 1 mile long worked for us.

4. Zoom-Level Logic

We still wanted to give as much accuracy as possible at every view, so we needed to come up with a zoom-level logic that tied all of our filters together. For example, we recognized that we were only able to reduce the number of polylines at a nationwide view. If we reduced the number of polylines at state-level views, our routes would look like they were missing pieces. The case was also the same for reducing decimal points down to 2 decimal degrees. This required a lot of manual testing to figure out the best combination at the right level.

You might have noticed that “reducing memory usage” appears a lot in this post. We paid closer attention to this because it kept the program lean and allowed us to emphasize more useful polylines. After combining all of the methods above, we were finally able to effectively plot routes across the nation and provide value to our users.