Hi, All! I've tried to parse the problem map from the wiki http://www.osmaustralia.org/garminroute/VIC_route.img.zip w/ libgarmin's gartest. And here are the results: garmin_subdiv.c:370:1|Error have 1 points but datalen is 1, bpx=2, bpy=2 si.sign_info_bits=4 garmin_subdiv.c:371:1|dp=05 extra_bit=1 bs_info=00 garmin_subdiv.c:376:1|05 This comes quite often - looks like the extra_bit is not accounted correctly. 4+2+2 = 8 but with extra bit it's 9. There are some garmin_subdiv.c:200:15|Point 1 have zero deltas eb=1 which means that deltas from the bitstream are 0 only the extrabit is set. garmin_net.c:469:1|SF:63242702 SD:2022 l=0 ot=3 idx=83 gt=0x06(0) lng=150.880587 lat=-34.388967 d:0 sc:0 eb:1 dt:6 garmin_net.c:478:1|1 150.880587/-34.388967 (6b4af9/ffe78bae) garmin_net.c:486:1|1 150.880930/-34.387057 (6b4b09/ffe78c07) e=0 garmin_net.c:486:1|2 150.880952/-34.386992 (6b4b0a/ffe78c0a) e=0 garmin_net.c:486:1|3 150.881402/-34.385684 (6b4b1f/ffe78c47) e=1 garmin_net.c:486:1|4 150.881531/-34.384761 (6b4b25/ffe78c72) e=0 garmin_net.c:486:1|5 150.882239/-34.381135 (6b4b46/ffe78d1b) e=1 garmin_net.c:486:1|6 150.882518/-34.380705 (6b4b53/ffe78d2f) e=1 garmin_net.c:502:1|segments:0 i:83 sd:2022 garmin_net.c:508:1|NOD info at 616790 garmin_net.c:517:1|NOD1 at 3120649 bmlen=5 fb=1 garmin_net.c:522:1|NET: BITMAP: 1f Here the bmlen should be 4. I'll look for more later. -- have fun, alex
Hi, Extra bit should be set only on segments on level 0. level=0 bits:24 in the VIC_... map. But looks like it's set on all levels now. -- have fun, alex
Hi, This looks wrong. No extra bit between signinfo and the bitstream itself. -- have fun, alex
Hi, Ignore the prev diff. Actually the extrabit is before deltas, not after them. -- have fun, alex
Hi, Not even compile tested but ... Try to check if the road comes from level0 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. -- have fun, alex
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? Here's a of all bmlen / bs in a large map: # bmlen bs ---------------------------------------------- 1 03 06 1 07 7e 1 08 fe 1 12 ff ff 03 1 16 ff ff 3f 1 17 ff ff 7f 1 18 ff ff ff 1 19 ff ff ff 01 1 1a ff ff ff 03 1 1c ff ff ff 0f 1 20 ff ff ff ff 1 25 ff ff ff ff 1f 1 28 ff ff ff ff ff 2 14 ff ff 0f 2 15 ff ff 1f 2 21 ff ff ff ff 01 3 01 01 3 1b ff ff ff 07 5 02 02 6 11 ff ff 01 7 10 ff ff 7 13 ff ff 07 8 0e ff 3f 10 0c ff 0f 12 0d ff 1f 14 0f ff 7f 25 0b ff 07 31 08 ff 31 0a ff 03 39 09 ff 01 51 07 7f 62 05 1f 73 06 3f 107 04 0f 151 03 07 21713 02 03 Cheers Robert
Hi, On 12/12/08, Robert Vollmert <rvollmert-lists@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
On Dec 11, 2008, at 18:05, Alexander Atanasov wrote:
Ignore the prev diff. Actually the extrabit is before deltas, not after them.
A bitstream appears to be as follows: signinfo extra bit 0 deltas 1 extra bit 1 deltas 2 extra bit 2 ... deltas n extra bit n I.e., there's n+1 extra bits for n deltas. This is a little hard to track down because the last extra bit is usually zero, but there are cases where it isn't. But even if it's zero, this bit may mean that an extra zero byte is written. That last extra bit went in with r730, fixing some problems. Now, suppose "deltas k" describe "coordinate k" (with the polyline starting at coordinate 0). It's kind of open whether "extra bit k" should be associated with coordinate k, with coordinate k+1, or with the line segment between coordinates k and k+1. But associating extra bit k with coordinate k offers the easiest interpretation of the extra bits I've seen: Except for extra bit 0 and extra bit n, extra bit k is set iff coordinate k is a node. I've never seen extra bit 0 set, and I believe extra bit n is set iff coordinate n is a node of the road, but not the last node. All quite unsure, though. Cheers Robert
Hi, Robert! On Thu, Dec 11, 2008 at 11:45 PM, Robert Vollmert <rvollmert-lists@gmx.net> wrote:
A bitstream appears to be as follows:
signinfo extra bit 0 deltas 1 extra bit 1 deltas 2 extra bit 2 ... deltas n extra bit n
I.e., there's n+1 extra bits for n deltas. This is a little hard to track down because the last extra bit is usually zero, but there are cases where it isn't. But even if it's zero, this bit may mean that an extra zero byte is written. That last extra bit went in with r730, fixing some problems.
Now, suppose "deltas k" describe "coordinate k" (with the polyline starting at coordinate 0). It's kind of open whether "extra bit k" should be associated with coordinate k, with coordinate k+1, or with the line segment between coordinates k and k+1.
But associating extra bit k with coordinate k offers the easiest interpretation of the extra bits I've seen: Except for extra bit 0 and extra bit n, extra bit k is set iff coordinate k is a node. I've never seen extra bit 0 set, and I believe extra bit n is set iff coordinate n is a node of the road, but not the last node.
All quite unsure, though.
I've seen 0x00 at the end too, but i think it's the zero delta or padding most probably if bpx+bpy+eb > 8, so every thing can be read in 16 or 32bit chunks. I did some quick tests here but can not find a map with the zero eb set or the last is set too. can you send me such map for testing? eb marks a node, that's sure. two nodes make the arc. and that's why first and last are not so important. from the gps position you find the closest point on the line P0, P1,P2,P3. It's between two nodes and you travel to one of them. S--P0---N1-----P1------P2-------N2---P3-------E(s1) If on P0, next node is N1, if past N1 next is N2, if past P3 you reach the end of line. You don't need eb at S and E in that case. If there is one more segment continuing at E E(s2)---P4---N3-------N4------E2 E(s1) and E(s2) are exactly the same point, that continues the line. the line is connected and you are between N2 and N3 - thats the arc. If E is a node you need an eb in that case on P4, you are between E and N3. Traveling in the oposite direction is the same, if you leave the line over S you are on a new road, if you are past N1 you travel to S. That's why i think that S don't need an eb(you can always consider it as a node). And E only if there are more segments. More important are bmlen and the bitmap. bmlen is the count of nodes bitmap probably defines nodes to skip. When you start to read from the node how much nodes there are that point to the same road in NET. Reading is something like that read the node, recursive walk all arcs and follow the ones that are for the same road as the starting node. That gives exactly bmlen nodes. That's needed when you want to find where are you on the road. More testing will show better what is what :) -- have fun, alex
On Dec 11, 2008, at 17:36, Alexander Atanasov wrote:
Extra bit should be set only on segments on level 0. level=0 bits:24 in the VIC_... map. But looks like it's set on all levels now.
Thanks, both for the diagnosis and the patch (applied). I'm hoping that's what caused the VIC display problems. This is also good in so far as we don't have to worry about what to do with nodes when lines are simplified. Cheers Robert
participants (2)
-
Alexander Atanasov -
Robert Vollmert