bearing/heading influence on routing
Hi Programmers, first see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q1/014145.html I see two different interpretations: 1) mkgmap encodes the initial heading (A-B) and the final heading (C-D), always using one byte "curve data " for the final heading. 2) display tool displays the initial heading as "direction", and one or two bytes curve data My theory is that the two byte curve data is used when we have a road where initial heading AND final heading are (very) different from the direction (A-D). Question is: what value is stored in the different fields? Does anybody already know more details? If not, what is the best way to find out? I could either try to write a program that displays the data in real maps, or I could simply use try and error in the mkgmap write routine to find out how MapSource reacts one different codings. I played a little bit with the latter and I see differences in the calculated times. Gerd
Hi Gerd
first see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q1/014145.html
I see two different interpretations: 1) mkgmap encodes the initial heading (A-B) and the final heading (C-D), always using one byte "curve data " for the final heading. 2) display tool displays the initial heading as "direction", and one or two bytes curve data
My theory is that the two byte curve data is used when we have a road where initial heading AND final heading are (very) different from the direction (A-D). Question is: what value is stored in the different fields?
Does anybody already know more details?
Not me :)
If not, what is the best way to find out?
Even though I only ever worked with a map consisting of 3 roads I found it very difficult to keep track of all the data. For the global index I eventually decided that a program that checked theories about how the format worked rather than just displaying the data was very useful. So I would calculate the actual angles and distances for a road segment and compare with the route data. Only print things that don't fit with what is known. Concentrate on one test at a time. I'd be interested in helping out it if possible. A visual program to see large scale layout would probably be useful too, but that is a lot of work. I might try writing as an OSM file or SVG.
I could either try to write a program that displays the data in real maps, or I could simply use try and error in the mkgmap write routine to find out how MapSource reacts one different codings. I played a little bit with the latter and I see differences in the calculated times.
Of course that is all interesting information too. ..Steve
Hi Steve,
I'd be interested in helping out it if possible.
great. I got lost looking at the different tools (NetDisplay, NodDisplay, NodConvert, NetCheck), and mkgmap itself also reads the data for the combiners, all implement maybe 50% of what I'd like to have, and the code is hard to understand. If I got this right, we are pretty good (=sure what we do) at reading RGN, LBL and NET, while NOD1 data is difficult to read, and looking at the output of NodDisplay for my Garmin map I see too many errors like "lost sync". So, as a first step, I'd like to have a routine that reads NET and maybe also LBL and stores all offsets to NOD1 in a HashMap, similar to nod1recs in NodDisplay. Finally, the NOD1 read routine should use the HashMap to resync. Or more generally: Start reading what is known best, extract and store pointers, and use them to verify further read actions. Missing or empty sections should not stop the processing, e.g. my original map contains an empty NET2 and NET3 section. A test program should be able to call a few routines to read data and than be able to analyse or convert NOD data. Gerd
Hi Gerd
great. I got lost looking at the different tools (NetDisplay, NodDisplay, NodConvert, NetCheck),
Ha! I didn't realise or remember that Robert had written NodConvert. That could be useful. There is also imgdecode, which is at the top of the display project. There are a few updates to John Mechalas's implementation so that it doesn't crash on modern files. It is best for TRE LBL and for RGN if you don't need the complete set of points.
and mkgmap itself also reads the data for the combiners, There is only minimal read code in mkgmap and I try to do things in display first.
If I got this right, we are pretty good (=sure what we do) at reading RGN, LBL and NET, while NOD1 data is difficult to read, and looking at the output of NodDisplay
Well there are still a few problems reading NET as well. So NOD1 has the most complex structure, but at least there are section that have a length so we can always re-sync.
Or more generally: Start reading what is known best, extract and store pointers,
Yes, we have had code like that before, sometimes I take it out once it is not needed any more. ..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Steve, today I noticed that I can use mkgmaps MapReader to read my Garmin map, it just doesn't contain code to read the NOD file. I should be able to use that code in a small program like NodDisplay, just to fill a list of NOD1 offsets. Gerd Steve Ratcliffe wrote
Hi Gerd
great. I got lost looking at the different tools (NetDisplay, NodDisplay, NodConvert, NetCheck),
Ha! I didn't realise or remember that Robert had written NodConvert. That could be useful.
There is also imgdecode, which is at the top of the display project. There are a few updates to John Mechalas's implementation so that it doesn't crash on modern files. It is best for TRE LBL and for RGN if you don't need the complete set of points.
and mkgmap itself also reads the data for the combiners, There is only minimal read code in mkgmap and I try to do things in display first.
If I got this right, we are pretty good (=sure what we do) at reading RGN, LBL and NET, while NOD1 data is difficult to read, and looking at the output of NodDisplay
Well there are still a few problems reading NET as well.
So NOD1 has the most complex structure, but at least there are section that have a length so we can always re-sync.
Or more generally: Start reading what is known best, extract and store pointers,
Yes, we have had code like that before, sometimes I take it out once it is not needed any more.
..Steve _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/bearing-heading-influence-on-routing-tp578246... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (3)
-
Gerd Petermann -
GerdP
-
Steve Ratcliffe