Reduce road class/speed when road is narrow
I want to dissuade my gps from using very narrow roads (for car routing) so one way of doing that is to reduce the road class and/or speed if the road is narrower than some threshold. I can easily imagine how to do that in mkgmap using some new Java code but I suspect that it could be done using style rules (of which I know nothing). Is that possible? Thanks, Mark
On Oct 12, 2009, at 17:12, Mark Burton wrote:
I want to dissuade my gps from using very narrow roads (for car routing) so one way of doing that is to reduce the road class and/or speed if the road is narrower than some threshold. I can easily imagine how to do that in mkgmap using some new Java code but I suspect that it could be done using style rules (of which I know nothing). Is that possible?
I suspect you could do it with something like the following: highway= primary & (width=narrow | width < 2 | est_width < 2) [0x04 road_class=2 road_speed=3 resolution 20] highway=primary [0x03 road_class=3 road_speed=4 resolution 19] (This would demote a primary road to the equivalent of a secondary.) I, however have not tested this, so I cannot confirm if this would work. Cheers.
Hi Clinton, Thanks for the response.
I suspect you could do it with something like the following:
highway= primary & (width=narrow | width < 2 | est_width < 2) [0x04 road_class=2 road_speed=3 resolution 20]
highway=primary [0x03 road_class=3 road_speed=4 resolution 19]
(This would demote a primary road to the equivalent of a secondary.) I, however have not tested this, so I cannot confirm if this would work.
It probably has to cope with widths that have either m or ft suffix (I have also seen widths in the UK as 6'6" !). Can the style file hack that? Cheers, Mark
2009/10/13 Mark Burton <markb@ordern.com>:
It probably has to cope with widths that have either m or ft suffix (I have also seen widths in the UK as 6'6" !). Can the style file hack that?
This, of course, is why units really suck in fields that could so easily be strictly numeric... Dermot -- -------------------------------------- Iren sind menschlich
Hi Dermot,
It probably has to cope with widths that have either m or ft suffix (I have also seen widths in the UK as 6'6" !). Can the style file hack that?
This, of course, is why units really suck in fields that could so easily be strictly numeric...
The OSM wiki says: Describes the width of a way or other map feature. The unit is meters unless otherwise specified. Why didn't they say "the unit is meters" and leave it at that. Completely mad. Cheers, Mark
2009/10/13 Mark Burton <markb@ordern.com>:
The OSM wiki says:
Describes the width of a way or other map feature. The unit is meters unless otherwise specified.
Why didn't they say "the unit is meters" and leave it at that. Completely mad.
Many such keys did indeed in the past indicate that values were to be in m, km/h and other internationally-standard measures. But "it's a wiki" and the docs often change... Dermot -- -------------------------------------- Iren sind menschlich
Mark Burton wrote:
The OSM wiki says:
Describes the width of a way or other map feature. The unit is meters unless otherwise specified.
Why didn't they say "the unit is meters" and leave it at that. Completely mad.
Agreed - we've got the worst possible scenario currently. What *should* have been done IMHO is that the OSM editor software (potlatch, JOSM, maybe others) could have allowed for widths and heights and speed-limit to be input in silly units, but that they would be converted locally, and be submitted to OSM in SI units as you might expect. Users could then be able to set 'preferences' for their editor software's default behaviour (and then to forget about it), and no-one dealing with OSM data downstream would ever know that they'd originally entered the height limit in cubits, or the weight limit in short tons or the speed limit in furlongs per microfortnight! :-) Such a change to OSM's database and the editor tools could still be accomplished with a bit of effort, with a robot written to trawl existing data and rewrite it to SI units. ( Please note that speed-limits should be in m/s if you're being pedantically SI-compliant, and weight limits in kg, not tonnes. ) Steve PS: Some US users might well have been entering weight limits in the "wrong" ton(ne)s already, though the percentage difference between long tons and tonnes is only slight. What sort of tons do they put on US bridge weight limits warning signs anyway?
Steve Hosgood wrote:
PS: Some US users might well have been entering weight limits in the "wrong" ton(ne)s already, though the percentage difference between long tons and tonnes is only slight. What sort of tons do they put on US bridge weight limits warning signs anyway?
It is unlikely that the numbers you see written for weight limits on bridges in different countries are in any way related as different building codes are used, and they define the weight limits differently. An imperfect world.
Garvan & maew wrote:
Steve Hosgood wrote:
PS: Some US users might well have been entering weight limits in the "wrong" ton(ne)s already, though the percentage difference between long tons and tonnes is only slight. What sort of tons do they put on US bridge weight limits warning signs anyway?
It is unlikely that the numbers you see written for weight limits on bridges in different countries are in any way related as different building codes are used, and they define the weight limits differently. An imperfect world.
Fair point. Steve.
Hi Mark
It probably has to cope with widths that have either m or ft suffix (I have also seen widths in the UK as 6'6" !). Can the style file hack that?
All the inequality tests use the ValueWithUnit class that is intended to deal with things like that. There is no real implementation of the idea, apart from attempting to separate the number from the value. As for 6'6", unsurprisingly the current code wouldn't deal with it as is! ..Steve
Steve Ratcliffe wrote:
Hi Mark
It probably has to cope with widths that have either m or ft suffix (I have also seen widths in the UK as 6'6" !). Can the style file hack that?
All the inequality tests use the ValueWithUnit class that is intended to deal with things like that. There is no real implementation of the idea, apart from attempting to separate the number from the value.
As for 6'6", unsurprisingly the current code wouldn't deal with it as is!
Just as a note if someone would implement code to change current behaviour here, not only do it for m/foot km/miles but also other similar like %/° for inclinations, all of this is currently a big mess in OSM.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (7)
-
Clinton Gladstone -
Dermot McNally -
Felix Hartmann -
Garvan & maew -
Mark Burton -
Steve Hosgood -
Steve Ratcliffe