Hello, Does mkgmap support STOP or GIVE-Way signs for routing? It is acutally interesting to know if the calculated route will bring you in front of a STOP... If the sings are tagged like described here http://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop "As nodes on the ways approaching intersections" it would be possible to create two ways in opposite direction, both with oneway=yes, and different values for maxspeed. The way in direction of the main road could be set to 1 or 2 km/h, so it will cost a couple of extra seconds for the routing algorithm. If the original road is already oneway=yes, no opposite way has to be created, otherwise the original oneway=yes will loose its effect... What do you thing about this? Kindly Hendrik
A thread for improving routing gave this suggestion in the points style. highway=traffic_signals { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1' } highway=crossing { add mkgmap:road-speed = '-1'; add mkgmap:road-speed-min = '1' } highway=stop { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1' } traffic_calming=* { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1' } barrier=toll_booth { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1' } The reduces the road speed of the way with the traffic_signal node. I haven't tested fully but it seems to improve time calculation. On Mon, Sep 20, 2010 at 6:31 PM, Hendrik Oesterlin <hendrikmail2002@yahoo.de> wrote:
Hello,
Does mkgmap support STOP or GIVE-Way signs for routing? It is acutally interesting to know if the calculated route will bring you in front of a STOP...
If the sings are tagged like described here http://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop "As nodes on the ways approaching intersections" it would be possible to create two ways in opposite direction, both with oneway=yes, and different values for maxspeed. The way in direction of the main road could be set to 1 or 2 km/h, so it will cost a couple of extra seconds for the routing algorithm.
If the original road is already oneway=yes, no opposite way has to be created, otherwise the original oneway=yes will loose its effect...
What do you thing about this?
Kindly Hendrik
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
On 09/20/2010 01:43 PM, maning sambale wrote:
A thread for improving routing gave this suggestion in the points style.
highway=traffic_signals { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1' } highway=crossing { add mkgmap:road-speed = '-1'; add mkgmap:road-speed-min = '1' } highway=stop { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1' } traffic_calming=* { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1' } barrier=toll_booth { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1' }
The reduces the road speed of the way with the traffic_signal node. I haven't tested fully but it seems to improve time calculation.
I have tested it. There seems to be two major problems with that. First of all, it lowers the speed of the segment that has the poi. Lenght of that segment is sometimes just a few meters, sometimes a long road. So, it is more or less based on luck, whether the calculation of time is better or not. In any case, the time calculated should be longer. Matters could be improved by for example making an automatic split for a road if the segment containing speed-lowering poi gets too long. Another problem is with Garmin routing. I'd be more interested in avoiding the low-speed points. However, Garmin does not use road speed too intelligently. Instead it seems to calculate the route based on road_class mostly. -- Harri
"Harri" kuuma@bastu.net wrote on 20/09/2010 at 22:22:58 +1100 subject "[mkgmap-dev] STOP signs and routing" :
On 09/20/2010 01:43 PM, maning sambale wrote:
A thread for improving routing gave this suggestion in the points style.
highway=traffic_signals { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1' } highway=crossing { add mkgmap:road-speed = '-1'; add mkgmap:road-speed-min = '1' } highway=stop { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1' } traffic_calming=* { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1' } barrier=toll_booth { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1' }
The reduces the road speed of the way with the traffic_signal node. I haven't tested fully but it seems to improve time calculation.
I have tested it. There seems to be two major problems with that. First of all, it lowers the speed of the segment that has the poi. Lenght of that segment is sometimes just a few meters, sometimes a long road.
So, it is more or less based on luck, whether the calculation of time is better or not. In any case, the time calculated should be longer. Matters could be improved by for example making an automatic split for a road if the segment containing speed-lowering poi gets too long.
This reduces the speed in both directions?
Another problem is with Garmin routing. I'd be more interested in avoiding the low-speed points. However, Garmin does not use road speed too intelligently. Instead it seems to calculate the route based on road_class mostly.
Generally, the maxspeed value seems to be respected. But I have seen a case where higher speed was applied to the road, probably the speed of the next road segment. Maybe it was triggered by some turn of the road. You can see the effective road speed if you put your Garmin device in "simulation" mode and route to some POI. -- Sincerely Hendrik Oesterlin - email hendrikmail2002@yahoo.de
On 09/20/2010 09:50 PM, Hendrik Oesterlin wrote:
So, it is more or less based on luck, whether the calculation of time is better or not. In any case, the time calculated should be longer. Matters could be improved by for example making an automatic split for a road if the segment containing speed-lowering poi gets too long.
This reduces the speed in both directions?
That is another problem with road speed reduction based on unidirectional poi. (unless you make some workaround such as generate overlaying one-way streets for a workaround or whatever).
You can see the effective road speed if you put your Garmin device in "simulation" mode and route to some POI.
Simulation yes. Routing, no. For example, routing for a faster roads ignores mostly minor roads and seems to caltulate faster route based on what was not ignored. So, a major road with lots of traffic_calming and traffic_signals gets preferred. :( -- harri
participants (3)
-
Harri -
Hendrik Oesterlin -
maning sambale