
Here is a possible patch for maxspeed. Around here lots of roads have been tagged with their speed limit (which is 60mph). However, these are unclassified roads and you are unlikely to get above 40mph. At the moment the default behaviour of mkgmap is set overide the style file for these roads and set the road class appropriate to 60mph, which is too fast. I could turn on ignore-maxspeeds which would fix these roads but in turn that would result in the trunk roads in town getting too high a speed. The patch attempts to overcome this by offerring an extra option for ignore-maxspeed, so the options become [Default] - Use maxspeed if it exists, otherwise Road Class from the style "ignore-maxspeeds" - Use road class from the style file "ignore-maxspeeds:0" - Use road class from the style file "ignore-maxspeeds:1" - Use maxspeed from the style file "ignore-maxspeeds:2" - Use the lower of road class and maxspeed Effectively option 2 solves my problem. The other numbered options are there to reproduce existing behaviour using a number. The non-numbered option is to keep compatiblity with existing code. Note: - This is the first patch I've done so I might have gone about it completely the wrong way. If so I'm sorry and please give me some hints - It is also the first Java code I've ever edited so I might have done something wrong! All I can say is that it worked for me ! Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java =================================================================== --- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (revision 1145) +++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (working copy) @@ -100,7 +100,7 @@ private final Rule nodeRules; private final Rule relationRules; - private boolean ignoreMaxspeeds; + private int ignoreMaxspeeds=1; class AccessMapping { private final String type; @@ -141,8 +141,17 @@ wayRules = style.getWayRules(); nodeRules = style.getNodeRules(); relationRules = style.getRelationRules(); - ignoreMaxspeeds = props.getProperty("ignore-maxspeeds") != null; + String ignoreMaxspeedsPar = props.getProperty("ignore-maxspeeds", null); + if(ignoreMaxspeedsPar != null){ + try { + ignoreMaxspeeds = Integer.parseInt(ignoreMaxspeedsPar); + } + catch (Exception e) { + ignoreMaxspeeds = 0; + } + } + LineAdder overlayAdder = style.getOverlays(lineAdder); if (overlayAdder != null) lineAdder = overlayAdder; @@ -903,17 +912,28 @@ } int speedIdx = -1; - if(!ignoreMaxspeeds) { - // maxspeed attribute overrides default for road type - String maxSpeed = way.getTag("maxspeed"); - if(maxSpeed != null) { - speedIdx = getSpeedIdx(maxSpeed); - log.info(debugWayName + " maxspeed=" + maxSpeed + ", speedIndex=" + speedIdx); - } + String maxSpeed; + switch(ignoreMaxspeeds) + { + case 0: + // Use the style file and ignore the maxspeed tag + road.setSpeed(gt.getRoadSpeed()); + break; + case 1: + // Use maxspeed tag, only use the style file if maxspeed is missing (the default if ignoreMaxspeeds is not defined) + maxSpeed = way.getTag("maxspeed"); + if(maxSpeed!=null) speedIdx = getSpeedIdx(maxSpeed); + road.setSpeed(speedIdx >= 0? speedIdx : gt.getRoadSpeed()); + break; + + case 2: + // Use the lower of the maxspeed tag and the style file value + maxSpeed = way.getTag("maxspeed"); + if(maxSpeed!=null) speedIdx = getSpeedIdx(maxSpeed); + road.setSpeed(speedIdx >= 0? Math.min(gt.getRoadSpeed(),speedIdx ) : gt.getRoadSpeed()); + break; } - road.setSpeed(speedIdx >= 0? speedIdx : gt.getRoadSpeed()); - boolean[] noAccess = new boolean[RoadNetwork.NO_MAX]; String highwayType = way.getTag("highway"); if(highwayType == null) {

Hi Mark, Thanks for the contribution - it sounds like a good idea. One thought, how about using words and not numbers, words are easier to interpret when you come back to them 3 months (5 minutes?) later. So you could have something like: ignore-maxspeeds (same meaning as now for compatibility but we could retire it in the future) but then have a new option that gives the flexibility you want: maxspeed=ignore (use speed defined in roadclass) maxspeed=heed (use maxspeed if defined, roadclass otherwise) maxspeed=lowest (use lowest of those speeds) maxspeed=highest (use highest of those speeds - why not?) Cheers, Mark ----------
Here is a possible patch for maxspeed.
Around here lots of roads have been tagged with their speed limit (which is 60mph). However, these are unclassified roads and you are unlikely to get above 40mph. At the moment the default behaviour of mkgmap is set overide the style file for these roads and set the road class appropriate to 60mph, which is too fast.
I could turn on ignore-maxspeeds which would fix these roads but in turn that would result in the trunk roads in town getting too high a speed.
The patch attempts to overcome this by offerring an extra option for ignore-maxspeed, so the options become
[Default] - Use maxspeed if it exists, otherwise Road Class from the style
"ignore-maxspeeds" - Use road class from the style file "ignore-maxspeeds:0" - Use road class from the style file "ignore-maxspeeds:1" - Use maxspeed from the style file "ignore-maxspeeds:2" - Use the lower of road class and maxspeed
Effectively option 2 solves my problem. The other numbered options are there to reproduce existing behaviour using a number. The non-numbered option is to keep compatiblity with existing code.
Note: - This is the first patch I've done so I might have gone about it completely the wrong way. If so I'm sorry and please give me some hints - It is also the first Java code I've ever edited so I might have done something wrong! All I can say is that it worked for me !

Mark Burton wrote:
Hi Mark,
Thanks for the contribution - it sounds like a good idea.
One thought, how about using words and not numbers, words are easier to interpret when you come back to them 3 months (5 minutes?) later. So you could have something like:
ignore-maxspeeds (same meaning as now for compatibility but we could retire it in the future)
but then have a new option that gives the flexibility you want:
maxspeed=ignore (use speed defined in roadclass) maxspeed=heed (use maxspeed if defined, roadclass otherwise) maxspeed=lowest (use lowest of those speeds) maxspeed=highest (use highest of those speeds - why not?)
Cheers,
Mark
I'll change it. The original intention was to avoid creating another option (as I'd seen some comment about "yet another option"). But I'm happy to go down that route.

Mark,
I'll change it. The original intention was to avoid creating another option (as I'd seen some comment about "yet another option"). But I'm happy to go down that route.
Personally, i'd rather see a new option added than an old option obscured! Also, if we introduce a new option to provide what you want and it is still compatible with the current functionality, we can retire the old option after a while. If we decide to do that, we can make the old option print a warning along the lines of "this option will self destruct in 7 seconds". Mark

MarkS wrote:
Mark Burton wrote:
Hi Mark,
I'll change it. The original intention was to avoid creating another option (as I'd seen some comment about "yet another option"). But I'm happy to go down that route.
Here's a revised version of the patch picking up the suggestions Mark made. This adds a new option "maxspeed". This can be set to: "ignore" - The maxspeed tag is ignored and road class from the style file is used. "heed" - The maxspeed tag is used. If it doesn't exist then road class from the style file is used "lower" - The lower of the maxspeed tag and the road class is used. "higher" - The higher of the maxspeed tag and the road class is used. If "maxspeed" isn't defined then the patch will look for ignore-maxspeed ; if ignore-maxspeed is present then it will just use the road class from the style file. This will ensure current usage isn't broken. If "maxspeed" and "ignore-maxspeed" are not defined then it will default to "heed" which reproduces current behaviour. Mark Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java =================================================================== --- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (revision 1147) +++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (working copy) @@ -101,6 +101,7 @@ private final Rule relationRules; private boolean ignoreMaxspeeds; + private String MaxspeedsPar; class AccessMapping { private final String type; @@ -143,6 +144,18 @@ relationRules = style.getRelationRules(); ignoreMaxspeeds = props.getProperty("ignore-maxspeeds") != null; + MaxspeedsPar=props.getProperty("maxspeed",null); + if(MaxspeedsPar==null){ + // If the maxspeeds parameter has not been defined then fall back to looking at the ignore-maxspeeds parameter + if(ignoreMaxspeeds){ + MaxspeedsPar="ignore"; + } + else{ + MaxspeedsPar="heed"; + } + } + MaxspeedsPar=MaxspeedsPar.toLowerCase(); + LineAdder overlayAdder = style.getOverlays(lineAdder); if (overlayAdder != null) lineAdder = overlayAdder; @@ -903,17 +916,30 @@ } int speedIdx = -1; - if(!ignoreMaxspeeds) { - // maxspeed attribute overrides default for road type - String maxSpeed = way.getTag("maxspeed"); - if(maxSpeed != null) { - speedIdx = getSpeedIdx(maxSpeed); - log.info(debugWayName + " maxspeed=" + maxSpeed + ", speedIndex=" + speedIdx); - } + String maxSpeed; + if(MaxspeedsPar.equals("ignore")){ + // Use the style file and ignore the maxspeed tag + road.setSpeed(gt.getRoadSpeed()); } + else if(MaxspeedsPar.equals("heed")){ + // Use maxspeed tag, only use the style file if maxspeed is missing + maxSpeed = way.getTag("maxspeed"); + if(maxSpeed!=null) speedIdx = getSpeedIdx(maxSpeed); + road.setSpeed(speedIdx >= 0? speedIdx : gt.getRoadSpeed()); + } + else if(MaxspeedsPar.equals("lower")){ + // Use the lower of the maxspeed tag and road class from the style file + maxSpeed = way.getTag("maxspeed"); + if(maxSpeed!=null) speedIdx = getSpeedIdx(maxSpeed); + road.setSpeed(speedIdx >= 0? Math.min(gt.getRoadSpeed(),speedIdx ) : gt.getRoadSpeed()); + } + else if(MaxspeedsPar.equals("higher")){ + // Use the higher of the maxspeed tag and the style file value + maxSpeed = way.getTag("maxspeed"); + if(maxSpeed!=null) speedIdx = getSpeedIdx(maxSpeed); + road.setSpeed(speedIdx >= 0? Math.max(gt.getRoadSpeed(),speedIdx ) : gt.getRoadSpeed()); + } - road.setSpeed(speedIdx >= 0? speedIdx : gt.getRoadSpeed()); - boolean[] noAccess = new boolean[RoadNetwork.NO_MAX]; String highwayType = way.getTag("highway"); if(highwayType == null) {

MarkS <OSM@redcake.co.uk> writes:
This adds a new option "maxspeed". This can be set to:
"ignore" - The maxspeed tag is ignored and road class from the style file is used. "heed" - The maxspeed tag is used. If it doesn't exist then road class from the style file is used "lower" - The lower of the maxspeed tag and the road class is used. "higher" - The higher of the maxspeed tag and the road class is used.
If "maxspeed" isn't defined then the patch will look for ignore-maxspeed ; if ignore-maxspeed is present then it will just use the road class from the style file. This will ensure current usage isn't broken.
If "maxspeed" and "ignore-maxspeed" are not defined then it will default to "heed" which reproduces current behaviour.
This all makes sense, but it seems that the real problem needs to be solved at the database semantics level. Patching it up in mkgmap certainly is useful, but other routing engines should have a consistent view. I think we're really talking about "given a .osm file and a particular way, how do you decide what speed you should assume one can drive on that way".

With this maxspeed debate, aren't we confusing two different data items.? maxspeed is defined as the legal speed limit, but the speed we are discussing here is an average transit speed for routing purposes. The 'real' maxspeed would be useful in applications like excessive speed warning, or notification of changes to the limit while in transit, even (on the future) as a physical limit for automated vehicles; as the average transit speed is a different value and is what is needed for routing Shouldn't a separate data item (eg "routingspeed") be used, leaving maxspeed for what it is, the legal limit?

WessexMario wrote:
With this maxspeed debate, aren't we confusing two different data items.?
maxspeed is defined as the legal speed limit, but the speed we are discussing here is an average transit speed for routing purposes.
The 'real' maxspeed would be useful in applications like excessive speed warning, or notification of changes to the limit while in transit, even (on the future) as a physical limit for automated vehicles; as the average transit speed is a different value and is what is needed for routing
Shouldn't a separate data item (eg "routingspeed") be used, leaving maxspeed for what it is, the legal limit? Agreed. I suggested early that perhaps this option would be better labelled "speed" rather than "maxspeed". However, routingspeed is probably more specfic and might be even better.

On Fri, 2009-08-28 at 07:43 +0100, WessexMario wrote:
With this maxspeed debate, aren't we confusing two different data items.?
maxspeed is defined as the legal speed limit, but the speed we are discussing here is an average transit speed for routing purposes.
The 'real' maxspeed would be useful in applications like excessive speed warning, or notification of changes to the limit while in transit, even (on the future) as a physical limit for automated vehicles; as the average transit speed is a different value and is what is needed for routing
Shouldn't a separate data item (eg "routingspeed") be used, leaving maxspeed for what it is, the legal limit?
Do we even need a tag for this when we can just glean it from the GPX traces now that folks uploading traces can choose to keep speed data in tact?

Greg Troxel wrote:
This all makes sense, but it seems that the real problem needs to be solved at the database semantics level. Patching it up in mkgmap certainly is useful, but other routing engines should have a consistent view. I think we're really talking about "given a .osm file and a particular way, how do you decide what speed you should assume one can drive on that way".
I agree with the principle. However, I guess a limitation on mkgmap routing is that mkgmap doesn't do the routing it supplies that data to garmin who do the routing. We can affect the data going in but not the routing algorithms. I was testing yesterday and road speed doesn't seem to make much difference to mapsource routes. Mapsource seems to follow the road class (set in preferences) and only allows speed to affect the route if it makes a major difference. However, this patch doesn't really attempt to provide a calculation of the correct speed. All it tries to do is make it more flexible to choose what method mkgmap uses to set the road speed attribute. In its current form it provides four options (which compares with the two we have available at the moment). If this patch were added we could add extra methods in the future. For example last night I added an extra option for a new method to calculate the speed which took 90% of maxspeed, unless it was a single track road in which case it took 60%. I could easily try this alternative method by using "maxspeed=MarkS". I don't pretend this new method is any good and I don't see much point in showing this extra code off. But what this method did show was that having "maxpseed=xxxx" allows extra methods to be added easily. If maxspeed patch is added then a future job is to come up with better speed algorithms.

MarkS wrote:
Greg Troxel wrote:
This all makes sense, but it seems that the real problem needs to be solved at the database semantics level.
I agree with the principle. However, I guess a limitation on mkgmap routing is that mkgmap doesn't do the routing it supplies that data to garmin who do the routing. We can affect the data going in but not the routing algorithms. I was testing yesterday and road speed doesn't seem to make much difference to mapsource routes. Mapsource seems to follow the road class (set in preferences) and only allows speed to affect the route if it makes a major difference.
I see two separate problems here: One is how to indicate to a routing engine what the likely speed for a way is. The second is, for a given routing engine, how to actually achieve passing that data. I'm with Grex Troxel and the others in thinking that "maxspeed=" should reflect the legal limit. I can see numerous cases in my area however where the likely speed of a route is *way* lower than that, and we need a way to flag it. Someone suggested "routingspeed=" which sounds fine to me. Let's try and remember that we shouldn't try to munge OSM's data to suit the Garmin routing engines. There are other routers with OSM support (Android GSM-equipped phones for instance). I got caught in the trap of "adapting" OSM to suit my Streetpilot before a friend with an Android pointed out that it was causing his unit to issue silly driving instructions. We certainly shouldn't muck about with "maxspeed=". How do we go about getting "routingspeed=" adoped? We presumably also adopt a standing rule along the lines of "default routingspeed is 80% of maxspeed if 'routingspeed=' isn't stated" or something like that. Anyone got a better default rule? Steve

Mark Burton schreef:
but then have a new option that gives the flexibility you want:
maxspeed=ignore (use speed defined in roadclass) maxspeed=heed (use maxspeed if defined, roadclass otherwise) maxspeed=lowest (use lowest of those speeds) maxspeed=highest (use highest of those speeds - why not?)
Because it's against the law? ;-) I would say: maxspeed=roadclass (or default?) maxspeed=maxspeed (which falls back to roadclass?) maxspeed=lowest maxspeed=highest Or maybe "speed=" if you think "maxspeed=maxspeed" is confusing. (I don't know if all roads exactly need a maximum speed, or if it possible to have a road without a maximum - in which case "speed=ignore" could be an extra option). V. -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579

On Wed, Aug 26, 2009 at 04:37:37PM +0100, MarkS wrote:
Here is a possible patch for maxspeed.
Around here lots of roads have been tagged with their speed limit (which is 60mph). However, these are unclassified roads and you are unlikely to get above 40mph. At the moment the default behaviour of mkgmap is set overide the style file for these roads and set the road class appropriate to 60mph, which is too fast.
I could turn on ignore-maxspeeds which would fix these roads but in turn that would result in the trunk roads in town getting too high a speed.
The patch attempts to overcome this by offerring an extra option for ignore-maxspeed, so the options become
Wouldnt it make sense to make it possible to apply factors based on road class to the maxspeed setting? e.g unclassified -> maxspeed*0.6 tertiary -> maxspeed*0.8 OTOH this should all be the responsibility of the routing engine and at the moment as i understand we abuse the maxspeed (OSM) to set an "average speed" in the Garmin dataset - not something like a speed limit which is obviously broken anyway and just some idea to make use of the maxspeed ... Flo -- Florian Lohoff flo@rfc822.org "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

Florian Lohoff wrote:
Wouldnt it make sense to make it possible to apply factors based on road class to the maxspeed setting?
e.g unclassified -> maxspeed*0.6 tertiary -> maxspeed*0.8
OTOH this should all be the responsibility of the routing engine and at the moment as i understand we abuse the maxspeed (OSM) to set an "average speed" in the Garmin dataset - not something like a speed limit which is obviously broken anyway and just some idea to make use of the maxspeed ...
I'd come across this whilst setting up the patch. The main road near me has maxspeed=50mph on it. This then gets converted to kilometers and just scrapes over the 80kph barrier and gets a road class of 5 which effectively assumes you will never drop below the speed limit. My feeling was that there might be a case for another patch which reduces the maxspeed by a certain amount (eg. 5mph or by 20%) when deciding which road class to allocate. This probably needs (yet) another parameter. My patch isn't really concerned with how the maxspeed tag is converted to a road class. It is aimed at deciding whether to use set the road class from the style file, the maxspeed tag (however that is translated to road class) or both.

Hello, as I said some months ago, deciding the right speed to set in the garmin map for each way shoud be a new mkgmap function. The function should take into consideration: the assigned OSM highway tag the assigned OSM maxspeed the number of crosses per km (maybe the number of routing nodes / lenght) the number of traffic_lights per km the curves ((for each node, add the angle) / lenght)) .... All these info shoud be properly combined to tell how fast a vehicle can run on that road. We should experiment a lot... But maybe this is too far away ;-) Ciao, Marco.

Marco Certelli wrote:
Hello,
as I said some months ago, deciding the right speed to set in the garmin map for each way shoud be a new mkgmap function.
The function should take into consideration:
the assigned OSM highway tag the assigned OSM maxspeed the number of crosses per km (maybe the number of routing nodes / lenght) the number of traffic_lights per km the curves ((for each node, add the angle) / lenght)) ....
All these info shoud be properly combined to tell how fast a vehicle can run on that road. We should experiment a lot...
But maybe this is too far away ;-)
Ciao, Marco. I agree with this. We have a level crossing near us where the barriers are down for around 2-3 minutes and are down around 10 times an hour. At the moment routing always goes across the crossing rather than using an alternative route (which takes about 30 seconds longer but which would be quicker on average).
I do have doubts how it work in practice. In practice the average speed of a road comes from a mix of fast sections (ie. plain road) and slow sections (junctions, lights...). Whilst we can count crossings/traffic lights along a road and get the overall speed for the road right, it doesn't work so well if you turn on/off along the road. This patch allows you to switch the methods used to set the road speed in the IMG file. At the moment it simply switches between maxpseed and the style file setting. However, it would be easier to include an extra option (eg. "MarcosMethod") to offer extra options if somebody wants to write it. Maybe it would be better to change the option in the patch from "maxspeed" to "speed".
participants (9)
-
Florian Lohoff
-
Greg Troxel
-
Marco Certelli
-
Mark Burton
-
MarkS
-
Paul Johnson
-
Steve Hosgood
-
Valentijn Sessink
-
WessexMario