<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hi WanMil,<br><br>> ><br><div>> > First of all: In most cases the existing code works quite well,<br>> > but in many special cases it fails.<br>> <br>> I remember when I started to implement the house number support for OSM <br>> data I thought "oh just give it a short try if a very simple algorithm <br>> can convert some of the house numbers to the mkgmap format". I am <br>> surprised how good it works :-) Anyhow rather no specials are supported <br>> and OSM sometimes is also an abbreviation for "Open Specials Map"...<br><br>Well, when you coded it I found only a few housenumbers in my <br>area, so I did not even care about the result. Nowadays the data is much better,<br>but there are also many more errors.<br><br>> <br>> ><br>> > I did not yet find a good solution, so I start to describe the problems<br>> > with the existing code.<br>> ><br>> > 1) No support for random house numbers.<br>> > In some areas there is no obvious order in house numbers.<br>> > Nevertheless the current code in mkgmap always produces<br>> > house number data that assumes that the numbers are either<br>> > in ascending or descending order. We would need new data<br>> > structures to support this, or at least ignore random housenumbers.<br>> > The effect of the current code is that MapSource shows multiple<br>> > possible places when you enter a road and a housenumber,<br>> > and maybe none of the places is correct.<br>> <br>> Are single house numbers supported by the mkgmap format or do we always <br>> have to attach an address interpolation to a street segment? If single <br>> house numbers are not supported it is possible only to ignore them or to <br>> cut the street into little segments.<br><br>If I got it right, we could add nodes and assign one number to each.<br>I've started the new branch housenumbers2 to experiment with this.<br><br>> <br>> ><br>> > 2) No plausibility check is done.<br>> > The current code assigns a house (number element) to the closest road<br>> > segment.<br>> > It orders the houses by sorting these closest points.<br>> > a) This doesn't work very well when multiple houses lie at the end of a<br>> > road.<br>> > As an effect, a house with number 12 maybe assigned to the left side of<br>> > a road<br>> > containing only odd numbers (or vice versa), or<br>> > b) It also often fails when multiple houses are connected to the road<br>> > with an unnamed<br>> > service road. In many areas you have a group with odd numbers 1-9<br>> > followed by another group<br>> > with numbers 11-17. Depending on the position of the houses, the<br>> > calculated order might be<br>> > 5,7,9,1,17,15,13,11 which results in an interval 5..11 instead of 1..17.<br>> > The result also depends on whether the service road is in the map or not .<br>> <br>> Maybe this should be changed so that mkgmap tries to detect if the house <br>> numbers are in/decreasing, even/odd/mixed and then use <br>> min/max(housenumber) instead of first/last(housenumber)?<br><br>Yes, tried that in the branch, seems to improve many cases<br>where the code in trunk is wrong.<br><br>> <br>> > c) In some areas, different road objects are created with the same road<br>> > name, e.g. when<br>> > a p-shaped road is split or the road forms some kind of grid like this a<br>> > # sign.<br>> > In such an area it is likely that some houses are assigned to the wrong<br>> > (part of a )road.<br>> <br>> I think this can be fixed only by associated street relations. It would <br>> also be possible to calculate a candidate list of street segments for <br>> each house number and then try to assing the house number so that it <br>> fits best. But this sounds quite complex.<br><br>I'd like to repair the cases where we have addr:interpolation info.<br>The rest is more complex, but seldomly needed.<br><br>> <br>> > d) In some cases we might be able to detect wrong OSM data as such and print<br>> > a corresponding message.<br>> <br>> Can you give some examples beside the easy ones (no street found for <br>> house number 999 or house number without street name tag)?<br><br>I found a few wrong numbers in my area because they did not<br>match the odd/even rule which is used almost everywhere.<br>Also, a sequence like 2,4,6,8,10,1,14 looks like the 1 should be a 12.<br><br>Later I noticed this link:<br><a href="http://gulp21.bplaced.net/osm/housenumbervalidator/" target="_blank">http://gulp21.bplaced.net/osm/housenumbervalidator/</a><br><br>> <br>> ><br>> > Both points 1) and 2) are correlated. Without a plausibilty check we<br>> > cannot detect<br>> > the random house number case, so I think it is an interesting problem<br>> > of pattern recognition. The human brain is very good with that, but it<br>> > is difficult to find<br>> > a quick and good algo for it.<br>> <br>> Yep. Can you estimate how many percents of house number are not handled <br>> well by the current algorithm?<br><br>I think in my hometown I found more errors caused by wrong OSM data.<br>The branch is already a little bit better.<br>In areas that use addr:place mkgmap doesn't work at all until we support<br>random numbers.<br><br>Gerd<br></div> </div></body>
</html>