Proposal talk:Traffic speed

What data is needed?

• The speed during the given time-span
  • Not the fastest speed at the given time, but the typical average speed when travelling along the way. i.e. the distance divided by the time, in hours, to travel along the way.
• Allow specification of different speeds/time for both directions of a way (rush hour traffic is often only in one direction).
• Allow the mode of transport to be specified (e.g if there are bus+taxi lanes, then buses+taxis would have a different speed to car stuck in rush hour traffic).

When is it appropriate to use this relation?

It is recommended that the traffic_speed relation should only be used when the speed is:

• Significantly different to the legal maximum speed
  • We should expect routing systems to know that most traffic on most roads in an area (e.g. UK) travels at an average speed that is slower than the legal maximum, and make allowances (although all the navigation systems I have used under-estimate route times significantly!) Spod 22:08, 4 October 2010 (BST)Spod
  • In the US I think the reverse occurs - most of the time traffic is moving faster than the posted speed limit (at least on the East Coast where posted limits on Interstates are 55 or 65 MPH) DNesbitt
    • Yes, it should be for either significantly slower or faster traffic, not just slower. I've no experience of driving in the USA, but on UK motorways where some cars are often going faster than the legal limit, the average speed of the average car is slower than the limit. I suspect that even for those who regularly go faster than the limit, that their average speed is significantly slower than their maximum, because they are always going to catch up with traffic doing the legal limit or slower. I guess that one reason for the roads you mention ion the USA is that slower legal limits mean that a higher percentage of traffic goes faster than the limit (where there is lax enforcement). I would expect routing systems to know about such "local norms" and apply a realistic factor (faster or slower) to the maxspeed tag to get the "normal" speed for a particular country/area. I think that the traffic_speed tag should be for ways where the traffic speed does not match the country/area "norm", or varies consistently in some way, like rush hours. Spod 20:09, 7 October 2010 (BST)Spod
• Regularly and consistently measurable.

e.g.:

• "rush hours"
• Where the traffic "always" travels at a speed that is significantly different to the legal maximum

Relation name

Is "traffic_speed" a good name for the relation?

List of "modes of transport" and "time-spans"

Is the accepted way of tagging a list of items in a key to have the items semicolon-separated? e.g. "bus;taxi"

Time span

Is the time-span specification suggested in the Key:opening_hours page appropriate for traffic speed time spans?

Do we need to allow 'years' to be specified in the time-span?

It is only relevant on ways?

Is there any reason for this relation to be applicable to nodes or areas?

Should it be used to tag ways affected by "one-off" events like soccer matches and music festivals

Probably not, because the effect of such events will be more variable and widespread than daily, normal traffic conditions on a specific road, so it would be much more difficult to measure it accurately. Maybe "events" need a different of tag on an area to show the area affected, plus the speeds etc?

Weather conditions

And what about the weather conditions ? The primary at the entrance of my city is affected daily by the commute, but also on the week-end by the departure and return. But the trafic (hour and intensity) is very sensitive to weather conditions, sunny or cloudy, summer or winter.., How to get something accurate ?--FrViPofm 08:28, 5 October 2010 (BST)

Is the effect of weather localised to a way, or does it really affect an "area" rather than a way? Is the effect of rain consistently measurable? In my city there is also a rain/snow effect, but it varies quite a lot - from just slower speeds on all roads, up to total lock-down of the whole city! So, to record that, you would need to design a tag that allowed different levels of weather to be defined. If weather really affects an area rather than just a way, then it would be more like an event like a soccer match or music festival - not so localised as rush-hour traffic- so maybe it would be better to use a different tag for such things? Spod 10:38, 5 October 2010 (BST)Spod

Static vs dynamic data

I would suggest that the value be quoted for some standard set of conditions, such that routing/navigation programs can add in their own dynamic data as they see fit. For example, by defining the value given by traffic_speed as the speed in daytime, with good weather and no other traffic. Like this the value will not need any day/time information although variations by vehicle type may still be appropriate. A routing/navigation program could acquire current weather and traffic data from some other source and factor those in to its calculations, e.g. if it's raining then speed=speed*0.8. OSM is really intended for static, objective information and attempting to extend it to heavily dynamic aspects is a serious development, which may happen some day. 14:57, 5 October 2010 (BST)Csmale

My concern is that by trying to cover all possible angles with explicit tags, which will often be inaccurate anyway (as they are unlikely to be able to predict YOUR journey time on a particular time/day), the discussion and the resulting tagging scheme will be so unbelievably complex that it will not get used effectively. Let's not overreach ourselves; keep it simple with a pragmatic approach. 14:57, 5 October 2010 (BST)Csmale

Using a relation is dubious

As far as I can see, the only reason why this proposal uses a relation is so that the properties can be applied to a number of ways. Is the intention to save bytes, or to make it easier to update a number of ways at the same time, or both ? Please update the proposal. The problem with doing it like this is that it makes to more difficult for contributors to verify and update. -- Nic 18:19, 5 October 2010 (BST)

• The reasons to use a relation are 1) to group the speeds for the various modes of transport together (so that it is easier to edit, because the tags are separated from all the other tags on the ways) and 2) to then be able to apply that group to a number of ways, without having to manually add/change the same tags to many ways, which will be error-prone.
  For example, a road near me consists of 4 separate ways - to manually add/change the tags 4 times would be error-prone.
  I tried to search the wiki to get an idea of how other tags are being grouped and using relations was suggested a few times, including on the main relations page, so I used a relation. Is there maybe a better way to group tags?
  Because the relation is just being used to group the tags, it's probably not as confusing as things like turn restrictions where you need to enter the member tag as well (which is confusing in Potlatch 1 because there's no way to get at the members from the relation!).
  Is the alternative to have each transport mode in a direct tag something like "traffic_speed:bus;taxi:forward=Mo-Fr 08:30-09:30 40mph"? I'm not sure of how the syntax of such complicated tags are being standardised - any suggestions? Spod 20:55, 5 October 2010 (BST)Spod

As the author of Routino a router for OSM data I agree that adding this information as a relation seems wrong. The argument given for doing it could be applied to any other tags that are normally applied to ways - tagging a relation that contains the ways will be easier than adding the tags to the individual ways. The problem is that it is less clear when editing a single way what its properties are. More relevant for a router is that when processing the OSM data the relation information must be applied to the member ways (and recursively to member relations). AMB 14:47, 9 October 2010 (BST)

Misc comments

Some of my concerns: a) Historical data for time dependent speed generally requires a large number of data points/observations to be accurate and useful. Casual OSM users may get stuck in an unusual traffic situation and apply a statistically extreme speed that could adversely impact routing. Bottom line: I don't trust users to generate meaningful data here. Reading a speed limit off a sign and applying it as maxspeed is pretty safe but applying a perception of speed based on a handful of instances will not likely generate valid data. b) Ways are generally much longer than they should be for applying this type of data. Applying the time based speed over a very long way may not be desirable. Ways would likely need to be split to identify true slow spots. c) Time dependent speed needs to be populated fully to be useful. I can't see a use where a very small percentage of roads have data applied for a given time period. d) Applying information at each way for multiple time periods will lead to a large expansion of data size (if it were populated at the level where it could be useful). DNesbitt 6 October 2010 DNesbitt

Practicality of Using Info in Router

The practicalities of using this data in a router algorithm mean that it is unlikely to be widely used. The time and date of starting the route must now be an input to the router algorithm. For car satnavs (and equivalent) you may know that the route is required to start at the current time, but for general router algorithms this is not the case. Even if the start time of the route is known the routing algorithm must keep track of the time at which it will follow each highway segment so that the reduced or normal traffic speed can be used. An additional problem is that traffic jams are not well modelled by a Boolean variable, but will increase at the start of the rush hour and decline at the end. AMB 14:59, 9 October 2010 (BST)