A map is often used to display overlays conveying information to users. How you go about getting your data onto the map varies depending upon the mapping API. In this post we will explore how you can get your vector data on the map (points, lines and polygons) using the mapping APIs from Bing, Google, and OpenLayers.

I was inspired to write this post after recently building a demo where I worked with several mapping APIs. This post will talk about are the formats that are natively supported by three of these mapping APIs. However, it’s worth noting that you can get pretty much any web-based format onto a map by using FME Server – or by parsing the data, looping through it and using the mapping API’s standard calls to create geometry and add it to the map.

Bing MapsBing

Native Formats Supported:

As you will see, GeoRSS and KML are standard across all platforms. The one that stands out with Bing is the ability to display data directly from your spatially enabled SQL Server 2008 database (available in both the Silverlight and Ajax frameworks). I have never actually used the SQL Server data connector so I would be interested to get some feedback from anyone that has. Having played around with the demo and having looked at the code, this looks like it would definitely be worth a look if you already have a SQL Server database setup and running.

Performing the Overlay:

Overlaying the GeoRSS/KML is trivial with only a few lines of code. The problem I have is that Bing Maps gives every feature a pushpin icon irrespective of the type. For example, if you import a polygon it will put a push pin in the middle of the polygon and it is the same for the polyline. There is a workaround detailed here, but why not enable me to configure the visibility of the push pins through the API?

Pushpins in Bing maps

Pushpins which are auto-generated for every geometry type.

Google MapsGoogle

Native Formats Supported:

Performing the Overlay:

The main thing which caught me out when using these services relates to the google.maps.KmlLayer (or GGeoXML in Maps v2.0) caching the data. For example, if you have a KML/GeoRSS file on the server and change the content, there is the potential that the changes will not be reflected in the client application. The way to ensure this doesn’t happen is to append a timestamp at the end of every request as a parameter.

varmyKml = “http://mypublichost/roads.kml”;

varkmlObj = new google.maps.KmlLayer(myKml + ‘? dummy=’ + (new Date()).getTime());

The trouble is that the caching is there for a reason, so ideally you would only append the timestamp if you knew the data had changed. Easier said than done…

The other limitation of rendering using the google.maps.KmlLayer (or GGeoXML in Maps v2.0) is that the URL has to be public. There is however an alternative to using Google’s service, you can do it client-side. I have used this great little open source library from Lance Alan Dyas on several occasions to render my KML, and it works perfectly. It has the added advantage of giving you the freedom to step through and tweak the code which does the parsing; it also extends your format support to:


Native Formats Supported:
As you would expect, OpenLayers is the king of format support. Here are the major formats that are supported (check the API for a full list):

Performing the Overlay:

While the documentation and examples related to OpenLayers are excellent, I have found the community content to be not quite as extensive compared to Google/Bing. When I have a problem with Google/Bing, 9 times out of 10 I can find a solution on a forum somewhere. When working with OpenLayers I have hit several issues that have taken be a good amount of time to figure out. Having said that OpenLayers is a fantastic project, so give it a try – post your problem and contribute to the OpenLayers community.

Which mapping API have you worked with? Do you have any gotchas that you would like to share?

About Data Google Maps KML OpenLayers Web Mapping

Stewart Harper

Stewart is the Technical Director of Cloud Applications and Infrastructure at Safe. When he isn’t building location-based tools for the web, he’s probably skiing or mountain biking.


3 Responses to “Mapping APIs: Bringing Your Spatial Data into Bing, OpenLayers, and Google”

  1. Usha Iyer says:


    I am Usha Iyer, a Senior Acquisition Editor with Packt Publishing. As an Acquisition Editor, it is my role to evaluate, develop and ultimately bring book ideas to publication. I am also responsible for finding the right author for any book; bringing them onboard, then working with them as the book is written.

    I have begun to develop a title on ‘Openlayers Cookbook’ following the success of our first Openlayers book, and am now looking for an author to write this book.
    You can find some more information about writing for us at Packt’s website http://www.packtpub.com/authors.

    Our book will include problem solving recipes for people familiar with Openlayers who are already familiar with the basics of Openlayers.

    Please contact me if you are interested in writing this book and I would love to discuss the opportunity with you further.

    Even if you do not want to involve yourself in the project, can you please suggest someone who may suit this project?


  2. […] styling through the API’s of the mapping frameworks. This however requires knowledge of the mapping API and you are tied to overlaying the data on the vendors background mapping. They are also very […]

  3. Hi Usha,

    Thanks for the interest but at this point I don’t have the bandwidth.


Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts