[PATCH] turn restrictions - alpha code for testing
Folks, The attached patch implements the OSM turn restriction relation as described in http://wiki.openstreetmap.org/wiki/Relation:restriction Here's an example that shows multiple relations being used at a junction http://www.openstreetmap.org/?lat=50.26386&lon=10.96498&zoom=17 JOSM shows little restriction signs but I think a lot of renderers won't show anything. Only "well formed" turn restrictions are handled - i.e. the 'from' and 'to' ways must terminate at the 'via' node. Badly formed turn restrictions will yield a (hopefully) useful error message that includes the OSM id so that you can go find the relation using JOSM, etc and fix it. Multiple 'via' members or the 'via' member being a way rather than a node are not handled. Those variants are not forbidden by the above description but not encouraged either and I don't, at this time, think there's good reason to handle them - if you believe otherwise and can present a compelling case for their inclusion, I will add support for them. The "except", "day_on/off", "hour_on/off" tags are ignored. I don't know how to express those constraints in garmin-speak. The --ignore-turn-restrictions option can be used to disable the feature. Please test and report success/failure, etc. Cheers, Mark
Mark Burton escribió:
Folks,
The attached patch implements the OSM turn restriction relation as described in
http://wiki.openstreetmap.org/wiki/Relation:restriction
Here's an example that shows multiple relations being used at a junction
http://www.openstreetmap.org/?lat=50.26386&lon=10.96498&zoom=17
JOSM shows little restriction signs but I think a lot of renderers won't show anything.
Only "well formed" turn restrictions are handled - i.e. the 'from' and 'to' ways must terminate at the 'via' node.
Badly formed turn restrictions will yield a (hopefully) useful error message that includes the OSM id so that you can go find the relation using JOSM, etc and fix it.
Multiple 'via' members or the 'via' member being a way rather than a node are not handled. Those variants are not forbidden by the above description but not encouraged either and I don't, at this time, think there's good reason to handle them - if you believe otherwise and can present a compelling case for their inclusion, I will add support for them.
The "except", "day_on/off", "hour_on/off" tags are ignored. I don't know how to express those constraints in garmin-speak.
The --ignore-turn-restrictions option can be used to disable the feature.
Please test and report success/failure, etc.
Cheers,
Mark I've tried your patch, but can't build the map. Only first relation below is known to be badly formed. GRAVE (RestrictionRelation): Turn restriction 67728 'to' way doesn't start or end at 'via' node (39,47141/-6,38059) GRAVE (RestrictionRelation): Turn restriction 65998 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 67653 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 69891 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 65999 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 67655 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 65997 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 67654 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 69105 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 69104 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 71958 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 71654 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 70233 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 76693 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 66917 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 68592 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 76692 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 73416 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 66916 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 66919 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 66918 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 67657 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 68050 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 67656 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 67659 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 67658 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 69303 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 69302 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 69301 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 74519 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 73703 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 73704 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 79086 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 69306 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 69305 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 69304 has unsupported type 'null' GRAVE (RestrictionRelation): Turn restriction 66000 has unsupported type 'null' Exception in thread "main" java.lang.NoSuchMethodError: uk.me.parabola.imgfmt.app.lbl.LBLFile.createCity(Luk/me/parabola/imgfmt/app/lbl/Region;Ljava/lang/String;)Luk/me/parabola/imgfmt/app/lbl/City; at uk.me.parabola.mkgmap.build.MapBuilder.processPOIs(MapBuilder.java:189) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:126) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:87) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:53) at uk.me.parabola.mkgmap.main.Main.processFilename(Main.java:150) at uk.me.parabola.mkgmap.CommandArgs$Filename.processArg(CommandArgs.java:329) at uk.me.parabola.mkgmap.CommandArgs.readArgs(CommandArgs.java:119) at uk.me.parabola.mkgmap.main.Main.main(Main.java:91)
Cheers Carlos
On Feb 23, 2009, at 18:04, Carlos Dávila wrote:
I've tried your patch, but can't build the map. Only first relation below is known to be badly formed. GRAVE (RestrictionRelation): Turn restriction 67728 'to' way doesn't start or end at 'via' node (39,47141/-6,38059) GRAVE (RestrictionRelation): Turn restriction 65998 has unsupported type 'null' ...
GRAVE (RestrictionRelation): Turn restriction 66000 has unsupported type 'null' Exception in thread "main" java.lang.NoSuchMethodError: uk.me.parabola.imgfmt.app.lbl.LBLFile.createCity(Luk/me/parabola/ imgfmt/app/lbl/Region;Ljava/lang/String;)Luk/me/parabola/imgfmt/app/ lbl/City; at uk.me.parabola.mkgmap.build.MapBuilder.processPOIs(MapBuilder.java: 189) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:126) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java: 87) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java: 53) at uk.me.parabola.mkgmap.main.Main.processFilename(Main.java: 150) at uk.me.parabola.mkgmap.CommandArgs $Filename.processArg(CommandArgs.java:329) at uk.me.parabola.mkgmap.CommandArgs.readArgs(CommandArgs.java:119) at uk.me.parabola.mkgmap.main.Main.main(Main.java:91)
The crash seems unrelated to the new code. Could you try 'ant clean; ant dist'? Cheers Robert
Robert Vollmert escribió:
On Feb 23, 2009, at 18:04, Carlos Dávila wrote:
GRAVE (RestrictionRelation): Turn restriction 66000 has unsupported type 'null'
This one has restriction_type=no_left_turn instead of restriction=no_left_turn which the code expects. :-[ All my relations were wrong!! Thanks for the advise. I have rebuilt mkgmap and now it works. Restrictions are correctly processed in my nuvi (not in gpsMapEdit). Great work.
Regards Carlos
First off, superb work on mkgmap and routing - my Vista HCx regularly gets new maps as new features are added! Thanks very much. At http://www.openstreetmap.org/browse/relation/79516, there is an offset crossroads where it is acceptable to approach Boroughgate from Beech Hill, but not from Manor Square. (On a "normal" crossroads, it would be acceptable to go straight on to Boroughgate, but not to turn left or right into it). The crossroad is sufficiently offset that the centre point has been added as a way rather than a node. The via part of the turn restriction is on a way, rather than a node. Either this is a reasonable example of having a way as the via part, or there is a better way for me to have added the turn restriction. Does anyone have any alternative suggestions? Alan 2009/2/23 Mark Burton <markb@ordern.com>:
Folks,
The attached patch implements the OSM turn restriction relation as described in
http://wiki.openstreetmap.org/wiki/Relation:restriction
Here's an example that shows multiple relations being used at a junction
http://www.openstreetmap.org/?lat=50.26386&lon=10.96498&zoom=17
JOSM shows little restriction signs but I think a lot of renderers won't show anything.
Only "well formed" turn restrictions are handled - i.e. the 'from' and 'to' ways must terminate at the 'via' node.
Badly formed turn restrictions will yield a (hopefully) useful error message that includes the OSM id so that you can go find the relation using JOSM, etc and fix it.
Multiple 'via' members or the 'via' member being a way rather than a node are not handled. Those variants are not forbidden by the above description but not encouraged either and I don't, at this time, think there's good reason to handle them - if you believe otherwise and can present a compelling case for their inclusion, I will add support for them.
The "except", "day_on/off", "hour_on/off" tags are ignored. I don't know how to express those constraints in garmin-speak.
The --ignore-turn-restrictions option can be used to disable the feature.
Please test and report success/failure, etc.
Cheers,
Mark
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Alan,
First off, superb work on mkgmap and routing - my Vista HCx regularly gets new maps as new features are added! Thanks very much.
Cheers!
At http://www.openstreetmap.org/browse/relation/79516, there is an offset crossroads where it is acceptable to approach Boroughgate from Beech Hill, but not from Manor Square. (On a "normal" crossroads, it would be acceptable to go straight on to Boroughgate, but not to turn left or right into it). The crossroad is sufficiently offset that the centre point has been added as a way rather than a node. The via part of the turn restriction is on a way, rather than a node.
Either this is a reasonable example of having a way as the via part, or there is a better way for me to have added the turn restriction. Does anyone have any alternative suggestions?
I have looked at that junction - interesting. The problem I have at the moment is understanding how to convert a 'via' way into a turn restriction (or, perhaps, restrictions) as understood by the gps. I shall think about this and maybe others will be able to help. It's early days for this capability. Cheers, Mark
Me again, I just looked at the satpic and I understand the layout better now. I think I would be tempted to do this: A | B | -------- | \ | \| @------ C | | | | D At @, you can have a no_left_turn that stops A->C but it won't stop B->C. The diagonal segment can be positioned/shaped as you please, perhaps like this: A | B | ----------. . . @------ C | | | | D Does that make sense? Cheers, Mark
Does that make sense?
Thanks for the suggestions. They do make sense, although a part of me thinks that it doesn't quite "feel" right. Another argument for making the centrepoint a node rather than a way is that the traffic lights at either end of the way are synced together. For all intents and purposes, it _is_ a node, albeit a long, thin one. Despite that, my preference would still be to leave it as is, for the time being. I think that we should aim to make the map data correct in the first instance. If there is a problem with routing on a particular (brand of) GPS, then that can be broached separately. Others may disagree. I'll write it up on the Wiki as has been requested. Alan
Hi Alan,
Does that make sense?
Thanks for the suggestions. They do make sense, although a part of me thinks that it doesn't quite "feel" right. Another argument for making the centrepoint a node rather than a way is that the traffic lights at either end of the way are synced together. For all intents and purposes, it _is_ a node, albeit a long, thin one.
Despite that, my preference would still be to leave it as is, for the time being. I think that we should aim to make the map data correct in the first instance. If there is a problem with routing on a particular (brand of) GPS, then that can be broached separately. Others may disagree.
Well, "correctness" is in the eye of the beholder. People have different agendas and expect different things from the map. In this situation there is a conflict between the visual look of the map and the need to express some constraint about how traffic may be routed. It seems to me that the main cause of this particular problem is the lack of support in the garmin for restrictions of the form: "don't go to point X if you came from point Y". As far as I am aware, it can only cope with "don't go to point X if you came from point Y via point Z". Where X, Y and Z are all adjacent (no other nodes between them). So, for the garmin, I am not sure that restrictions that have a Way for the 'via' member can ever be supported. Put it this way, if I knew how to implement it, I would do it anyway even if it wasn't actually very useful. Cheers, Mark
Well, "correctness" is in the eye of the beholder. People have different agendas and expect different things from the map. In this situation there is a conflict between the visual look of the map and the need to express some constraint about how traffic may be routed.
I agree. If the map was purely intended to support Garmins, with whatever limitations are in their routing functions, then I think it would be a change worth making. But another group (Tomtom, etc) might have a router that supports ways as the via, so they would be able to make the most of a map that looks good _and_ has correct routing data.
So, for the garmin, I am not sure that restrictions that have a Way for the 'via' member can ever be supported. Put it this way, if I knew how to implement it, I would do it anyway even if it wasn't actually very useful.
It'd be a real shame if it wasn't possible, even if there's only a small number of realistic cases. I wonder how the Garmin paid-for mapping solutions model the same situation? <...goes off to think about it some more...> Keep up the good work. Alan
On Feb 23, 2009, at 18:14, Alan Bowman wrote:
Either this is a reasonable example of having a way as the via part, or there is a better way for me to have added the turn restriction. Does anyone have any alternative suggestions?
It seems to be a valid use of a way for the via-role. Please document it on the wiki! On the other hand, I'm not sure Garmin maps support this directly, and I'm sure we don't know how if it's possible. Does cGPSmapper allow specifying restrictions of this type? I'd suggest mkgmap ignore this for now. Cheers Robert
That's not an offset crossroads that's 2 T junctions!!!. I'll bow to your local knowledge if you say that you can go down Boroughgate from Beech Hill but that just seems wrong to me but who are we to argue with the gods of town planning ;) Incidentally you were missing a tag in your relations. Along with the restriction, no_left_turn you also need a type,restriction tag. I've added these for you and you'll notice that in the latest versions of JOSM this now shows an icon for a turn restriction on the southern of the 2 nodes. As the northern junction is "incorrect" this does not show an icon and instead has an * next to the relation in the list of relations. Cheers Paul Alan Bowman wrote:
First off, superb work on mkgmap and routing - my Vista HCx regularly gets new maps as new features are added! Thanks very much.
At http://www.openstreetmap.org/browse/relation/79516, there is an offset crossroads where it is acceptable to approach Boroughgate from Beech Hill, but not from Manor Square. (On a "normal" crossroads, it would be acceptable to go straight on to Boroughgate, but not to turn left or right into it). The crossroad is sufficiently offset that the centre point has been added as a way rather than a node. The via part of the turn restriction is on a way, rather than a node.
Either this is a reasonable example of having a way as the via part, or there is a better way for me to have added the turn restriction. Does anyone have any alternative suggestions?
Alan
2009/2/23 Mark Burton <markb@ordern.com>:
Folks,
The attached patch implements the OSM turn restriction relation as described in
http://wiki.openstreetmap.org/wiki/Relation:restriction
Here's an example that shows multiple relations being used at a junction
http://www.openstreetmap.org/?lat=50.26386&lon=10.96498&zoom=17
JOSM shows little restriction signs but I think a lot of renderers won't show anything.
Only "well formed" turn restrictions are handled - i.e. the 'from' and 'to' ways must terminate at the 'via' node.
Badly formed turn restrictions will yield a (hopefully) useful error message that includes the OSM id so that you can go find the relation using JOSM, etc and fix it.
Multiple 'via' members or the 'via' member being a way rather than a node are not handled. Those variants are not forbidden by the above description but not encouraged either and I don't, at this time, think there's good reason to handle them - if you believe otherwise and can present a compelling case for their inclusion, I will add support for them.
The "except", "day_on/off", "hour_on/off" tags are ignored. I don't know how to express those constraints in garmin-speak.
The --ignore-turn-restrictions option can be used to disable the feature.
Please test and report success/failure, etc.
Cheers,
Mark
_______________________________________________ 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
but who are we to argue with the gods of town planning ;)
I think that there's something to do with preventing long lorries taking tight bends in the middle of the town. I haven't asked too closely, for fear that I might get a ridiculous response :-)
Incidentally you were missing a tag in your relations.
Good catch - I hadn't spotted that. That'll teach me to read the instructions a bit better next time. Cheers Alan
Nice one. I had a chance to try this today and I was no longer instructed to turn right at places where it's a no_right_turn so in my admittedly limited testing this works well. I also ran this against the great_britain.osm file and had no problems other than the obvious large number of incorrect restrictions in the raw data Paul Mark Burton wrote:
Folks,
The attached patch implements the OSM turn restriction relation as described in
http://wiki.openstreetmap.org/wiki/Relation:restriction
Here's an example that shows multiple relations being used at a junction
http://www.openstreetmap.org/?lat=50.26386&lon=10.96498&zoom=17
JOSM shows little restriction signs but I think a lot of renderers won't show anything.
Only "well formed" turn restrictions are handled - i.e. the 'from' and 'to' ways must terminate at the 'via' node.
Badly formed turn restrictions will yield a (hopefully) useful error message that includes the OSM id so that you can go find the relation using JOSM, etc and fix it.
Multiple 'via' members or the 'via' member being a way rather than a node are not handled. Those variants are not forbidden by the above description but not encouraged either and I don't, at this time, think there's good reason to handle them - if you believe otherwise and can present a compelling case for their inclusion, I will add support for them.
The "except", "day_on/off", "hour_on/off" tags are ignored. I don't know how to express those constraints in garmin-speak.
The --ignore-turn-restrictions option can be used to disable the feature.
Please test and report success/failure, etc.
Cheers,
Mark
------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Paul, Thanks for the feedback.
Nice one. I had a chance to try this today and I was no longer instructed to turn right at places where it's a no_right_turn so in my admittedly limited testing this works well.
Excellent.
I also ran this against the great_britain.osm file and had no problems other than the obvious large number of incorrect restrictions in the raw data
Yes, I think there are a lot of broken restrictions in the OSM database but, hopefully, as they are identified, they will get fixed. Cheers, Mark
participants (5)
-
Alan Bowman -
Carlos Dávila -
Mark Burton -
Paul -
Robert Vollmert