Hi Gerd, I agree with you that the trunk approach is the better solution. I think that the second case is difficult to develop and maintain and adds little value in terms of navigation.
Alexandre 2015-03-01 5:42 GMT-03:00 Gerd Petermann <[email protected]>: > Hi all, > > during the last days I've analysed the reasons for the error messages > reported > by some of you. I came to the conclusion that I have to > - change the handling of addr:interpolation ways completely > - add code to detect the "random number" case earlier and - if detected - > use different methods to split the number intervals > > Both are rather complex changes, so I'll need a few days to code this. > > One open question for you: > How should we handle "missing" information? > If mkgmap finds the numbers 1,3,9,11,17 in that order on the left side > of a road called ABC, it can create different housenumber informations. > One could be like "odd numbers from 1 to 17 on the left", > another could be a more complex sequence > 1) "odd numbers from 1 to 3 on the left", > 2)"odd numbers from 9 to 11 on the left", > 3) "odd number 17 on the left" > A search for ABC 5 would either show a point between 3 and 9 > or two entries with the numbers 3 and 9. > The latter tells you that OSM probably doesn't contain the > exact information and let's you decide where to search for ABC 5. > > The trunk version tends to the simple info, while r3486 > is more likely to produce the complex one. > I think trunk is better here, the complex case should only > occur if the "random number" case was detected. > > Do you agree? > > Gerd > > > _______________________________________________ > mkgmap-dev mailing list > [email protected] > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >
_______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
