Hi Is there any problem with this option, such that you might not want to use it? As I understand it, if you do not give it then routing will not work, as we know (or believe) that all routing arcs have to be more than 5.4m. If that is so, then we should just set the required behaviour whenever the route option is given. I realize that there might be other approaches, eg we could stretch arcs instead of removing them, but if removing them is our current best approach, lets make it the default. ..Steve
Hello Steve, Steve Ratcliffe schreef:
As I understand it, if you do not give it then routing will not work, as we know (or believe) that all routing arcs have to be more than 5.4m.
Your 5.4m confuses me a bit. the help file says: "If MinLength is specified (in metres), arcs shorter than that length will be removed. If a length is not specified, only zero-length arcs will be removed." Also, Mark Burton noted "As you know, the resolution is just over 2m so any (connected) nodes that are less than approx 2.5m apart will need to be merged to avoid having short arcs.". That's why I (manually) set my short-arcs option to 4 meters; but now I understand that that's too small?
but if removing them is our current best approach, lets make it the default.
I agree. V.
Hi Steve,
Is there any problem with this option, such that you might not want to use it?
I am not aware of any problem.
As I understand it, if you do not give it then routing will not work, as we know (or believe) that all routing arcs have to be more than 5.4m.
I believe that the mimimum distance will depend on lat/lon because the real constraint is that the source and target nodes must not have the same coordinates (resolution being 360 deg / 2^24)
If that is so, then we should just set the required behaviour whenever the route option is given.
Why don't we do that but still provide an option to turn off the short arc removal (which should never need to be used but may be useful when tracking down problems).
I realize that there might be other approaches, eg we could stretch arcs instead of removing them, but if removing them is our current best approach, lets make it the default.
It seems to be working well enough at the moment. Shall I change the code to remove the --remove-short-arcs option and, instead, enable that function if --route is specified and (the new) --keep-short-arcs option is not specified? Cheers, Mark
Mark Burton wrote:
Hi Steve,
Is there any problem with this option, such that you might not want to use it?
I am not aware of any problem.
As I understand it, if you do not give it then routing will not work, as we know (or believe) that all routing arcs have to be more than 5.4m.
I believe that the mimimum distance will depend on lat/lon because the real constraint is that the source and target nodes must not have the same coordinates (resolution being 360 deg / 2^24)
If that is so, then we should just set the required behaviour whenever the route option is given.
Why don't we do that but still provide an option to turn off the short arc removal (which should never need to be used but may be useful when tracking down problems).
I realize that there might be other approaches, eg we could stretch arcs instead of removing them, but if removing them is our current best approach, lets make it the default.
It seems to be working well enough at the moment.
Shall I change the code to remove the --remove-short-arcs option and, instead, enable that function if --route is specified and (the new) --keep-short-arcs option is not specified?
Cheers,
Mark
Yes, but we should be clear about the distance needed. I used =3 because without specifying it, I had some route calculation working, that without specifying did not work. If there is really 5.4m then the default should go for 5.4 -- or just leave the option as it is right now but use it by default except if say --remove-short-arcs=no is given...
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix,
Mark Burton wrote:
Hi Steve,
Is there any problem with this option, such that you might not want to use it?
I am not aware of any problem.
As I understand it, if you do not give it then routing will not work, as we know (or believe) that all routing arcs have to be more than 5.4m.
I believe that the mimimum distance will depend on lat/lon because the real constraint is that the source and target nodes must not have the same coordinates (resolution being 360 deg / 2^24)
If that is so, then we should just set the required behaviour whenever the route option is given.
Why don't we do that but still provide an option to turn off the short arc removal (which should never need to be used but may be useful when tracking down problems).
I realize that there might be other approaches, eg we could stretch arcs instead of removing them, but if removing them is our current best approach, lets make it the default.
It seems to be working well enough at the moment.
Shall I change the code to remove the --remove-short-arcs option and, instead, enable that function if --route is specified and (the new) --keep-short-arcs option is not specified?
Cheers,
Mark
Yes, but we should be clear about the distance needed. I used =3 because without specifying it, I had some route calculation working, that without specifying did not work. If there is really 5.4m then the default should go for 5.4 -- or just leave the option as it is right now but use it by default except if say --remove-short-arcs=no is given...
Ahh, I forgot about that aspect. At this time, if you don't specify a length with the --remove-short-arcs option, it only removes zero-length arcs. I think that is the most sensible behaviour because we know that zero-length arcs are bad for routing. The fact that some maps require a minimum arc length to be specified should be investigated some more to see what the issue is. Cheers, Mark
Mark Burton wrote:
Hi Felix,
Mark Burton wrote:
Hi Steve,
Is there any problem with this option, such that you might not want to use it?
I am not aware of any problem.
As I understand it, if you do not give it then routing will not work, as we know (or believe) that all routing arcs have to be more than 5.4m.
I believe that the mimimum distance will depend on lat/lon because the real constraint is that the source and target nodes must not have the same coordinates (resolution being 360 deg / 2^24)
If that is so, then we should just set the required behaviour whenever the route option is given.
Why don't we do that but still provide an option to turn off the short arc removal (which should never need to be used but may be useful when tracking down problems).
I realize that there might be other approaches, eg we could stretch arcs instead of removing them, but if removing them is our current best approach, lets make it the default.
It seems to be working well enough at the moment.
Shall I change the code to remove the --remove-short-arcs option and, instead, enable that function if --route is specified and (the new) --keep-short-arcs option is not specified?
Cheers,
Mark
Yes, but we should be clear about the distance needed. I used =3 because without specifying it, I had some route calculation working, that without specifying did not work. If there is really 5.4m then the default should go for 5.4 -- or just leave the option as it is right now but use it by default except if say --remove-short-arcs=no is given...
Ahh, I forgot about that aspect. At this time, if you don't specify a length with the --remove-short-arcs option, it only removes zero-length arcs. I think that is the most sensible behaviour because we know that zero-length arcs are bad for routing. The fact that some maps require a minimum arc length to be specified should be investigated some more to see what the issue is.
Cheers,
Mark
I think actually the reason for routing to work better with 3 instead of simply no argument might be, that garmin would not crash on very short arcs, but simply avoids to change roads often, so by setting 3 or higher one could actually reduce some unneccessary street changes, hence sometimes (very rare) better routing over long distances. Probabely this issue that was a bit controlled by the patch, should be addressed by other patches however.... Until we have those patches, I am a bit sceptical about dropping the support to specify the arc length.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix,
Until we have those patches, I am a bit sceptical about dropping the support to specify the arc length.
I am not suggesting that we drop the ability to specify the min arc length but I do think it's reasonable for it to default to zero rather than some length like 3 or 5 (at least until we really understand what's going on). I propose: If --route is specified but --remove-short-arcs is not, we enable the short arc removal for zero length arcs. If --remove-short-arcs=num is specified then we remove arcs <= num. If --remove-short-arcs=no is specified, we don't do any short arc removal even if --route is specified. How's that sound? Cheers, Mark
Mark Burton wrote:
Hi Felix,
Until we have those patches, I am a bit sceptical about dropping the support to specify the arc length.
I am not suggesting that we drop the ability to specify the min arc length but I do think it's reasonable for it to default to zero rather than some length like 3 or 5 (at least until we really understand what's going on).
I propose:
If --route is specified but --remove-short-arcs is not, we enable the short arc removal for zero length arcs.
If --remove-short-arcs=num is specified then we remove arcs <= num.
If --remove-short-arcs=no is specified, we don't do any short arc removal even if --route is specified.
How's that sound?
to me that sounds good.
Cheers,
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Mark Burton <markb@ordern.com> writes:
I am not suggesting that we drop the ability to specify the min arc length but I do think it's reasonable for it to default to zero rather than some length like 3 or 5 (at least until we really understand what's going on).
I propose:
If --route is specified but --remove-short-arcs is not, we enable the short arc removal for zero length arcs.
If --remove-short-arcs=num is specified then we remove arcs <= num.
If --remove-short-arcs=no is specified, we don't do any short arc removal even if --route is specified.
That sounds fine, but I don't see why --remove-short-arcs should not be the default even when routing is not enabled. I can see the point that it is not strictly needed, but aren't repeated points in a way non-sensical anyway?
Hi Greg,
That sounds fine, but I don't see why --remove-short-arcs should not be the default even when routing is not enabled. I can see the point that it is not strictly needed, but aren't repeated points in a way non-sensical anyway?
I prefer not to mess with the map data unless absolutely necessary or explicitly called for by the user. Cheers, Mark
Hi Mark, On 12/08/09 11:23, Mark Burton wrote:
I believe that the mimimum distance will depend on lat/lon because the real constraint is that the source and target nodes must not have the same coordinates (resolution being 360 deg / 2^24)
Are you sure that is the real constraint? The 5.4m value is widely known and used by everyone else in the Garmin map making communities, so it sees unwise to ignore it. So OK, we do not know where this number comes from. The best speculation was from Alex who notes that it is close (within 10%) of the minimum length that can be encoded into RouteArc.lenth Since the conversion factor from meters/feet is empirically determined, it could be incorrect by a few percent anyway. Cheers, ..Steve
Hi Steve,
On 12/08/09 11:23, Mark Burton wrote:
I believe that the mimimum distance will depend on lat/lon because the real constraint is that the source and target nodes must not have the same coordinates (resolution being 360 deg / 2^24)
Are you sure that is the real constraint?
Nope.
The 5.4m value is widely known and used by everyone else in the Garmin map making communities, so it sees unwise to ignore it.
So OK, we do not know where this number comes from. The best speculation was from Alex who notes that it is close (within 10%) of the minimum length that can be encoded into RouteArc.lenth Since the conversion factor from meters/feet is empirically determined, it could be incorrect by a few percent anyway.
Well, I don't mind. Would you like the default min arc length be 5.4m rather than 0? Easily done. Cheers, Mark
It could be like this: --remove-short-arcs (a) --remove-short-arcs=MinLength (b) --remove-short-arcs=no (c) If routing is enabled, arcs shorter than 5.4m will be removed to avoid routing problems. This behaviour can be modified with this option. It has three variants: (a) turn on short arc removal even if routing is not enabled. (b) explicitly specify the minimum arc length (no 'm' suffix). (c) completely disable short arc removal.
What we want is that the result of RouteArc.convertMeters() is not less than 1. So with the values it has at the moment that requires a min arc length of 4.878 metres. If we set the default to 5m, we should be chuckling. It could look like the attached patch.
On 12/08/09 17:13, Mark Burton wrote:
What we want is that the result of RouteArc.convertMeters() is not less than 1. So with the values it has at the moment that requires a min arc length of 4.878 metres. If we set the default to 5m, we should be chuckling.
It could look like the attached patch.
------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Sorry about previous blank email... On 12/08/09 17:13, Mark Burton wrote:
What we want is that the result of RouteArc.convertMeters() is not less than 1. So with the values it has at the moment that requires a min arc length of 4.878 metres. If we set the default to 5m, we should be chuckling.
OK and how about we take the opportunity to check out convertToMeters() Could anyone that has a route that they know or can measure the exact length of and compare to the length given by mapsource with an mkgmap generated map post their results to the list or to me. ..Steve
Hi Steve,
OK and how about we take the opportunity to check out convertToMeters()
The numbers it uses at the moment suggest that the Garmin wants the arc length in unit of 16 feet.
Could anyone that has a route that they know or can measure the exact length of and compare to the length given by mapsource with an mkgmap generated map post their results to the list or to me.
I did a very quick check and the results were plausible but further checks would certainly be a good idea. Cheers, mark
Hi Mark
Well, I don't mind. Would you like the default min arc length be 5.4m rather than 0? Easily done.
Yes I would like the default to be 5.4m as that is the best information we have. I also see no need to remove short arcs when not routing as that case is handled fine by the existing code. ..Steve
participants (5)
-
Felix Hartmann -
Greg Troxel -
Mark Burton -
Steve Ratcliffe -
Valentijn Sessink