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