[mkgmap-dev] Commit: r3169: Fix the e-road rule in the relations file
Version mkgmap-r3169 was committed by wanmil on Sat, 05 Apr 2014 Fix the e-road rule in the relations file ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Missing } in relations of default style?
Hi,
I found out myself:
add int_ref='${int_ref'};
need to be
add int_ref='${int_ref}';
Will commit it soon.
WanMil
Hi,
The relations file of the mkgmap default style seems to have a problem.
The apply rule of the e-road rule has an open bracket { only. But it is
not closed and the rule never seems to be executed.
Closing it the style parser complains.
Using the following single rule in the relations file the parser complains:
route=road & network=e-road {
apply { add ref='${ref}'; add int_ref='${int_ref'}; add
network='e-road'; }
}
Error in style: Error: (relations:3): Incomplete expression, just a
single symbol: }
What's wrong here? Parser or style or??
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Missing } in relations of default style?
Hi,
The relations file of the mkgmap default style seems to have a problem.
The apply rule of the e-road rule has an open bracket { only. But it is
not closed and the rule never seems to be executed.
Closing it the style parser complains.
Using the following single rule in the relations file the parser complains:
route=road & network=e-road {
apply { add ref='${ref}'; add int_ref='${int_ref'}; add
network='e-road'; }
}
Error in style: Error: (relations:3): Incomplete expression, just a
single symbol: }
What's wrong here? Parser or style or??
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] r3165 in via_ways branch
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] r3165 in via_ways branch
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] r3165 in via_ways branch
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r3168: improve WrongAngleFixer: before merging nodes that are not very close,
Version mkgmap-r3168 was committed by gerd on Sat, 05 Apr 2014 improve WrongAngleFixer: before merging nodes that are not very close, check that a nearly straight line goes through both nodes and that this line is improved by the merge. In rare cases, nodes where merged causing distorted lines. The merge should happen in a situation like this: b b c c Road a is straight, roads b and c are connected to it with nodes that are close together. If a is not perfectly horizontal, the two connection points might be rounded to very different positions, so that road a is zig-zagging in the map. The merge helps to avoid this. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
