Using Map Service APIs

Google, Microsoft, and Yahoo have all released APIs for incorporating their respective map services inside html/javascript pages. This week I spent some time exploring Microsoft’s Virtual Earth sdk. Map services provide a number of useful tools that are difficult or expensive for end users to create. Worldwide detailed background imagery and street maps, geocoding, routing, location based queries are all basic tools found in the three major map services. In addition it is possible to add custom layers of points, lines, polygons, and even imagery.

Here is a basic wrapper showing how these map service functions can be put inside a customized page: http://www.web-demographics.com/MapService/ Most of the functions are just rehashes of the examples found in the Microsoft developers sdk pages.

Find Location lets a user input an address to center the map view at that location: map.Find(null, txtWhere.value); Using the other parameter lets a user locate a set of nearby features: map.Find(txtWhat.value, null);

Find Directions simply lets the user plug in a ‘from’ and ‘to’ location to show a map route and list a set of driving directions:map.GetRoute(txtFrom.value, txtTo.value, null, null, onGotRoute); Unfortunately the route line does not show up in this sample.

Add Shape lets users add simple points, lines, and polygons. The features are canned features but features can be customized. The interesting aspect of adding custom features is the ability to make the rollover tooltip include arbitrarily complex html, even media links as shown in the sample:

var shape = new VEShape(VEShapeType.Pushpin, map.GetCenter());
shape.SetTitle(‘My pushpin’);
shape.SetCustomIcon(icon1);
map.ClearInfoBoxStyles();
shape.SetTitle(“<h2>Custom Pin</h2>”);
shape.SetDescription(infobox);
map.AddShape(shape);

Import GeoRSS is where customization gets serious. GeoRSS is a standard for XML encoding spatial features. Although GeoRSS includes arbitrarily complex GML I believe that only the simple GeoRSS is supported:

<item>
<title>Coldwater Lake</title>
<description>Formed by the 1980 eruption of Mount St. Helens.</description>
<georss:polygon>46.31409 -122.22616 46.31113 -122.22968 46.31083 -122.23320 46.29802 -122.25877 46.29245 -122.26641 46.29286 -122.26392 46.28746 -122.26744 46.28741 -122.26006 46.29049 -122.25955 46.29120 -122.25620 46.28924 -122.255430 46.30271 -122.23251 46.31284 -122.22315 46.31409 -122.22616</georss:polygon>
<mappoint:icon>http://dev.live.com/virtualearth/sdk/img/hiking_icon.gif</mappoint:icon>
</item>

Unfortunately the arbitrary icon configuration shown here does not really work. There appears to be a bug in the implementation of <icon> which requires a workaround involving walking the Shape tree and manually setting shape.SetCustomIcon(“<img src=’icons/green.gif’/>”); Future releases will probably fix this problem more efficiently.

Go To lat,Long allows user input of Latitdue Longitude and zoom level for locating a map view center:

function FindLatLong()
{
var lat = document.getElementById(‘txtLatitude’).value;
var lon = document.getElementById(‘txtLongitude’).value;
var zoom = document.getElementById(‘zoomLevel’).value;
map.SetCenterAndZoom(new VELatLong(lat, lon), zoom);
}

Display Lat,Long provides a function for clicking on the map view to obtain the longitude latitude of the click point. As usual, follow normal sign conventions for hemispheres.

function PixelClick(e)
{
 var x = e.mapX;
var y = e.mapY;
pixel = new VEPixel(x, y);
var LL = map.PixelToLatLong(pixel);
info.innerHTML = “Pixel X: ” + x + ” | Pixel Y: ” + y + “<br /> LatLong: ” + LL;
}

Storm Tracks illustrates some of the power of GeoRSS import. In this instance the default url points at a custom proxy service, which looks up the current storm situation from www.solar.ifa.hawaii.edu. This text information is reconfigured as a GeoRSS XML point file that is added to a new storm layer. This also illustrates the use of custom icons to indicate differing storm severity levels. There were about 500 points as of my experiment for the current 2007 storm season. Even at this number of points the performance limitations of using custom overlays becomes apparent. Large numbers of features make the map unresponsve for pan and zoom as well as the orginal map loading.

Considering that each point is a an <img> reference, memory utilization is probably terrible. The interesting possibilty of Virtual Earth’s future is its alliance with ASP .NET and WPF. Using WPF graphics features and having C# scripting may limit Virtual Earth to .NET 3.0 enabled IE browsers, but performance would be much better for custom overlays than anything currently available.

Image Tile shows the promise of adding actual custom imagery to the overlay mix. This capability is limited to imagery populating a tile schema. Microsoft offers a tool called MapCruncher for producing these tile schemes from your imagery. Unfortunately the real deal here would be to use OGC WMS or WCS services through a proxy over the Virtual Earth. I don’t believe this is currently possible and limits the utility of image interoperability. Again given the competition among the map services I am hoping that this type of capability will appear in the not distant future.

In summary Microsoft’s map service, Virtual Earth, affords an SDK interface for adding powerful map functions to existing html pages. There are still some bugs and drawbacks but things are progressing rapidly due to the heated Google Microsoft rivalry. Yahoo still owns a lot of legacy map hits but it seems that they will be less often incorprated into the next generation of map enabled sites. All the map services provide functionality at the cost of branding gravity toward their own services. Customization is still relatively primitive largely due to the need to fit inside html/javascript constraints. Interoperability with OGC based standards is still problematic but the GeoRSS import capability is nice to have since all three map services provide that gateway. There are rumors that KML import could be added to Virtual Earth at some future date. Even though KML has been submitted to the OGC standards process, the Google connection will make it a hard pill for Microsoft to swallow.

The potential for incorporating these services under a WPF layer makes Virtual Earth intriguing. That capability would allow Virtual Earth to incorporate custom OGC service overlays as well as fairly complex drawing tools over their map service. In addition WPF 3D is coming over the horizon for some very interesting end user experiences.

Posted in Uncategorized