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


Improving On The MapPoint Geocoding Algorithm - Pt. I

Rainer Barthels shares a method for getting better geocodes in MapPoint than the built-in routine by using the return values from FindAddressResults

With MapPoint you can import data from any sources and show these data as area, circle, chart or pushpin on the map. This is made by the Import Data Wizard and the Link Data Wizard.

For being able to put the graphical objects on the map, MP needs coordinates. In the wizards you can directly link to your own coordinates. Perhaps you have coordinates in your database by means of GPS or by using other systems. The format of the coordinates is WGS84 which means World Geodetic System 1984 (

Normally you don’t have coordinates but country, postcode, city and street. The process of finding a coordinate out of these infos is called geocoding. The wizards have this capability.

Unfortunately the result of wizard-geocoding is sometimes very bad in MP. Have a look at the complaints of Derek in the Q&A forum (

Sometimes an object is put far away from the real place. No problem if you have a few objects. But in my application I have sometimes several thousand graphical objects and it is very time consuming to correct them. This is not possible if the objects are changing every day.

So I wrote a program, which is based on the FindAddressResults– function of the ActiveX-Control and uses an Access database for the input fields. After geocoding the coordinates, the name of the assigned location, the quality, and the coordinates are written back to the database. Then I can use the Import Data Wizard and MP takes these coordinates directly.

The FindAddressResults-function has return-values:

- geoFirstResultGood
- geoAmbiguousResults
- geoNoGoodResult
- geoNoResults

When returning geoNoResults the address is completely wrong and must be corrected manually.

Problems came up with all other results. In real-world data streets and city-names are misspelled and abbreviated. Additionally the map of MP is incomplete. A lot of streets are missing in the rural country.

So I guess (without the code it is hard to say) MP looks for the combination postcode-street or city-street. He uses a match for city-name and this can lead to bad results (see the examples).

The geocoder ignores the resulting location, if the postcode of the street-address is different. Normally you can rely on the postcode. If the postcode is identical it is garantueed that the pushpin is not far away from the real place. Also city names are not unique and they can be controlled by the postcode-coordinate.


D, 66919, Harsberg, Bergstr. 14

The function returns Bergstrasse, 49205 Hasbergen and the result is geoFirstResultGood. Geocoder puts this object on the city 66919 Harsberg.

D, 67816, St.Alban, Hauptstrasse 32

The function returns Hauptstrasse, 26935 Stadtland and the result is geoFirstResultGood. Geocoder puts this object on the postcode 67816.

D, 67580, Hamm, Friedensstrasse

The function returns Friedensstrasse, 59073 Hamm and the result is geoFirstResultGood. Geocoder puts this object on the city 67580 Hamm.

Hauptstrasse 6; 66909 Nanzdietschweiler

Postcode and Street are not unique in germany (particularly in Rhineland-Palatinate). The 'Hauptstrasse' exists in 66909 Herschweiler-Pettersheim and in 66909 Wahnwegen. These addresses are proposed with result geoAmbiguousResults. 'Hauptstrasse' in Nanzdietschweiler is not in the MP-data. Geocoder ignores the streetname and sets the object on Nanzdietschweiler.

Hafenstrasse 6; 34125 Kassel

This address exists two times in MP with result geoAmbiguousResults. This is an error in the MP-data. The coordinates differ slightly. Here a unique assignment to one of these two locations is made.

Discuss this story in the forum.

Author: Rainer Barthels
Email: rbarthels(AT)
Rainer Barthels is working for 10 years in the field of optimization of vehicles (VRP=vehicle routing problem). He studied phyiscs at the university of Stuttgart and is now senior project manager at Kempten/Germany but heavily involved in programming (Delphi, C++).

MP2Kmag Internet

 Recent Discussion
Browse GIS books and periodicals
Find a MapPoint Partner or Consultant
Real Estate Columbia For Sale By Owner

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.