wrong rendering of direction with oneway=-1?
I notice that mkgmap-r2946 renders the direction of arrows in the reverse direction compared with previous versions. This is only the case with oneway=-1, oneway=yes is pointing in the same direction as expected. Before the merge (mkgmap-r2815) it was rendered ok. Is there something changed or is it a bug? See OFM https://www.dropbox.com/s/6wn24e97iu1l20r/oneway-1.jpg OSM http://www.openstreetmap.org/way/253023406 BTW routing is still as expected, only the drawing is now in the opposite direction! My style rules: http://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts/Styles/ # display direction arrows highway=* & (oneway=yes | bicycle:oneway=yes ) & (cycling!=twoway) & bicycle!=no [0x10007 resolution 24 continue with_actions] highway=* & (oneway=yes | bicycle:oneway=yes ) & (cycling=twoway) [0x10008 resolution 24 continue with_actions] highway=* & (oneway=-1 | bicycle:oneway=-1 ) & (cycling!=twoway) & bicycle!=no [0x10010 resolution 24 continue with_actions] highway=* & (oneway=-1 | bicycle:oneway=-1 ) & (cycling=twoway) [0x10011 resolution 24 continue with_actions] In my typ file it still shows as expected: oneway=yes is rendered as Type=0x10010 is ---> oneway=-1 is rendered as Type=0x10007 is <--- http://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts/10010.typ In gpsmapedit I dont see errors either, both lines are produced as expected.
PS: mkgmap-r2934 is working as expected, directions of arrows are ok in this version
Hi Minko, with r2944 normalization of oneway roads to oneway=yes has been moved. I think this is the reason for the effect you observe. You should be able to fix the problem by assigning the same code 0x10007 either to oneway=yes and to oneway=-1 roads. I think we need to clarify that the direction of oneway roads is always normalized to oneway=yes. So direction oriented typ items must be drawn accordingly. Gerd, what do you think? The RoadMerger would not be able to merge two roads with oneway=yes and oneway=-1 if it is not allowed to reverse the direction at an early stage in the StyledProcessor. WanMil
I notice that mkgmap-r2946 renders the direction of arrows in the reverse direction compared with previous versions. This is only the case with oneway=-1, oneway=yes is pointing in the same direction as expected.
Before the merge (mkgmap-r2815) it was rendered ok. Is there something changed or is it a bug?
See OFM https://www.dropbox.com/s/6wn24e97iu1l20r/oneway-1.jpg OSM http://www.openstreetmap.org/way/253023406
BTW routing is still as expected, only the drawing is now in the opposite direction!
My style rules: http://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts/Styles/
# display direction arrows highway=* & (oneway=yes | bicycle:oneway=yes ) & (cycling!=twoway) & bicycle!=no [0x10007 resolution 24 continue with_actions] highway=* & (oneway=yes | bicycle:oneway=yes ) & (cycling=twoway) [0x10008 resolution 24 continue with_actions]
highway=* & (oneway=-1 | bicycle:oneway=-1 ) & (cycling!=twoway) & bicycle!=no [0x10010 resolution 24 continue with_actions] highway=* & (oneway=-1 | bicycle:oneway=-1 ) & (cycling=twoway) [0x10011 resolution 24 continue with_actions]
In my typ file it still shows as expected: oneway=yes is rendered as Type=0x10010 is ---> oneway=-1 is rendered as Type=0x10007 is <---
http://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts/10010.typ
In gpsmapedit I dont see errors either, both lines are produced as expected.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Thanks Wanmil, it's an easy fix if you know it ;-) I havent notice the change: - the oneway=* tag is simplified after style processing. If it is "true" or "1" it is changed to "yes", if it is "-1" or "reverse", the points of the way are reversed and the tag is changed to "yes". If finally the tag is not "oneway=yes" the tag is removed from the way. This is also done for (overlaying) lines, and it improves the RoadMerger as it allows a few more merges. - simplified "oneway=*" handling in RoadMerger I assume this also means that I should render a) cycleway=opposite_lane & oneway=-1 the same as b) cycleway=opposite_lane & oneway=yes Now I have two other line types for these situations (bike lane on either left or right side of the road)
I assume this also means that I should render a) cycleway=opposite_lane & oneway=-1 the same as b) cycleway=opposite_lane & oneway=yes
Now I have two other line types for these situations (bike lane on either left or right side of the road)
Yes, as far as I understand all oneway roads are normalized to oneway=yes which also means that the points are always sorted by direction: oneway=yes 1>>>>>>>>>2 is normalized after the style to: oneway=yes 1>>>>>>>>>2 oneway=-1 2<<<<<<<<<1 is normalized after the style to: oneway=yes 1>>>>>>>>>2 Maybe we should think about performing the normalization step before running the style files. That might be easier to understand? WanMil
Normalization step before running the style files is maybe a better option, but beware for other tags like vehicle:backward=* or vehicle:forward=* If the direction of the way is reversed, these should reverse too.
Maybe we should think about performing the normalization step before running the style files. That might be easier to understand?
Am 12.01.2014 11:02, schrieb Minko:
Normalization step before running the style files is maybe a better option, but beware for other tags like vehicle:backward=* or vehicle:forward=* If the direction of the way is reversed, these should reverse too.
Yes, that's the reason roads should not be reversed before running the style, IMHO. But what would be good is a non-reversing normalization: oneway=yes/true/1 -> oneway=yes oneway=-1/reverse -> oneway=-1 BTW: reverse != reversible :-) Chris
Hi Chris,
Normalization step before running the style files is maybe a better option, but beware for other tags like vehicle:backward=* or vehicle:forward=* If the direction of the way is reversed, these should reverse too.
Yes, that's the reason roads should not be reversed before running the style, IMHO.
I agree that we should not reverse the ways before style processing.
But what would be good is a non-reversing normalization:
oneway=yes/true/1 -> oneway=yes oneway=-1/reverse -> oneway=-1
I don't think so. A lot of work was done to remove tag depended java code and change it into style rules. I think this normalization should be done in the style. Gerd
Am 12.01.2014 14:26, schrieb Gerd Petermann:
But what would be good is a non-reversing normalization:
oneway=yes/true/1 -> oneway=yes oneway=-1/reverse -> oneway=-1
I don't think so. A lot of work was done to remove tag depended java code and change it into style rules. I think this normalization should be done in the style.
Ok, I understand. Chris
Hi,
Yes, as far as I understand all oneway roads are normalized to oneway=yes which also means that the points are always sorted by direction:
I think we always did that, just a bit later in the chain. The big change in r2944 was that "This is also done for (overlaying) lines" I simply considered the old behaviour to be wrong, but I did not take into account that users created work arounds for the bug in the style and typ file. Gerd
participants (4)
-
chris66 -
Gerd Petermann -
Minko -
WanMil