ARTICLES

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 (http://www.wgs84.com).

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 (http://www.mp2kmag.com/mappoint/discussion/viewtopic.asp?t=4078).

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.

Examples:

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.

	MP2Kmag Internet