We’ve upgraded our broadband map! It tracks ten times as many lit buildings and is faster! How was this magic accomplished?
First, let’s back up and take a tour of the map as it was. In a word: KML.
KML (Keyhole Markup Language) is XML with geolocation data elements added. If you’ve ever viewed points in Google Earth, you’ve probably seen KML at work. Google Maps natively supports loading KML and it turned out to be a pretty good option for mapping static points. Because Google is adding the markers to the map directly, a KML layer can have thousands of markers instead of hundreds.
To create the broadband map I wrote ruby scripts (rake tasks) that parsed our points data into five KML layers: central offices, lit buildings, EoC coverage, and two for DSL coverage. To handle DSL and EoC coverage — transparent circles centered on a central office — I generated KML files that specified circular polygons and styling. I parsed the central office data, checked to see if it was DSL or EoC, and then calculated 30 points in a circle around the central office to form the “circular” outline. KML allowed us to specify markers for the points and the coloring/alpha transparency for the polygons.
A typical central office point:
<description>1049 N 3RD ST</description>
A typical DSL coverage area:
KML worked out great, except for two things. First, it was slow. Turning on the DSL layer could take up to ten seconds to complete — an eternity in modern browsing! Second, our lit buildings’ data quickly ran up against Google’s size and complexity limits for KML data. We had to split our DSL coverage into two layers because of the size limits. To fully bring up all 300,000 lit buildings would’ve required over ten KML layers to be loaded in sequence. At that point we’d be talking over a minute to load the points.
Last week I was determined to get a solution. At first I thought that network linked KML files would be the key. After all, the Google Maps documentation said it was the way to go if you needed to render a large number of points. The idea here is to have a bunch of KML files split out by region and Google Maps will only load the files that are needed. Parsing our existing KML files into regions was a bit tricky and I never came up with a good solution. The files I generated would work just fine in Google Earth, but I never got them to load correctly in Google Maps. I suspect that I was running into the Google Maps limit of no more than ten network links per KML file.
My research led me back to Google Fusion Tables. Fusion Tables have always been labeled “experimental” in the maps documentation, but faced with slow load times, too many points, and recalcitrant XML I figured it was worth a shot. In a word: Wow! If you’ve seen the broadband map lately, then you can see the kind of speed this change has brought. Points now load so quickly that they seem as if they are native map features. We are completely pleased with their result.
Google Fusion Tables are essentially spreadsheets on the web, but spreadsheets that have a direct connection to Google Maps and that can natively import KML files — even KML files that define polygons. For our purposes they’re essentially fast hosting for our KML and that’s perfect! But it gets even better. With Fusion Tables we’re able to change the marker styling with the click of a mouse in the browser, change info window text directly, load different columns of data, completely control the coloring of the layer polygons, and get access to a bunch of really nifty map features that are simply unavailable to standard points. Most of that was possible before, but required recompiling the KML and uploading the file.