mkgmap-869 pinky routing line
Hi, i have tested r869 with a simple trailtrack. A part of this track(trackpart_26), which caused the problem before now is working. Unfortunately trying the whole track doesn't work. The pinky line is drawn straight between trackpart_140 and trackpart_141 and again ok starting with trackpart_142. Splitting trackpart_141 into 2 pieces solves it. trackpart_141 contains 24 nodes with 711m length. But there were other parts(e.g. 105, 142,143) which are bigger. For me without any knowledge of the garmin img structure its a riddle. As you already mentioned, there must be another reason. But anyway hope my observings are helpful for you guys. I tried to attached the zipped mp-format-file of this track not knowing if its possible in this mailinglist. regards Gert Münzel
Hi, as I read from the mails in the last month here, address search by generated PIOs is the only alternative because the structure of the garmin 'search address' function is not understood. If I understand correctly, it's given as fact now that garmin-like address search can not be achieved. Can somebody give me a little heads up on the garmin address search? Under what circumstances can it be used by non-garmin data? Cause i actually have OSM maps for my etrex legend hcx here, which support the build in address search function. The map data is pretty old, and the search function doesn't work very well (doesn't know every street) but at least the search function itself is usable. So how could this be achieved, and why isn't it even remotely possible in mkgmap? Please don't mistake this as an 'I want this feature'-rant-mail, I'm just curious about the technical background. I've allready contacted the author of the map and asked which toolchain he used, but got no answer :( thanks Stefan
On Feb 11, 2009, at 10:17, stefan@binaervarianz.de wrote:
as I read from the mails in the last month here, address search by generated PIOs is the only alternative because the structure of the garmin 'search address' function is not understood.
If I understand correctly, it's given as fact now that garmin-like address search can not be achieved.
That's not at all how I understood the discussion, see e.g. http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/000392.html Cheers Robert
On Feb 11, 2009, at 08:27, Gert Münzel wrote:
i have tested r869 with a simple trailtrack. A part of this track(trackpart_26), which caused the problem before now is working. Unfortunately trying the whole track doesn't work. The pinky line is drawn straight between trackpart_140 and trackpart_141 and again ok starting with trackpart_142.
Splitting trackpart_141 into 2 pieces solves it. trackpart_141 contains 24 nodes with 711m length. But there were other parts(e.g. 105, 142,143) which are bigger. For me without any knowledge of the garmin img structure its a riddle. As you already mentioned, there must be another reason. But anyway hope my observings are helpful for you guys. I tried to attached the zipped mp-format-file of this track not knowing if its possible in this mailinglist.
I've put the attached mkgmaptest.mp through current SVN, and the resulting IMG through test.display.NNDisplay. One strange thing that showed up is that TRACKPART_141 has length 0 in NET, so clearly something is going wrong. I'll try to track it down. Cheers Robert
On Feb 11, 2009, at 10:38, Robert Vollmert wrote:
On Feb 11, 2009, at 08:27, Gert Münzel wrote:
i have tested r869 with a simple trailtrack. A part of this track(trackpart_26), which caused the problem before now is working. Unfortunately trying the whole track doesn't work. The pinky line is drawn straight between trackpart_140 and trackpart_141 and again ok starting with trackpart_142.
TRACKPART_141 has length 0 in NET, so clearly something is going wrong.
r877 (trunk) fixes the length 0. Does this also help with the routing error? Cheers Robert
Robert Vollmert schrieb:
On Feb 11, 2009, at 10:38, Robert Vollmert wrote:
On Feb 11, 2009, at 08:27, Gert Münzel wrote:
i have tested r869 with a simple trailtrack. A part of this track(trackpart_26), which caused the problem before now is working. Unfortunately trying the whole track doesn't work. The pinky line is drawn straight between trackpart_140 and trackpart_141 and again ok starting with trackpart_142.
TRACKPART_141 has length 0 in NET, so clearly something is going wrong.
r877 (trunk) fixes the length 0. Does this also help with the routing error?
Cheers Robert
Hi Robert, Yes, r877 seems to fix it. Actually i only tested it with the simple track i sent, but i will test it with more complicated networks of trails. Just for my interest (actually i don't no much about the structure of Garmin imgs and what is hold in the NET NOD RGN etc. sections), but how it is possible that one trackpart, which looks ok to me, causes this problem? Cheers Gert
On Feb 11, 2009, at 13:51, Gert Münzel wrote:
Yes, r877 seems to fix it. Actually i only tested it with the simple track i sent, but i will test it with more complicated networks of trails.
Just for my interest (actually i don't no much about the structure of Garmin imgs and what is hold in the NET NOD RGN etc. sections), but how it is possible that one trackpart, which looks ok to me, causes this problem?
It was a bug in mkgmap: A rounding error in the distance calculation between two nodes in the track caused a floating point result of NaN (not a number) instead of zero, because for the particular latitude involved, it turned out that sin(lat)^2+cos(lat)^2 was greater than 1. The NaN in turn was apparently converted to the integer 0, and written to the IMG as such (in two places: the length of the road in NET, and the length of the edge in the routing graph in NOD). Cheers Robert
participants (3)
-
Gert Münzel -
Robert Vollmert -
stefan＠binaervarianz.de