Mark Burton schrieb:
Hi Felix (cc Johann)
Just as a follow up, I noticed that the v8 patch (simplify ...) -
actually routing over long distances in Mapsource became worse. Some
routes I can calculate without using this patch, don't calculate with
the patch anymore.
You posted this comment with a subject line related to "remove bogus
nodes" but I guess you're really talking about the latest patch from
Johann.
'v8 patch (simplify) is really missleading. I too was unsure, which
patch you meant.
If you're saying that with that patch some long distance routing is
broken it doesn't surprise me. I haven't looked at the patch in detail
but my initial impression is that it can't work because it joins up
line segments that "belong" to different roads. Here's my reasoning:
Basically, each routable road generates 2 data items:
1 - the routing data (nodes and arcs used to calculate routes)
2 - the graphical line data (what you see on the screen)
So if a route across the country uses, say, 4 different roads (for
this discussion assume the roads just connect one end to the other
without side roads) then there will be 4 arcs in the route. On the
screen, the line segments for the 4 roads will be displayed. There is a
one-to-one correspondence between the displayed lines and the
underlying routing arcs. In fact, there is a real linkage between the
line data and the routing info.
Thanks for explaining that in detail. I am fully aware of the fact, that
there is a one to one linking between the routing data and the drawing
data. But to my understanding, this linking exists only in resolution
24, not in lower resolutions.
(Or is there really routing information with lower resolution?? I doubt
that strongly.)
I actually think that one should even thing about simplifying routable
ways at resolution=24. Especially those that directly originate from
GPS tracks (that will be difficult to find out though), maybe only if
nodes are closer than 20m over longer distances. So say 6 nodes in 60m
okay, 20 nodes over 200m simplify because it seems to originate
directly from a track. Often people put nodes on curves very close to
each other, I think one would have to experiment whether routing works
better if those nodes are simplified (maybe only for routing, but not
for display?).
The simplify patch in it's current form reduces the number of drawn
lines by merging the graphical line data. It doesn't (unless I am
mistaken) merge the routing information. So now there is no-longer a
one-to-one correspondence between the displayed line(s) and the
underlying routing arcs.
Yes, you're right. My patch tries only to merge draing data. The initial
intention was only to speedup drawing on the etrexes. I could not
imagine how to merge routing data. In my opinion it should be absolutely
not neccessary to 'merge' rounting data, as there should be no mergable
arcs existing. If such nodes would exist, this would mean, that there is
a arc connecting exactly two lines of same type. This would mean a node
in the middle of road. This should not exist or at least filtered out in
previous stages. (Ignoring the special case of splitted arcs)
Imagine that in our 4 road route, the 3 following roads are merged
into the first. So now we have 1 graphical entity but we still have 4
arcs. The linkage from the remaining line relates to the 1st arc only
even though the graphical line spans the whole route.
As I said, I haven't studied the patch in detail. I could be wrong.
Seems you missed the important fact, that the merging takes place only
at resolutions <=23. As far as I understand the whole thing, line data
at lower resolutions is used only for displaying.
Please correct me, if I'm wrong.
In this case the merging would have to take place before generating of
routing tables. Another coder has tried it (can't find the thread at the
moment), but this is also unfinished work.
Regards,
Johann
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev