Road speed through urban areas
Hello, I'm a mapper in OpenStreetMap. We have a user that uses mkgmap with Garmin devices and he's setting road class inside cities lower than the local convention to get Garmin to avoid being routed through slow roads, which is bad practice. [4] I'd like to ask for some advice on how to help him set mkgmap to avoid such problems without disrespecting community guidelines. I've downloaded the source code [1] and read through the default styles in ./trunk/resources/styles/default/ . If I understood correctly, it sets road_speed=3 (60km/h [2]) for highway=secondary and road_speed=2 (40km/h [2]) for highway=tertiary. Those are reasonable in rural areas, but too fast in urban areas, where average speeds usually drop by around half of their real speed limit.I also found rules for handling the speed limit in maxspeed=*, but it seems like his issue would persist even when this tag is provided in map data. I think it might make sense to write a custom style [3] setting road_speed=2 for highway=secondary and road_speed=1 (20km/h [2]) for highway=tertiary. Perhaps this would then break some rural routes. I've found that Garmin supports traffic data, [5] but I'm unsure if this works with maps converted using mkgmap, as I don't own any Garmin device. Do you know? Thanks in advance for any information and advice. Best regards, [1] https://www.mkgmap.org.uk/mkgmap [2] https://www.mkgmap.org.uk/doc/pdf/style-manual.pdf [3] https://wiki.openstreetmap.org/wiki/Mkgmap/help/Custom_styles#Writing_a_styl... [4] https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer#General_meaning [5] https://www8.garmin.com/traffic/index.html -- Fernando Trebien
Hi Fernando. My Nuvi routes like an "honest taxi driver". I do not build my maps since now I use the map from i-nis.com.ar (has custom rules for speeds and semaphores). Put only real facts on OSM data (maxspeed -official limit-, maxspeed:practical, semaphores (I my city they add delay)) As traffic varies along hours of day, or days of week, maxspeed:practical changes, so it's not possible to translate OSM possibly richer data rules to a garmin map to this. It's a compromise, you have to choose a static road_class and road_speed. My Nuvi have never found a traffic feed in Brazil (RS or SC). But I have TraficTrends feature enabled, so maybe it learns from my drivings. Regards, M. ----- Mensaje original ----- De: "Fernando Trebien" <fernando.trebien@gmail.com> Para: "mkgmap-dev" <mkgmap-dev@lists.mkgmap.org.uk> Enviados: Sábado, 4 de Julio 2020 19:46:41 Asunto: [mkgmap-dev] Road speed through urban areas Hello, I'm a mapper in OpenStreetMap. We have a user that uses mkgmap with Garmin devices and he's setting road class inside cities lower than the local convention to get Garmin to avoid being routed through slow roads, which is bad practice. [4] I'd like to ask for some advice on how to help him set mkgmap to avoid such problems without disrespecting community guidelines. I've downloaded the source code [1] and read through the default styles in ./trunk/resources/styles/default/ . If I understood correctly, it sets road_speed=3 (60km/h [2]) for highway=secondary and road_speed=2 (40km/h [2]) for highway=tertiary. Those are reasonable in rural areas, but too fast in urban areas, where average speeds usually drop by around half of their real speed limit.I also found rules for handling the speed limit in maxspeed=*, but it seems like his issue would persist even when this tag is provided in map data. I think it might make sense to write a custom style [3] setting road_speed=2 for highway=secondary and road_speed=1 (20km/h [2]) for highway=tertiary. Perhaps this would then break some rural routes. I've found that Garmin supports traffic data, [5] but I'm unsure if this works with maps converted using mkgmap, as I don't own any Garmin device. Do you know? Thanks in advance for any information and advice. Best regards, [1] https://www.mkgmap.org.uk/mkgmap [2] https://www.mkgmap.org.uk/doc/pdf/style-manual.pdf [3] https://wiki.openstreetmap.org/wiki/Mkgmap/help/Custom_styles#Writing_a_styl... [4] https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer#General_meaning [5] https://www8.garmin.com/traffic/index.html -- Fernando Trebien _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev --------------------------------------------------------------------------------------------------------------------------------------- Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin costo. Informate si aplicás aquí. mvdfactura.uy ---------------------------------------------------------------------------------------------------------------------------------------
Fernando Trebien <fernando.trebien@gmail.com> writes:
I've downloaded the source code [1] and read through the default styles in ./trunk/resources/styles/default/ . If I understood correctly, it sets road_speed=3 (60km/h [2]) for highway=secondary and road_speed=2 (40km/h [2]) for highway=tertiary. Those are reasonable in rural areas, but too fast in urban areas, where average speeds usually drop by around half of their real speed limit.I also found rules for handling the speed limit in maxspeed=*, but it seems like his issue would persist even when this tag is provided in map data.
The basic problem is that if you are using default speeds baseed on osm road type, that's a clue that speed limits rae missing. The next problem is that there is maxspeed and maxspeed:practical, and if you cannot drive at the speed limit usually, you should set maxspeed:practical check that if maxspeed:practical exists, mkgmpa uses it as the speed limit
I think it might make sense to write a custom style [3] setting road_speed=2 for highway=secondary and road_speed=1 (20km/h [2]) for highway=tertiary. Perhaps this would then break some rural routes.
That may make a map that works in one area, but it just moves the problem.
I've found that Garmin supports traffic data, [5] but I'm unsure if this works with maps converted using mkgmap, as I don't own any Garmin device. Do you know?
I have never seen a claim that it works.
Thank you very much for your reply, Greg. On Sat, Jul 4, 2020 at 10:55 PM Greg Troxel <gdt@lexort.com> wrote:
The next problem is that there is maxspeed and maxspeed:practical, and if you cannot drive at the speed limit usually, you should
set maxspeed:practical
check that if maxspeed:practical exists, mkgmpa uses it as the speed limit
Just to be sure: does mkgmap understand maxspeed:practical by default? I didn't find any reference to maxspeed:practical in the most recent mkgmap code, and an old patch submission [1] had code with maxspeed:practical which is not part of the latest default style. I believe this means a custom style would be necessary, is that right? [1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q3/018684.html Best regards, -- Fernando Trebien
Hi Fernando The mkgmap default style doesn't understand maxspeed:practical. If you are currently using the default style, it is easiest to make a complete copy of the subdirectory mkgmap-rXXXX/examples/styles/default into your own working area subdirectory, eg 'lowspeed', point the --style-file option at this and then modify as necessary. You should be able to confine all your changes to lowspeed/inc/roadspeed and not need to touch lowspeed/lines. See tags mkgmap:road-speed, mkgmap:road-speed-class, mkgmap:road-speed -max etc in the style manual (mkgmap-rXXXX/doc/style-manual.pdf) Maybe make use of the new is-in function, eg: highway=secondary & is_in(landuse, residential, any) {add mkgmap:road-speed=-1} Ticker On Tue, 2020-07-07 at 00:25 -0300, Fernando Trebien wrote:
Thank you very much for your reply, Greg.
On Sat, Jul 4, 2020 at 10:55 PM Greg Troxel <gdt@lexort.com> wrote:
The next problem is that there is maxspeed and maxspeed:practical, and if you cannot drive at the speed limit usually, you should
set maxspeed:practical
check that if maxspeed:practical exists, mkgmpa uses it as the speed limit
Just to be sure: does mkgmap understand maxspeed:practical by default? I didn't find any reference to maxspeed:practical in the most recent mkgmap code, and an old patch submission [1] had code with maxspeed:practical which is not part of the latest default style. I believe this means a custom style would be necessary, is that right?
[1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q3/018684.html
Best regards,
-- Fernando Trebien _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
The mkgmap default style doesn't understand maxspeed:practical.
Thanks. I was unclear on this. I would suggest that mkgmap should in the default style use the first one of these that is defined: maxspeed:practical maxspeed:advisory (yellow sign, in the US, not a requirement, but advice) maxspeed (legal limit) I am unclear on if advisory is used in non-US places. Here we often e.g. have yellow "45" signs on curves on roads with "55" limit (white) signs, and on exit ramps (slip roads in en_GB, *_link in osm). Sometimes the advisory speeds are sensible, some times they are way too low and occasionally they are too high. A great case for using practical to fix them. I would expect this to be quite necessary in rural UK and IE, as it seems there is a tradition of 100 km/h or 60 mph outside town centers, but at times roads often narrower/twisty such that at least I didn't think it wise. (The US doesn't do this so much; very rarely is the legal limit unsafe. There are dirt roads where :practical should be used, though.)
Hi Seems like a good idea. In the British Isles I find 359 maxspeed:advisory and no maxspeed:practical. maxspeed:practical was rejected: https://wiki.openstreetmap.org/wiki/Proposed_features/Practical_maxspee d but seems to be accepted: https://wiki.openstreetmap.org/wiki/Key:maxspeed:practical I'll do a patch for this sometime soon. Ticker On Tue, 2020-07-07 at 08:28 -0400, Greg Troxel wrote:
The mkgmap default style doesn't understand maxspeed:practical.
Thanks. I was unclear on this.
I would suggest that mkgmap should in the default style use the first one of these that is defined:
maxspeed:practical maxspeed:advisory (yellow sign, in the US, not a requirement, but advice) maxspeed (legal limit)
I am unclear on if advisory is used in non-US places. Here we often e.g. have yellow "45" signs on curves on roads with "55" limit (white) signs, and on exit ramps (slip roads in en_GB, *_link in osm). Sometimes the advisory speeds are sensible, some times they are way too low and occasionally they are too high. A great case for using practical to fix them.
I would expect this to be quite necessary in rural UK and IE, as it seems there is a tradition of 100 km/h or 60 mph outside town centers, but at times roads often narrower/twisty such that at least I didn't think it wise.
(The US doesn't do this so much; very rarely is the legal limit unsafe. There are dirt roads where :practical should be used, though.)
Thank you Ticker and Greg. Somehow, I didn't get the message from Ticker in my mailbox, but now I can read it here. [1] I'm using BaseCamp to test the changes, assuming that Garmin devices run the same routing algorithm and, therefore, would give the same result to end users. In the meantime, I modified the default example style by adding this line at the beginning: maxspeed:practical=* & maxspeed=* & maxspeed:practical < $maxspeed { set maxspeed='${maxspeed:practical}' } And it appears to be working just as expected! Although I think this rule would not work for maxspeed:practical represented in mph. I tried to create a rule that substitutes the value of maxspeed with the value of maxspeed:practical only if maxspeed:practical is lower than maxspeed. By duplicating that line and replacing "practical" with "advisory", one gets the behaviour suggested by Greg previously. It surprises me that currently few routing software supports maxspeed:advisory (so far I think only OsmAnd supports both maxspeed:advisory and maxspeed:practical), as this tends to be more closely related to the expected average speed than maxspeed when both are present. Similar rules could be written further to support various values of surface and smoothness, further improving routing in specific situations. [5][6] In a way, I feel that the lack of available built-in speed levels between 5 and 20kmph restricts the ability of Garmin devices to produce high-quality routes in areas with poorer infrastructure, as is the case in developing countries.
From Ticker's mention of the is-in function, I found this message [2] that mentions mkgmap:urban, which sounds like a more general solution without requiring the maxspeed:practical tag too much. But there's no mkgmap:urban in the latest code. A definitive solution, though more complex, would probably require support for traffic patterns. [3][4] I'll look into the specifics of the is-in function now.
Thank you again. Regards. [1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031264.html [2] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q1/026124.html [3] https://wiki.openstreetmap.org/wiki/Global_Statistical_Speed_Matrix [4] https://github.com/graphhopper/open-traffic-collection [5] https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua [6] https://github.com/graphhopper/graphhopper/blob/master/core/src/main/java/co... On Tue, Jul 7, 2020 at 9:28 AM Greg Troxel <gdt@lexort.com> wrote:
The mkgmap default style doesn't understand maxspeed:practical.
Thanks. I was unclear on this.
I would suggest that mkgmap should in the default style use the first one of these that is defined:
maxspeed:practical maxspeed:advisory (yellow sign, in the US, not a requirement, but advice) maxspeed (legal limit)
I am unclear on if advisory is used in non-US places. Here we often e.g. have yellow "45" signs on curves on roads with "55" limit (white) signs, and on exit ramps (slip roads in en_GB, *_link in osm). Sometimes the advisory speeds are sensible, some times they are way too low and occasionally they are too high. A great case for using practical to fix them.
I would expect this to be quite necessary in rural UK and IE, as it seems there is a tradition of 100 km/h or 60 mph outside town centers, but at times roads often narrower/twisty such that at least I didn't think it wise.
(The US doesn't do this so much; very rarely is the legal limit unsafe. There are dirt roads where :practical should be used, though.) _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Fernando Trebien
On Wed, Jul 8, 2020 at 11:08 AM Fernando Trebien <fernando.trebien@gmail.com> wrote:
In the meantime, I modified the default example style by adding this line at the beginning:
maxspeed:practical=* & maxspeed=* & maxspeed:practical < $maxspeed { set maxspeed='${maxspeed:practical}' }
Sorry, I wasn't very clear. I added this line at the beginning of ./inc/roadspeed in the custom style copied from the default example style. -- Fernando Trebien
Fernando Trebien <fernando.trebien@gmail.com> writes:
maxspeed:practical=* & maxspeed=* & maxspeed:practical < $maxspeed { set maxspeed='${maxspeed:practical}' }
Not really bearing on your particular problem, but I don't think checking with < makes sense. If maxspeed:practical is set, it represents the speed that people actually can reasonably drive. It can be that this practical, socially acceptable speed is higher than the limit. There is a road around me that is built almost like an interstate but has an inexplicable 45 mph speed limit. Traffic normally flows at 70 mph. Anyone going 45 mph is really in the way to the point of being dangerous, and people might call the police to report an impaired driver. So if practical is higher, use it. Which means "if practical is set, use it".
Hi Fernando & Greg You need to use the maxspeedkph() or maxspeedmph() function to read the OSM maxspeed tag as it understands values like "30 mph". Then, following Greg's idea that you should use maxspeed:practical if set and the that logic to compare speeds is going to be very tricky, just have following near the start of inc/roadspeed: maxspeed:advisory=* {set maxspeed='${maxspeed:advisory}'} maxspeed:practial=* {set maxspeed='${maxspeed:practial}'} It also needs something at the end to limit motorways for most countries: highway=motorway & mkgmap:road-speed-max!=* & mkgmap:country!=DEU {set mkgmap:road-speed-max=6} Ticker On Wed, 2020-07-08 at 10:57 -0400, Greg Troxel wrote:
Fernando Trebien <fernando.trebien@gmail.com> writes:
maxspeed:practical=* & maxspeed=* & maxspeed:practical < $maxspeed { set maxspeed='${maxspeed:practical}' }
Not really bearing on your particular problem, but I don't think checking with < makes sense. If maxspeed:practical is set, it represents the speed that people actually can reasonably drive.
It can be that this practical, socially acceptable speed is higher than the limit. There is a road around me that is built almost like an interstate but has an inexplicable 45 mph speed limit. Traffic normally flows at 70 mph. Anyone going 45 mph is really in the way to the point of being dangerous, and people might call the police to report an impaired driver.
So if practical is higher, use it. Which means "if practical is set, use it". _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Ticker Berkin <rwb-mkgmap@jagit.co.uk> writes:
It also needs something at the end to limit motorways for most countries:
highway=motorway & mkgmap:road-speed-max!=* & mkgmap:country!=DEU {set mkgmap:road-speed-max=6}
Do you mean Except Germany, most/all countries have speed limits on motorways, but some of them don't have explicit tags in OSM. While this is a bug in the data and should be fixed, mkgmap ought to do something sensible more or less?
Hi Greg & Gerd Yes, this is what I mean, more or less. I don't know what the OSM tagging policy is on applying maxspeed tags to every road, but mkgmap applies its own limits based on highway type to everything except motorway, and this patch now does motorways as well. There are a couple of other countries that don't have max speed limits on some roads and I haven't bothered with them explicitly, but if the road is tagged with maxspeed/:practical/:advisory that is above 120kmh than it won't be limited. patch attached. Ticker On Wed, 2020-07-08 at 20:14 -0400, Greg Troxel wrote:
Ticker Berkin <rwb-mkgmap@jagit.co.uk> writes:
It also needs something at the end to limit motorways for most countries:
highway=motorway & mkgmap:road-speed-max!=* & mkgmap:country!=DEU {set mkgmap:road-speed-max=6}
Do you mean
Except Germany, most/all countries have speed limits on motorways, but some of them don't have explicit tags in OSM. While this is a bug in the data and should be fixed, mkgmap ought to do something sensible
more or less?
Hi all, reg. maxspeed:practical I think we should not use disputed tags in preference to well established tags in the default style. reg. maxspeed:advisory: I see no problem with that. What's the purpose of this rule? Is it meant to improve travel time estimation? highway=motorway & maxspeed!=* & mkgmap:road-speed-max!=* & mkgmap:country!=DEU {set mkgmap:road-speed-max=6} Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 9. Juli 2020 09:51 An: mkgmap development Betreff: Re: [mkgmap-dev] Road speed through urban areas Hi Greg & Gerd Yes, this is what I mean, more or less. I don't know what the OSM tagging policy is on applying maxspeed tags to every road, but mkgmap applies its own limits based on highway type to everything except motorway, and this patch now does motorways as well. There are a couple of other countries that don't have max speed limits on some roads and I haven't bothered with them explicitly, but if the road is tagged with maxspeed/:practical/:advisory that is above 120kmh than it won't be limited. patch attached. Ticker On Wed, 2020-07-08 at 20:14 -0400, Greg Troxel wrote:
Ticker Berkin <rwb-mkgmap@jagit.co.uk> writes:
It also needs something at the end to limit motorways for most countries:
highway=motorway & mkgmap:road-speed-max!=* & mkgmap:country!=DEU {set mkgmap:road-speed-max=6}
Do you mean
Except Germany, most/all countries have speed limits on motorways, but some of them don't have explicit tags in OSM. While this is a bug in the data and should be fixed, mkgmap ought to do something sensible
more or less?
Hi all I'm not too fussed about maxspeed:practical; there were no examples in the British Isles. Comments from other people suggest it is used widely elsewhere and would be useful. The motorway rule is for completeness. It might improve travel time estimation but I've no idea what Garmin uses as the driving speed for road_speed 7/unlimited; maybe it knows about national speed limits. Ticker On Thu, 2020-07-09 at 10:16 +0000, Gerd Petermann wrote:
Hi all,
reg. maxspeed:practical I think we should not use disputed tags in preference to well established tags in the default style. reg. maxspeed:advisory: I see no problem with that.
What's the purpose of this rule? Is it meant to improve travel time estimation? highway=motorway & maxspeed!=* & mkgmap:road-speed-max!=* & mkgmap:country!=DEU {set mkgmap:road-speed-max=6}
Gerd
Hi Ticker, the speed used for routing depends also on your device. For road_speed 7, I detected 112 km/h on an Oregon 600, and 132 km/h on an Oregon 400. For more details, see my old post on that topic at http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2014q3/021620.html Kind regards, Bernhard Am 09.07.2020 um 13:41 schrieb Ticker Berkin:
Hi all
I'm not too fussed about maxspeed:practical; there were no examples in the British Isles. Comments from other people suggest it is used widely elsewhere and would be useful.
The motorway rule is for completeness. It might improve travel time estimation but I've no idea what Garmin uses as the driving speed for road_speed 7/unlimited; maybe it knows about national speed limits.
Ticker
On Thu, 2020-07-09 at 10:16 +0000, Gerd Petermann wrote:
Hi all,
reg. maxspeed:practical I think we should not use disputed tags in preference to well established tags in the default style. reg. maxspeed:advisory: I see no problem with that.
What's the purpose of this rule? Is it meant to improve travel time estimation? highway=motorway & maxspeed!=* & mkgmap:road-speed-max!=* & mkgmap:country!=DEU {set mkgmap:road-speed-max=6}
Gerd
Thanks Bernhard Gerd - I've attached a modified patch that disables maxspeed:practical and adds a comment about unlimitied Ticker
Hi Gerd Could you apply this Thanks Ticker On Fri, 2020-07-10 at 10:01 +0100, Ticker Berkin wrote:
Thanks Bernhard
Gerd - I've attached a modified patch that disables maxspeed:practical and adds a comment about unlimitied
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Ticker Berkin <rwb-mkgmap@jagit.co.uk> writes:
Yes, this is what I mean, more or less. I don't know what the OSM tagging policy is on applying maxspeed tags to every road, but mkgmap applies its own limits based on highway type to everything except motorway, and this patch now does motorways as well.
OSM policy is more or less that every road should have its actual maxspeed tagged, and that while it is reasonable to infer defaults from road type when it isn't, that's a workaround for lack of data. Which is what you are doing, so that's 100% fine in my view.
On Wed, Jul 8, 2020 at 11:08 AM Fernando Trebien <fernando.trebien@gmail.com> wrote:
From Ticker's mention of the is-in function, I found this message [2] that mentions mkgmap:urban, which sounds like a more general solution without requiring the maxspeed:practical tag too much. But there's no mkgmap:urban in the latest code. A definitive solution, though more complex, would probably require support for traffic patterns. [3][4] I'll look into the specifics of the is-in function now.
Would mapping boundary=urban [1] help solve the problem of assigning a slower estimated speed to ways within dense urban areas in routing apps such as mkgmap? [2][3] It looks like an elegant solution to this problem that would not have the same issues with verifiability that maxspeed:practical has. It is currently common only in France (see an example in Rennes [4]) and there is official data available in my area that could be imported into OSM. [5] [1] https://wiki.openstreetmap.org/wiki/Tag:boundary%3Durban [2] https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed [3] https://wiki.openstreetmap.org/wiki/Default_speed_limits [4] https://www.openstreetmap.org/way/602186761 [5] https://lists.openstreetmap.org/pipermail/tagging/2014-May/017670.html -- Fernando Trebien
Fernando Trebien <fernando.trebien@gmail.com> writes:
Would mapping boundary=urban [1] help solve the problem of assigning a slower estimated speed to ways within dense urban areas in routing apps such as mkgmap? [2][3] It looks like an elegant solution to this problem that would not have the same issues with verifiability that maxspeed:practical has. It is currently common only in France (see an example in Rennes [4]) and there is official data available in my area that could be imported into OSM. [5]
I don't see why drawing a line that encloses the area where you think maxspeed:practical is low is any more verifiable. You are tagging about an area where people drive slower than the speed limits, I think. So it's really the same thing. Also, maxspeed:practical is easy to verify. Drive on the road 10 times and see what the average speed you actually went is. I have lots of commuting data and someday, I will process it and see what the distributions look like. If there really are speed limits, then by all means tag them.
Hi all, I fear I don't get the point in this discussion. My understanding is that you want a style that sets a lower road class for major roads within a city. Question is in what situation this will lead to better routing. If there is a good alternative route around the city it should already have the higher highway tag in OSM. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Greg Troxel <gdt@lexort.com> Gesendet: Donnerstag, 16. Juli 2020 01:21 An: Fernando Trebien Cc: Development list for mkgmap Betreff: Re: [mkgmap-dev] Road speed through urban areas Fernando Trebien <fernando.trebien@gmail.com> writes:
Would mapping boundary=urban [1] help solve the problem of assigning a slower estimated speed to ways within dense urban areas in routing apps such as mkgmap? [2][3] It looks like an elegant solution to this problem that would not have the same issues with verifiability that maxspeed:practical has. It is currently common only in France (see an example in Rennes [4]) and there is official data available in my area that could be imported into OSM. [5]
I don't see why drawing a line that encloses the area where you think maxspeed:practical is low is any more verifiable. You are tagging about an area where people drive slower than the speed limits, I think. So it's really the same thing. Also, maxspeed:practical is easy to verify. Drive on the road 10 times and see what the average speed you actually went is. I have lots of commuting data and someday, I will process it and see what the distributions look like. If there really are speed limits, then by all means tag them. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, In urban areas the 'practical maxspeed' is often lower then the 'official' maxspeed because of existence of traffic lights and traffic calmers. I would rely on the intended routing basics of road_class and corresponding maxspeeds and the common usage of highway types and tagging in osm. Maybe it helps to make these roads less attractive for the routing engines to check for traffic lights. Because these are node-tags and not line-tags I don't know the exact impact. highway = residential & highway=crossing & crossing=traffic_signals {set mkgmap:road-speed=-2} highway = residential & traffic_calming=table { set mkgmap:road-speed=-1} highway = residential & access = destination { set mkgmap:road-speed=-2} Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 16 juli 2020 09:11 Aan: Fernando Trebien <fernando.trebien@gmail.com>; Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Road speed through urban areas Hi all, I fear I don't get the point in this discussion. My understanding is that you want a style that sets a lower road class for major roads within a city. Question is in what situation this will lead to better routing. If there is a good alternative route around the city it should already have the higher highway tag in OSM. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Greg Troxel <gdt@lexort.com> Gesendet: Donnerstag, 16. Juli 2020 01:21 An: Fernando Trebien Cc: Development list for mkgmap Betreff: Re: [mkgmap-dev] Road speed through urban areas Fernando Trebien <fernando.trebien@gmail.com> writes:
Would mapping boundary=urban [1] help solve the problem of assigning a slower estimated speed to ways within dense urban areas in routing apps such as mkgmap? [2][3] It looks like an elegant solution to this problem that would not have the same issues with verifiability that maxspeed:practical has. It is currently common only in France (see an example in Rennes [4]) and there is official data available in my area that could be imported into OSM. [5]
I don't see why drawing a line that encloses the area where you think maxspeed:practical is low is any more verifiable. You are tagging about an area where people drive slower than the speed limits, I think. So it's really the same thing. Also, maxspeed:practical is easy to verify. Drive on the road 10 times and see what the average speed you actually went is. I have lots of commuting data and someday, I will process it and see what the distributions look like. If there really are speed limits, then by all means tag them. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
That approach based on POIs does not work too well. You have no idea if you lower the speed for a short segment or a long one, it just depends on eg. if there are traffic lights on long or short segment. Same problem with other poi types like crossings. BTW, For another message suggesting lower road classes. I'd not lower road classes too much. According to my tests garmin seems to ignore lower road classes on long trips (except near ends) and if there are huge number of equal road classes, route calculation time can get really large. I tried a few years back lifting cycleways to category similar to motorways (to get better cycling routing). That resulted in route calculation times like 10 or 15 minutes for a 10km trip in the city. (At least on my older Oregon). On 7/16/20 11:14 AM, Joris Bo wrote:
Hi,
In urban areas the 'practical maxspeed' is often lower then the 'official' maxspeed because of existence of traffic lights and traffic calmers. I would rely on the intended routing basics of road_class and corresponding maxspeeds and the common usage of highway types and tagging in osm.
Maybe it helps to make these roads less attractive for the routing engines to check for traffic lights. Because these are node-tags and not line-tags I don't know the exact impact.
highway = residential & highway=crossing & crossing=traffic_signals {set mkgmap:road-speed=-2} highway = residential & traffic_calming=table { set mkgmap:road-speed=-1} highway = residential & access = destination { set mkgmap:road-speed=-2}
Joris
Hi Harri, yes, the Garmin algo seems to work like this: try to get on a high class road as soon as possible and try to reach a point near the target without using a lower class road again. So, once a class 4 road is used it will accept rather long detours to get to a target. The img data even contains rather redundant information to help with this calculation. This algo works well for countries with motorways and car routing but for cycling maps you might get better results when you don't use high road classes unless you want a map for long and nice cycling tours where a long detour on a nicer road is welcomed. Besides that you should not rely on results that you got from much older mkgmap versions if they wrote different NOD information. We still learn how the bits and bytes in the IMG format are interpreted by Garmin and thus older releases often simply encoded wrong data. Sometimes it was a miracle to me how the Garmin algo still found reasonable routes. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Harri Suomalainen <hsuomal@welho.com> Gesendet: Donnerstag, 16. Juli 2020 10:35 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Road speed through urban areas That approach based on POIs does not work too well. You have no idea if you lower the speed for a short segment or a long one, it just depends on eg. if there are traffic lights on long or short segment. Same problem with other poi types like crossings. BTW, For another message suggesting lower road classes. I'd not lower road classes too much. According to my tests garmin seems to ignore lower road classes on long trips (except near ends) and if there are huge number of equal road classes, route calculation time can get really large. I tried a few years back lifting cycleways to category similar to motorways (to get better cycling routing). That resulted in route calculation times like 10 or 15 minutes for a 10km trip in the city. (At least on my older Oregon). On 7/16/20 11:14 AM, Joris Bo wrote:
Hi,
In urban areas the 'practical maxspeed' is often lower then the 'official' maxspeed because of existence of traffic lights and traffic calmers. I would rely on the intended routing basics of road_class and corresponding maxspeeds and the common usage of highway types and tagging in osm.
Maybe it helps to make these roads less attractive for the routing engines to check for traffic lights. Because these are node-tags and not line-tags I don't know the exact impact.
highway = residential & highway=crossing & crossing=traffic_signals {set mkgmap:road-speed=-2} highway = residential & traffic_calming=table { set mkgmap:road-speed=-1} highway = residential & access = destination { set mkgmap:road-speed=-2}
Joris
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all Various points and ideas: I think that testing for admin level boundaries is trivial provided you are using --bounds=..zip. So, for country XXX, could add the following to inc/roadspeed: mkgmap:country=XXX & mkgmap:admin_level8=* {set mkgmap:road-speed=-1} However, I haven't looked at the bounds/admin_level topic in any detail. As Gerd says, fine-tuning road speeds might have no effect on the choice between routing through or around urban areas, so enhancing the above with: mkgmap:country=XXX & mkgmap:admin_level8=* {set mkgmap:road-class=-1} might be more effective. NB might also need mkgmap:road-class-min and protect some highway types from modification. Accurate road speeds must be a good idea, giving better estimates of journey time and, in some cases, faster routes. Even if maxspeed:practical isn't in the default style, I'd have it in mine if there was a chance of useful data for it to pick up. To indicate slowed speeds at lights/crossings, need --link-pois-to-way and, in "points", something like: highway=traffic_signals | highway=crossing {set mkgmap:road-speed=1} This, if necessary, chops the road up and applies the specified speed to a short section around the point. Ticker
Ticker Berkin <rwb-mkgmap@jagit.co.uk> writes:
mkgmap:country=XXX & mkgmap:admin_level8=* {set mkgmap:road-speed=-1} However, I haven't looked at the bounds/admin_level topic in any detail.
In Massachusetts, *everywhere* is within an admin_level=8. One of these is Boston, which is very crowded, and there are towns with 300 people and probably more cows than that, over probably 40 km^2. So being in an admin_level=8 does not imply that you can't drive the posted limit. This "admin8 is slow" rule also fails verifiability as much as maxspeed:practical.
Accurate road speeds must be a good idea, giving better estimates of journey time and, in some cases, faster routes. Even if maxspeed:practical isn't in the default style, I'd have it in mine if there was a chance of useful data for it to pick up.
To me it's clear that the right thing is to 1) tag major roads in cities with maxspeed:practical, if you can't drive at the posted speed and 2) respect maxspeed:practical. Just because the wiki crowd doesn't like is not that important; OSM has a culture of arguing about tagging in a vacuum rather than in the context of how data consumers use it, and this culture is broken.
To indicate slowed speeds at lights/crossings, need --link-pois-to-way and, in "points", something like: highway=traffic_signals | highway=crossing {set mkgmap:road-speed=1} This, if necessary, chops the road up and applies the specified speed to a short section around the point.
That sounds promising. OsmAnd I am pretty sure adds time for traversing lights, but it isn't trying to program someone else's routing engine. I suppose the traffic_signasl (and stop) could also drop the class for longer segments if it basically works out the same.
Be careful, if you drop the class for traffic_signals it brokes long distance routing, because (at least in South America) a lot of primarys and trunks have traffic_signals. I have been using the a map with a style that applies a -1 penalty for road_speed in case of traffic signals, and it works well in cities and in long distance routing, and it improves the estimated times. Regards, M. ----- Mensaje original ----- De: "Greg Troxel" <gdt@lexort.com> Para: "Ticker Berkin" <rwb-mkgmap@jagit.co.uk> CC: "mkgmap-dev" <mkgmap-dev@lists.mkgmap.org.uk> Enviados: Jueves, 16 de Julio 2020 8:53:12 Asunto: Re: [mkgmap-dev] Road speed through urban areas Ticker Berkin <rwb-mkgmap@jagit.co.uk> writes:
mkgmap:country=XXX & mkgmap:admin_level8=* {set mkgmap:road-speed=-1} However, I haven't looked at the bounds/admin_level topic in any detail.
In Massachusetts, *everywhere* is within an admin_level=8. One of these is Boston, which is very crowded, and there are towns with 300 people and probably more cows than that, over probably 40 km^2. So being in an admin_level=8 does not imply that you can't drive the posted limit. This "admin8 is slow" rule also fails verifiability as much as maxspeed:practical.
Accurate road speeds must be a good idea, giving better estimates of journey time and, in some cases, faster routes. Even if maxspeed:practical isn't in the default style, I'd have it in mine if there was a chance of useful data for it to pick up.
To me it's clear that the right thing is to 1) tag major roads in cities with maxspeed:practical, if you can't drive at the posted speed and 2) respect maxspeed:practical. Just because the wiki crowd doesn't like is not that important; OSM has a culture of arguing about tagging in a vacuum rather than in the context of how data consumers use it, and this culture is broken.
To indicate slowed speeds at lights/crossings, need --link-pois-to-way and, in "points", something like: highway=traffic_signals | highway=crossing {set mkgmap:road-speed=1} This, if necessary, chops the road up and applies the specified speed to a short section around the point.
That sounds promising. OsmAnd I am pretty sure adds time for traversing lights, but it isn't trying to program someone else's routing engine. I suppose the traffic_signasl (and stop) could also drop the class for longer segments if it basically works out the same. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev --------------------------------------------------------------------------------------------------------------------------------------- Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin costo. Informate si aplicás aquí. mvdfactura.uy ---------------------------------------------------------------------------------------------------------------------------------------
muralito@montevideo.com.uy writes:
Be careful, if you drop the class for traffic_signals it brokes long distance routing, because (at least in South America) a lot of primarys and trunks have traffic_signals.
I have been using the a map with a style that applies a -1 penalty for road_speed in case of traffic signals, and it works well in cities and in long distance routing, and it improves the estimated times.
What I meant is compute using a richer routing algorithm how long traversal will take compute what length to have a reduced class, or what length/reduction combos, to match the richer alogrithm make sure to do this in both directions demote for some class/distance, or perhaps the whole length for short segements between adjoining traffic_signals essentially construct a network with road_class set so that routing on that network as garmin does, produces the same outcome as using a signals-aware routing algorithm which I realize is a tall order
muralito@montevideo.com.uy writes:
Be careful, if you drop the class for traffic_signals it brokes long distance routing, because (at least in South America) a lot of primarys and trunks have traffic_signals.
I don't think your situation is unusual, but I have never driven south of Key West :-) In the US, Interstates ("motorway") never have siganls. Primaries often do, in more urban areas, and in unpopulated areas rarely do. Some US highways near me are posted 30 mph (~50 km/h) and have lights every 400m, and lots of businesses. primary in the road hierarchy - the one I am talking about is US 20 and it goes from Boston all the way to the west coast - and the biggest road around, arguably the 4th most important E-W road in massachusetts. But still in eastern mass it is slow to drive on. trunk, more or less, is supposed to be things that are sort of a bit like motorways but aren't quite. around me, those are divided, very few if any businesses on them, occasional (every mile or so?) intersections that aren't grade-spearated. Typically you can achive 50 mph (80 km/h) on them and maybe average 40mph/65km/h over longish intervals.
On Thu, Jul 16, 2020 at 7:52 AM Ticker Berkin <rwb-mkgmap@jagit.co.uk> wrote:
Hi all
Various points and ideas:
I think that testing for admin level boundaries is trivial provided you are using --bounds=..zip. So, for country XXX, could add the following to inc/roadspeed: mkgmap:country=XXX & mkgmap:admin_level8=* {set mkgmap:road-speed=-1} However, I haven't looked at the bounds/admin_level topic in any detail.
If you do, note that querying boundary=administrative would not really help the situation much, as this is used for administrative areas that generally include both urban and rural areas of such entities. What I am suggesting is support for the relatively new boundary=urban, [1] which has not yet been widely used, but, by definition, represents (most often almost exactly) the boundary between the urban and the rural part of administrative entities (such as municipalities). It is at this boundary that average speeds tend to drop. An alternative to boundary=urban is place=* on areas, [2] specifically the values of place=* that represent the boundaries of urban settlements. [3] So, for example, when mkgmap is processing OSM data and finds a secondary road (highway = secondary), it can (1) check that the way does not have mkgmap:fast_road=yes, then (2) query urban boundaries to find out if it lies within any boundary=urban and, if both are true, (3) apply some speed reduction (say, 0.5 * maxspeed) to better estimate the average speed. This would result in a preference for bypassing cities on the outside and for following main routes instead of finding slow shortcuts through busy urban streets. For sure there would be situations where this will not produce an optimal result, but I think that on average it would improve routing. It is surely not as accurate as collecting real average speeds, but as the urban boundary is usually obvious to mappers from satellite images (and sometimes official data sources exist), it reduces the need for maxspeed:practical, which presents many issues to the mapping community. [4] It also saves a lot of mapping work. [1] https://wiki.openstreetmap.org/wiki/Tag:boundary%3Durban [2] https://wiki.openstreetmap.org/wiki/Key:place#Mapping_populated_places_as_ar... [3] https://wiki.openstreetmap.org/wiki/Key:place#Populated_settlements.2C_urban [4] https://wiki.openstreetmap.org/wiki/Proposed_features/Practical_maxspeed [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Practical_maxspeed -- Fernando Trebien
Hi Joris, my understanding is that we talk about roads with road_class > 0 (highway=tertiary, secondary ... ) which go through cities. A highway=residential is rarely a better alternative for such a road but another major road going around the city (center) might be. If both are alternatives are highway=secondary the default style might select the shorter route through the city. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 16. Juli 2020 10:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Road speed through urban areas Hi, In urban areas the 'practical maxspeed' is often lower then the 'official' maxspeed because of existence of traffic lights and traffic calmers. I would rely on the intended routing basics of road_class and corresponding maxspeeds and the common usage of highway types and tagging in osm. Maybe it helps to make these roads less attractive for the routing engines to check for traffic lights. Because these are node-tags and not line-tags I don't know the exact impact. highway = residential & highway=crossing & crossing=traffic_signals {set mkgmap:road-speed=-2} highway = residential & traffic_calming=table { set mkgmap:road-speed=-1} highway = residential & access = destination { set mkgmap:road-speed=-2} Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: donderdag 16 juli 2020 09:11 Aan: Fernando Trebien <fernando.trebien@gmail.com>; Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] Road speed through urban areas Hi all, I fear I don't get the point in this discussion. My understanding is that you want a style that sets a lower road class for major roads within a city. Question is in what situation this will lead to better routing. If there is a good alternative route around the city it should already have the higher highway tag in OSM. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Greg Troxel <gdt@lexort.com> Gesendet: Donnerstag, 16. Juli 2020 01:21 An: Fernando Trebien Cc: Development list for mkgmap Betreff: Re: [mkgmap-dev] Road speed through urban areas Fernando Trebien <fernando.trebien@gmail.com> writes:
Would mapping boundary=urban [1] help solve the problem of assigning a slower estimated speed to ways within dense urban areas in routing apps such as mkgmap? [2][3] It looks like an elegant solution to this problem that would not have the same issues with verifiability that maxspeed:practical has. It is currently common only in France (see an example in Rennes [4]) and there is official data available in my area that could be imported into OSM. [5]
I don't see why drawing a line that encloses the area where you think maxspeed:practical is low is any more verifiable. You are tagging about an area where people drive slower than the speed limits, I think. So it's really the same thing. Also, maxspeed:practical is easy to verify. Drive on the road 10 times and see what the average speed you actually went is. I have lots of commuting data and someday, I will process it and see what the distributions look like. If there really are speed limits, then by all means tag them. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (8)
-
Bernhard Hiller -
Fernando Trebien -
Gerd Petermann -
Greg Troxel -
Harri Suomalainen -
Joris Bo -
muralito＠montevideo.com.uy -
Ticker Berkin