It’s Fab Friday again! This is getting fun, I like doing this. This week’s theme is Street View. First up, Andres Ferrate from Maps Developer Relations (or MDR as some of us are calling it these days) produced this screencast on incorporating Street View and Custom Panoramas into your app. Check it out:
Next up, we have Historypin. Historypin is a site that lets you upload and view historic photos in Google Maps. Better, you can actually view them on top of current Street View imagery. Here’s a screenshot from Florence, Italy:
Finally, there’s the fabulous gta4.net fan site that uses the Google Maps API Custom Street View Panorama API to render Liberty City entirely in Street View. Let me be clear, not the Liberty City of Florida, but the fictitious city in the video game Grand Theft Auto IV. Lots of fan hours went into doing screen capture, let me tell you.
Posted by Mano Marks, Maps Developer Relations team
pyKML is an open source Python library for generating, parsing, and modifying KML, the geo-spatial data language used by Google Earth, Google Maps and a number of other GIS platforms.
I was motivated to create pyKML because I frequently need to visualize large, and often complex, environmental datasets. While the KML language has a wide range of options for styling, annotating and interacting with geo-spatial and temporal data, most programs that generate KML don’t take full advantage of these rich features. I created the pyKML library to address this problem by providing easy, programmatic access to all KML elements.
pyKML facilitates working with large and complex KML documents by leveraging the use of basic programming constructs (looping, branching, etc.). In this regard pyKML is similar to libkml, Google’s open source C++ library, but takes advantage of the highly readable syntax of the Python programming language and the processing capabilities of the popular lxml Python library.
As a simple example, check out this Python script that loops through a text string (“Hello World!”) and uses pyKML to create a series of KML Placemarks. You can download the resulting KML document, and below is a screenshot of how it looks in Google Earth.
We’ve been talking a lot recently around the Maps Developer Relations Team about heat maps. Heat maps use colors to represent the intensity of occurrence or certain values. Heat maps are a popular way to represent data. People often ask me how to create them themselves. So the other day when I ran across heatmap.js, with it's nifty Google Maps API Heatmap Overlay, I thought it would be perfect to share with you. Heatmap.js uses HTML5 Canvas to render the heatmap on top of the map. Apparently, it’s in early release, so feel free to help the developer, Patrick Wied out with some patches. Here's what it looks like:
On another note, we recently announced that several college campuses are now available in Google Street View, in areas outside roads. That data is now available to you in the Google Maps API. Here’s the Quad at Stanford:
Finally, if any of you are going to be at Strata, Chris Broadfoot and I will be presenting a workshop there March 1st called Beautiful Vectors. Check it out or just find us and say hi.
Posted by Mano Marks, Maps Developer Relations team
Inspired by Scott Knaster over on the Google Code Blog, I’m starting a new tradition of Fab Friday on the Google Geo Developers Blog. On most Fridays I’m going to post about something cool going on in the world of Google Maps. Nothing formal! So please don’t wear a tie to read my posts.
I’ve got a couple of fun things today. The first one comes from a member of my team, Chris Broadfoot, who put together this great screencast on working with the Styled Maps feature of the Google Maps API:
I also found a cool map you might like. The Domesday Book was the result of a survey in England commissioned by William the Conquerer and completed in 1086. It was a survey of all the landholdings in most of England and parts of Wales. Open Domesday maps this survey. And it also has an API in case you want to play with the data yourself.
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 www.discoverbps.org. The walkshed map (which would require policy changes by Boston Public Schools) is being considered for use in 2013.
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
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.
Posted by Thor Mitchell, Product Manager, Google Maps API
