r3165 in via_ways branch

Hi all, I think r3165 is ready for a deeper test. Changes compared to trunk: - handling of RouteRestrictions was mostly rewritten to make sure that mkgmap doesn't write wrong restrictions to the img file (this was possible when different roads connected the same points with direct arcs) - added support for restrictions with one via way (see below) - added support for tag type=restriction:* , e.g. type=restriction:motorcar - added support for tag restrection:*=<turn> , e.g. restriction:motorcar=only_left_turn - added support for no_entry and no_exit restrictions - improved log messages for invalid or possibly obsolete restriction relations Reg. via ways: According to NodCheck in the display tool the data written by mkgmap r3165 is correct, but I found no effect on routing :-( Up to now mkgmap adds a 4 node restriction to both end points of the via way. Maybe there is a bit in a header which has to be (un)set, but I can't find any. Multiple via ways are not yet supported, but partly verified to be correct. Maybe I'll look at that when we see an effect on routing for a single via way. @Steve: Do you see any effect of them in your maps? If yes, what might be wrong with the data written by mkgmap? Gerd

Hi Gerd, I haven't really understood what the via ways branch is doing... Could you explain it again? Is it only about restrictions? What could really improve the maps for me would be short invisible short via ways on all intersections in order to reduce the turn angle... So instead of | | -----|------ | | make every intersection (on those places where the angle is over 60°) look like | / | \ -----|------ \ | / | Basically building short invisible via ways (if invisible routing lines are not what this is about, then just give a style/command option possiblity to define the type and then set it invisible in the typfile) for routing (basically the same as highway junctions are in reality, just smaller but serving the purpose of having no sharp turn angle). I'm pretty sure this would improve routing a lot for my maps, but this is only an assumption as I cannot build large maps to try it out... (the via ways should'nt be straight as in the above example but of course round to minimize the angle. Length of 10m is long enough - so make em consist of 3-4 points). On 03.04.2014 09:28, Gerd Petermann wrote:
Hi all,
I think r3165 is ready for a deeper test. Changes compared to trunk: - handling of RouteRestrictions was mostly rewritten to make sure that mkgmap doesn't write wrong restrictions to the img file (this was possible when different roads connected the same points with direct arcs) - added support for restrictions with one via way (see below) - added support for tag type=restriction:* , e.g. type=restriction:motorcar - added support for tag restrection:*=<turn> , e.g. restriction:motorcar=only_left_turn - added support for no_entry and no_exit restrictions - improved log messages for invalid or possibly obsolete restriction relations
Reg. via ways: According to NodCheck in the display tool the data written by mkgmap r3165 is correct, but I found no effect on routing :-( Up to now mkgmap adds a 4 node restriction to both end points of the via way. Maybe there is a bit in a header which has to be (un)set, but I can't find any. Multiple via ways are not yet supported, but partly verified to be correct. Maybe I'll look at that when we see an effect on routing for a single via way.
@Steve: Do you see any effect of them in your maps? If yes, what might be wrong with the data written by mkgmap?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

Hi Felix, the via_ways branch tries to implement the information that is stored in restriction relations: http://wiki.openstreetmap.org/wiki/Relation:restriction The Garmin format also has a so called "route restriction". It allows to say something like "if you come from node n1 travaling on arc a1 to point n2, you are not allowed to travel on to point n3 via arc a2. The so called 4 node restriction is similar : if you come from n1 on a1 via n2 and n3 on arc a2 you are not allowed to continue to n4 on arc a3. So, it has nothing to do with invisible ways. What you are asking for is an algo similar to that for the --adjust-turn-headings option. I don't think that we really need invisible ways for that, it should be enough to manipulate the angle between the roads which is stored in the img file. My understanding of the Garmin algo is that it doesn't like sharp angles, so I am pretty sure that the angle has an effect on routing. I'll do a few experiments with that. Gerd Date: Thu, 3 Apr 2014 10:42:57 +0200 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] r3165 in via_ways branch Hi Gerd, I haven't really understood what the via ways branch is doing... Could you explain it again? Is it only about restrictions? What could really improve the maps for me would be short invisible short via ways on all intersections in order to reduce the turn angle... So instead of | | -----|------ | | make every intersection (on those places where the angle is over 60°) look like | / | \ -----|------ \ | / | Basically building short invisible via ways (if invisible routing lines are not what this is about, then just give a style/command option possiblity to define the type and then set it invisible in the typfile) for routing (basically the same as highway junctions are in reality, just smaller but serving the purpose of having no sharp turn angle). I'm pretty sure this would improve routing a lot for my maps, but this is only an assumption as I cannot build large maps to try it out... (the via ways should'nt be straight as in the above example but of course round to minimize the angle. Length of 10m is long enough - so make em consist of 3-4 points). On 03.04.2014 09:28, Gerd Petermann wrote: Hi all, I think r3165 is ready for a deeper test. Changes compared to trunk: - handling of RouteRestrictions was mostly rewritten to make sure that mkgmap doesn't write wrong restrictions to the img file (this was possible when different roads connected the same points with direct arcs) - added support for restrictions with one via way (see below) - added support for tag type=restriction:* , e.g. type=restriction:motorcar - added support for tag restrection:*=<turn> , e.g. restriction:motorcar=only_left_turn - added support for no_entry and no_exit restrictions - improved log messages for invalid or possibly obsolete restriction relations Reg. via ways: According to NodCheck in the display tool the data written by mkgmap r3165 is correct, but I found no effect on routing :-( Up to now mkgmap adds a 4 node restriction to both end points of the via way. Maybe there is a bit in a header which has to be (un)set, but I can't find any. Multiple via ways are not yet supported, but partly verified to be correct. Maybe I'll look at that when we see an effect on routing for a single via way. @Steve: Do you see any effect of them in your maps? If yes, what might be wrong with the data written by mkgmap? Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

On 03.04.2014 10:58, Gerd Petermann wrote:
Hi Felix,
the via_ways branch tries to implement the information that is stored in restriction relations: http://wiki.openstreetmap.org/wiki/Relation:restriction
The Garmin format also has a so called "route restriction". It allows to say something like "if you come from node n1 travaling on arc a1 to point n2, you are not allowed to travel on to point n3 via arc a2. The so called 4 node restriction is similar : if you come from n1 on a1 via n2 and n3 on arc a2 you are not allowed to continue to n4 on arc a3.
So, it has nothing to do with invisible ways.
What you are asking for is an algo similar to that for the --adjust-turn-headings option. I don't think that we really need invisible ways for that, it should be enough to manipulate the angle between the roads which is stored in the img file. My understanding of the Garmin algo is that it doesn't like sharp angles, so I am pretty sure that the angle has an effect on routing. I'll do a few experiments with that.
Gerd Ah okay. Now I got it.
Well for car navigation we don't need invisible ways. I'm pretty sure also playing with angles won't really help much except in some special cases. The street layout in general is good enough - as there are usually via ways for cars to cut down sharp angles in real life anyhow. For cycling this is not the case. Actually real invisible via/junction was wouldn't be needed everywhere. Only on/off/between those lines that we define as "cycleworthy". The higher the "road-speed" the more it's needed. Also on many junction 2 via ways would be enough as / ____/___ / / here for example only in the right top corner and left lower corner the angle matters while the angles are fine on the other to combinations.
------------------------------------------------------------------------ Date: Thu, 3 Apr 2014 10:42:57 +0200 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] r3165 in via_ways branch
Hi Gerd, I haven't really understood what the via ways branch is doing...
Could you explain it again? Is it only about restrictions?
What could really improve the maps for me would be short invisible short via ways on all intersections in order to reduce the turn angle... So instead of
| | -----|------ | |
make every intersection (on those places where the angle is over 60°) look like | / | \ -----|------ \ | / |
Basically building short invisible via ways (if invisible routing lines are not what this is about, then just give a style/command option possiblity to define the type and then set it invisible in the typfile) for routing (basically the same as highway junctions are in reality, just smaller but serving the purpose of having no sharp turn angle). I'm pretty sure this would improve routing a lot for my maps, but this is only an assumption as I cannot build large maps to try it out... (the via ways should'nt be straight as in the above example but of course round to minimize the angle. Length of 10m is long enough - so make em consist of 3-4 points).
On 03.04.2014 09:28, Gerd Petermann wrote:
Hi all,
I think r3165 is ready for a deeper test. Changes compared to trunk: - handling of RouteRestrictions was mostly rewritten to make sure that mkgmap doesn't write wrong restrictions to the img file (this was possible when different roads connected the same points with direct arcs) - added support for restrictions with one via way (see below) - added support for tag type=restriction:* , e.g. type=restriction:motorcar - added support for tag restrection:*=<turn> , e.g. restriction:motorcar=only_left_turn - added support for no_entry and no_exit restrictions - improved log messages for invalid or possibly obsolete restriction relations
Reg. via ways: According to NodCheck in the display tool the data written by mkgmap r3165 is correct, but I found no effect on routing :-( Up to now mkgmap adds a 4 node restriction to both end points of the via way. Maybe there is a bit in a header which has to be (un)set, but I can't find any. Multiple via ways are not yet supported, but partly verified to be correct. Maybe I'll look at that when we see an effect on routing for a single via way.
@Steve: Do you see any effect of them in your maps? If yes, what might be wrong with the data written by mkgmap?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- keep on biking and discovering new trails
Felix openmtbmap.org &www.velomap.org <http://www.velomap.org>
_______________________________________________ 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
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

Hi Gerd Can you have a look at this situation: https://www.openstreetmap.org/relation/3478910 type=restriction restriction:motorcar=no_entry Cars (good), but also bicycles (not good) are blocked in this restriction (riding from west > east into Ekris) Probably because restriction:* is not supported in combination with no_entry?

Hi Minko, thanks for reporting. Evaluation of allowed vehicles did not work with any kind of restriction:*=<turn> tag. Fixed with r3166. Gerd
Date: Thu, 3 Apr 2014 11:23:04 +0200 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] r3165 in via_ways branch
Hi Gerd Can you have a look at this situation: https://www.openstreetmap.org/relation/3478910
type=restriction restriction:motorcar=no_entry
Cars (good), but also bicycles (not good) are blocked in this restriction (riding from west > east into Ekris) Probably because restriction:* is not supported in combination with no_entry? _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

On Thu, Apr 03, 2014 at 09:28:06AM +0200, Gerd Petermann wrote:
I think r3165 is ready for a deeper test.
Here is a restriction that forbids turning to left, to highway=service,oneway=yes (not against oneway direction): 2014/04/04 15:02:52 WARNING (RoadNetwork): 63240008.osm.pbf: Turn restriction (only_straight_on) http://www.openstreetmap.org/browse/relation/905336 (at http://www.openstreetmap.org/?mlat=63.678088&mlon=22.715307&zoom=17) restriction ignored because it forbids only u-turn Also, would it be possible to split the following warning message "ignored because A or B" into two messages: "ignored because A" and "ignored because B"? ... restriction ignored because all possible other ways are wrong direction in oneway or not accessible for restricted vehicles A future improvement could be to handle no_through_route or no_through_driving restrictions, such as relations 2886802 and 2886879. They are not describing the complete route; it is a bit ambiguous what is meant by the relations (and the traffic signs). Marko

Hi Marko, thanks for reporting.
Here is a restriction that forbids turning to left, to highway=service,oneway=yes (not against oneway direction):
2014/04/04 15:02:52 WARNING (RoadNetwork): 63240008.osm.pbf: Turn restriction (only_straight_on) http://www.openstreetmap.org/browse/relation/905336 (at http://www.openstreetmap.org/?mlat=63.678088&mlon=22.715307&zoom=17) restriction ignored because it forbids only u-turn
Yes, I found an error in the check.
Also, would it be possible to split the following warning message "ignored because A or B" into two messages: "ignored because A" and "ignored because B"?
... restriction ignored because all possible other ways are wrong direction in oneway or not accessible for restricted vehicles
okay. See r3167 which also corrects the error above.
A future improvement could be to handle no_through_route or no_through_driving restrictions, such as relations 2886802 and 2886879. They are not describing the complete route; it is a bit ambiguous what is meant by the relations (and the traffic signs).
If I got that right, the meaning is that you are not allowed to drive into an area if you plan to drive through it. In my eyes this should be handled with the tag access=destination ? Gerd

Hi Gerd,
Yes, I found an error in the check.
Thanks, this message is no longer being issued for this relation. Here is another: 2014/04/05 18:38:10 WARNING (RoadNetwork): 63240002.osm.pbf: Turn restriction (only_right_turn) http://www.openstreetmap.org/browse/relation/423035 (at http://www.openstreetmap.org/?mlat=60.168471&mlon=24.934714&zoom=17) restriction ignored because all possible other ways are wrong direction in oneway The way straight ahead is marked as oneway=yes that prohibits entry, but it carries bicycle:oneway=no, psv:oneway=no. Similarly, the turn restriction is tagged as except=psv;bicycle. While it is a redundant restriction, I suspect that this form of tagging is not being recognized by the via_ways branch. Would mkgmap now be refusing bicycle routing straight ahead? At least the message is a bit misleading or imprecise. I understand that the ; delimiter is troublesome. How should this be tagged? restriction:bicycle=no?
A future improvement could be to handle no_through_route or no_through_driving restrictions, such as relations 2886802 and 2886879. They are not describing the complete route; it is a bit ambiguous what is meant by the relations (and the traffic signs).
If I got that right, the meaning is that you are not allowed to drive into an area if you plan to drive through it. In my eyes this should be handled with the tag access=destination ?
It might not be that simple, because my understanding is that access=destination would prohibit any through-routes, while only certain through-route are being prohibited by the traffic sign. Looking more closely at relation 2886803, the idea seems to be this: ----------------A------------ | | Mestarintie | --------B---+---+---- | | | C | Panuntie If you turn from A down to Mestarintie, you must not turn at crossing B to Panuntie (C), but instead you must continue straight on to the left. (If you stop for a while somewhere between A and B, then it is OK. It is somewhat fuzzy and ambiguous, and seldom enforced, I guess.) There could be some alternative routes A-B-C in that subnet, and I guess that the no_through_driving should still apply, even if you did not use the shortest route A-B-C. An approximation of this restriction could be to prohibit driving only on the shortest route A-B-C. Marko

Hi Marko,
Thanks, this message is no longer being issued for this relation.
Here is another:
2014/04/05 18:38:10 WARNING (RoadNetwork): 63240002.osm.pbf: Turn restriction (only_right_turn) http://www.openstreetmap.org/browse/relation/423035 (at http://www.openstreetmap.org/?mlat=60.168471&mlon=24.934714&zoom=17) restriction ignored because all possible other ways are wrong direction in oneway
The way straight ahead is marked as oneway=yes that prohibits entry, but it carries bicycle:oneway=no, psv:oneway=no. Similarly, the turn restriction is tagged as except=psv;bicycle.
While it is a redundant restriction, I suspect that this form of tagging is not being recognized by the via_ways branch. Would mkgmap now be refusing bicycle routing straight ahead? At least the message is a bit misleading or imprecise. I understand that the ; delimiter is troublesome. How should this be tagged? restriction:bicycle=no?
For mkgmap, the except tag can contain a comma or semicolon separated list. On the other hand, the message says that the restriction is ignored. It doesn't mean that the restriction relation in OSM is wrong or obsolete, as it depends on the style and used options if any routable way is available for that the restriction has an effect, also, the input file might not contain the complete area, so you always have to look at the OSM data. If you use option --make-opposite-cycleways and remove the bicycle from the except list, the message should disappear. By the way, I've also modified splitter to make sure that it keeps all supported restriction types complete.
A future improvement could be to handle no_through_route or no_through_driving restrictions, such as relations 2886802 and 2886879. They are not describing the complete route; it is a bit ambiguous what is meant by the relations (and the traffic signs).
If I got that right, the meaning is that you are not allowed to drive into an area if you plan to drive through it. In my eyes this should be handled with the tag access=destination ?
It might not be that simple, because my understanding is that access=destination would prohibit any through-routes, while only certain through-route are being prohibited by the traffic sign. Looking more closely at relation 2886803, the idea seems to be this:
----------------A------------ | | Mestarintie | --------B---+---+---- | | | C | Panuntie
If you turn from A down to Mestarintie, you must not turn at crossing B to Panuntie (C), but instead you must continue straight on to the left. (If you stop for a while somewhere between A and B, then it is OK. It is somewhat fuzzy and ambiguous, and seldom enforced, I guess.)
There could be some alternative routes A-B-C in that subnet, and I guess that the no_through_driving should still apply, even if you did not use the shortest route A-B-C.
An approximation of this restriction could be to prohibit driving only on the shortest route A-B-C.
I see no simple way to support that, as it requires 1st to implement a routing algo, and I also doubt that we can translate that to the img format. I agree to you 2nd post that mkgmap should only print one message for this. Gerd

Hi Gerd, one more annoyance: I suppose that restriction relation 3297476 should be unrecognized (type=restriction,restriction=no_through_driving). If mkgmap does not handle this restriction type, it should issue only one message for it, "unsupported restriction no_through_driving". Instead, mkgmap is now issuing two messages, about the via ways not being connected. (If mkgmap is supporting this restriction type, then these messages are OK to issue.) This is a similar restriction as the one I described in more detail. This relation even carries a note explaining that the role=via is not well-defined. Marko

Hi Marko, Marko Mäkelä wrote
Hi Gerd,
one more annoyance:
I suppose that restriction relation 3297476 should be unrecognized (type=restriction,restriction=no_through_driving).
If mkgmap does not handle this restriction type, it should issue only one message for it, "unsupported restriction no_through_driving".
I've changed that with r3170. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/r3165-in-via-ways-branch-tp5802056p5802449.ht... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (5)
-
Felix Hartmann
-
Gerd Petermann
-
GerdP
-
Marko Mäkelä
-
Minko