This is a guest post by Joel Mahoney, a 2011 Fellow at Code for America. Joel worked with the City of Boston on projects related to public education.

Every year in Boston, parents navigate the school selection process in an effort to get their kids into the best possible public schools. The process is complicated, and, depending on the outcome, can leave parents feeling frustrated and confused. DiscoverBPS was designed to make the process more intuitive, and to help parents make better choices for their kids.

Iteration #1 - Geocoded Addresses
In our first iteration, we used a home address and grade level to identify a student's eligible schools, and then displayed the results on a map. In the screenshot below, the green circle represents the student's "walk zone" (in this case, a 1.5 mile radius appropriate to a 7th grade student), the yellow polygon represents the North Assignment Zone, and the markers represent the schools.

With a little help from Google's Geocoding and Maps APIs, we seemed to be well on our way!

On closer inspection, however, we noticed one school that fell just outside of the walk zone boundary, even though – after zooming in and switching to satellite view – the school campus was clearly overlapping with the walk zone:

Obviously, if our goal was to build a tool to make the process more intuitive, we needed to avoid introducing new ambiguities into the system.

Iteration #2 - School Parcel Shapefiles
To solve the overlap issue, we obtained shapefiles for all of the City's school properties, and used a PostGIS-enabled database to calculate distances between the home address and the nearest point on the school parcel. In so doing, we were able to calculate walk zone distances, which allowed us to properly identify schools with walk zone eligibility:

After a several weeks of deep-diving into the internals of PostGIS mapping, we seemed to be back on track.

Stepping back, however, a new consideration came to light: was it fair to assume that a 7th grader could walk from downtown Boston, across the Charles River, and to a school in Charlestown in less than 1.5 miles? A Google Directions search suggested otherwise (the route below is estimated at 1.9 miles):

If the purpose of the walk zone policy was to determine which schools a student could reasonably get to on foot (and to discourage parents from busing their kids to schools on the other side of town), our walk zone circle began to seem misleading.

Iteration #3 - Walkshed Mapping
In the end, we decided to use an open source project called pgRouting (which extends PostGIS to provide geospatial routing functionality) along with OpenStreetMap to derive a "walkshed" polygon and to calculate street walking distances. We also could have used the Google Maps Distance Matrix API to calculate walking distance, but opted to go with pgRouting based on the need to create the walkshed polygon. These tools allowed us to then visualize the walkshed in Google Maps:

Aside from being noticeably smaller than the walk zone circle, the walkshed conveys a representation of walkability that is customized to the home address. Notice how the walkshed area is confined by bodies of water that are not spanned by any bridges.

DiscoverBPS is now live at The walkshed map (which would require policy changes by Boston Public Schools) is being considered for use in 2013.


[Cross posted from the Google Analytics Blog]

Does your organization have several websites, each serving a particular geographic region? If so you know how challenging it is to analyze the data across these regions in a meaningful way.

Visualizations can help, but they can be difficult to design. Newland communities, a developer of residential and urban home communities, manages numerous web properties for each community and is no stranger to these challenges. To address them, Newland used the query tool from ShufflePoint. The tool enabled the combination of data from Google Analytics and Google Earth, allowing Newland to visualize the data in new ways.

ShufflePoint implemented a pilot project after discussing the idea with Chief Ingredient and their client Newland Communities. Their goal: deal with some of the problems associated with clarifying large amounts of data in a visually appealing manner. The outcome of the project was an integration of Google Analytics data with Google Earth.

Using the Google Analytics API, the ShufflePoint query tool extracts metrics by location from Google Analytics for multiple Newland Communities web properties and creates KML representations viewable in Google Earth. The mashup provides advanced visual reporting on location based campaigns, showing their effect on pageviews, and highlighting any anomalies requiring further investigation. Additionally, the visualization is a great fit for promotional videos, or digital signage needs.

“ShufflePoint uses almost every feature and capability of the Google Analytics API. The API has all of the characteristics that a developer could hope for, including great performance, correct semantics, OAuth for authentication, and good community support. The Google Earth based application has given ShufflePoint recognition for doing innovative and challenging things with Google Analytics. This has been beneficial for promoting ShufflePoint’s offerings.” Chris Harrington, CTO

The ShufflePoint application can be found on the ShufflePoint website.

If you’re interested in developing solutions for the Google Analytics platform, visit Google Analytics Developer Program.

One of the biggest challenges of mapping the world is that the world is continually changing. At Google we aim to provide fresh, detailed, and accurate maps that evolve at the same pace as the world around us. As a consequence we’re happy to roll out updated maps for the United Kingdom, Germany, Finland, and Sweden, accompanied by the launch of the "Report a Problem" tool for these countries.

The map updates we are rolling out today include a number of improvements, such as more accurate water bodies, and more comprehensive parks coverage. The “Report a Problem” tool allows Google Maps users, and Maps API developers, to notify Google of errors in our map data, with email notification when their error reports have been resolved. For more information, see our announcement on the Google LatLong blog.

As with previous map data updates, it’s important that any data you have cached for these countries that was obtained using a Maps API service such as the Geocoding API be refreshed following this update. Periodical refreshing of cached data will also ensure that you benefit from any updates and corrections that are applied in future. If you have any questions or concerns, please consult the relevant Maps API forum.