The following guest blog post was written by Albert Sun of the Wall Street Journal. He takes us behind the scenes in the creation of a recent news graphic titled: "Going the Distance: Comparing Marathons".
The Google Maps API has been a great boon for news websites and a great help in creating all kinds of interactive graphics involving maps. Here at the WSJ we're big fans of the API and happy that Google continues to improve it and roll out new features.
We got the idea to map out the routes of Marathons from
a story by Kevin Helliker about how despite the beautiful scenic route of the race, the San Francisco marathon was still very unpopular. The difficulty and the hilly terrain kept people from attempting it. To help people see this better, we decided to compare the San Francisco marathon to the big three US marathons: Boston, New York and Chicago.
The code for
our marathons graphic grew out of a similar graphic we did for our coverage of the Tour De France. In this one, we managed to incorporate many improvements. Two new features of the Google Maps API played a big role in this graphic. The Elevation API let us quickly and easily get a comparison between the different routes.
Styled Maps let us give the map more of a distinctive WSJ look. We have a distinctive style for our maps in print, and there is some reluctance to run maps online that deviate from that style. Styled Maps lets us get close enough for what we're trying to show. When Styled Maps first becomes available we used the
Styled Map Wizard to create a set of different looks for different types of maps, trying to recreate our own maps style.
Along with the Google Maps API, we used jQuery for its wealth of convenience functions and how much easier it makes writing programs in JavaScript. The core of the graphic is a basic Polyline drawn in Google Maps showing the route.
If your path is simple enough, (fewer than 300 or so points) you can take that and directly request elevations along it using an ElevationService object. The elevations are handily returned at equidistant intervals along the path. If a path is more complicated than that, like ours were, you can either break it up into multiple requests, or send a simpler path. We decided to pre-simplify the paths with a Ramer-Douglas-Peucker algorithm (a very useful algorithm for GIS applications) and sent the simplified path off to get elevations.
Taking the array of elevations returned by the API, we used Flot (http://code.google.com/p/flot/) to draw a chart. The result of an Elevation API request retains the LatLng points and elevation for each point along the path in order, so from there it was easy enough to detect the x position of the mouse over the chart and use that as an index for the array of results.
This worked at first, until we noticed that in places where the marathon route was going over bridges, the elevation API was returning negative values. As it turns out, if given a point over water, the elevation API will return the depth of the sea bed. That might be useful for some applications, but was clearly unsuitable for this map. We ended up saving the results from the elevation API and splicing in the elevations of bridges by hand, an inelegant solution, but manageable since we were only doing four paths.
Now, the final feature was Street View, and it really surprised me how easily Street View could be integrated. After registering a Street View panorama object and assigning it a div, it's literally as simple as passing it a LatLng to place the pegman on the map. Because the Street View API responds super speedily to requests, it can mostly keep up with the rapid fire requests from dragging the mouse across the chart.
As newspapers' Web sites continue to draw a larger and larger share of overall readership, its important to keep moving forward in finding and creating great tools for making informative and beautiful graphics.
So, thanks Google for creating such a useful API!
) that I created from the July 28 imagery.
