FIGURE 3: Sample data in an Access 2000 database to be plotted with MapPoint 2000.
With the release of Office 2000, Microsoft quietly added a new member to the Microsoft Office family of products: Microsoft MapPoint 2000. Officially, they describe this new program as "Mapping and Geographic Analysis Software for Business."
Users of Microsoft's consumer mapping products will recognize the basic user interface (see FIGURE 1). What MapPoint brings to the table is demographic data, an interface to your own data, and an object model. In this article, I'll introduce you to MapPoint and show you how to make use of some of its features from other Office products. If you're working with a sales or service organization, or anyone else who needs to compare locations with demographics, you may find this product has a lot of value to add to your operations.
MapPoint is well stocked with information out of the box. It includes street- and address-level information for the entire US, as well as a number of demographic data sets. For example, FIGURE 1 uses information on the Age 15-24 population to produce the shading for each state. This is just one of the data sets that MapPoint includes. Although this data is aggregated to the state level, you can also group these data sets by census tract, ZIP code, county, or metropolitan area.
Here are a few of the data sets to give you a sense of what's packaged with MapPoint:
In addition to the packaged data sets, you can buy additional data sets from Claritas, National Decision Systems, and Spectra Marketing. This flexibility means that it's easy (although not always inexpensive) to tailor MapPoint's demographics to the needs of a particular industry.
In addition to plotting demographic data, MapPoint can also display sets of geographic locations, known as pushpin sets. For example, the map in FIGURE 1 displays the location of the U.S. Marshal Service's offices across the country. You can choose a pushpin symbol for each set, and MapPoint supplies a special symbol for cases where multiple pushpins are too close to display. Pushpin sets can be imported or dynamically linked to existing Access and Excel files, Outlook contact folders, or any OLE DB data provider for which you have created a Microsoft DataLink (.udl) file to access.
Of course you can save your maps, e-mail them to other users, or export them as Web pages. You can also export a map as a pocket streets file for use on a Windows CE handheld, which opens up interesting prospects for use by outside salespersons. Other tools let you measure distances, zoom in or out, and search for particular addresses or places.
For more information on MapPoint 2000, including an online tour and pricing information, check out Microsoft's Web site at http://www.microsoft.com/office/mappoint/default.htm.
The MapPoint Object ModelAs a part of the Office family, MapPoint includes a rather rudimentary object model (see FIGURE 2). It's better than nothing at all, but it lacks large parts of the product's functionality.
One important thing to note is that there are no collections in the MapPoint object model. Although each lower-level object (Map, Location, and Pushpin) includes properties to retrieve its parent, the reverse is not true. For example, MapPoint offers no means in this release to iterate through all of the pushpins displayed on a map.
The Application ObjectAt the top of the MapPoint object model is the Application object. This object represents MapPoint, and is characterized by six properties:
All of the Application object's properties are read-only except for the Units property.
The Application object also supports four methods:
The Map object represents a single map open in MapPoint. MapPoint's interface is strictly SDI, so at all times there will be a single Map object available. You can get at this Map object with the ActiveMap method of the Application object.
The Map object is characterized by six properties. All of them are read-only:
The Map object supports eight documented methods:
The Location object represents a particular geographic location, typically a country, county, state, or city. It only has three properties:
The Location object has one method. This is the GoTo method, which centers the map at the specified location.
The Pushpin ObjectFinally, the Pushpin object represents a single pushpin. Pushpin objects have six properties:
There are two methods available for Pushpin objects. The Delete method deletes the pushpin, and the GoTo method centers the map on the pushpin.
Using the Object ModelGiven the simplicity of MapPoint's object model, the obvious question is posed: What do we do with it? When confronted with a new server, it's often profitable to ask what new capabilities the product brings to your computer. Looking over the MapPoint object model, it seems that calculating distances is a capability not duplicated in other products in the Microsoft universe.
Suppose you have a table of addresses in Access 2000, as shown in FIGURE 3, and you want to calculate the distances from these addresses to some central point (e.g. One Microsoft Way in Redmond, WA). You can use the MapPoint object model to make these calculations (see FIGURE 4).
FIGURE 3: Sample data in an Access 2000 database to be plotted
with MapPoint 2000.
' Determine distances
of each office from the home
' location by using the
object model directly.
Sub
GetDistances1()
Dim objApp As
MapPoint.Application
Dim objMap As MapPoint.Map
Dim objLocation As
MapPoint.Location
Dim objHomeLocation As
MapPoint.Location
Dim rstMarshals As
ADODB.Recordset
' Open
MapPoint and get a pointer to
' a new
blank map.
Set objApp = New
MapPoint.Application
Set objMap = objApp.NewMap
' Get a
location object for our home location.
Set objHomeLocation = objMap.FindAddress( _
"1 Microsoft Way",
"Redmond", "WA", "98052")
' Open a
recordset on the table and loop through it.
Set rstMarshals = New
ADODB.Recordset
rstMarshals.Open
"tblUSMarshals", _
CurrentProject.Connection,
adOpenForwardOnly, _
adLockOptimistic
Do
Until rstMarshals.EOF
' Locate this entry.
Set objLocation = objMap.FindAddress( _
CStr(rstMarshals("Address")), _
CStr(rstMarshals("City")), _
CStr(rstMarshals("State")), _
CStr(rstMarshals("Zip")))
' Make sure we found something.
If Not objLocation
Is Nothing Then
' Find and save the distance.
rstMarshals("Distance1") =
_
objMap.Distance(objHomeLocation,
objLocation)
Else
rstMarshals("Distance1") =
-1
End If
rstMarshals.Update
rstMarshals.MoveNext
Loop
rstMarshals.Close
objApp.Quit
Set objApp = Nothing
End SubFIGURE 4: Using MapPoint to calculate distances.
The procedure in FIGURE 4 works by using the Map.FindAddress method to locate each entry in the table on the map, and the Map.Distance method to find the distance from that location to the central point. Because you can never be sure that the FindAddress method will actually find the address (the address, map, or both might be in error), you need to check that the returned location is something other than Nothing before calling the Distance method.
Running this procedure on a sample of 95 addresses, I discovered that MapPoint was able to plot only 44 of them. That's not a great average. There are two main problems with this particular data set from the point of view of the FindAddress method. First, there are addresses of the form "3rd and Mulberry Street," which may make sense to a person but can't be adequately parsed by any of the common mapping programs. Second, there are some addresses that are a close match, but not close enough. For example, the Portland office is in the data set as "1000 SW 3rd Avenue," but the matching address on the map is stored as "1000 SW 3rd Ave." Any deviation is enough to make the FindAddress method return Nothing.
One way to increase your hit ratio in plotting addresses is to use the MapPoint user interface instead of the FindAddress method to locate initial addresses. By choosing File | Import Data, you can launch the Data Import Wizard. I don't know what this wizard does under the covers, but it's able to accurately plot 82 of the original addresses. Although that's still not perfect, it returns far better results than does using the FindAddress method directly. In the absence of any documentation, I presume the wizard incorporates some heuristics it tries when FindAddress fails, such as substituting street abbreviations for the spelled-out words.
In any case, if you take this route, you can run the alternate code shown in FIGURE 5 to calculate distances. Rather than working with a blank map, this procedure opens a saved map where the user interface has already been used to import the addresses in question as a set of pushpins. Each pushpin is located with the FindPushpin method of the Map object. Then the Pushpin object's Location property can be used with the Distance method.
' Determine distances
of each office from the home
' location by using a
saved map.
Sub
GetDistances2()
Dim objApp As
MapPoint.Application
Dim objMap As MapPoint.Map
Dim objPushpin As
MapPoint.Pushpin
Dim objLocation As
MapPoint.Location
Dim objHomeLocation As
MapPoint.Location
Dim rstMarshals As
ADODB.Recordset
' Open
MapPoint and open a saved map.
Set objApp = New
MapPoint.Application
Set objMap = objApp.OpenMap( _
CurrentProject.Path
& "\" & _
"Marshals with
Population.ptm")
' Get a
location object for our home location.
Set objHomeLocation = objMap.FindAddress( _
"1 Microsoft Way",
"Redmond", "WA", "98052")
' Open a
recordset on the table and loop through it.
Set rstMarshals = New
ADODB.Recordset
rstMarshals.Open
"tblUSMarshals", _
CurrentProject.Connection,
adOpenForwardOnly, _
adLockOptimistic
Do
Until rstMarshals.EOF
' Locate this entry.
Set objPushpin = objMap.FindPushpin( _
rstMarshals("Address"))
' Make sure we found something.
If Not objPushpin Is Nothing Then
' Find and save the distance.
rstMarshals("Distance2") =
_
objMap.Distance(objHomeLocation,
_
objPushpin.Location)
Else
rstMarshals("Distance2") =
-1
End If
rstMarshals.Update
rstMarshals.MoveNext
Loop
rstMarshals.Close
objApp.Quit
Set objApp = Nothing
End SubFIGURE 5: An alternative procedure for calculating distances.
ConclusionAfter having worked with MapPoint 2000's object model since the middle of the Office beta cycle, I've come to the conclusion that this is definitely an object model that needs work. Rather than dismiss it out of hand, however, I recall the Access 1.1 object model. Like MapPoint 2000's object model, it was completely inadequate for many purposes, yet it showed promise that's been amply delivered on in subsequent versions. Based on watching the other Office object models develop over the past several releases, I'd be willing to bet we're going to see good things in future versions of MapPoint, as well. I don't know what Microsoft is considering, but here's what I'd like to see:
Although these changes wouldn't give the developer complete control over MapPoint, they would add enough control to make it much more realistic to use this product as part of a business intelligence solution.
The files accompanying this article are available for download.
Mike Gunderloy (MikeG1@mcwtech.com) is a Senior Consultant with MCW Technologies, a Microsoft Solution Provider. He's also the co-author of SQL Server 7 In Record Time (SYBEX, 1999) and author of Visual Basic Developer's Guide to ADO (SYBEX, 1999).
Copyright © 1999 Informant Communications Group. All Rights Reserved. • Site Use Agreement • Send feedback to the Webmaster • Important information about privacy