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