(Cross posted on Google Maps Lat Long Blog) 

Today we’re launching an update to the Google Maps Android API, which gives developers the ability to use Google’s comprehensive, accurate and useful maps to build beautiful Android apps. The updated API is easy to use and features vector-based maps that load quickly and enables users to easily navigate 2D and 3D views, and tilt and rotate the map with simple gestures.

With the new version of the Google Maps Android API, developers can utilize Google Maps to its fullest. We’ve incorporated many of the highly-requested features developers want, such as:

• More dynamic and flexible UI designs for large screen Android devices, such as tablets, using Android Fragments

• Adding more Google Maps layers in their apps including satellite, hybrid, terrain, traffic and now indoor maps for many major airports and shopping centers

• The ability to create markers and info windows with less code

Some of our favorite apps already use Google Maps, such as Trulia, Expedia Hotels and FlightTrack. Soon, when you upgrade to the latest version of these apps, you’ll experience the new API and maps as rich as those in Google Maps for Android.

With the latest Google Maps Android API, Trulia Android app users can search for a place to buy or rent in 3D.

To hear from these developers about their apps and migration to the new version of the API, check out the following Google Developers Live video below.

More than 800,000 sites around the world use our mapping APIs to create amazing and useful apps. We hope you enjoy using this new addition to the Google Maps API family and building mapping experiences that were never before possible on a mobile device.

To get started, follow the Google Maps Android API v2 documentation and reach out to the developer community if you have questions on building your app with this API.

Posted by Andrew Foster, Senior Product Manager, Google Maps

Map of the Week: GetFlight.com.au

[Editors Note: Last week we lauched morethanamap.com to showcase the unique features of the Google Maps API. As part of this, each week we’ll be featuring one story from our global community of developers who are using the Google Maps API to start businesses, help improve their communities or save the environment.]

As part of morethanamap.com, we went around the world to speak with developers who are using the Google Maps API. Sydney, Australia was our first stop, where we met with GetFlight.com.au founder Ian Cumming at the Fishburners coworking space.

GetFlight is an Australian-based airfare search site that uses the Google Maps API to help users discover cheap airfare to global destinations. This site is tailored to Aussie travelers who don't have a particular location in mind and want to visualize where in the world they can travel within a certain price and date range. This ‘go anywhere’ exploratory travel site is something that’s really unique to the mindset of the Aussie travel. Another thing that really stands about GetFlight is that the entire site is built, operated, and maintained by Ian alone. It’s a true testament to the Australian entrepreneurial spirit.

The site takes advantage of Styled Maps and Google Maps API v3 to ensure that the site works on multiple devices. For GetFlight, it’s critical to their users’ experience that the site works as well on a tablet device as it does on a desktop. Using Styled Maps, Ian was able to create a more branded and simplified look for his application. There’s even the ability to view flight routes with geodesic lines which are more true to the actual flight paths. In the video below, Ian walks us through the ins and outs of his site and also shows us how the site works on multiple devices in real-time.



You may have noticed something a little peculiar next to Ian’s laptop in the video: an older model Dell Pentium 4 laptop. Ian uses this laptop to test and debug all his work. Ian’s philosophy is, “if I can make it work well on here [the older laptop], I know it’s going to be screaming fast there [his newer laptop and tablet].”

A big thanks to Ian Cumming, founder of GetFlight.com.au, for inviting us into his office and sharing with us his latest project. To learn more about GetFlight.com.au and the things that you can do with the Google Maps API, visit morethanamap.com. Tune in next week to read about our visit with Computerlogy in Bangkok, Thailand.

Posted by Carlos Cuesta, Google Maps API Product Marketing Manager

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.

Editor’s note: Today we have Peter Batty from Ubisense to talk about how the company is using Google Maps API Premier to make sense of complicated GIS data. This is cross-posted on the Google Enterprise blog.



Large utilities and telcos have very large amounts of geospatial data about their network assets, typically hundreds of tables and millions of records, and complex rules for how these should be displayed on a map. Ubisense myWorld is a Software as a Service (SaaS) product that brings the ease of use and performance of Google Maps to the challenge of presenting these complex network maps in a way which is simple to use. myWorld uses the Google Maps JavaScript API V3 with Google Maps API Premier.

The data for these network maps is stored and maintained in a Geographic Information System (GIS). These systems have been around a lot longer than Google Maps, for 30 years or so, and tend to be powerful but complex to use. We have focused on working with data from GE Smallworld for utility GIS, but can also work with data from ESRI and others. We render the network data from the GIS to raster map tiles to create an image map overlay that is displayed on top of the Google Maps basemap. The advantage of this approach versus using a vector data format is that it is much easier to match the cartographic design of the network maps used in the GIS, and the users expect consistency between the systems.

All features on the map need to be clickable so that users can display information about any of the network items such as cables, poles, transformers, etc. To handle this we just define a click event that queries a server to find items close to that point. We use a system called Arc2Earth Cloud, which stores spatial data in Google App Engine.

One cool feature of our application is its tight integration with Google Street View. You can click on an object on the map, such as a pole or a building, and see a Street View of that object. This gives the user additional information that they can't get from their existing GIS database. We calculate the right bearing for the Street View automatically, and this works surprisingly well, given the potential for mismatches between the Street View and GIS location data. When necessary, the user can adjust and save the view, over-riding the automatic view. We can display markers in the Street View and click on them to display attributes of poles or other characterisitcs - this is a great feature of the V3 API.

The JavaScript API gives us great portability across multiple platforms. Mobile applications are very important in utilities, as access to and update of map data is often done by field workers. Being able to access the same functionality not only in desktop browsers but on smart phones such as the iPhone or Android, or tablets such as the iPad, is a major benefit. Our main application runs really well on the iPad without any change, and we also provide the same functionality but with modified layout on smart phones. We take advantage of the GPS devices in the phones and link to the built-in maps applications for routing.

I've developed geospatial applications on many platforms over the past 20 years, and have been really impressed with how quickly we were able to develop a pretty sophisticated application with Google Maps V3 JavaScript API, while keeping everything very simple for users. We have a lot of ideas for further enhancements, we are just scratching the surface!


Posted by Peter Batty, VP of Geospatial Technology, Ubisense

We’ve just launched Tripline (http://www.tripline.net), and we’re excited to talk about how we’re using Google Maps. We’ve been laboring for months in solitude, so it feels great to finally talk about what we’ve built.

Tripline is all about maps. The Tripline concept goes back to 2005 when I started manually creating map-based plans to visualize upcoming trips. I’m one of those people who can stare at the moving map on an airplane for the duration of a long flight, so my desire to understand travel from a geographical viewpoint is inherent, and I think quite common. And, as we so often see in movies, a moving line on a map is a great way to tell a story.

The Tripline Player uses the Google Maps API for Flash and animates progression from point to point using a simplified KML-like data structure. We chose Flash primarily because it was the best platform to combine the maps, animation, and soundtrack elements that were part of the design. It also means that trips are shareable, as you can see from the example embedded above. We chose the terrain view because we think it best conveys the feeling of an adventurous journey. One of my favorite things to do is to press play, enter full screen mode and just sit back and watch a story unfold. The Google Maps API for Flash helps make that experience smooth and beautiful. It’s essential to our product.

The player represents the end-product of a created trip, but what about the creation process itself? Our goal was to make trip-creation as simple and flexible as typing a bullet list, and we spent a lot of time working towards that goal. We’re using many different Maps API components in our trip editor, including geodesic polylines, custom markers and custom infowindows. To add places, we’re using the Google AJAX Search API and the Geocoder API, and for trip thumbnails, we’re using the Google Static Maps API.

Speed and reliability are also essential. Users will forgive a lack of features and even bad design, but if your application is slow, you’re dead. The Google Maps APIs are always on and always fast, which is something that very few services can guarantee. That's one of the key reasons why we use Google services to support the core capabilities of our product. We’ve been live now for just under a month, and it’s been smooth sailing. We’re also hard at work on our next release, so stay tuned for more. Thanks Google.

Posted by Byron Dumbrill, Founder & CEO, Tripline

Hi, my name is Björn Brala. In the last two years, I've been working on GeoStart, a framework based on the Google Maps API. In that time, the developer community has been an invaluable source of information and help.

When the Google Maps API V3 was released, we were asked to port V2 utility libraries over to work with V3. Since I enjoy challenges, I decided to port over the MarkerManager library. After some rigorous testing and help from Daniel Lee, one of Google's Developer Programs Engineers supporting Geo APIs, I succeeded!

For those who are not familiar with MarkerManager, it's a class originally created by Doug Ricket that manages the additions and removals of many markers when the viewport changes.

Since real code can sometimes speak a thousand words, here's a basic Weather Map example which uses the MarkerManager class. This map creates a random collection of weather markers. When you zoom in, more weather markers are displayed to show more detailed local weather.

If you want to see more examples coupled with detailed explanations on how to use the code, visit the examplespage and the reference guide, which are both hosted in the Google Maps Utility Library V3 project.

Posted by Björn Brala

I'm Gary Little, a realtor in the small town of Sechelt, British Columbia, located about 40 minutes by ferry from Vancouver. Before returning to Canada a few years ago, I worked for many years in Silicon Valley at Apple Inc. and Sun Microsystems, Inc.

I'm known around here as "Map Guy", not only for my numerous interactive maps but also my collection of antique paper maps of the west coast of North America. I've even got a car with MAP GUY plates!

My most prolific mapping project to date has been an interactive map application that shows the locations of all MLS-listed properties for sale on the Sunshine Coast (an area about 50 miles long with Sechelt at the center). You can see the application at map.garylittle.ca. I recently rewrote and simplified this application so that it works well on iPhone and Android phones. This meant migrating to theV3 Maps API. One problem I faced was that there was no easy way to create and display a custom info window when a property's marker was clicked.

To solve this problem I created a class called InfoBox. You use it just as you would a google.maps.InfoWindow but it supports several additional properties for controlling the styling of the box. You can also use an InfoBox as a map label, so it's useful for identifying landmarks that are not on the base map. InfoBox is now part of the google-maps-utility-library-v3.

The image below shows an InfoBox from my V3 real estate map at imap.garylittle.ca. It's a simple yellow box with a small arrow pointing to the property's location. A flashier box could easily be displayed through creative use of CSS styles.

To learn more about InfoBox, read the class reference and check out the examples.

Posted by Gary Little, Maps API Developer

Lombard Street, San Francisco is featured on a million postcards as "the crookedest street in the world" due to the 8 hairpin bends on the block between Hyde and Leavenworth Streets. The famous turns are clearly visible on a map, but it is not obvious why they are necessary. And the rest of Lombard St looks like an innocent section of straight road from above.

However, it was while driving along the section of Lombard St west of Hyde that I was first introduced to the smell of a burning clutch. I was stuck in traffic in a car with manual transmission trying to drive up what is actually an incredibly steep hill, one of many in San Francisco. But apart from the shading in Terrain view there is no way to appreciate that on a map unless you switch to Street View.

We are therefore happy to introduce a new service to the Maps API family that enables applications to determine elevation profiles. Using either the new ElevationService Maps API v3 class or the Elevation Web Service you can request the elevation in meters for one or more sets of coordinates, or you can request a specific number of elevation samples equally spaced along a path. If any sampling points are over bodies of water, the service will return the depth relative to sea level as a negative number.

The below application uses the Google Visualization API to plot elevation profiles. You can add additional points by clicking on the map or entering an address, drag existing points arounds, and switch between different modes of travel. If you roll your mouse over the profile chart you can see on the map the point that the given sample relates to.

To facilitate easy generation of elevation profiles for routes generated for driving, cycling, or walking directions we have also added a new property to the DirectionsResult object called overview_path. This is a simplified path guaranteed to be short enough to pass to the Elevation Service.

As with all other Google Maps API services, the elevation service must be used in compliance with the Maps API Terms of Service which require that it be used in conjunction with display of a Google map. This means that if you display elevation information to your users that you have obtained using this service, or any data that you have derived from it, you must also show a Google map that indicates the points, path, or route concerned.

We think that this new elevation service is a natural complement to our recently launched bicycling directions. Now you can determine in advance just how painful your bicycling route is likely to be. In fact you’ll be happy to hear that the Maps API bicycling directions already factor in elevation, which is why if you ask for a route up Lombard Street you will be sent the long way round.

Posted by Thor Mitchell, Maps API Product Manager

When we launched the Google Maps JavaScript API v3 last year our goal was to develop a framework in which we could deliver compelling and innovative features to our developers that cater to the new breed of location-aware mobile internet devices.

As we look ahead it is clear that HTML 5 offers us the platform we need to deliver on this vision. However as we develop features that exploit the potential of HTML5 it will not be possible to maintain our current level of support for older web browsers. For this reason we will be updating the list of supported browsers for the Maps API v3 on a regular basis. We are applying our first update today by removing Firefox 2, Internet Explorer 6, and Safari 3, while adding support for the Android browser and for Chrome on Mac and Linux.

We understand that many users work in environments in which they are not in control of the browser they must use. We will therefore do our best to ensure that users of browsers that we no longer support continue to have a good experience with Maps API v3 applications. If we develop a new feature that can be easily implemented in a manner compatible with these browsers we will do so, and we will continue to accept bug reports relating to them. We will also attempt to ensure that any features we launch in future that are not compatible with these browsers degrade gracefully for affected users.

The browsers that we no longer support for the Maps API v3 will continue to be supported for the Google Maps JavaScript API v2. We have no plans to change the list of supported browsers for the Maps API v2, and consequently if support for these browsers is important to you we recommend that you continue to develop your applications using the Maps API v2.

If however you are planning a new Maps API application or need to update an existing Maps API v2 application to offer improved support for mobile devices, we encourage you to consider using the Maps API v3. We are excited by the opportunities that HTML5 offers us and hope that you will enjoy using the Maps API v3 to develop the next generation of powerful and immersive Maps API applications.

Posted by Thor Mitchell, Maps API Product Manager

When we launched Directions in Maps API v3 last year we asked "Where will you go from here?". You may have asked the same question of us, and today we're pleased to be taking another step forward with several new Maps API v3 Directions features.

• Avoid highways and tolls. If you prefer to take the road less traveled you can now generate routes that avoid highways. Similarly, if you find yourself a little short of loose change, you can avoid tolls.
  
  
• Route optimization. Have many places to go but no preference as to the order you visit them in? We can now reorder the waypoints of your route to minimize the distance and time you must travel. Very useful for traveling salesman I hear.
  
  
• Bicycling directions. Prefer your vehicles of the two wheeled human powered variety? In conjunction with the launch of Bicycling directions in Google Maps you can now also request directions in Maps API v3 that are tailored to your Penny-farthing.

You can try these new features using the below map. Simply click to create waypoints and then generate directions between them. The first and last points you click are the start and end point, which remain fixed when the route is optimized. Any intermediary points may be reordered.


Note that Bicycling directions are currently only available in the U.S., and that the Bicycling layer available on Google Maps is not yet available in the Maps API.

In conjunction with these new features we are also making some changes to the DirectionsResults structure in response to developer feedback. The object representing a complete journey from origin to destination was previously called a "trip" but is now being renamed to a "route". The object previously called a "route", which represents the portion of the journey between two consecutive waypoints, is being renamed to a"leg". For more details please see the Maps API V3 Services documentation.

We will support both the old and new naming scheme in the v3 API for a transition period until May 1st, after which the old names will be removed. Please update any existing applications to use the new names. We realise this change may cause some inconvenience, but believe the new naming scheme is more intuitive for newcomers to the Maps API.

We hope that you will find interesting ways to put these new features to good use. Now if you'll excuse me, I have a bicycle to find and dust off...

Posted by Thor Mitchell, Maps API Product Manager

Geocoding - finding the geographical location of a given address - is one of the most popular features of the Google Maps API. Both the JavaScript Maps APIs and the Maps API for Flash include classes that enable applications to perform geocoding, and there is also a RESTful web service that offers the option of making geocoding requests from server side applications with output in both XML and JSON.

The Google Maps JavaScript API v3 introduced a new format for geocoding responses that offers a number of improvements over the format used in the v2 API:

• A flatter response format for address components that is easier to parse
• The ability to tag an address component with multiple types
• Both full names and abbreviations for countries and states
• Differentiation between rooftop and interpolated geocoder results
• Both the bounding box and recommended viewport for each result

We're happy to now announce a new Geocoding Web Service that adopts these improvements.

The Geocoding Web Service is intended to enable precaching of geocoder results that you know your application will need in the future. For example, if your application displays property listings, you can geocode the address of each property, cache the results on your server, and serve these locations to your API application. This ensures that your application does not need to geocode the address of a property every time it is viewed by a user. However we do ask that you regularly refresh your cache of geocoder results.

Note however that it is a requirement of the Maps API Terms of Service that you use the Geocoding Web Service in conjunction with a Google map. This means that when it comes time to use cached geocoder results in an application, the application must display the results or any data derived from them on a map generated using one of the Google Maps APIs or Google Earth API.

If your application needs to geocode arbitrary addresses that are entered by your users while they wait we recommend that you use the classes in the appropriate client API. This ensures that the requests your application generates reach Google directly from your users, which will improve the performance of your application and ensure it is resilient to unexpected spikes in use. For more details, I highly recommend this excellent blog post by our very own Mano Marks.

In addition to an improved response format you will notice some other changes in the new Geocoding Web Service. Requests no longer require a Maps API key, and Maps API Premier customers must sign their requests. In addition CSV output is not supported because we found that the minimal amount of data in a CSV response makes it is difficult to identify false positive results.

2,500 requests may be sent to the Geocoding Web Service per day from a single IP address. This is independent of any geocoding activity generated by applications using one of the client Maps APIs for geocoding. Maps API Premier quotas remain unchanged.

A forward geocoding request to the new Geocoding Web Service with XML output looks like:

http://maps.google.com/maps/api/geocode/xml?address=sydney&sensor=false

A reverse geocoding request with JSON output looks like:

http://maps.google.com/maps/api/geocode/json?latlng=-33.873038,151.20563&sensor=false

Check out the Geocoding Web Service documentation for more details on the options available for language and biasing of results.

In conjunction with the launch of the new Geocoding Web Service we are also announcing the deprecation of the current service, now retroactively named the "Geocoding V2 Web Service". Existing applications using the V2 Web Service need not worry though. Deprecation indicates that we no longer intend to pursue any further feature development, but we will continue to maintain and support the service in accordance with the deprecation policy set out in the Maps API Terms of Service.

We hope that you find the new Geocoding Web Service easier to use and useful. As always we encourage you to check out the Google Maps API Google Group if you have any questions or comments relating to the APIs. We look forward to adding more great features to the Geocoding Web Service in future.

Posted by Thor Mitchell, Maps API Product Manager

Over the last couple of years, my office has been working on using the Google Maps API to display the Missouri State University campus map. The map is used by campus faculty, staff, students, and visitors and includes buildings, parking and transit system information. Beginning this summer, we started work on incorporating live GPS tracking of our campus buses into the map. Both the idea and GPS application on the buses came from one of our computer science students who wanted more information on the campus transit system.

Using the Google Maps API v3, I was able to create a mobile version of our map for use on smartphones. After showing it to my users, one of the first responses I got was, "Are you going to make this available as an application?". After spending many hours developing a feature-rich mobile web version, the thought of investing a large amount of time to code the same experience on multiple platforms was overwhelming. Then I began thinking of the maintenance headaches; even simple changes, such as adding a new sets of icons for custom markers, would be time consuming. All of a sudden the idea sounded much less appealing. I'd spent all this time on the mobile web version of my map, why couldn't I just use that?

All Wrapped Up

So instead of writing the maps application using the SDK of each phone platform, I wrapped my v3 Maps API site into a WebView inside a stub application. Now all the work spent on the web version automatically applies to the "native" application and my users never even know the difference. The Google Maps API team have even provided some great reference articles for Android and iPhone which help get the process started.

Optimization

Response time in this type of application was a big concern both within an app and within the browser. I saw significant performance gains by using Closure-Compiler on my JavaScript, using the CSS sprite support in v3 for markers and following most of the suggestions in the Web Performance Best Practices document. To improve the user's initial loading experience I also pre-load the WebView with static HTML that contains a "Loading..." message and use JavaScript to redirect them to the actual map page.

Popularity

I was initially skeptical of the usefulness of such a project. The mobile version of the map offers users the same functionality that they can get by simply bookmarking the map in their browser. So I was very pleasantly surprised at the both the usage and publicity the application has garnered. Within the first two weeks, the iPhone application was downloaded 1,200 times and the Android application almost 200 times. Both applications are receiving very positive reviews.

We consider this project a huge success. Going forward it will now be a priority to make sure new features work well both on the desktop as well as on mobile devices wherever possible.

Posted by Chad Killingsworth, Assistant Director of Web & New Media, Missouri State University

For Australia Day this year I took a trip with some friends to the beautiful city of Melbourne, Australia. World renowned for the arts, world class sporting events, and a relaxed cafe culture, it's also well known for what Wikipedia tactfully calls "its changeable weather conditions". Or, as Crowded House described it, "Four Seasons in One Day".

This being the case, it's always good to check the weather forecast, and no weather forecast is complete without a map. Now if you're looking for an interactive map, you are spoilt for choice, but if you would prefer a simple static map to print out or view on your phone it's not so easy. Weather maps need weather symbols, and until now the only choices for marker icons on Static Maps have been the regular Google Maps pins.

Although we love our map pins here at Google, we understand that there are times when you need something different, which is why we're happy to announce that the Static Maps API now supports custom marker icons. Just specify the URL of a PNG, GIF, or JPEG icon in the marker definition, and we'll fetch the icon and add it to your map. We'll cache the icons you specify to maintain performance, and even generate shadows for your icons if you wish:

markers=icon:http://maps.google.com/mapfiles/kml/shapes/sunny.png|shadow:false

You can use up to 5 different icons on a single map, each of which can be used for multiple markers, so come rain or shine you can always take the weather with you.

For more details check out the Static Maps v2 API Developer's Guide, and be sure to post any feedback on the Google Maps API Google Group.

Posted by Thor Mitchell, Google Maps Developer Platform team

P.S. Oh, and one more thing. Requests made to the Static Maps API v2 no longer need a Maps API key.

Which is nice.

Opening ceremonies for the 2010 Winter Olympics are just days away and the city of Vancouver glitters in festivity. Its nightly sky has been adorned with 20 robotic searchlights thanks to Rafael Lozano-Hemmer at “Vectorial Elevation” powered by Google Maps and Google Earth APIs.

It is an interactive artwork that allows users to direct powerful light beams and transform Vancouver’s skyline between February 4 - 28, 2010. Using a custom interface built on Google Earth and Map APIs, the web site Vectorial Vancouver lets participants design huge light sculptures by directing 20 robotic searchlights located around English Bay.

Users submit designs together with name, location and dedication or comments. Every night from dusk to dawn new designs are quietly rendered sequentially as they are added to a queue. The project automatically creates a personal webpage for each participant, documenting his or her contribution with views from 4 project webcams. With a 15 Km visibility radius, the installation intends to blend the virtual space of the Internet with one of the most emblematic public spaces in Vancouver (see live view snapshot).

The user interface for personalization is very intuitive, consisting of an interactive Google Maps view of an overlay of search lights in Vancouver and a 3D view of Vancouver in Google Earth. User selections and configuration of search lights are adjusted using the jQuery JavaScript library and Maps API, and are dynamically reflected in the 3D Earth view using the Earth API.

Find out more on the Google Blog about Google's other offerings like Street View snowmobile for fans of the Games. Or personalize your own Vancouver nightly skyline and let your imaginations and Olympic spirits soar!

Just in time for your holiday coding enjoyment, we have three new articles to get you started on adding maps to mobile and using App Engine for spatial search.

Overview of Mobile Development Options for the Google Maps API
Putting a map on a phone seems natural these days. This article goes over the options for developing a Google Map for a mobile application.

Loading a Maps API site in a Native Android Application
Google Maps API Version 3 was designed to be used in a mobile environment. If you want to include a V3 page in a native Android application, this is how to get started.

Geospatial Queries with Google App Engine using GeoModel
Many developers are moving their applications to cloud computing. Here's how to get started with geospatial queries building on Google App Engine.

So enjoy your holidays, and I look forward to seeing your apps in January!

Posted by Mano Marks, Geo APIs team

When we first announced the Google Maps Data API in May, we were excited to provide developers with free scalable hosting of geographic content.  The idea was simple: to create an awesome maps mashup, you focus on creating a great user experience and Google will provide scalable hosting and bandwidth.  Moreover, your data should be accessible from any platform (like desktop, iPhone, or Android) using your language of choice (including JavaScript, Python, Java, or Objective-C).

Today we're launching several exciting new features based on all the great feedback we've gotten from developers.  First, we're adding geospatial and attribute search to your maps.  To see these features in action, play around with this College Finder demo (you can download and modify the source code here).  I created a Google My Map consisting of approximately 3000 U.S. 4-year colleges, and wrote a JavaScript app to search over this map (with no need to run my own server or database!).

Using the new search features, you can easily request "all colleges within 5km of San Francisco" and apply attribute filters like "[Type:public]".  You can also sort the results by proximity to a point (in this case, the center of the map).  The results are updated whenever the map is dragged or zoomed, or when the search criteria change.

In addition to search, many developers have requested the ability to enable API access to a public map without requiring users to be signed into a Google account.  We've also enabled this today: you can indicate (using the API) that you would like a map to be accessible by others via the API.  You can also programmatically control access to the maps you own, by making them public/private or adding specific collaborators.  Our official docs will be updated soon but, in the meantime, check our forum for updates about this.

To get started writing your next awesome geo app, you can download and modify our sample code, or refer to our documentation.  We look forward to seeing all the great collaborative mashups, store locators, and mobile apps you'll come up with.

If you have questions or feedback, or would like to tell us about your new creation, please visit our developer forum, tweet about #mapsdata, or file a feature request.  We have some other great features on the way, so stay tuned and keep mapping!

Posted by Matt Holden, Google Maps Data API Team

We're really excited to announce two upcoming hackathons for our Google Geo APIs. The first will be held in New York City on November 20th followed by a second one in Mountain View on December 15th. This will be a great learning opportunity for any developer interested or currently involved in building Geo-enabled applications using our APIs. Come join us for a great session where you'll be able to hack away on your own projects alongside our engineers who'll be readily available to provide support. Below is a list of the various Google Geo APIs you'll learn about:

• Google Maps API
• Google Maps API V3
• Google Maps API for Flash
• Google Maps Data API
• Google Earth API
• KML

Registration for these events are completely free, and space is limited. Reserve your spot now using the following links below!

• November 20th @ New York, NY
• December 15th @ Mountain View, CA

Bring your laptops, your brains, and we'll see you soon!

Calling all Bay Area coders! We've just finalized another hackathon for late September! On September 24th, 2009, from 1:30 to 8, Google will host a hackathon for our Geo APIs in our San Francisco office. At the hackathon, Google engineers will give one or two API overview presentations and then will be on hand to answer all your geo related questions. You can work on suggested codelabs, or just bring your own project and we'll lend you a hand.

The hackathon will cover the following APIs:

• The Google Maps API for JavaScript V2 and V3
• The Google Maps API for Flash
• The Google Earth API
• KML
• The Google Maps Data API

Space is limited, so register now! And remember, this will be a code-heavy event, so bring your laptop and come ready to code!

Posted by Roman Nurik, Geo APIs team

September 3rd, 2009, from 11 to 6, Google is hosting a hackathon for our Google Geo APIs in our Seattle offices. At the hackathon, you can code on our Google Geo APIs, with the guidance of Google Engineers. We'll provide you with suggested codelabs, or you can just work on your own projects. You can work on the following APIs: The Google Maps API for JavaScript V2and V3, the Google Maps API for Flash, the Google Earth API, KML, and the Google Maps Data API.

So bring your laptops, and your brains, and be prepared to code.

Space is limited, so register now!

Last week at Google I/O we released the Google Maps API (JavaScript version) addition to the Developer Qualification program. Designed for professionals who currently develop or want to develop applications based on Google and Google-sponsored Open Source APIs, the Google Qualified Developer program will help promote developers to the Google community, provide credibility, and leverage the wisdom of the masses in rating and recognizing best in class developers. In this program, we assess developers in four areas, each of which provides a score towards an overall total required for qualification. Developers must maintain a minimum number of points to remain qualified within the program. Points are awarded for examples of development work, community participation, professional references, and scores on examinations.

With the addition of the Google Maps API to the available qualifications, the program landing pages and registration have been moved to the Google Code site at http://code.google.com/qualify. The new landing pages provide information on the program and available APIs, details about qualification requirements, answers to frequently asked questions, and an opportunity to apply as a candidate in the qualification program.

We've also recently partnered with 3rd party training vendors who can help you get ready to qualify. The Developer Qualification program provides a mechanism by which Google can evaluate and promote the best developers in the community, but does not provide training in preparation for qualification. With the success of the program there exists a business opportunity for 3rd party training vendors to develop and deliver this training. In order to stimulate the growth of this ecosystem, several vendors have been identified and are working closely with Google to develop initial training efforts for the Google Maps API qualification.

To read more about the program, take a look at our site. We look forward to expanding our API support and growing the Developer Qualification program. Please reach out to us with questions and feedback at [email protected].

Posted by Shannon Madison, on behalf of the Developer Qualification team