Re: [OSM-talk] [Talk-us] Am I mapping this wrong, or should the router be fixed for this?
sent from a phone Am 31.07.2015 um 07:41 schrieb Maarten Deen md...@xs4all.nl: It is more than sufficient for a time calculation to use the maximum speed, multiplied by some factor (smaller than 1), or even a fixed speed per road class. Sometimes it also depends on the region and the intensity of usage of the road network. In certain metropolitan areas with at times more traffic than the network can digest, you would be far off with this metric. In these cases the general hierarchy of primary, secondary etc becomes meaningless and often the best you can do is use small lateral, residential roads to avoid the major traffic jam on the arterial roads ;-) Much better is virtually impossible to achieve since you don't know how much traffic there is on the road so you can not predict waiting times at traffic lights or junctions. Most major routing systems use indeed real time traffic information today, collected by other users of their system and by cellphone networks cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] Am I mapping this wrong, or should the router be fixed for this?
On 2015-07-31 09:22, Martin Koppenhoefer wrote: sent from a phone Am 31.07.2015 um 07:41 schrieb Maarten Deen md...@xs4all.nl: It is more than sufficient for a time calculation to use the maximum speed, multiplied by some factor (smaller than 1), or even a fixed speed per road class. Sometimes it also depends on the region and the intensity of usage of the road network. In certain metropolitan areas with at times more traffic than the network can digest, you would be far off with this metric. In these cases the general hierarchy of primary, secondary etc becomes meaningless and often the best you can do is use small lateral, residential roads to avoid the major traffic jam on the arterial roads ;-) That is why my next comment was: Much better is virtually impossible to achieve since you don't know how much traffic there is on the road so you can not predict waiting times at traffic lights or junctions. Most major routing systems use indeed real time traffic information today, collected by other users of their system and by cellphone networks But for that you need some kind of online connection. And my tablet has only wifi. So that may be practical to use in some cases (phones with a dataplan), you still need a general calculation which is not based on real time traffic info. And for that you can only use general terms with respect to speed and have to accept that the calculation will not be correct all the time. On top of this: I am not aware that OSMAND has this functionality ATM. So talking about this is only hypothetical at the moment. It will not result in better calculation times. Maarten ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] Am I mapping this wrong, or should the router be fixed for this?
James Mast rickmastfa...@hotmail.com writes: I've been normally mapping slip lanes as '_link' highways at intersections since the beginning. However, as most fellow US mappers know, they almost never have 'speed limits' posted for them, and that seems to help cause problems in some routing programs when they give those slip lanes a speed limit higher than the main highway. Anyways, I've been using OSMAnd recently for occasional offline routing on my tablet and have come across weird routing (I'd like to call them 'bugs') at some intersections that have 3+ traffic lights nodes at them because of the roads being divided. Here, OSMAnd routes me onto a slip lane, makes a U-Turn on the side road, and then continues the across the main road to accomplish what a simple 'left turn' could have done [1], all to avoid '1' traffic light node. So, I go report the 'bug' on the OSMAnd Google group [2], and then somebody forwards it to the GitHub site [3]. [This is a little US centric in details, but I think broadly applies. For context, white speed limit signs are legal limits, and yellow signs are advisory. You can probably be cited for exceeding a yellow limit by a lot, but it will be for having an unsafe speed, not for exceeding a specified limit.] I've been on the osmand list for over a year, and the issue of routing choices similar to yours have come up multiple times. It seems that the views of the osmand developers (who are not very active on the list) are different from the consensus on the list. The issue of on-ramps/off-ramps tagged as *_link has been a particular discussion focus. The notion you expressed that these don't have actual posted limits, just sometimes yellow signs is indeed shared by most in the discussions. And we generally agree that the right speed to use for them is more or less half the speed of the larger road from which the links go to/from. Perhaps half the speed of the actual road, perhaps half the speed of a nominal road of that class, and perhaps slower. But these are fine details, and the consensus is pretty strong. I do not understand why the osmand devleopers don't just implement this notion; it seems relatively obviously correct, and people who have modified their routing.xml files report reasonable results. A few further thoughts: While it's important to tag actual speed limits (posted, or unambiguously determined from local law, such as 30 mph in thickly settled areas in Massachusetts), routers should actually function on typical speeds, not limits. I think osm should have this data, but it gets a bit complicated. Still, a simple take on it would help a lot. One could just put in the yellow-sign value as typical. Or perhaps there should be a warning-sign tag, and a typical determined from a number of tracks. (Around me, there's a highway with limit 65 mph, and I'd say typical is 75 mph. Ramps are often yellow-signed at 30 mph and typical is 40mph on some of them.) Routing is clearly tricky. There are multiple steps: 1) modeling the real world in the database 2) computing how long and how far a path will take based on the database 3) choosing a function to minimize. Shortest distance and shortest time are both not right, as dangerous maneuvers are avoided by many people even if they save a few seconds. And then there's avoiding highly bumpy roads. In your case arguably you have done 1 right within the current rules, and adding typical speeds or yellow-sign speeds would help. osmand is doing 2 wrong. It is completely wrong to assume that exit ramps can be traversed at highway speeds (100 km/hr or so). Yes, there are a few like that joining Interstates, but in the normal case something like 30 mph (50 km/h) is rational. In 2, there should be a time penalty for u-turns. Really it's not a penalty: it's an estimate of how much time it actually takes, and ideally these times would be extracted from actual tracks so the actual time and the predicted time match in some zero-mean sense. 3 is much harder, but the basis for getting it right is to have 1 and 2 correct. If there were to be a penalty (distinct from a time/distance estimate), it should perhaps be for getting off a major road and getting back on. But, one could argue that this would be kludgy, and if one wanted that, the real issue would be that the underlying cost functions are wrong. Perhaps in addition to the time spent at stop signs, lights, etc. there should be a cost associated with the cognitive effort and accident risk, to be minimized, so that staying on the highway is treated as the rational choice (that it probably actually is). So my advice is to use a custom routing.xml with osmand that has sensible speeds for links. And perhaps to work towards typical speed tagging, and encourage osmand to use typical speed if present, and limit if not. pgp_mw2zOhuoI.pgp Description: PGP signature ___ talk mailing list
Re: [OSM-talk] [Talk-us] Am I mapping this wrong, or should the router be fixed for this?
On 2015-07-30 14:52, Greg Troxel wrote: If there were to be a penalty (distinct from a time/distance estimate), it should perhaps be for getting off a major road and getting back on. But, one could argue that this would be kludgy, and if one wanted that, the real issue would be that the underlying cost functions are wrong. Perhaps in addition to the time spent at stop signs, lights, etc. there should be a cost associated with the cognitive effort and accident risk, to be minimized, so that staying on the highway is treated as the rational choice (that it probably actually is). Penalties and costs are the basis of routing engines, not distance and speed. That is why OSMAND (and OSRM) make such silly mistakes as routing from the motorway to an offramp and straight on to the onramp to join the same motorway. Because both have the same speed limit and the offramp is slightly shorter it would be faster? Wrong. Faster is not the issue. The cost for using an offramp should be higher than taking the motorway. Probably even the action of changing from a certain class of way to the _link class (or indeed any lower class) should incur a penalty. A posted speed limit is just that: a legal maximum speed, not an actual driven speed. And therefore of only limited use to a router. Sure, a road with a posted speed limit of 30 will be slower than one with 120, but it is wrong to assume that two roads with a speed limit of 120 will be equally fast and therefor the shortest is always the better. I too have the feeling that that notion does not live within the OSMAND developers (nor the OSMR developers). IMHO brouter.de does this very nicely. When I see that by tinkering with the costs of certain road classes I can get a bicycle route exactly like how I would drive it is an indication to me that it is a very life-like router. Regards, Maarten ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] Am I mapping this wrong, or should the router be fixed for this?
On Thu, Jul 30, 2015 at 09:24:12PM +0200, Colin Smale wrote: I assume you are talking about typical speeds, and not a practical maximum. A max speed will almost never be achieved, by definition actually as the vehicle speeds will have a certain distribution. The highest recorded speed will be the de facto practical maximum, assuming the driver survived. quite clearly the key (maxspeed:practical) has been misnamed whenever it was invented. Sometimes a posted maxspeed is indeed a realistic travelling speed - consider the freeway through Nevada - and sometimes there is a huge gap between posted (or not even existent) speed limit and practically achievable speed. Routers could take account of hundreds of variables in their calculation of predicted journey time from A to B, but in practice their calculations make assumptions for most of them. For example, most of them assume the vehicle is a car, that it is technically not limited to any particular speed, that the weather is perfect, that it is daytime, that the driver is not inexperienced. And then there are the other volatile variables like traffic density, road works, oversize loads getting in the way etc. Routers cannot take everything into account (this would preclude a lot of preprocessing to simplify the real-time calculations), so they use heuristics which work most often. right, and sometimes they simply need help. So how would you define the concept of typical speed? From the wiki page The name of the key is somewhat misleading - maxspeed:practical should be interpreted as realistic average speed. and To be used especially in places where other tags are not sufficient to describe what kind of traveling speed could be reasonably expected. Many mountain or rural roads as well as desert tracks do not have posted speed limits and the realistic traveling speed may be severely limited by many factors difficult to describe and difficult to use for calculation by routing software. Practical does not equal what is physically possible, which varies by vehicle, but roughly a median speed. Urban routing problems like driving through supermarket service roads to save a few meters of freeway or avoid a traffic signal could be probably added to the list. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] Am I mapping this wrong, or should the router be fixed for this?
On Thu, Jul 30, 2015 at 08:52:57AM -0400, Greg Troxel wrote: The issue of on-ramps/off-ramps tagged as *_link has been a particular discussion focus. The notion you expressed that these don't have actual posted limits, just sometimes yellow signs is indeed shared by most in the discussions. And we generally agree that the right speed to use for them is more or less half the speed of the larger road from which the links go to/from. Perhaps half the speed of the actual road, perhaps half the speed of a nominal road of that class, and perhaps slower. But these are fine details, and the consensus is pretty strong. I do not understand why the osmand devleopers don't just implement this notion; it seems relatively obviously correct, and people who have modified their routing.xml files report reasonable results. There is http://wiki.openstreetmap.org/wiki/Routing#Highway-type clearly supporting this idea, however the details are probably very country and situation specific so the concept may be of little help in practice. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] Am I mapping this wrong, or should the router be fixed for this?
I assume you are talking about typical speeds, and not a practical maximum. A max speed will almost never be achieved, by definition actually as the vehicle speeds will have a certain distribution. The highest recorded speed will be the de facto practical maximum, assuming the driver survived. Routers could take account of hundreds of variables in their calculation of predicted journey time from A to B, but in practice their calculations make assumptions for most of them. For example, most of them assume the vehicle is a car, that it is technically not limited to any particular speed, that the weather is perfect, that it is daytime, that the driver is not inexperienced. And then there are the other volatile variables like traffic density, road works, oversize loads getting in the way etc. Routers cannot take everything into account (this would preclude a lot of preprocessing to simplify the real-time calculations), so they use heuristics which work most often. So how would you define the concept of typical speed? --colin On 30 July 2015 20:38:32 CEST, Richard ricoz@gmail.com wrote: On Thu, Jul 30, 2015 at 08:00:55PM +0200, Colin Smale wrote: Practical maxspeed is useless as well. A straight wide road may be capable of hosting land speed records, but traffic density is likely to be a far more important factor. yes, and this is what practical maxspeed is good for. Not an ideal solution but works. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] Am I mapping this wrong, or should the router be fixed for this?
It is more than sufficient for a time calculation to use the maximum speed, multiplied by some factor (smaller than 1), or even a fixed speed per road class. My car navigation has this (there are three speeds I can set) and usually the time is correct within a few minutes. Much better is virtually impossible to achieve since you don't know how much traffic there is on the road so you can not predict waiting times at traffic lights or junctions. But again: the duration of a route has nothing to do with the actual route calculation. You first calculate the route based on cost factors and then calculate the time you need based on speed profiles. Maarten On 2015-07-30 21:24, Colin Smale wrote: I assume you are talking about typical speeds, and not a practical maximum. A max speed will almost never be achieved, by definition actually as the vehicle speeds will have a certain distribution. The highest recorded speed will be the de facto practical maximum, assuming the driver survived. Routers could take account of hundreds of variables in their calculation of predicted journey time from A to B, but in practice their calculations make assumptions for most of them. For example, most of them assume the vehicle is a car, that it is technically not limited to any particular speed, that the weather is perfect, that it is daytime, that the driver is not inexperienced. And then there are the other volatile variables like traffic density, road works, oversize loads getting in the way etc. Routers cannot take everything into account (this would preclude a lot of preprocessing to simplify the real-time calculations), so they use heuristics which work most often. So how would you define the concept of typical speed? --colin On 30 July 2015 20:38:32 CEST, Richard ricoz@gmail.com wrote: On Thu, Jul 30, 2015 at 08:00:55PM +0200, Colin Smale wrote: Practical maxspeed is useless as well. A straight wide road may be capable of hosting land speed records, but traffic density is likely to be a far more important factor. yes, and this is what practical maxspeed is good for. Not an ideal solution but works. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] Am I mapping this wrong, or should the router be fixed for this?
On Thu, Jul 30, 2015 at 08:00:55PM +0200, Colin Smale wrote: Practical maxspeed is useless as well. A straight wide road may be capable of hosting land speed records, but traffic density is likely to be a far more important factor. yes, and this is what practical maxspeed is good for. Not an ideal solution but works. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] Am I mapping this wrong, or should the router be fixed for this?
On Thu, Jul 30, 2015 at 08:52:57AM -0400, Greg Troxel wrote: The issue of on-ramps/off-ramps tagged as *_link has been a particular discussion focus. The notion you expressed that these don't have actual posted limits, just sometimes yellow signs is indeed shared by most in the discussions. And we generally agree that the right speed to use for them is more or less half the speed of the larger road from which the links go to/from. Perhaps half the speed of the actual road, perhaps half the speed of a nominal road of that class, and perhaps slower. But these are fine details, and the consensus is pretty strong. if there is no hard limit this might help: http://wiki.openstreetmap.org/wiki/Key:maxspeed:practical another thing that could help - routers should add a cost for every lane switch or changing to different road, likewise every implicit or explicit yield which would be implied here. However this has the problem that sometimes what looks as different road in OSM data is a road that was split for some technical reason. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] Am I mapping this wrong, or should the router be fixed for this?
Practical maxspeed is useless as well. A straight wide road may be capable of hosting land speed records, but traffic density is likely to be a far more important factor. On 30 July 2015 19:56:41 CEST, Richard ricoz@gmail.com wrote: On Thu, Jul 30, 2015 at 08:52:57AM -0400, Greg Troxel wrote: The issue of on-ramps/off-ramps tagged as *_link has been a particular discussion focus. The notion you expressed that these don't have actual posted limits, just sometimes yellow signs is indeed shared by most in the discussions. And we generally agree that the right speed to use for them is more or less half the speed of the larger road from which the links go to/from. Perhaps half the speed of the actual road, perhaps half the speed of a nominal road of that class, and perhaps slower. But these are fine details, and the consensus is pretty strong. if there is no hard limit this might help: http://wiki.openstreetmap.org/wiki/Key:maxspeed:practical another thing that could help - routers should add a cost for every lane switch or changing to different road, likewise every implicit or explicit yield which would be implied here. However this has the problem that sometimes what looks as different road in OSM data is a road that was split for some technical reason. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] Am I mapping this wrong, or should the router be fixed for this?
In reality there is only one set of stop lights there, correct? In other words, if one were headed south on McKnight Road turning east on Seibert, one would not have to stop (assuming red lights) three different times. 1) A routing engine should have some heuristics to interpret the three (in this case) nodes tagged highway=traffic_signals as one. 2) There should be some cost in a routing engine for making a u-turn so as to discourage such routes even if there was an extra set of signals. Making a u-turn does take time (one can not go from the posted speed limit in one direction to the posted speed limit in the other direction instantly). The presence of other traffic in the opposing directly would add further to the time needed to make a u-turn as one would have to wait for an opening. Mike On Mon, Jul 27, 2015 at 9:58 AM, James Mast rickmastfa...@hotmail.com wrote: I've been normally mapping slip lanes as '_link' highways at intersections since the beginning. However, as most fellow US mappers know, they almost never have 'speed limits' posted for them, and that seems to help cause problems in some routing programs when they give those slip lanes a speed limit higher than the main highway. Anyways, I've been using OSMAnd recently for occasional offline routing on my tablet and have come across weird routing (I'd like to call them 'bugs') at some intersections that have 3+ traffic lights nodes at them because of the roads being divided. Here, OSMAnd routes me onto a slip lane, makes a U-Turn on the side road, and then continues the across the main road to accomplish what a simple 'left turn' could have done [1], all to avoid '1' traffic light node. So, I go report the 'bug' on the OSMAnd Google group [2], and then somebody forwards it to the GitHub site [3]. In the response I get back on GitHub, one of the maintainers of OSMAnd says it's a 'map data' issue and closes it. Claims that in the 'maneuver', since it avoids an extra traffic light node, it's the shortest route, even though it does that funky U-Turn. Say what?! I mean, honestly, if both MapQuest Open OSMR can do that left turn 'normally' without needing to make a funky U-Turn, something has to be wrong in OSMAnd, right?? Sure, there isn't a 'NO U-Turn' sign posted for this maneuver, but still, the routing engine shouldn't be suggesting it since there isn't a 'NO Left Turn' relation there preventing the left turn from McKnight SB to Siebert EB. So, that leads me to my question. Does anybody think I've tagged the intersection incorrectly? This is how I've been tagging intersections like this from since the start, and I know most other US mappers have been doing the same. Or should I start adding 'false' U-Turn restrictions to prevent the routing bugs and then be called out as 'tagging for the router', or even maybe start putting traffic light nodes at the stop lines for intersections that have both roads divided (and just leave simple one-node intersections as-is)? I'm very curious to see what others have to say about this to see how I'll move forward when I map in the future. Also, don't hesitate to respond at the Google Group post or the GitHub one too as I get the e-mail notifications from them as well. -James [1] - (MapQuest routing, OSMAnd suggestion in [2] link) - https://www.openstreetmap.org/directions?engine=mapquest_carroute=40.53204%2C-80.01073%3B40.53002%2C-80.00614 https://www.openstreetmap.org/directions?engine=mapquest_carroute=40.53204%2C-80.01073%3B40.53002%2C-80.00614 [2] - https://groups.google.com/forum/#!topic/osmand/XJ-HVOHhKEM [3] - https://github.com/osmandapp/Osmand/issues/1501 ___ Talk-us mailing list talk...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
