[mkgmap-dev] Re: my map testing

Fri Dec 12 15:58:15 GMT 2008

Hi,

On 12/12/08, Robert Vollmert <rvollmert-lists at gmx.net> wrote:
> On Dec 11, 2008, at 18:58, Alexander Atanasov wrote:
> > Do not increase bmlen if the starting point is not a node.
> > It represents the count of nodes, not their locations in the line
> > and nnodes is set to the real count from the reader.
> >
> > I don't know how this is handled:
> >  R1                           R1
> > ------------------X-------------------
> >                      | R2
> >
> > If R1 is the first segment it can be split in two and have bmlen=2 and
> > 01 10 bitmaps.
> >
> > If it's not the first segment starting point is a node depending on
> > the last point from the previous segment.
> >
> > So extend the nodes count only for roads with one node which is not
> > the starting one, i don't see how to find the segments.
> >
>
> I tried to code what I saw in some maps. Namely, most of the time, there's
> just the lower bmlen bits set, and bmlen=nnodes (eg bmlen=3, bs=7). Then
> there's a few cases where the lowest bit is not set, but above that bmlen
> bits are set, and bmlen=nnodes+1 (eg bmlen=3, bs=6). Furthermore, this
> appears to happen iff the start point of a road is not a node. In all the
> cases I've seen,
> (highest bit in bs) == (1 << (bmlen - 1)) .
>
> Do you have different examples?

I've seen bitmaps with holes too afaik somewhere in mg.
like bmlen=3 bitmap=101

For the extra bit you are right. If i read them the way they are in mkgmap
mapping looks accurate. Except for the start and end eb.

I found this for the case ----X---
garmin_net.c:469:1|SF:49915221 SD:10 l=0 ot=3 idx=12 gt=0x00(0) lng=10.579920 la
t=49.310932 d:0 sc:1 eb:1 dt:2
garmin_net.c:478:1|0 10.579920/49.310932 (78604/2310c8) e=1 <-- not a node
garmin_net.c:486:1|1 10.580800/49.311340 (7862d/2310db) e=1
garmin_net.c:486:1|2 10.581465/49.311619 (7864c/2310e8) e=0
garmin_net.c:502:1|segments:0 i:12 sd:10
garmin_net.c:508:1|NOD info at 740
garmin_net.c:517:1|NOD1 at 4165 bmlen=2 fb=0
garmin_net.c:522:1|NET: BITMAP: 2

[POLYLINE]
Type=0x0
RoadID=108
Data0=(49.31093,10.57992),(49.31134,10.58080),(49.31162,10.58146)
Nod1=1,169,0
[END]

and another ----X--- case

garmin_net.c:469:1|SF:49915221 SD:8 l=0 ot=3 idx=59 gt=0x16(0) lng=10.572925 lat
=49.313121 d:0 sc:0 eb:0 dt:3
garmin_net.c:478:1|0 10.572925/49.313121 (784be/23112e) e=0
garmin_net.c:486:1|1 10.572925/49.313314 (784be/231137) e=0
garmin_net.c:486:1|2 10.572839/49.313507 (784ba/231140) e=0
garmin_net.c:486:1|3 10.572860/49.313700 (784bb/231149) e=0
garmin_net.c:502:1|segments:0 i:59 sd:8
garmin_net.c:508:1|NOD info at 333
garmin_net.c:517:1|NOD1 at 2782 bmlen=2 fb=0
garmin_net.c:522:1|NET: BITMAP: 2

[POLYLINE]
Type=0x16
RoadID=50
RouteParam=0,0,0,0,1,1,1,1,1,0,0,1
Data0=(49.31312,10.57292),(49.31331,10.57292),(49.31351,10.57284),(49.31370,10.5
7286)
Nod1=3,69,0
[END]

I think the difference comes from what road the node belongs to.
nodes have only one road offset.
So if nodes are from that road mark their positions with extra bit.
That can explain the above cases and why start and end eb are not
always set.

But from the first case it looks like eb is not always a node
but a segmentation point in the line and bitmap makes the mapping
to nodes. Still not quite clear ...

-- 
have fun,
alex