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.
[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.
[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.
[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.