Hi Gerd,
Hi all,
during the last weeks I tried to improve the --housenumber option.
Great!
First of all: In most cases the existing code works quite well,
but in many special cases it fails.
I remember when I started to implement the house number support for OSM
data I thought "oh just give it a short try if a very simple algorithm
can convert some of the house numbers to the mkgmap format". I am
surprised how good it works :-) Anyhow rather no specials are supported
and OSM sometimes is also an abbreviation for "Open Specials Map"...
I did not yet find a good solution, so I start to describe the problems
with the existing code.
1) No support for random house numbers.
In some areas there is no obvious order in house numbers.
Nevertheless the current code in mkgmap always produces
house number data that assumes that the numbers are either
in ascending or descending order. We would need new data
structures to support this, or at least ignore random housenumbers.
The effect of the current code is that MapSource shows multiple
possible places when you enter a road and a housenumber,
and maybe none of the places is correct.
Are single house numbers supported by the mkgmap format or do we always
have to attach an address interpolation to a street segment? If single
house numbers are not supported it is possible only to ignore them or to
cut the street into little segments.
2) No plausibility check is done.
The current code assigns a house (number element) to the closest road
segment.
It orders the houses by sorting these closest points.
a) This doesn't work very well when multiple houses lie at the end of a
road.
As an effect, a house with number 12 maybe assigned to the left side of
a road
containing only odd numbers (or vice versa), or
b) It also often fails when multiple houses are connected to the road
with an unnamed
service road. In many areas you have a group with odd numbers 1-9
followed by another group
with numbers 11-17. Depending on the position of the houses, the
calculated order might be
5,7,9,1,17,15,13,11 which results in an interval 5..11 instead of 1..17.
The result also depends on whether the service road is in the map or not .
Maybe this should be changed so that mkgmap tries to detect if the house
numbers are in/decreasing, even/odd/mixed and then use
min/max(housenumber) instead of first/last(housenumber)?
c) In some areas, different road objects are created with the same road
name, e.g. when
a p-shaped road is split or the road forms some kind of grid like this a
# sign.
In such an area it is likely that some houses are assigned to the wrong
(part of a )road.
I think this can be fixed only by associated street relations. It would
also be possible to calculate a candidate list of street segments for
each house number and then try to assing the house number so that it
fits best. But this sounds quite complex.
d) In some cases we might be able to detect wrong OSM data as such and print
a corresponding message.
Can you give some examples beside the easy ones (no street found for
house number 999 or house number without street name tag)?
Both points 1) and 2) are correlated. Without a plausibilty check we
cannot detect
the random house number case, so I think it is an interesting problem
of pattern recognition. The human brain is very good with that, but it
is difficult to find
a quick and good algo for it.
Yep. Can you estimate how many percents of house number are not handled
well by the current algorithm?
WanMil
Gerd
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
