spacer2 1_1 1_2
 The MP2K Update!
Front Cover
What's New
Sample Data
MapPoint 2013
Press Releases
MapPoint Forums
Link to MP2Kmag
Wish List
MapPoint Trial
 Earlier Content
Past News Items
Past What's New Announcements

MapPoint 2013

Programming MapPoint in .NET

MapPoint Book

  Spatial Community
SVG Tutorials

Map Visitors


Reverse Geocoding, Another Method

Gilles Kohl submitted this update to his previous article on reverse geocoding

My previous article on reverse geocoding showed how to find out more information about a lat/lon coordinate - an address in the ideal case where the coordinate would be precise enough to be located on a road MapPoint has address information for. In other cases,information like nearby pushpins, points of interest, and general vicinity information like city, county, state and country information. This is the topic this article focuses on. It demonstrates a potentially useful technique for retrieving a plausible "nearest address", and also explains the drawbacks associated with it, ways it can be improved, and why it does not always find an address or at least not the "best" one.

MapPoint does not have a "FindNearbyAddresses" functionality, unfortunately. For "good" coordinates, the ObjectsFromPoint technique discussed in the previous article will immediately return a matching address. But what to do for "bad" coordinates ?

Well, while it does not export that functionality, MapPoint is able to find the closest street to an arbitrarily positioned pushpin when computing a route. It will usually draw a straight line from the pushpin in question to the nearest road, and continue from there. The straight line will be referred to as "Local road(s)" in the directions pane, which is MapPoint's way of telling us that we're on our own on this segment of the trip :-)

The idea is to make use of this behaviour. While the endpoints of individual routing instructions are unfortunately not available as exact locations, each routing instruction has a position associated with it. According to the MapPoint documentation, this position is such that it represents "the best map view of the part of the route represented by the particular direction". As far as I could determine, this location is the center of a bounding box that encloses the corresponding route segment. As such, it is not particularly useful in general to learn anything about the endpoints of the segment or its form.

In the special case where the segment is a line though, things become more interesting - the location of the spot where this line connects to the nearest road can be interpolated when one knows the center of the bounding box.

The following image illustrates this:

The pushpin at [1] is the starting location of unknown address. When instructed to compute a route to a nearby spot, MapPoint will draw the first green segment identified as "Local road(s)". The white dot is the location associated with this routing instruction, available to us in the Directions collection. The yellow dot is computed by interpolation, and manages to get close enough to the nearest road to yield an address.

The "FindNearestAddress" routine in the sample below accepts a location object and tries to determine the nearest address. It first uses the "ObjectsFromPoint" technique described in the previous article in case the position provided is good enough for a direct match.

If this fails, it will instruct MapPoint to compute a route between the current position and another one (more details on that one later), using the fact that MapPoint will always try to route using a road, even if the two locations are close to each other.

The routine then tries to use the interpolation technique described above to find an address. This becomes the "new starting position".

If all goes well, the new starting position will match an address at the next iteration. If not, it will be used as the new position to find an address for.

That's the basic idea. In theory, our unknown pushpin is either located on a road, in which case we immediately get an address, or it is located "elsewhere", in which case the interpolation technique should get us the nearest road.

Unfortunately, reality is not that simple. There are two problems.

- The first problem is simply missing street address information. In some areas, MapPoint knows about roads and uses them for routing, but doesn't have names for them - they are simply called "local road(s)" and aren't useful as addresses of course. I have tried to add a device to the sample routine that copes with this situation, but it does not always succeed.
- The second problem is what I call the "so close, but yet so far" syndrome. When your "location X" is very close to a street, but not close enough to yield an address match, MapPoint will NOT draw the essential initial direct line that helps us find the road intersection. A starting location not that close would actually be better. This is actually what the sample tries to do in this case: move the starting point away some distance hoping that it will work on the next iteration. (Another option would be to retrieve the street name contained in the direction, giving up the chance of finding a better address that would include a house number)

To try the sample, do the following:

- Create a "Standard EXE" VB project and set a reference to your version of MapPoint
- Add a larger list box called List1, a command button Command1, and a checkbox called "Check1".
- paste the code below into the form
- Add my CalcPos routine from this former article
- Launch MapPoint
- launch the sample
- add a pushpin anywhere on the map.
- bring the sample form into the foreground, ideally in a way that you can still see MapPoint in the background and watch what happens in its window
- Press "Find address"
- Move the pushpin somewhere else and try again.

You can actually watch the iterations proceed and try to find a road.

The sample will create round yellow pushpins at the spot it tried for addresses, and a red pushpin at the one if finally found (if it did find an address)

The "local routing" checkbox determines which endpoint is used for the route starting at "location X". If local routing is checked, a spot close to locationX will be used. This is faster and tends to yield better results in urban areas.

If "local routing" is unchecked, the most specific nearby "object" will be used - usually, the center of a county or area. This tends to yield better results in rural areas and especially in connection with the "local road(s)" problem.

Note that the sample and "FindNearbyAddress" are not meant as routines that can simply plugged into your code. Rather, they are intended as demonstration and experimentation objects that can be elaborated on -I hope that MP2KMag will receive many improvement suggestions and ideas to develop a smarter device for "nearby address" determination.

Discuss this story in the forum.

Author: Gilles Kohl
Email: gilles(AT)
Gilles Kohl, a native of Luxembourg living in Germany, is a software development lead with PROCAD GmbH of Karlsruhe, Germany.

Mapping and especially GPS-related topics are a hobby - Gilles enjoys developing solutions for Microsoft MapPoint and his favorite outdoor occupation is confluence hunting.

As always, please direct questions to the newsgroup.

MP2Kmag Internet

 Recent Discussion
Browse GIS books and periodicals
Find a MapPoint Partner or Consultant
Real Estate Columbia, MO

Want Your Site To Appear Here?

   © 1999-2012 MP2K. Questions and comments to:
  Microsoft and MapPoint 2002/2004/2006/2009/2010/2011/2013 are either trademarks or registered trademarks of Microsoft.