avg speed on roads
Hi, i remember dark that the Garmin Data modell contains some classification for road speeds e.g. used for time calculation in routing. Is there any osm tag used for hinting those speeds except the highway type? The question i ask is that i am currently on la palma and i am mapping when family lets me go - i found that routing times are off by a factor or 2 or 3. Measuring the avg. speed for sections of 10-20km on primarys is something low like 35km/h on some parts and something like 55km/h on fast parts. The max speed on these sections is mostly 80km/h but in the end nobody gets that fast. The low avg speed is caused by very tight slopes the roads wind up the mountains. So is there something like "avgspeed=" which gets used? I could hint the long distance roads like primarys in the sections i measured the avg. speed. Flo -- Florian Lohoff f@zz.de "Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen." - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin
Measuring the avg. speed for sections of 10-20km on primarys is something low like 35km/h on some parts and something like 55km/h on fast parts. The max speed on these sections is mostly 80km/h but in the end nobody gets that fast. In Mass the speed limits are on most ways from the MassGIS import. I believe mkgmap can look at speeds and turn that into a speed bin for garmin, separately from primary/secondary. There has been discussion of this before, but AFAIK no real resolution. It seems that almost everyone agrees that having a tag that describes the typical speeds would be sensible. The problem is that typical speeds are time dependent, and that's too complicated. I'm not sure if there are formal tagging proposals. I would go with typical_speeed= to represent the travel speeds that are normally obtainable during day/evening *outside* of "rush hour". This is a single number, useful for a lot of circumstances. Then, having a more complicated tag that gives a transform from type of day and time of day to speed could be done - but it's a slippery slope and pretty soon you want real-time data. But garmin maps don't support time-dependent data. Another question is why you want accurate time estimates. If you want the user to know when they'll arrive, you need an accurate estimate. But a weaker, still useful condition, is that calculated routes be fairly close to the best route. Hence my notion of ignoring rush hour in typical_speed - everything gets jammed up becuase everyone else is optimizing. And, humans know that they have to apply a rush hour penalty. This discussion really belongs on tagging@, becuase the mkgmap part is easy once there is agreement on a typical_speed tag and the db is populated.
On 23.04.2010 15:04, Greg Troxel wrote:
Measuring the avg. speed for sections of 10-20km on primarys is something low like 35km/h on some parts and something like 55km/h on fast parts. The max speed on these sections is mostly 80km/h but in the end nobody gets that fast.
In Mass the speed limits are on most ways from the MassGIS import. I believe mkgmap can look at speeds and turn that into a speed bin for garmin, separately from primary/secondary.
There has been discussion of this before, but AFAIK no real resolution. It seems that almost everyone agrees that having a tag that describes the typical speeds would be sensible. The problem is that typical speeds are time dependent, and that's too complicated.
I'm not sure if there are formal tagging proposals. I would go with
typical_speeed=
to represent the travel speeds that are normally obtainable during day/evening *outside* of "rush hour". This is a single number, useful for a lot of circumstances.
Then, having a more complicated tag that gives a transform from type of day and time of day to speed could be done - but it's a slippery slope and pretty soon you want real-time data. But garmin maps don't support time-dependent data.
Garmin maps do, at least NT type maps do. However we don't know how to encode it. at least NT type maps support time dependant restrictions, they also support maxspeed, but we don't know how to encode it. There are plenty other things, like junction view, lane assist, and so on, which we don't know how to encode (or maybe only possible in NT format).
Another question is why you want accurate time estimates. If you want the user to know when they'll arrive, you need an accurate estimate. But a weaker, still useful condition, is that calculated routes be fairly close to the best route. Hence my notion of ignoring rush hour in typical_speed - everything gets jammed up becuase everyone else is optimizing. And, humans know that they have to apply a rush hour penalty.
This discussion really belongs on tagging@, becuase the mkgmap part is easy once there is agreement on a typical_speed tag and the db is populated.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Measuring the avg. speed for sections of 10-20km on primarys is something low like 35km/h on some parts and something like 55km/h on fast parts. The max speed on these sections is mostly 80km/h but in the end nobody gets that fast.
In Mass the speed limits are on most ways from the MassGIS import. I believe mkgmap can look at speeds and turn that into a speed bin for garmin, separately from primary/secondary.
There has been discussion of this before, but AFAIK no real resolution. It seems that almost everyone agrees that having a tag that describes the typical speeds would be sensible. The problem is that typical speeds are time dependent, and that's too complicated.
I'm not sure if there are formal tagging proposals. I would go with
typical_speeed=
to represent the travel speeds that are normally obtainable during day/evening *outside* of "rush hour". This is a single number, useful for a lot of circumstances.
The OSM wiki (http://wiki.openstreetmap.org/wiki/Maxspeed) points to maxspeed:practical but this is a proposal only with lots of opponents.
Then, having a more complicated tag that gives a transform from type of day and time of day to speed could be done - but it's a slippery slope and pretty soon you want real-time data. But garmin maps don't support time-dependent data.
Another question is why you want accurate time estimates. If you want the user to know when they'll arrive, you need an accurate estimate. But a weaker, still useful condition, is that calculated routes be fairly close to the best route. Hence my notion of ignoring rush hour in typical_speed - everything gets jammed up becuase everyone else is optimizing. And, humans know that they have to apply a rush hour penalty.
I would also like to have accurate time estimates :-) So I think it's good to think about their improvement. Anyhow they will never be 100% accurate unless you have an algorithm that calculates the future (which I would use to calculate the lottery numbers).
This discussion really belongs on tagging@, becuase the mkgmap part is easy once there is agreement on a typical_speed tag and the db is populated.
I aggree. Generally there's nothing to do for mkgmap at the moment. The maxspeed tag is used to speed-classify the roads. Only two things for the future: * Support of the increasing DE:urban, DE:motorway etc. maxspeed values. * Get more knowledge of the Garmin map format to be able to support other speed information. WanMil
I think there are currently some tools in mkgmap to get a better time estimation. I have the lines below in my points style file, which certainly improve the arrival time estimation: 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' } --ignore-maxspeeds also helps to get better time. WanMil escribió:
Measuring the avg. speed for sections of 10-20km on primarys is something low like 35km/h on some parts and something like 55km/h on fast parts. The max speed on these sections is mostly 80km/h but in the end nobody gets that fast.
In Mass the speed limits are on most ways from the MassGIS import. I believe mkgmap can look at speeds and turn that into a speed bin for garmin, separately from primary/secondary.
There has been discussion of this before, but AFAIK no real resolution. It seems that almost everyone agrees that having a tag that describes the typical speeds would be sensible. The problem is that typical speeds are time dependent, and that's too complicated.
I'm not sure if there are formal tagging proposals. I would go with
typical_speeed=
to represent the travel speeds that are normally obtainable during day/evening *outside* of "rush hour". This is a single number, useful for a lot of circumstances.
The OSM wiki (http://wiki.openstreetmap.org/wiki/Maxspeed) points to maxspeed:practical but this is a proposal only with lots of opponents.
Then, having a more complicated tag that gives a transform from type of day and time of day to speed could be done - but it's a slippery slope and pretty soon you want real-time data. But garmin maps don't support time-dependent data.
Another question is why you want accurate time estimates. If you want the user to know when they'll arrive, you need an accurate estimate. But a weaker, still useful condition, is that calculated routes be fairly close to the best route. Hence my notion of ignoring rush hour in typical_speed - everything gets jammed up becuase everyone else is optimizing. And, humans know that they have to apply a rush hour penalty.
I would also like to have accurate time estimates :-) So I think it's good to think about their improvement. Anyhow they will never be 100% accurate unless you have an algorithm that calculates the future (which I would use to calculate the lottery numbers).
This discussion really belongs on tagging@, becuase the mkgmap part is easy once there is agreement on a typical_speed tag and the db is populated.
I aggree. Generally there's nothing to do for mkgmap at the moment. The maxspeed tag is used to speed-classify the roads. Only two things for the future: * Support of the increasing DE:urban, DE:motorway etc. maxspeed values. * Get more knowledge of the Garmin map format to be able to support other speed information.
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Fri, Apr 23, 2010 at 06:31:42PM +0200, Carlos Dávila wrote:
I think there are currently some tools in mkgmap to get a better time estimation. I have the lines below in my points style file, which certainly improve the arrival time estimation: highway=traffic_signals { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1' }
I found the road speed stuff in the source already. It seems it is in the default style hardcoded by street type/classification which should be possible to override with some tag i think. And a maxspeed has nothing to do with what i hav a problem with. All the roads i travel dont have a maxspeed set, are primary and thus for the time calculation my GPSMap 60 takes something like 80 km/h - which on la palma is on some parts more than twice the actual speed one can travel ... An its nothing time dependent - its something which depends on the physics of the street - tight corners reduce the speed beeing traveled ... Typical speed/ average speed would be more accurate ... -- Florian Lohoff f@zz.de "Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen." - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin
On Fri, Apr 23, 2010 at 06:31:42PM +0200, Carlos Dávila wrote:
I think there are currently some tools in mkgmap to get a better time estimation. I have the lines below in my points style file, which certainly improve the arrival time estimation: highway=traffic_signals { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1' }
I found the road speed stuff in the source already. It seems it is in the default style hardcoded by street type/classification which should be possible to override with some tag i think.
And a maxspeed has nothing to do with what i hav a problem with. All the roads i travel dont have a maxspeed set, are primary and thus for the time calculation my GPSMap 60 takes something like 80 km/h - which on la palma is on some parts more than twice the actual speed one can travel ... An its nothing time dependent - its something which depends on the physics of the street - tight corners reduce the speed beeing traveled ...
Typical speed/ average speed would be more accurate ...
Yes of course. But this is the wrong mailing list for this. First you have to set up a widely accepted tagging scheme for this. Once this has been done it should be no problem to use this data with mkgmap. WanMil
How much time penalty is added when the traffic_signal style below is added: 2010/4/24 Florian Lohoff <f@zz.de>:
certainly improve the arrival time estimation: highway=traffic_signals { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1'
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
El 02/06/10 03:41, maning sambale escribió:
How much time penalty is added when the traffic_signal style below is added:
2010/4/24 Florian Lohoff<f@zz.de>:
certainly improve the arrival time estimation: highway=traffic_signals { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1'
Time penalty is applied to the way section between the previous node and the node after the one tagged as highway=traffic_signals, so it depends on the length of that section. In a particular case I had to add an extra node closer to the traffic signal, because it was a long straight street and penalty was to high, diverting to a not optimal route, but in general it works fine. -- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale OpenOffice desde http://es.openoffice.org/programa/index.html OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones.
On 02.06.2010 03:41, maning sambale wrote:
How much time penalty is added when the traffic_signal style below is added:
2010/4/24 Florian Lohoff<f@zz.de>:
certainly improve the arrival time estimation: highway=traffic_signals { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1'
There is no time penalty. You simply decrease the speed/priority of the next adjoining streets that touch the POI.
El 02/06/10 23:26, Felix Hartmann escribió:
On 02.06.2010 03:41, maning sambale wrote:
How much time penalty is added when the traffic_signal style below is added:
2010/4/24 Florian Lohoff<f@zz.de>:
certainly improve the arrival time estimation: highway=traffic_signals { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1'
There is no time penalty. You simply decrease the speed/priority of the next adjoining streets that touch the POI.
That's right, of course, but at last speed decrease becomes an increase in estimated arrival time.
On 02.06.2010 23:53, Carlos Dávila wrote:
El 02/06/10 23:26, Felix Hartmann escribió:
On 02.06.2010 03:41, maning sambale wrote:
How much time penalty is added when the traffic_signal style below is added:
2010/4/24 Florian Lohoff<f@zz.de>:
certainly improve the arrival time estimation: highway=traffic_signals { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1'
There is no time penalty. You simply decrease the speed/priority of the next adjoining streets that touch the POI.
That's right, of course, but at last speed decrease becomes an increase in estimated arrival time. Well it's a big difference. Imagine a very long street as one piece, only split by one traffic light. Here the mechanism will completely fail. On the other hand, it could also only change for a few meters, again fail. In general it works well though. Unluckily Garmin hasn't foreseen time penalties based on POI. (there exist realt time penalties, but only for turning WHEN changing the street...).
thanks for clearing things up. On Thu, Jun 3, 2010 at 5:57 AM, Felix Hartmann <extremecarver@googlemail.com> wrote:
On 02.06.2010 23:53, Carlos Dávila wrote:
El 02/06/10 23:26, Felix Hartmann escribió:
On 02.06.2010 03:41, maning sambale wrote:
How much time penalty is added when the traffic_signal style below is added:
2010/4/24 Florian Lohoff<f@zz.de>:
certainly improve the arrival time estimation: highway=traffic_signals { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1'
There is no time penalty. You simply decrease the speed/priority of the next adjoining streets that touch the POI.
That's right, of course, but at last speed decrease becomes an increase in estimated arrival time. Well it's a big difference. Imagine a very long street as one piece, only split by one traffic light. Here the mechanism will completely fail. On the other hand, it could also only change for a few meters, again fail. In general it works well though. Unluckily Garmin hasn't foreseen time penalties based on POI. (there exist realt time penalties, but only for turning WHEN changing the street...).
_______________________________________________ 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/ ------------------------------------------------------
participants (7)
-
Carlos Dávila -
Carlos Dávila -
Felix Hartmann -
Florian Lohoff -
Greg Troxel -
maning sambale -
WanMil