Restriction relations and additional (cycle) ways
Hi, the via-ways branch is almost done, but I wonder what to do when make-opposite-cycleways is used or when the style creates multiple routable lines for one OSM way. The Garmin format for restrictions reqires nodes and arcs. The OSM format specifies from and to ways and via nodes or ways. Assume that a via way of an only_left restriction has also an opposite cycleway. Should mkgmap create all possible combinations of restrictions to make sure that also bicycles are only routed left ? Or should it make sure that the bicycle ways are not affected? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Restriction-relations-and-additional-cycle-wa... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, I just noticed that I forgot the existence of the except tag and that mkgmap only supports type=restriction relations, not something type=restriction:bicycle. So, I have to do some more coding... Gerd GerdP wrote
Hi,
the via-ways branch is almost done, but I wonder what to do when make-opposite-cycleways is used or when the style creates multiple routable lines for one OSM way. The Garmin format for restrictions reqires nodes and arcs. The OSM format specifies from and to ways and via nodes or ways. Assume that a via way of an only_left restriction has also an opposite cycleway. Should mkgmap create all possible combinations of restrictions to make sure that also bicycles are only routed left ? Or should it make sure that the bicycle ways are not affected?
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/Restriction-relations-and-additional-cycle-wa... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On Sat, Mar 29, 2014 at 08:05:15AM -0700, GerdP wrote:
the via-ways branch is almost done
I just cloned and built it, and already addressed one error message that it emitted (redundant turn restriction, prohibiting turn against oneway direction). In the same crossing, there was a wrong turn restriction that an automated check might detect too: \ ---->---- (oneway) \ On a crossing like this, there is a very sharp turn (135 degrees to right from the diagonal road to the horizontal road), and the turn restriction said no_left_turn. I guess it should have said no_right_turn. I changed it to only_straight_on (role=from and role=to being the diagonal road). Marko
On Sat, Mar 29, 2014 at 08:49:53PM +0200, Marko Mäkelä wrote:
On Sat, Mar 29, 2014 at 08:05:15AM -0700, GerdP wrote:
the via-ways branch is almost done
I just cloned and built it, and already addressed one error message that it emitted (redundant turn restriction, prohibiting turn against oneway direction).
In the same crossing, there was a wrong turn restriction that an automated check might detect too:
\ ---->---- (oneway) \
On a crossing like this, there is a very sharp turn (135 degrees to right from the diagonal road to the horizontal road), and the turn restriction said no_left_turn. I guess it should have said no_right_turn. I changed it to only_straight_on (role=from and role=to being the diagonal road).
Maybe the patch is actually trying to address the above situation. The above case was version 1 in http://www.openstreetmap.org/relation/2350374/history I think that the new code is generating noise for a U-shaped oneway "handles" on major twoway roads (a parking lane for making a break, only accessible from one direction of travelling). Here is an example: 2014/03/29 19:56:21 SEVERE (RoadNetwork): 63240005.osm.pbf: Turn restriction http://www.openstreetmap.org/browse/relation/298645 (at http://www.openstreetmap.org/?mlat=61.346723&mlon=26.206187&zoom=17) check special case from = to arc 2014/03/29 19:56:21 SEVERE (RouteNode): 63240005.osm.pbf: check: old code would have selected wrong arc from road 42859595 instead of road 32485453 2014/03/29 19:56:21 SEVERE (RoadNetwork): 63240005.osm.pbf: Turn restriction http://www.openstreetmap.org/browse/relation/298646 (at http://www.openstreetmap.org/?mlat=61.346238&mlon=26.204694&zoom=17) check special case from = to arc These two relations are forbidding a U-turn via this "handle". I agree that it is more intuitive to map this with only_straight_on, but at the same time I think that this should only be a WARNING, not SEVERE. I will be replacing this kind of situations with only_straight_on, and I think that a WARNING is OK. But, I think that mkgmap should generate the same routing graph with only_straight_on and no_*_turn (with different role=to ways, of course). Marko
Hi Marko, Marko Mäkelä wrote
I think that the new code is generating noise for a U-shaped oneway "handles" on major twoway roads (a parking lane for making a break, only accessible from one direction of travelling). Here is an example:
when the message contains the word check it is for me. It means that I plan to verify that mkgmap does the right thing. I'll remove them later. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Restriction-relations-and-additional-cycle-wa... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On Sun, Mar 30, 2014 at 04:45:35AM -0700, GerdP wrote:
Hi Marko,
Marko Mäkelä wrote
I think that the new code is generating noise for a U-shaped oneway "handles" on major twoway roads (a parking lane for making a break, only accessible from one direction of travelling). Here is an example:
when the message contains the word check it is for me. It means that I plan to verify that mkgmap does the right thing. I'll remove them later.
OK. But, like I said, a warning for this would be nice. The only_* looks better in JOSM and I suppose is easier to understand too, than the no_*. Here is one more strange message (no_u_turn with a via way). I see nothing wrong with the way: 2014/03/29 19:56:21 WARNING (RestrictionRelation): 63240005.osm.pbf: can't add restriction relation 532033 type no_u_turn Maybe the two oneway lanes of the road were merged to other ways, so that in the mkgmap routing graph, the two oneways and the via way form a loop of three ways? But still, the no_u_turn should make sense. Relations with access tags can sometimes be hard to understand, such as relation 2996233, which is type=no_u_turn, motor_vehicle=destination. I think that it would be better to avoid turn restrictions and tag the ways instead. That could be done in this case too. I will ask the mapper, because the role=to way looks like a stub. Marko
Hi Marko,
Here is one more strange message (no_u_turn with a via way). I see nothing wrong with the way:
2014/03/29 19:56:21 WARNING (RestrictionRelation): 63240005.osm.pbf: can't add restriction relation 532033 type no_u_turn
If I get that right the via way is a oneway going into the wrong direction.
Relations with access tags can sometimes be hard to understand, such as relation 2996233, which is type=no_u_turn, motor_vehicle=destination.
I think that it would be better to avoid turn restrictions and tag the ways instead. That could be done in this case too. I will ask the mapper, because the role=to way looks like a stub.
yes, I think mkgmap should try to detect unclear cases and ignore those restrictions. Gerd
GerdP wrote
If I get that right the via way is a oneway going into the wrong direction.
forget that, I was mislead by the OSM renderer. It is probably an error in the branch. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Restriction-relations-and-additional-cycle-wa... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On Sun, Mar 30, 2014 at 05:11:43AM -0700, GerdP wrote:
GerdP wrote
If I get that right the via way is a oneway going into the wrong direction.
forget that, I was mislead by the OSM renderer. It is probably an error in the branch.
No, it was wrong. I moved the relation "one step further" in the crossing. Marko
On Sun, Mar 30, 2014 at 02:05:08PM +0200, Gerd Petermann wrote:
If I get that right the via way is a oneway going into the wrong direction.
Oh, you are of course right. I will move the restriction to the proper ways.
yes, I think mkgmap should try to detect unclear cases and ignore those restrictions.
IMO, mkgmap should not silently ignore anything. We should generate a warning too. BTW, one more case that I do not know if you are handling yet: Issue a warning if the result would not be any different if the turn restriction did not exist. This is not only about oneway direction. For example, if there is only_straight_on on a road with no junction, a warning should be issued. BTW, I accidentally loaded a relation somewhere in Russia and downloaded the surroundings. There were lots of no_u_turn on every crossing of a major road. That kind of micro-mapping does not exist over here; I guess that mappers expect people to apply common sense and not make a u-turn as soon as the navigator suggests it, no matter what. I think that no_u_turn restrictions are somewhat a matter of a local convention. In the US it is common to forbid left turns and U-turns except in a few junctions. In Finland, that practice only exists on some major through-routes in cities. Marko
Hi Marko,
IMO, mkgmap should not silently ignore anything. We should generate a warning too.
BTW, one more case that I do not know if you are handling yet: Issue a warning if the result would not be any different if the turn restriction did not exist. This is not only about oneway direction. For example, if there is only_straight_on on a road with no junction, a warning should be issued.
Sure, whenever a restriction is ignored there should be a reasonable explanation.
BTW, I accidentally loaded a relation somewhere in Russia and downloaded the surroundings. There were lots of no_u_turn on every crossing of a major road. That kind of micro-mapping does not exist over here; I guess that mappers expect people to apply common sense and not make a u-turn as soon as the navigator suggests it, no matter what.
I think that no_u_turn restrictions are somewhat a matter of a local convention. In the US it is common to forbid left turns and U-turns except in a few junctions. In Finland, that practice only exists on some major through-routes in cities.
AFAIK we have no no_u_turn restrictions in Germany, so for me they all look obsolete ;-) Gerd
On Sun, Mar 30, Gerd Petermann wrote:
I think that no_u_turn restrictions are somewhat a matter of a local convention. In the US it is common to forbid left turns and U-turns except in a few junctions. In Finland, that practice only exists on some major through-routes in cities.
AFAIK we have no no_u_turn restrictions in Germany, so for me they all look obsolete ;-)
Not sure, we have the sign 272, and combined with a traffic light allowing left turns this is in my opinion a no_u_turn restriction. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
On Sun, Mar 30, 2014 at 02:34:07PM +0200, Gerd Petermann wrote:
BTW, I accidentally loaded a relation somewhere in Russia and downloaded the surroundings. There were lots of no_u_turn on every crossing of a major road. That kind of micro-mapping does not exist over here; I guess that mappers expect people to apply common sense and not make a u-turn as soon as the navigator suggests it, no matter what.
I found an example of this in Finland. IMO, these relations should simply be ignored, maybe emitting a NOTE or INFO (not WARNING): 2014/04/01 08:03:24 SEVERE (RoadNetwork): 63240002.osm.pbf: Turn restriction http://www.openstreetmap.org/browse/relation/1785864 (at http://www.openstreetmap.org/?mlat=60.224055&mlon=24.995477&zoom=17) check special case from = to arc Normally the navigator should not generate routes where you do a U-turn like this. Even if it did, the driver should know to make the U-turn at the next convenient place where it is both practical and not forbidden. Marko
Hi Marko, just to make sure: The example shows a no_u_turn restriction where "from" way and "to" way are equal and a via node is used. Are that the criteria which should tell mkgmap to emit an info and ignore the restriction? Why not a warning? I'd say all correct restriction relations which are ignored should produce a warning. Gerd
Date: Tue, 1 Apr 2014 16:10:52 +0300 From: marko.makela@iki.fi To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Turn restriction angle checks
On Sun, Mar 30, 2014 at 02:34:07PM +0200, Gerd Petermann wrote:
BTW, I accidentally loaded a relation somewhere in Russia and downloaded the surroundings. There were lots of no_u_turn on every crossing of a major road. That kind of micro-mapping does not exist over here; I guess that mappers expect people to apply common sense and not make a u-turn as soon as the navigator suggests it, no matter what.
I found an example of this in Finland. IMO, these relations should simply be ignored, maybe emitting a NOTE or INFO (not WARNING):
2014/04/01 08:03:24 SEVERE (RoadNetwork): 63240002.osm.pbf: Turn restriction http://www.openstreetmap.org/browse/relation/1785864 (at http://www.openstreetmap.org/?mlat=60.224055&mlon=24.995477&zoom=17) check special case from = to arc
Normally the navigator should not generate routes where you do a U-turn like this. Even if it did, the driver should know to make the U-turn at the next convenient place where it is both practical and not forbidden.
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hallo Gerd, On Tue, Apr 01, 2014 at 03:54:14PM +0200, Gerd Petermann wrote:
just to make sure: The example shows a no_u_turn restriction where "from" way and "to" way are equal and a via node is used.
Are that the criteria which should tell mkgmap to emit an info and ignore the restriction?
Why not a warning? I'd say all correct restriction relations which are ignored should produce a warning.
Yes, this is a restriction=no_u_turn, with the same way in role=to and role=from, and one of the way endpoints being the role=via node. You are right, it could be a warning as well. The warning message should mention the restriction type and that the from,to ways are equal. The warning could then be filtered out with a grep -vf script (as long as it is for restriction=no_u_turn), or the map data could be reviewed and edited, possibly after consulting the mapper, the wiki, or the applicable 'authorities'. Marko PS: Yesterday and today I addressed most warnings from via-ways -r3143 for Finland. Tomorrow it should complain very little. I left this no_u_turn relation unchanged.
Hi Gerd, IMO it should goes like that: - Each duplication of a road should duplicate restrictions. - Any modification of access flags for original or duplicated roads should be performed accordingly on restrictions. - Redundant restrictions should be removed, this can happen because of changes in access flags or when restriction goes wrong-way.
Assume that a via way of an only_left restriction has also an opposite cycleway. Should mkgmap create all possible combinations of restrictions to make sure that also bicycles are only routed left ?
I don't understand this problem. If OSM restriction "only_left_turn" include bicycle, then you should create Garmin restrictions to route bicycles too. I see your next post, will processing of restriction:bicycle solve this question? -- Best regards, Andrzej
Hi Andrzej,
IMO it should goes like that: - Each duplication of a road should duplicate restrictions. - Any modification of access flags for original or duplicated roads should be performed accordingly on restrictions. - Redundant restrictions should be removed, this can happen because of changes in access flags or when restriction goes wrong-way.
Yes, that's what it should do.
Assume that a via way of an only_left restriction has also an opposite cycleway. Should mkgmap create all possible combinations of restrictions to make sure that also bicycles are only routed left ?
I don't understand this problem. If OSM restriction "only_left_turn" include bicycle, then you should create Garmin restrictions to route bicycles too.
correct. As I said in my next post, I forgot that the mapper can specify to which vehicles the restriction applies. My fear is that I can have multiple arcs for each part (from,via,to) of a restriction relation. If the restriction applies to cars and bicycles and all arcs allow traffic for both of them, I have to add various combinations of arcs. I don't know if this happens, I assume that style developpers are NOT creating duplicate arcs which allow the same vehicles. The make-opposite-cycleways option adds a cycleway and forbids traffic for bicycles on the normal road. I think I should be able to create a reasonable amount of restriction for that.
I see your next post, will processing of restriction:bicycle solve this question?
Yes, this and the except=* tag. I just have to add code to support type=restriction:* tags. Gerd
participants (5)
-
Andrzej Popowski -
Gerd Petermann -
GerdP
-
Marko Mäkelä -
Thorsten Kukuk