This one took me a couple of minutes to figure out, so I thought I’d pass it along. Recently I launched an update to an application (in beta) that used the VEMap.Find method to geocode addresses in Los Angeles, CA, but for some reason the results for a few of the addresses would show up somewhere in Italy. Eventually I noticed that this was only happening for avenues (as opposed to streets or boulevards). I realized that our street database used the abbreviation “AV” instead of “AVE” and deduced that there must be an Italian province (Avellino?) that used that abbreviation and the parsing engine behind VEMap.Find must pick that out before the zip code.
My solution was to replace the word “AV” with “AVE” in the address string before passing it to the VEMap.Find function with the following:
So far, so good. I wonder how may more calls to replace I’ll end up daisy chaining on to that before I’m through with this one…
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/.