Average speed per way
This page shall collect thoughts about the possibility to derive average speed data for osm ways from uploaded tracks.
There are a lot of tracks stored in the osm database. Not sure if there is an overview but we can use
to get the meta data of a track. This will give us basic information like the position (starting point?) of the track. This enables us to select the tracks we want to look at in the next step.
Qualification of tracks
With the information from the first step it is now possible to select tracks to download with
This information has to be stored locally. Next we have to find out if we can use this track. We have to look for
- valid timestamps
- source of the track (foot, bicycle, car, truck etc.) - maybe this has to be derived?
- direction (sometimes you have diferent speeds in each direction)
Ideally (in the future) an uploaded track is taged with
- vehicle (car(car fast, car slow, car), bike, foot, heavyGoodsVehicle) used
- type of day (weekday(other(monday, tuesday, ...), friday, holiday), weekend)
- type of time (day(afternoon, noon, morning), night)
Use of tracks
Once we decided we can use a track we have to
- calculate average speeds (for certain times/weekdays)
- assign those speeds to ways in osm data
Of course the last point here will be the challenge!
Use of data / upload
Once we have such derived data we can tag the ways according to the found speeds.
- Tags? (general, time specific, vehicle specific)
As an alternative we can have a web-service collect this kind of information and allow it to be queried.
- An incomplete, simple proof of concept is Speedcollector.
- documentation: Speedcollector
- submit and query here (link is dead, June 10, 2012)
OpenStreetMap Speeds is a github organization that was formed as a result of a discussion about how one could apply more accurate default speeds to OSM ways for the purposes of motor vehicle routing. The organization provides both the tooling for statistically generating the data as well as the data itself. The schema is hierarchical first by geography (country and principal subdivision) then by density (urban, suburban, rural) and finally by OSM tagging convention. Only a few tagging conventions are supported but they have broad coverage in the application of motor vehicle routing on OSM.
The current data artifact is derived from GPS trace data via Mapillary's APIs and the Valhalla map-matching API on OSM data. The tooling for generating the data supports a plugin model which should allow for others to contribute implementations for other GPS data sources (such as OSM tracks) or other map-matchers.
- Proposed features/Practical maxspeed - trying to do it manually instead of using automatic data collection