[mkgmap-dev] Issues with --housenumbers

Thu Jan 8 19:44:55 GMT 2015

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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>