Felix Hartmann wrote:

svn commit wrote:

...

Version 1410 was commited by markb on 2009-11-29 19:18:02 +0000 (Sun, 29 Nov 2009) Add --merge-lines option to combine lines at lower zoom levels.

Also adds --reduce-point-density option to set the error distance used by the Douglas Peucker line simplifying filter.

Patch by Johann Gail.

Trivial mods by me to options text and also to disable the DP filter when --reduce-point-density=0 is specified.

Actually I just noticed a but that sometimes happens when using this. Routing in Mapsource can get broken if not in resolution 24. So once you zoom out, and point with the mouse somewhere, the tooltip shows up somewhere else! If this is pretty close, you will instead be routed to somewhere else, or clicking into the map makes no routing at all.

I can remember that the "wrong" tooltip location happend around one year ago with mkgmap too. It was then solved later on (don't ask my when, was it the introduction of routing?), maybe with 1410 we have run into that error again.

- I'm currently trying out if any particular option is responsible for this, or if this new revision is the cause for the failure (upon closer inspection I noticed the same problem for "patch v8" - simply overlooked it before). Okay, the merge-lines seems to be responsible for it! - However also very aggressive dp filter settings might cause the tooltip to show up slighltly away from the mouse (the tooltip will show up where the road would be in resolution 24) - however only when using --merge-lines the tooltip distance gets so great that sometimes it actually breaks using the routing tool in Mapsource. Aggressive dp filter alone (=10) cause no damage.

...

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Felix, Johann,

...

Okay, the merge-lines seems to be responsible for it! - However also very aggressive dp filter settings might cause the tooltip to show up slighltly away from the mouse (the tooltip will show up where the road would be in resolution 24) - however only when using --merge-lines the tooltip distance gets so great that sometimes it actually breaks using the routing tool in Mapsource. Aggressive dp filter alone (=10) cause no damage.

Only to be sure I understand you correctly: If you dont use the merge-lines option, then the error with the tooltip does not appear? If this is the case, then the fault lies for sure in the newly introduced merge line code.

I can confirm that this issue exists. I think it's related to my posting the other day where I talked about the disparity between graphical lines and the routing arcs when the lines are being merged. My guess is... After merging you have 1 graphical line that spans the length of the combined lines associated with a routing arc that only spans the length of the original un-merged line. When you put the cursor near the lines that have been merged, mapsource, finds the arc associated with that line and puts the pop-up as close to the cursor as it can while still being on the arc. As the arc only spans a part of the whole merged line, the popup jumps (away from the cursor) to the end of the arc away. It's not really that surprising given the resulting data structure that has been produced by the merging. Cheers, Mark

Am 30.11.2009 um 13:51 schrieb Felix Hartmann:

...

So if I understand correctly, the only real possibility for merging, will be before creating the routing? And as I understood this is really complex (won't be implemented soon, because there are more important things to do). So for the while being the merge-lines can only be considered very experimental.

For reference: I've already posted about this in the thread "[PATCH v1] Merge similar lines and ways". You'll have to do the merging after the processing of the ways, but before the IMG file is created. As the current code creates the IMG file "on the fly" during processing, there is no "in between" available. I tried to collect all the (half) processed ways in a list, then do the merging and proceed with the processing later. But that turned out to be hard as well, because there is actually no good "in between" point. I didn't succeed in the end, the ways got merged just fine, but the routing broke every time. So yes, I think this is really complex. Regards Thilo

My guess is...

After merging you have 1 graphical line that spans the length of the combined lines associated with a routing arc that only spans the length of the original un-merged line. When you put the cursor near the lines that have been merged, mapsource, finds the arc associated with that line and puts the pop-up as close to the cursor as it can while still being on the arc. As the arc only spans a part of the whole merged line, the popup jumps (away from the cursor) to the end of the arc away.

It's not really that surprising given the resulting data structure that has been produced by the merging.

Hi Mark, if your guess is true (it indeed seems so), then this would mean that there is some linking between the graphical line and the arc. I know there is a one to one link at highest resolution. There seems to be link at lower resolutions too. This may well be the unknown reason for the improving of the routing with the merge-lines option. What I do not understand: How can I link a long line to a lot of arcs. There must be a way, as the original garmin maps contains long lines too. Are there some arcs for lower resolutions too? Regards, Johann

On 01.12.2009 22:43, Mark Burton wrote:

Hi Johann,

...

Hi Mark,

if your guess is true (it indeed seems so), then this would mean that there is some linking between the graphical line and the arc. I know there is a one to one link at highest resolution. There seems to be link at lower resolutions too.

This may well be the unknown reason for the improving of the routing with the merge-lines option.

Perhaps, but that is a mystery to me.

...

What I do not understand: How can I link a long line to a lot of arcs. There must be a way, as the original garmin maps contains long lines too. Are there some arcs for lower resolutions too?

So far, I have not seen any evidence of that.

What I have seen in some maps created by cgpsmapper is what I call "short-circuit arcs". These are extra arcs that jump over some of the points in the way to make a more direct route. Here's some ascii art that illustrates what I mean:

---------SCA--------- | | -----A++++B++++C++++D++++E---- | | | | | |

Well I suppose those short-circuit lines are related to avoiding turn time penalties, or artificially set them. This is in my part (well said it often enough) - the most important thing for good routing, the only workaround being what I wrote down in the patch before - but of course this adds to map size much more than short-circuits would do. Are these arcs visible within gpsmapedit? I have not seen them (maybe did not look well enough).

The + signs show a single road that has nodes A-E. Nodes B, C and D have other roads connected to them. A and E are connected to other ways but they also have a short-circuit arc (SCA) between them. I have seen short-circuit arcs span from one end of a road to the other and also from an inner node (like B, C or D) to one of the ends. Note that the short-circuit arcs don't span roads, they just connect nodes within single roads.

I have been planning to do some experiments to get to understand this more but have not found the time to do so yet.

Cheers,

Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev