 |
|
 |
 |
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)_deletethisincludingunderlines_compuserve.com URL: http://www.procad.de 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.
|
 |
 |
 |
Recent Discussion
|
 |
|
 |
 |
|
 |
Resources
|
 |
|
 |
|
 |