Hi Alexandre, thanks.
Maybe I should point out in what case the complex case is better: 1) assume a second road also named ABC and very close to the first one contains numbers 13, 5,15 in that order. This is what I call the "random number" case for which mkgmap has to produce many small intervals in both roads, else Garmin software will show multiple possible places for each number. 2) assume there is no other road named ABC in the near, but the numbers 1 to 11 are all at the beginning of the road (say first 50 m) while 17 is 500m away on the very end of the road. This is the case where I think mkgmap should add a number node so that the interpolated positions are closer to the houses. Gerd Date: Sun, 1 Mar 2015 07:03:22 -0300 From: [email protected] To: [email protected] Subject: Re: [mkgmap-dev] open issues in the housenumber2 branch 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
_______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
