Hi all, I think I understand now most of the miracles related to short arcs and I am pretty sure that we can solve the known problems without adding source complexity. 1) In 2009 Mark Burton added the remove-short-arcs option with r1049. 2) With r1060 he added the option to pass a parameter giving the minimum arc length to fix problems like "disappearing ways". Unfortunately, he missed the real reason for the error, which IMHO was the buggy implementation of --link-pois-to-ways and --remove-short-arcs regarding the highway count causing more or less unpredictable results. 3) For four years people wondered what value to use as a change of the value was likely to "fix" a known routing error while also adding other "not yet known" errors. Today I've committed r2736. I my eyes (presuming all coding errors are fixed now) the only usable value is --remove-short-arcs=0, everything else is likely to create problems like distorted lines, wrong routing (cars routed through footways) and wrong exit hints in roundabouts. The only advantage that I see is a slightly smaller number of nodes, but this will soon be fixed when the mergeroads branch is merged to trunk, but I might have missed something. So, in short: All those that are using mkgmap to create routable maps, please try r2736 with --remove-short-arcs=0 (binary is here http://files.mkgmap.org.uk/download/152/mkgmap.jar) or use the mergeroads branch (requires style changes) If you find any problem regarding routing, please let us know and try to provide details. If I hear no complains until Oct 15, I like to change the default back to 0 and print a warning if a different value is used. If --remove-short-arcs=0 works fine for everybody, we should remove the option. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/short-arcs-demystified-please-try-value-0-tp5... Sent from the Mkgmap Development mailing list archive at Nabble.com.
El 05/10/13 11:56, GerdP escribió:
Hi all,
I think I understand now most of the miracles related to short arcs and I am pretty sure that we can solve the known problems without adding source complexity.
1) In 2009 Mark Burton added the remove-short-arcs option with r1049. 2) With r1060 he added the option to pass a parameter giving the minimum arc length to fix problems like "disappearing ways". Unfortunately, he missed the real reason for the error, which IMHO was the buggy implementation of --link-pois-to-ways and --remove-short-arcs regarding the highway count causing more or less unpredictable results. 3) For four years people wondered what value to use as a change of the value was likely to "fix" a known routing error while also adding other "not yet known" errors.
Today I've committed r2736. I my eyes (presuming all coding errors are fixed now) the only usable value is --remove-short-arcs=0, everything else is likely to create problems like distorted lines, wrong routing (cars routed through footways) and wrong exit hints in roundabouts. The only advantage that I see is a slightly smaller number of nodes, but this will soon be fixed when the mergeroads branch is merged to trunk, but I might have missed something.
So, in short: All those that are using mkgmap to create routable maps, please try r2736 with --remove-short-arcs=0 (binary is here http://files.mkgmap.org.uk/download/152/mkgmap.jar) or use the mergeroads branch (requires style changes) If you find any problem regarding routing, please let us know and try to provide details.
If I hear no complains until Oct 15, I like to change the default back to 0 and print a warning if a different value is used. If --remove-short-arcs=0 works fine for everybody, we should remove the option.
Gerd Thanks for the deep work you have done on it Gerd. I have a roundabout test case where routing have been failing for a long time. With r2736 routing works fine with remove-short-arcs=0 and without any value (default), but the shape of the roundabout is a circle with 0 and something like a start with default, so much better with 0.
Hi Carlos, thanks for the quick feedback. I just noticed that I forgot to remove a debug output. r2737 is available here: http://files.mkgmap.org.uk/download/153/mkgmap.jar Gerd Carlos Dávila-2 wrote
El 05/10/13 11:56, GerdP escribió:
Hi all,
I think I understand now most of the miracles related to short arcs and I am pretty sure that we can solve the known problems without adding source complexity.
1) In 2009 Mark Burton added the remove-short-arcs option with r1049. 2) With r1060 he added the option to pass a parameter giving the minimum arc length to fix problems like "disappearing ways". Unfortunately, he missed the real reason for the error, which IMHO was the buggy implementation of --link-pois-to-ways and --remove-short-arcs regarding the highway count causing more or less unpredictable results. 3) For four years people wondered what value to use as a change of the value was likely to "fix" a known routing error while also adding other "not yet known" errors.
Today I've committed r2736. I my eyes (presuming all coding errors are fixed now) the only usable value is --remove-short-arcs=0, everything else is likely to create problems like distorted lines, wrong routing (cars routed through footways) and wrong exit hints in roundabouts. The only advantage that I see is a slightly smaller number of nodes, but this will soon be fixed when the mergeroads branch is merged to trunk, but I might have missed something.
So, in short: All those that are using mkgmap to create routable maps, please try r2736 with --remove-short-arcs=0 (binary is here http://files.mkgmap.org.uk/download/152/mkgmap.jar) or use the mergeroads branch (requires style changes) If you find any problem regarding routing, please let us know and try to provide details.
If I hear no complains until Oct 15, I like to change the default back to 0 and print a warning if a different value is used. If --remove-short-arcs=0 works fine for everybody, we should remove the option.
Gerd Thanks for the deep work you have done on it Gerd. I have a roundabout test case where routing have been failing for a long time. With r2736 routing works fine with remove-short-arcs=0 and without any value (default), but the shape of the roundabout is a circle with 0 and something like a start with default, so much better with 0.
mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/short-arcs-demystified-please-try-value-0-tp5... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, Just tried it with my Benelux cyclemap. I couldnt find any specific routing bugs that were solved but I didnt see any differences in routing with previous mkgmap versions either. One particular routing error that still bugs me is that pedestrians can't cross tile borders (Basecamp) unless toll roads are avoided. In all other vehicle profiles this bug is only triggered when interstate highways are avoided. When toll road avoidance is active the routing is ok. Tested with the default style on Lambertus' maps.
Hi Minko,
Just tried it with my Benelux cyclemap. I couldnt find any specific routing bugs that were solved but I didnt see any differences in routing with previous mkgmap versions either. Thanks for testing :-) Does that mean you find routing errors with value 0 that you cannot explain with the OSM input data? If yes, d like to reproduce them.
One particular routing error that still bugs me is that pedestrians can't cross tile borders (Basecamp) unless toll roads are avoided. In all other vehicle profiles this bug is only triggered when interstate highways are avoided. When toll road avoidance is active the routing is ok. Tested with the default style on Lambertus' maps.
Is that the same problem that was discussed here? http://gis.19327.n5.nabble.com/Basecamp-4-2-2-Inter-tile-routing-problem-tp5... I have no idea how to work on this :-( Gerd
Hi Gerd
I couldnt find any specific routing bugs that were solved but I didnt see any differences in routing with previous mkgmap versions either. Thanks for testing :-) Does that mean you find routing errors with value 0 that you cannot explain with the OSM input data? If yes, d like to reproduce them.
No I meant I couldnt find any routing errors besides the already known bugs (see below) but they seems not have anything to do with short arcs. So, as far as I have tested remove-short-arcs=0 seems to work fine.
One particular routing error that still bugs me is that pedestrians can't cross tile borders (Basecamp) unless toll roads are avoided. In all other vehicle profiles this bug is only triggered when interstate highways are avoided. When toll road avoidance is active the routing is ok. Tested with the default style on Lambertus' maps.
Is that the same problem that was discussed here? http://gis.19327.n5.nabble.com/Basecamp-4-2-2-Inter-tile-routing-problem-tp5...
I have no idea how to work on this :-(
Yes, same problem.
Hi Gerd, great! I have merged the changes to the mergeroads branch and it runs fine for me. I didn't yet check a style that uses continue statements but your work seems to be *very* reasonable :-) WanMil
Hi all,
I think I understand now most of the miracles related to short arcs and I am pretty sure that we can solve the known problems without adding source complexity.
1) In 2009 Mark Burton added the remove-short-arcs option with r1049. 2) With r1060 he added the option to pass a parameter giving the minimum arc length to fix problems like "disappearing ways". Unfortunately, he missed the real reason for the error, which IMHO was the buggy implementation of --link-pois-to-ways and --remove-short-arcs regarding the highway count causing more or less unpredictable results. 3) For four years people wondered what value to use as a change of the value was likely to "fix" a known routing error while also adding other "not yet known" errors.
Today I've committed r2736. I my eyes (presuming all coding errors are fixed now) the only usable value is --remove-short-arcs=0, everything else is likely to create problems like distorted lines, wrong routing (cars routed through footways) and wrong exit hints in roundabouts. The only advantage that I see is a slightly smaller number of nodes, but this will soon be fixed when the mergeroads branch is merged to trunk, but I might have missed something.
So, in short: All those that are using mkgmap to create routable maps, please try r2736 with --remove-short-arcs=0 (binary is here http://files.mkgmap.org.uk/download/152/mkgmap.jar) or use the mergeroads branch (requires style changes) If you find any problem regarding routing, please let us know and try to provide details.
If I hear no complains until Oct 15, I like to change the default back to 0 and print a warning if a different value is used. If --remove-short-arcs=0 works fine for everybody, we should remove the option.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/short-arcs-demystified-please-try-value-0-tp5... 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
Hi WanMil, I noticed that the branch had one more call to incHighwayCount(). I can't think of a situation where this causes problems, but the call was correct. Please merge again. Gerd WanMil wrote
Hi Gerd,
great! I have merged the changes to the mergeroads branch and it runs fine for me. I didn't yet check a style that uses continue statements but your work seems to be *very* reasonable :-)
WanMil
Hi all,
I think I understand now most of the miracles related to short arcs and I am pretty sure that we can solve the known problems without adding source complexity.
1) In 2009 Mark Burton added the remove-short-arcs option with r1049. 2) With r1060 he added the option to pass a parameter giving the minimum arc length to fix problems like "disappearing ways". Unfortunately, he missed the real reason for the error, which IMHO was the buggy implementation of --link-pois-to-ways and --remove-short-arcs regarding the highway count causing more or less unpredictable results. 3) For four years people wondered what value to use as a change of the value was likely to "fix" a known routing error while also adding other "not yet known" errors.
Today I've committed r2736. I my eyes (presuming all coding errors are fixed now) the only usable value is --remove-short-arcs=0, everything else is likely to create problems like distorted lines, wrong routing (cars routed through footways) and wrong exit hints in roundabouts. The only advantage that I see is a slightly smaller number of nodes, but this will soon be fixed when the mergeroads branch is merged to trunk, but I might have missed something.
So, in short: All those that are using mkgmap to create routable maps, please try r2736 with --remove-short-arcs=0 (binary is here http://files.mkgmap.org.uk/download/152/mkgmap.jar) or use the mergeroads branch (requires style changes) If you find any problem regarding routing, please let us know and try to provide details.
If I hear no complains until Oct 15, I like to change the default back to 0 and print a warning if a different value is used. If --remove-short-arcs=0 works fine for everybody, we should remove the option.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/short-arcs-demystified-please-try-value-0-tp5... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/short-arcs-demystified-please-try-value-0-tp5... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, GerdP wrote
If I hear no complains until Oct 15, I like to change the default back to 0 and print a warning if a different value is used. If --remove-short-arcs=0 works fine for everybody, we should remove the option.
I've committed r2757 which sets the default back to 0. If --remove-short-arcs= is used with a value > 0, a warning is printed to stderr. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/short-arcs-demystified-please-try-value-0-tp5... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (5)
-
Carlos Dávila -
Gerd Petermann -
GerdP
-
Minko -
WanMil