Since my last post on the topic of adding polygon data to your VirtualEarth map, VE has released not one, but two versions of the API. Starting with version 5 you are now able to add a layer containing polygon and line features to your map via a GeoRSS feed. Pretty cool.
Now the hard part becomes getting your GIS data in GeoRSS format, and that is where the GeoFeeder from BrightiSolutions comes in. It’s a desktop application that reads many types of GIS data (including ESRI Shapefile) and outputs the features in a GeoRSS file format. Check out the demo to see how you can customize the output.
Unfortunately it’s not free, but it could well be worth the $95 license if you don’t have the time to write your own code to converting your GIS data to a GeoRSS file.
We all know that the Virtual Earth (VE) API makes it easy to overlay a layer of your own georeferenced point data as a layer of pushpins on their maps. However, what if you need to add non-point georeferenced data such as zip codes or pipelines? The VE API only supports two types of layers: point and tiled image. The VE API does support adding both individual polygons and individual polylines to any map (and impressively these shapes will even be displayed in 3D mode), but there is no support for adding a layer of such features. In this post I will look at a couple of hacks for achieving this and the reasons why you might want or (most likely) not want to implement them. In Part 2, I’ll explore using tiled image layers to display non-point data in VE.
The first solution that I have found to this problem comes from http://www.blogthevote.net/veshapefilec.htm. This site displays a VML overlay containing the polygon or polyline features on top of the map. While this is an ingenious solution, I wondered why they did not take advantage of the VE support for adding polygons and polylines directly to the map instead of using a VML overlay. After all, this required them to not only write their own code to generate VML graphics, but also to handle rescaling and shifting the graphics when the user panned or zoomed the map. In addition to the burden of writing more code, there are issues with browser support for VML (though I will admit it is much better now than it was a few years ago). I suspected that the only reason to go to that much work would be to improve performance, and I would quickly confirm my own suspicions.
I created my own demo application (http://waysonweb.com/maps/ve/demos/polylayer/) by tweaking their code a bit to try adding the features as polygons or polylines to the map directly using the VE API instead of creating a VML overlay. Using the same Seattle zip code data for comparison I found that the initial load of the maps was slower, as were subsequent pan and zoom operations, but the difference in performance was barely perceptible. However, the performance went well into the “unusable” end of the spectrum when I added my own higher resolution data (with more vertices per polygon). Using my demo application, it took about 90 seconds for the initial map load and around 20 second for each subsequent pan or zoom operation. Further testing demonstrated that the bottleneck was not in the parsing of the coordinate data (usually < 10% of total processing time), but was indeed on the VE server’s end of the load operation.
Essentially, if you want to use the support for polygons and polylines built-in to the VE API to display a layer of GIS data, you will quickly find yourself limited by the number of vertices that make up the features you add to the map. It works great if you want to add a rectangle representing the state of Wyoming, but it is not ready for real world GIS data (imagine trying to add all the property parcels in Los Angeles County).
Another option for adding your own polygon and polyline data to a VE map is the tiled image layer. In Part 2, I’ll examine the pros and cons of this promising method, but in the mean time, you can view an example at http://showcase.sharpgis.net/ve/.