[mkgmap-dev] Issues with --housenumbers

Thu Jan 8 20:08:30 GMT 2015

Hi WanMil,

> >
> > 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"...

Well, when you coded it I found only a few housenumbers in my 
area, so I did not even care about the result. Nowadays the data is much better,
but there are also many more errors.

> 
> >
> > 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.

If I got it right, we could add nodes and assign one number to each.
I've started the new branch housenumbers2 to experiment with this.

> 
> >
> > 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)?

Yes, tried that in the branch, seems to improve many cases
where the code in trunk is wrong.

> 
> > 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.

I'd like to repair the cases where we have addr:interpolation info.
The rest is more complex, but seldomly needed.

> 
> > 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)?

I found a few wrong numbers in my area because they did not
match the odd/even rule which is used almost everywhere.
Also, a sequence like 2,4,6,8,10,1,14 looks like the 1 should be a 12.

Later I noticed this link:
http://gulp21.bplaced.net/osm/housenumbervalidator/

> 
> >
> > 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?

I think in my hometown I found more errors caused by wrong OSM data.
The branch is already a little bit better.
In areas that use addr:place mkgmap doesn't work at all until we support
random numbers.

Gerd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20150108/7547f484/attachment-0001.html>