[PATCH] route recalculation sensitivity
Hi, I think I found the required bits. Seams to be the flag at 0x43 in the TRE header. Patch is attached. Seams to work fine in simulation mode on the nuvi 360. Lets see how it works tomorrow morning on the road ... Please let me know if this also works for you guys. Thanks Berni. Index: src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java =================================================================== --- src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java (revision 314) +++ src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java (working copy) @@ -167,8 +167,8 @@ writer.put(getPoiDisplayFlags()); writer.put3(displayPriority); - writer.putInt(0xd0401); - + writer.putInt(0x110301); // Was 0xd0401 before. 31.03.2009 Changed to 0x110301 to increase route recalculation speed + writer.putChar((char) 1); writer.put((byte) 0);
Bernhard Heibler wrote:
I think I found the required bits. Seems to be the flag at 0x43 in the TRE header. Patch is attached.
+ writer.putInt(0x110301); // Was 0xd0401 before. 31.03.2009 Changed to 0x110301 to increase route recalculation speed
Judging by the source code and the "documentation", the use of this word starting at 0x43 isn't yet known, and it does look as if the two low-order bytes here haven't changed much. *If* the important part of this patch is to change the value of byte 0x45 from 0x0D to 0x11 then we might postulate that the "recalculate distance" is actually "EarthPerimeter/(12 * pow(2, n))" where 'n' is that byte. (The '12' is just a fiddle-factor here). Assuming Earth's perimeter is 40Mm, that gives an original recalculate-distance of about 406m (yeah - I can believe that) changing to the new one of about 25m as claimed by Michel Marti. Internally of course the recalculate "distance" will actually be in some fraction of degrees or radians - probably in "Map Units" in practice. Again - assuming the 0x0D -> 0x11 change is the important bit, it leaves the interesting question of what the other bytes do. It will be easy experimentation to try other values of byte 0x45 to see if my postulated relationship holds. Byte 0x44 changed from 0x04 to 0x03. What did *that* do? Steve PS: I must admit that this isn't where I expected the recalculate-distance to be.
Hi, On Tue, Mar 31, 2009 at 5:58 PM, Steve Hosgood <steve@tallyho.bc.nu> wrote:
Bernhard Heibler wrote:
I think I found the required bits. Seems to be the flag at 0x43 in the TRE header. Patch is attached.
+ writer.putInt(0x110301); // Was 0xd0401 before. 31.03.2009 Changed to 0x110301 to increase route recalculation speed
Judging by the source code and the "documentation", the use of this word starting at 0x43 isn't yet known, and it does look as if the two low-order bytes here haven't changed much.
*If* the important part of this patch is to change the value of byte 0x45 from 0x0D to 0x11 then we might postulate that the "recalculate distance" is actually "EarthPerimeter/(12 * pow(2, n))" where 'n' is that byte. (The '12' is just a fiddle-factor here).
Assuming Earth's perimeter is 40Mm, that gives an original recalculate-distance of about 406m (yeah - I can believe that) changing to the new one of about 25m as claimed by Michel Marti. Internally of course the recalculate "distance" will actually be in some fraction of degrees or radians - probably in "Map Units" in practice.
Again - assuming the 0x0D -> 0x11 change is the important bit, it leaves the interesting question of what the other bytes do. It will be easy experimentation to try other values of byte 0x45 to see if my postulated relationship holds. Byte 0x44 changed from 0x04 to 0x03. What did *that* do?
I'm trying to understand better zoom levels. On gmxt the lowest distance i've seen is 0.380meters on zoom 30m from the ground. (i'm courios what's on other devices) Which lead to one unit of garmin map scale is 2.28 meters. To get this from (1<<24) earth circumference comes as 38260 kilometers(i've searched for this number and closest i've found are related to earths magnetic field) earthcirc*1000/(1<<(0xd))= 4670.410156 meters earthcirc*1000/(1<<(0xd+0x4))= 291.900635 meters earthcirc*1000/(1<<(0x11))= 291.900635 meters earthcirc*1000/(1<<(0x11+0x3))= 36.487579 meters 0xd looks like a base bits and 0x4 like a detail bits, maps inherits basemap at 0xd bits and goes up to 0xd+0x4 bits. Which gives the most deailed resolution of the map, which is level 0. If this is the map resolution which would explain why this lives in TRE header. Roads are on level 0 and it makes sense to look for nearest road in the range of the level 0 resolution. And select other road only if the last selected is out of that range. If that is true. For a map 20-24bits value of 0x1404 should trigger recalculation on earthcirc*1000/(1<<(0x14+0x4))= 2.280474 meters. -- have fun, alex
Bernhard Heibler wrote:
Hi,
I think I found the required bits. Seams to be the flag at 0x43 in the TRE header. Patch is attached. Seams to work fine in simulation mode on the nuvi 360. Lets see how it works tomorrow morning on the road ...
Please let me know if this also works for you guys.
Thanks Berni.
Not being a programmer of any kind the only way I know how to apply a patch is patch -p1 < mkgmap-route-recal-speed.patch Only this fails with can't find file to patch at input line 5 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Index: src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java |=================================================================== |--- src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java (revision 314) |+++ src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java (working copy) -------------------------- File to patch: If you tell me the necessary incantation I'll apply this and report back tomorrow Cheers Paul P.S. This is being applied against the current trunk
Paul escribió:
Bernhard Heibler wrote:
Hi,
I think I found the required bits. Seams to be the flag at 0x43 in the TRE header. Patch is attached. Seams to work fine in simulation mode on the nuvi 360. Lets see how it works tomorrow morning on the road ...
Please let me know if this also works for you guys.
Thanks Berni.
Not being a programmer of any kind the only way I know how to apply a patch is
patch -p1 < mkgmap-route-recal-speed.patch
Only this fails with
can't find file to patch at input line 5 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Index: src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java |=================================================================== |--- src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java (revision 314) |+++ src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java (working copy) -------------------------- File to patch:
I couldn't apply the patch but as it's only one line, I edited the file. Tested on the road, recalculation works fine now. Well done!! Cheers Carlos
If you tell me the necessary incantation I'll apply this and report back tomorrow
Cheers
Paul
P.S. This is being applied against the current trunk
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale OpenOffice desde http://es.openoffice.org/programa/index.html OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. OpenOffice es gratis. El uso de OpenOffice es totalmente legal. OpenOffice funciona mejor que otros paquetes de oficina. OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones.
Bernhard Heibler wrote:
Hi,
I think I found the required bits. Seams to be the flag at 0x43 in the TRE header. Patch is attached. Seams to work fine in simulation mode on the nuvi 360. Lets see how it works tomorrow morning on the road ...
Please let me know if this also works for you guys.
Thanks Berni.
Yep works for me too. I would guesstimate between 25m and 50m before recalculatio and far better than it previously was. Cheers Paul
On Tue, Mar 31, 2009 at 12:28:20AM +0200, Bernhard Heibler wrote:
Hi,
I think I found the required bits. Seams to be the flag at 0x43 in the TRE header. Patch is attached. Seams to work fine in simulation mode on the nuvi 360. Lets see how it works tomorrow morning on the road ...
Please let me know if this also works for you guys.
Works on my Edge 705. I tested by starting routing on my back yard and then walking to my front yard. About half way, it recalculated the route to use the road that is accessible from my front yard. Marko
Bernhard Heibler wrote:
Hi,
I think I found the required bits. Seams to be the flag at 0x43 in the TRE header. Patch is attached. Seams to work fine in simulation mode on the nuvi 360. Lets see how it works tomorrow morning on the road ...
Please let me know if this also works for you guys.
I hate to rain on the parade, but this *doesn't* work for me (Streetpilot i3). I think I see that some of the widths of the roads drawn on the map have got narrower (which is an improvement IMHO) but the recalculate distance isn't improved. Still around 250m for me. It must be said that because I don't have a working java development environment, I used a stock mkgmap and hacked the .img file it created. I was marginally surprised to see that the .img file has only got a single "GARMIN TRE" header in it, but it's a fairly small map just covering about 100km x 50km of my area (South Wales). The whole .img file is about 1.7Mb. Steve
Steve Hosgood wrote:
Bernhard Heibler wrote:
Please let me know if this also works for you guys.
I hate to rain on the parade, but this *doesn't* work for me (Streetpilot i3).
Sadly I must confirm this. I built maps with mkgmap r991 (which has the "fix") last night but it's still the same 250m recalculate-distance on the Streetpilot i3. What is (slightly) interesting is that the behaviour of the displayed map and the navigator on the i3 appear to be disjoint. You can quite clearly see that the "you are here" triangle jumps onto the road you're really driving quite quickly as you depart from the navigated route. It's just that the navigator doesn't notice and doesn't announce "recalculating" until you're 250m off the navigator's route. I think this had always been the case, even with the old constant of 0xD0401 in the TRE header. Am I the only guy in the world trying to run OSM maps on a Streetpilot? :-( Steve PS: I used the tool that I'd written to do a binary patch on existing maps on my genuine Garmin map, looking for TRE headers and printing the value of the mystery word at offset 0x43. There were plenty of them, and all were 0x110301.
On Fri, 3 Apr 2009, Steve Hosgood wrote:
Am I the only guy in the world trying to run OSM maps on a Streetpilot? :-(
Maybe on the i3. I successfully use a StreetPilot c510 with OSM. Currently I do not compile the maps by myself (I am waiting for the support for polygonal tiles), but I am just about to download a new mapset from Lambertus' site. I will report if I notice something on the route calculation sensitivity. -Wolfgang
Hi Ulf, as far as I know my patch was not yet committed into any svn branch. You have to patch the code yourself. I have attached the patch to this mail. To apply it go to the mkgmap folder and call: cat /whateverdir/mkgmap-route-recalspeed.patch | patch -p0 Berni. Ulf Möller schrieb:
Steve Hosgood schrieb:
Sadly I must confirm this. I built maps with mkgmap r991 (which has the "fix") On which branch is that? I did an update on trunk, and it still has the old code...
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Index: src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java =================================================================== --- src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java (revision 314) +++ src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java (working copy) @@ -167,8 +167,8 @@ writer.put(getPoiDisplayFlags()); writer.put3(displayPriority); - writer.putInt(0xd0401); - + writer.putInt(0x110301); // Was 0xd0401 before. 31.03.2009 Changed to 0x110301 to increase route recalculation speed + writer.putChar((char) 1); writer.put((byte) 0);
Bernhard Heibler wrote:
Hi Ulf,
as far as I know my patch was not yet committed into any svn branch. You have to patch the code yourself. I have attached the patch to this mail.
Mea culpa. I have a locally-patched checkout, and when I did an "svn up" of course it updated me to r991 (the latest at that time) but of course kept my local edit. As you say, stock -r991 doesn't do it. Should have checked my gmapsupp.img before posting. Sorry folks. Steve
Hi Steve, could you try if this patch works for you. It contains all changed bits in the various headers I found so far in the latest version of Free Malaysia Maps. Maybe some garmins need all this stuff. If your garmin supports route simulations you also might try if recalculation works on there maps http://www.malfreemaps.net/MFMv150.exe Until know I was not able to decode 0x43. In simulation mode it is hard to measure the distance you really have to debug it on the road. I didn't noticed a different behavior between 0x110301 or 0x110401. Both worked fine on my nuvi. Berni. Steve Hosgood schrieb:
Steve Hosgood wrote:
Bernhard Heibler wrote:
Please let me know if this also works for you guys.
I hate to rain on the parade, but this *doesn't* work for me (Streetpilot i3).
Sadly I must confirm this. I built maps with mkgmap r991 (which has the "fix") last night but it's still the same 250m recalculate-distance on the Streetpilot i3.
What is (slightly) interesting is that the behaviour of the displayed map and the navigator on the i3 appear to be disjoint.
You can quite clearly see that the "you are here" triangle jumps onto the road you're really driving quite quickly as you depart from the navigated route. It's just that the navigator doesn't notice and doesn't announce "recalculating" until you're 250m off the navigator's route. I think this had always been the case, even with the old constant of 0xD0401 in the TRE header.
Am I the only guy in the world trying to run OSM maps on a Streetpilot? :-(
Steve
PS: I used the tool that I'd written to do a binary patch on existing maps on my genuine Garmin map, looking for TRE headers and printing the value of the mystery word at offset 0x43. There were plenty of them, and all were 0x110301.
------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Index: src/uk/me/parabola/imgfmt/app/net/NETHeader.java =================================================================== --- src/uk/me/parabola/imgfmt/app/net/NETHeader.java (revision 347) +++ src/uk/me/parabola/imgfmt/app/net/NETHeader.java (working copy) @@ -29,7 +29,7 @@ * @author Steve Ratcliffe */ public class NETHeader extends CommonHeader { - public static final int HEADER_LEN = 55; // Other lengths are possible + public static final int HEADER_LEN = 100; //55; // Other lengths are possible private static final char SORTED_ROAD_RECSIZE = 3; @@ -89,6 +89,9 @@ writer.putInt(0); writer.put((byte) 1); writer.put((byte) 0); + writer.putInt(0); + writer.put((byte) 1); + writer.putInt(0x01000000); } ImgFileWriter makeRoadWriter(ImgFileWriter writer) { Index: src/uk/me/parabola/imgfmt/app/net/NODHeader.java =================================================================== --- src/uk/me/parabola/imgfmt/app/net/NODHeader.java (revision 347) +++ src/uk/me/parabola/imgfmt/app/net/NODHeader.java (working copy) @@ -62,7 +62,8 @@ nodes.writeSectionInfo(writer); // now sets 0x02 (enable turn restrictions?) - writer.putInt(0x27); + //writer.putInt(0x27); + writer.putInt(0x0303); writer.putChar(align); writer.putChar((char) (align - 1)); Index: src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java =================================================================== --- src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java (revision 347) +++ src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java (working copy) @@ -167,8 +167,8 @@ writer.put(getPoiDisplayFlags()); writer.put3(displayPriority); - writer.putInt(0xd0401); - + writer.putInt(0x110301); // Was 0xd0401 before. 31.03.2009 Changed to 0x110301 to increase route recalculation speed + writer.putChar((char) 1); writer.put((byte) 0);
Steve Hosgood wrote:
Bernhard Heibler wrote:
Hi,
I think I found the required bits.
I hate to rain on the parade, but this *doesn't* work for me (Streetpilot i3).
Hmm - I have a ray of sunshine for y'all. Though it seemed true that the new map was no better than the old one, today I had to replace the batteries in my Streetpilot which forced the unit through a cold restart (took 5 minutes to find the satellites). After all that, I was suddenly aware that the recalculate distance was down to about 30 - 50m!! So - maybe it *does* work for me then. Maybe the Streetpilot caches certain parameters from the mapping files? However - I have in the past switched from mkgmap maps to Garmin's own maps and back again, yet it didn't seem to fix the recalculate distance in that case. I don't get it. Steve
I thought patch to correct recalculation sensibility had been committed, but I'm again having about 200-250 m before nuvi recalculates. I'm using r1022, but I have noticed this behaviour since some days ago. Do I have to modify something in my local copy? Regards Carlos
On Tue, Apr 28, 2009 at 08:47:06PM +0200, Carlos Dávila wrote:
I thought patch to correct recalculation sensibility had been committed, but I'm again having about 200-250 m before nuvi recalculates. I'm using r1022, but I have noticed this behaviour since some days ago. Do I have to modify something in my local copy?
It was committed. However, this (the patch not working on Streetpilot) might apply to you: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q2/001776.html If the batteries are removeable, you might want to try that. Coincidentally, I tested bicycle routing today. It still fails (out of memory) for destinations some 300 km away, but worked to 120 km. I didn't try disabling the option "avoid highways", maybe I should have. Car routing seems fine for all of Finland. In the Edge 705, there is a routing option that will ask for confirmation before recalculating the route, which would be practical when riding a bicycle in built-up areas that can distort the GPS signal enough to fire the recalculation trigger. In Finnish, the option is called "fast" or "quick", looks like a translation bug. (Also, for car routing, it is possible to select "shortest route"/"shortest time"/"fast". The "fast" option will ask each time which one to favour, shortest route or time.) Marko
Marko Mäkelä escribió:
On Tue, Apr 28, 2009 at 08:47:06PM +0200, Carlos Dávila wrote:
I thought patch to correct recalculation sensibility had been committed, but I'm again having about 200-250 m before nuvi recalculates. I'm using r1022, but I have noticed this behaviour since some days ago. Do I have to modify something in my local copy?
It was committed. However, this (the patch not working on Streetpilot) might apply to you: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q2/001776.html
I had read that, but it have been working for me till last week or so, so may be a different reason. I'll drive with a nuvi and a hcx together and see if they behave different.
If the batteries are removeable, you might want to try that.
Coincidentally, I tested bicycle routing today. It still fails (out of memory) for destinations some 300 km away, but worked to 120 km. I didn't try disabling the option "avoid highways", maybe I should have. Car routing seems fine for all of Finland.
In the Edge 705, there is a routing option that will ask for confirmation before recalculating the route, which would be practical when riding a bicycle in built-up areas that can distort the GPS signal enough to fire the recalculation trigger. In Finnish, the option is called "fast" or "quick", looks like a translation bug. (Also, for car routing, it is possible to select "shortest route"/"shortest time"/"fast". The "fast" option will ask each time which one to favour, shortest route or time.)
Carlos Dávila escribió:
Marko Mäkelä escribió:
On Tue, Apr 28, 2009 at 08:47:06PM +0200, Carlos Dávila wrote:
I thought patch to correct recalculation sensibility had been committed, but I'm again having about 200-250 m before nuvi recalculates. I'm using r1022, but I have noticed this behaviour since some days ago. Do I have to modify something in my local copy?
It was committed. However, this (the patch not working on Streetpilot) might apply to you: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q2/001776.html
I had read that, but it have been working for me till last week or so, so may be a different reason. I'll drive with a nuvi and a hcx together and see if they behave different. Both Nuvi and HCx start recalculation at the same distance, so I think the problem must be in the map. If someone wants to check the map, it's available at http://mapas.alternativaslibres.es/gmapsupp.zip Regards Carlos
Carlos Dávila escribió:
Carlos Dávila escribió:
Marko Mäkelä escribió:
On Tue, Apr 28, 2009 at 08:47:06PM +0200, Carlos Dávila wrote:
I thought patch to correct recalculation sensibility had been committed, but I'm again having about 200-250 m before nuvi recalculates. I'm using r1022, but I have noticed this behaviour since some days ago. Do I have to modify something in my local copy?
It was committed. However, this (the patch not working on Streetpilot) might apply to you: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q2/001776.html
I had read that, but it have been working for me till last week or so, so may be a different reason. I'll drive with a nuvi and a hcx together and see if they behave different.
Both Nuvi and HCx start recalculation at the same distance, so I think the problem must be in the map. If someone wants to check the map, it's available at http://mapas.alternativaslibres.es/gmapsupp.zip It seems it was a problem with my mkgmap. After building a new mkgmap from a fresh source recalculation works as expected. Cheers Carlos
Hi, Had a chance to try out 0x110301 on a couple of bicycle rides and it appears to work OK on my etrex. The etrex recalculates after only a few tens of metres when I don't follow the route. I didn't spot it recalculating when it did not need to. I would have thought that changing to 0x110301 from 0xd0401 is probably worth doing anyway but as was suggested by some others, perhaps some further investigation would yield the "meaning" of those bits. I'm now quite busy with real work so I don't think I will be doing that. Cheers, Mark
On Thu, Apr 02, 2009 at 11:53:07PM +0100, Mark Burton wrote:
Had a chance to try out 0x110301 on a couple of bicycle rides and it appears to work OK on my etrex. The etrex recalculates after only a few tens of metres when I don't follow the route. I didn't spot it recalculating when it did not need to.
I took a bike trip today and can confirm this. In a railway underpass, the signal was so weak that the Edge 705 recalculated. Had the destination been 30 km away, this would have "blindfolded" me for tens of seconds. Not nice when you are in an unknown neighbourhood. This time, I knew the route and the recalculation (some 2 km distance) only took some seconds. For what it is worth, the route near the tunnel has quite many turns: * down the ramp (north), then turn 90 degrees left (west) * ride through the tunnel http://www.openstreetmap.org/browse/way/25813501 * up the ramp (west), then turn 270 degrees left (north) In the tunnel, the Garmin must have thought that I jumped to one of the roads that run on the surface. Back in Februray or so, when I was testing a routable map, the device almost crashed in this tunnel when I was riding the other way (southbound). It didn't stop recording the track, but it didn't display any map either until a power cycle. I can't see anything weird in the map data.
I would have thought that changing to 0x110301 from 0xd0401 is probably worth doing anyway but as was suggested by some others, perhaps some further investigation would yield the "meaning" of those bits. I'm now quite busy with real work so I don't think I will be doing that.
If the meaning is ever deciphered, it might be better to reduce the sensitivity a little bit, so that tunnels won't cause trouble. Marko
Bernhard Heibler wrote:
Hi,
I think I found the required bits. Seems to be the flag at 0x43 in the TRE header.... Tell you what, the code that handles the bytes at 0x47 and 0x48 looks flawed to me. Assuming 0x47 and 0x48 are a 16-bit number, mkgmap sets it to a constant '1':
writer.putInt(0x110301); writer.putChar((char) 1); writer.put((byte) 0); polyline.writeSectionInfo(writer); But looking at Garmin's own maps, I see a variety of numbers coded here in the range 0x4AE to 0x590.... (The following is a dump of the bytes at 0x43-0x46 and 0x47-0x4A interpreted at 32-bit LE numbers) Found 0: 0x110301 0x31000544 Found 1: 0x110301 0xC3000490 Found 2: 0x110301 0x8F0004CA Found 3: 0x110301 0x03000564 Found 4: 0x110301 0xF3000590 Found 5: 0x110301 0xDF000524 Found 6: 0x110301 0x1D000505 Found 7: 0x110301 0x94000537 Found 8: 0x110301 0x0000053F Found 9: 0x110301 0x3E000540 Found 10: 0x110301 0x5E00052F Found 11: 0x110301 0x06000512 Found 12: 0x110301 0x2E0004F8 Found 13: 0x110301 0xCE0004FF Found 14: 0x110301 0x880004EC Found 15: 0x110301 0x320004F1 Found 16: 0x110301 0x9C0004BC Found 17: 0x110301 0x240004F7 Found 18: 0x110301 0xA600050D Found 19: 0x110301 0x040004CD Found 20: 0x110301 0xBC0004EF Found 21: 0x110301 0x36000526 Found 22: 0x110301 0x080004D6 Found 23: 0x110301 0x100004AE Found 24: 0x110301 0x000004D8 So we see that Garmin themselves use 0x110301 at 0x43(!), it seems bytes 0x47-0x48 are a 16-bit number and presumably 0x49-0x410 are what mkgmap gets from the call to "polyline.writeSectionInfo(writer);". The document I have (John Mechalas, 2005) claims that 0x49 is actually constant '0' and that the byte at 0x4A is the "Offset of Polyline Overview Section TRE4". Steve
participants (10)
-
Alexander Atanasov -
Bernhard Heibler -
Carlos Dávila -
Mark Burton -
Marko Mäkelä -
Michel Marti -
Paul -
Steve Hosgood -
Ulf Möller -
Wolfgang v. Hansen