<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 Colin,<br><br>I think I tried it already, but here is my current knowledge:<br>The Garmin format stores addresses like interpolation ways along roads (=routable ways)<br>The corresponding information in mkgmap is stored in class Numbers,<br>which has the fields start, end, and style, once for the left, once for the right side of the road.<br>The style tells you what numbers are between start and end, one of "odd,even,both,none".<br>The log shows this as e.g. (n4),B,183,194,B,174,182<br>which means something like<br>"road segment number 4 has B="both" numbers from 183 to 194 on the left and B="both" numbers from 174 to 182 on the right"<br><br>Another example: (n3),O,1587,1587,E,764,894 <br>means<br>"road segment number 3 has O="odd" number 1587 on the left and E="even" numbers from 764 to 894 on the right"<br>The special case (n4),N,0,0,N,0,0 means "no numbers in road segment 4"<br><br>As you can see we can describe single numbers as well as intervals. <br>The numbers for the whole road is stored as a list of the above intervals, starting with the first segment.<br>This looks like<br>0,N,0,0,B,782,219 + (n1),B,240,1119,B,300,1161 + (n2),...<br><br>The tricky part:<br>Where does a segment start and end?<br>Each (number) segment starts and ends with a so called number node.<br>Each crossing or road junction is always a number node, any other point on the way can be flagged as a number node.<br><br>When you search for an addresss using a street name and house number,<br>the Garmin software seems to check each possible road starting with the first segment.<br>If the number falls into one of the segments (and matches the odd/even criteria)<br>the corresponding position in that road segment is interpolated and shown as a result,<br>else the closest matches are shown.<br><br>My goal is to produce a reasonable list of segments so that the interpolated <br>positions are close to the point on the road which you would like to use to <br>"park your car" without blowing up the img size too much and without<br>adding number nodes that cause visible angles (zig-zagging).<br><br>Gerd<br><br><br><div><hr id="stopSpelling">Date: Sun, 1 Mar 2015 10:31:03 +0100<br>From: colin.smale@xs4all.nl<br>To: mkgmap-dev@lists.mkgmap.org.uk<br>Subject: Re: [mkgmap-dev] open issues in the housenumber2 branch<br><br>

Gerd, can you explain how addresses are stored in the Garmin maps? Are they millions of individual nodes, or "interpolation ways" with a start and an end? Are they just coordinates, or are they internally linked to a road in some way? Can it handle non-numeric house numbers? Understanding the "target data model" might help to assess all the possibilities we have in interpreting the data from OSM.<BR>
Colin<BR>
<div>&nbsp;</div>
On 2015-03-01 09:42, Gerd Petermann wrote:<BR>
<blockquote style="padding-left:5px;border-left:#1010ff 2px solid;">
<div dir="ltr">Hi all,<br><br>during the last days I've analysed the reasons for the error messages reported<br>by some of you. I came to the conclusion that I have to <br>- change the handling of addr:interpolation ways completely<br>- add code to detect the "random number" case earlier and - if detected - <br>use different methods to split the number intervals<br><br>Both are rather complex changes, so I'll need a few days to code this.<br><br>One open question for you:<br>How should we handle "missing" information?<br>If mkgmap finds the numbers 1,3,9,11,17&nbsp; in that order on the left side<br>of a road called ABC, it can create different housenumber informations.<br>One could&nbsp; be like "odd numbers from 1 to 17 on the left",<br>another could be a more complex sequence <br>1) "odd numbers from 1 to 3 on the left",<br>2)"odd numbers from 9 to 11 on the left",<br>3) "odd number 17 on the left"<br>A search for ABC 5 would either show a point between 3 and 9<br>or two entries with the numbers 3 and 9.<br>The latter tells you that OSM probably doesn't contain the <br>exact information and let's you decide where to search for ABC 5.<br><br>The trunk version tends to the simple info, while r3486 <br>is more likely to produce the complex one.<br>I think trunk is better here, the complex case should only<br>occur if the "random number" case was detected.<br><br>Do you agree?<br><br>Gerd<br><br></div>
<br>
<pre>_______________________________________________
mkgmap-dev mailing list
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a>
<a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a>
</pre>
</blockquote>

<br>_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</div>                                               </div></body>
</html>