In-Depth

Microsoft MapPoint vs. Virtual Earth

Packaged software or Web service for running mapping applications?

Most people who think about Software as a Service (SaaS) look at full-blown applications like Salesforce.com, where users simply log in and begin working. But the concept of Web-based services is much broader than that. For example, Salesforce.com has gradually become a development platform in its own right, enabling IT to customize it and build applications that leverage its features and data.

A great example of a programming service is Microsoft's Virtual Earth. Most of us know Virtual Earth as the geographic mapping and aerial photograph site launched by Microsoft two years ago as its response to Google Earth. Unlike Google Earth, which requires a locally installed component, Virtual Earth runs entirely off the Web browser, with no additional installation required (unless you're using 3-D buildings).

Under the covers, however, Microsoft exposes an API that developers can use in customizing maps, adding features and mashing up data into entirely new geographic apps. The API is the essential part of the service, providing developers with maps and mapping features to be able to create a custom mapping application, using a combination of map features and internal and public data.

From the standpoint of IT management, such services pose interesting make or buy decisions. In the case of mapping and geographic information systems, Microsoft has an alternative product-based offering -- MapPoint.

The features of Virtual Earth and MapPoint are very comparable. And unlike MapPoint, Virtual Earth is free. The choice for IT seems to be obvious -- Virtual Earth is comparable in features, free to develop and use, and not a significant drain on enterprise servers. But-and it's a big but-Microsoft still considers Virtual Earth not to be ready for prime time, and doesn't provide Service Level Agreements (SLAs) for the service.

And, of course, you may have questions about the security of your data. Unlike Salesforce.com, you don't store your data on Virtual Earth servers, but in many cases it will have to be provided as input to the API in order to display on maps. If your data is sensitive, you may have issues with this.

Redmond magazine reviewer Bill Heldman had the opportunity to work with MapPoint this past summer as a part of an internship with the National Renewable Energy Laboratory (NREL) and Strategic Energy Analysis Center (SEAC). Redmond Executive Editor, Reviews Peter Varhol has been working with Virtual Earth for more than a year now, and has presented on the topic at the Redmond Media Group Web Builder 2.0 conference. Bill loaned Peter his data, and Peter used that data in attempting to do some of the things in Virtual Earth that Bill did in MapPoint.

The result is a look at features and capabilities of an established packaged software solution versus an up-and-coming Web service. There's no "best" choice, so choose the Web service or installed product depending on your needs and expectations.

Head-to-Head
[Click on image for larger view.]

Microsoft Virtual Earth
Virtual Earth is one of Microsoft's Live Services, a brand that covers a set of services including e-mail, Web sites and search. It combines both traditional online maps with aerial and satellite photos to provide an experience that takes you seamlessly from maps to photos as you zoom in on a location. And Virtual Earth seems to have more high-resolution photos than its Google counterpart, making it more fun to play with.

Microsoft Virtual Earth 6.0
REDMOND RATING
Installation 20%
10.0
Features 20%
8.0
Ease of Use 20%
9.0
Administration 20%
9.0
Documentation 20%
7.0
Overall Rating:
8.6

——————————————
Key:
1: Virtually inoperable or nonexistent
5: Average, performs adequately
10: Exceptional

More to the point, Virtual Earth has a highly functional and easy to use API for writing your own map-based applications. You start by learning about the Virtual Earth Map Control, which is now at version 6.0. The map control is called from the developer site of
Windows Live (http://dev.live.com/virtualearth). This API provides a large number of methods for manipulating the map, incorporating location, size and other characteristics.

Thanks to a large number of digital sources of geographic data, Virtual Earth also makes a great platform for mashups, those applications that combine components from different applications and data sources into a single use. Geographic mashups are of particular value, because they combine physical location with information about that location that is often much more useful combined than it is separated.

I approached my mashup cautiously. Many developers think that the mashup is about the applications used, but it's truly about the user experience. What information makes sense for users, and how to present that information geographically, is the key to a successful geographic mashup.

You can begin a mashup by creating an HTML or ASP.NET project from Visual Studio, depending on your application goals. Once your project is created, open a new HTML document. From there, calling maps in Virtual Earth is easy. First, you have to reference the map control as the source for your page to call.

Once your page references the map control, setting up the call to display a default map is simply a matter of doing a LoadMap ( ) method call:

function GetMap()
{
map = new VEMap('myMap');
map.LoadMap();
}

Then you need to display the map:

<body onload="GetMap();">
<div id='myMap' style="posi
tion:relative; width:600px; height:400px;"></div>
</body>

Without parameters, the LoadMap method provides a default map of the continental United States. You can use parameters to specify where the map is centered, and the zoom level, among other things. This provides you with a great deal of programmatic control over the type of map you display.

I also programmatically inserted a pushpin into the map to designate a specific location. The pushpin just requires a call to VEPushPin, with the location parameters. You can always use the latitude and longitude as variables, either to be input by the user or as a feed from another application or data source. Note that you may have to do a conversion to get the coordinates into the appropriate data format. You can also add a description that displays on the label for the pushpin.

The Virtual Earth API provides for the ability to map a route from one location to the other. This enables users of your map application to note a starting point and destination and determine the shortest way to get between those points. Virtual Earth uses the shortest distance route that is consistent with speed. I can find no way of applying another algorithm, although it may be possible to simply write your own. However, I have also found the built-in algorithm to provide reasonable routes across a variety of known journeys.

Figure 1
[Click on image for larger view.]
Figure 1. Web service Virtual Earth displays maps, pushpins and route information in a Web browser.

Calling for a routing is a simple experience. You basically input a starting point and destination, and the map control returns the route between them, along with driving distance and approximate time. It also provides directions at key points when you hover over those points.

GetRoute can use a combination of an address for one of the parameters, and a more general location or place name for the other. Such identification of locations can occur in any combination. Of course, you can use variables and input these parameters from the keyboard, or import them from another data source.

Layering is no problem. A new tool called MapCruncher for Virtual Earth allows anyone to import maps, layer them and display them on a Web site using the Microsoft Virtual Earth platform. MapCruncher automatically transforms maps into a common Mercator projection used by Virtual Earth, making it possible to create layers outside of Virtual Earth and then easily import them.

Searching for locations or places is also straightforward. By calling the FindLocation method of the VEMap object, you can let the user perform a search and return items that match that search. This particular code enables the user to type in a location, get back multiple matches as hyperlinks and select the correct match.

The Virtual Earth map control API is so easy to use that your biggest problem may well be where to get the data to feed into your mashup. One of the most important purposes of a mashup-type application is to provide data accessibility where it did not exist before. Bringing together data from one location into a map that does not normally have access to that data is one of the keys to producing a compelling mashup.

Much data is available through RSS or Atom feeds, in XML format or in a delimited file. These data sources will be easy to import, parse and apply to a Virtual Earth map. The problem is that much of the data found on many sites isn't available for streaming in one of these formats. Many travel Web sites like to keep their data on their site, rather than let it be exported and used in a completely different application. You may also have to change the format of your own data in order to display it on a Virtual Earth map.

Ultimately, the core idea is to welcome people to publish, annotate and share datasets. We don't do a very good job of that today. Finding data in a good format may well be the most time-consuming part of a geographic mashup. Look for sources with easily serializable data, and aggregate data on your site from multiple sources if necessary. As a last resort, you may have to consider screen-scraping on sites that don't stream their data in a useful format.

Virtual Earth is a very reasonable Web service solution to many mapping needs, even with the lack of an SLA. However, there is one more potential gotcha -- according to the online terms of use, Microsoft reserves the right to include advertising in the results provided via the service. It doesn't now, but there may well come a day where you either pay for the service or permit advertising.

Microsoft MapPoint
Microsoft MapPoint is very cool, mostly because it brings the enormous power of mapping software to your fingertips in a deceptively easy UI. You're using software that brings you a zoomable map of the globe, and for either the United States or Europe, includes all kinds of data such as roadways, cities and towns, counties, major landmarks, buildings, rivers, lakes and other waterways, and other places of interest, along with census demographic data.

Microsoft MapPoint 2006
REDMOND RATING
Installation 20%
9.0
Features 20%
9.0
Ease of Use 20%
8.0
Administration 20%
9.0
Documentation 20%
8.0
Overall Rating:
8.6

——————————————
Key:
1: Virtually inoperable or nonexistent
5: Average, performs adequately
10: Exceptional

There are different data views such as topological, data, and street (including night view in MapPoint 2006). MapPoint also brings you the ability to create custom territories (which we'll talk more about later) draw custom lines, import data into a map displaying it in a variety of ways and introduce map objects into other Office applications through OLE. It even brings a robust set of Visual Basic for Applications (VBA) capabilities. New to MapPoint 2006 is the ability to interface with a Geographical Positioning System (GPS). MapPoint can also send maps to any ActiveSync-enabled device.

A National Lab's App
I was recently honored to be chosen for an internship through the Department of Energy (DOE) Academies Creating Teacher Scientists (ACTS) program. I worked this summer for the National Renewable Energy Laboratory (NREL) Strategic Energy Analysis Center (SEAC). The folks at SEAC use computer-modeling tools to create data that indicates what the continental U.S. energy picture will look like over the next 50 years (from 2000 to 2050).

The modeling package SEAC uses is an over the counter (OTC) product that outputs proprietary data. SEAC wanted a way to show this data in maps. My job was to find a suitable package that was able to create maps with custom territory boundaries, then experiment with its ability to import data from Excel and bring up meaningful maps. SEAC wanted the process to be repeatable, as their clientele demanded different views of the data for various scenarios.

The nation's electric grid is a very old and extremely complicated collection of power plants, substations, transmission and distribution lines and interconnection points, different sections of which are owned by various utilities, co-ops, Regional Transmission Operators (RTOs) and other entities, and are regulated by a variety of governing bodies, including federal, state and local governments, among others.

Because of this, SEAC must view its model's data within a variety of different boundaries that have been formulated. For example, the North American Electric Reliability Council (NERC) consists of a grouping of eight separate councils that deal with electric power scenarios across Canada and Mexico.

MapPoint has a custom territory feature that allows you to describe the way your territories are laid out. Of course, you have to match your territory data with what MapPoint knows about. For example, in the ReEDS map the boundaries consist of U.S. counties. So it was straightforward (and time-consuming) to highlight the various counties for a given ReEDS region, then tell MapPoint what that region's name would be.

MapPoint also has a data import feature in which it can import or link to data from Excel (worksheets or named ranges) and Access, among other sources. The import wizard asks you what your data columns contain -- are they to be considered actual mapping information, are they some other source of data, or should they not be brought in. As long as the territory names in your custom territory map match the incoming territory names, MapPoint will do a fine job making the match.

Figure 2
[Click on image for larger view.]
Figure 2. The custom territory for the NERC regions shows overlays on the standard MapPoint map.

Customizing a Map
MapPoint also comes with a fairly robust set of VB and VBA commands that allow you to write custom MapPoint code. I say fairly because there are things I would like for it to have done, but I could not do. For example, the legend that comes with MapPoint is in a left-hand pane of the MapPoint UI and cannot be moved. SEAC would like to have been able to put a custom legend elsewhere on the map, and I would like to have been able to programmatically accomplish that task. The custom territory utility, while friendly, isn't as customizable as I would have liked it to be. For example, if you forgot to include a county in your custom boundary, you had to go into the custom territories pane, then go through a somewhat lengthy process to add the county. It would have been nice to be able to simply drag a county into a particular custom region.

VBA documentation is extremely sparse. MapPoint developers and technical writers give you barely enough information to figure out how to do something in MapPoint. I wasted lots of time simply trying different methods for doing something because the VBA documentation was so lean. The forums and MSDN sites weren't much more help. Want to write MapPoint VBA code? You're essentially on your own.

Also, there is a MapPoint Object Model, with associated objects, methods and properties that you can use with VBA. But there is also a MapPoint Control that can only be used with VB (and Visual Studio). I found that there were times when the MapPoint Control would be ideal for the things I wanted to do, but was forced to go with the object model because I was writing VBA code in Excel.

The biggest annoyance is the way that MapPoint approaches indexing and looking for something. Suppose you have created a custom territory map that consists of several hundred custom territories with just numbers for their names: 1, 2, 3, etc. If you type in 1 in the search box, you will get a vast amount of hits. Why? Because all of the data held in a MapPoint map is privy to search. But it's not likely that your custom territory called "1" is going to come up first in the list. Microsoft developers could easily cure this problem by simply giving custom territory names a higher priority on a map search than the underlying street and city information.

Finally, be aware that MapPoint is not a cheap product. At about $250 a throw, this is expensive code to run on desktops. But not all of your users need the full product. You can save maps in HTML format and send them to users that way. I was extremely pleased to be able to use VBA to open a map and save it in HTML format within a blank Excel sheet I'd opened using code. This is very cool, because all of your users are likely to utilize a spreadsheet package that can open Excel files.

In spite of these difficulties, I think that MapPoint represents the best SMB choice for shops that are interested in an agile, highly interactive mapping tool that can easily interface with Office or the Web.

comments powered by Disqus
Upcoming Events

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.