logo separator

[mkgmap-dev] open issues in the housenumber2 branch

From Gerd Petermann gpetermann_muenchen at hotmail.com on Sun Mar 1 10:02:57 GMT 2015

Hi Colin,

I think I tried it already, but here is my current knowledge:
The Garmin format stores addresses like interpolation ways along roads (=routable ways)
The corresponding information in mkgmap is stored in class Numbers,
which has the fields start, end, and style, once for the left, once for the right side of the road.
The style tells you what numbers are between start and end, one of "odd,even,both,none".
The log shows this as e.g. (n4),B,183,194,B,174,182
which means something like
"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"

Another example: (n3),O,1587,1587,E,764,894 
means
"road segment number 3 has O="odd" number 1587 on the left and E="even" numbers from 764 to 894 on the right"
The special case (n4),N,0,0,N,0,0 means "no numbers in road segment 4"

As you can see we can describe single numbers as well as intervals. 
The numbers for the whole road is stored as a list of the above intervals, starting with the first segment.
This looks like
0,N,0,0,B,782,219 + (n1),B,240,1119,B,300,1161 + (n2),...

The tricky part:
Where does a segment start and end?
Each (number) segment starts and ends with a so called number node.
Each crossing or road junction is always a number node, any other point on the way can be flagged as a number node.

When you search for an addresss using a street name and house number,
the Garmin software seems to check each possible road starting with the first segment.
If the number falls into one of the segments (and matches the odd/even criteria)
the corresponding position in that road segment is interpolated and shown as a result,
else the closest matches are shown.

My goal is to produce a reasonable list of segments so that the interpolated 
positions are close to the point on the road which you would like to use to 
"park your car" without blowing up the img size too much and without
adding number nodes that cause visible angles (zig-zagging).

Gerd


Date: Sun, 1 Mar 2015 10:31:03 +0100
From: colin.smale at xs4all.nl
To: mkgmap-dev at lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] open issues in the housenumber2 branch



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.

Colin

 
On 2015-03-01 09:42, Gerd Petermann wrote:


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
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20150301/46bec3c8/attachment.html>


More information about the mkgmap-dev mailing list