On 22.01.2010 12:36, Felix Hartmann wrote:
On 22.01.2010 01:15, Felix Hartmann wrote:
On 19.01.2010 00:02, svn commit wrote:
Version 1498 was commited by steve on 2010-01-18 23:02:57 +0000 (Mon, 18 Jan
2010)
Reduces style rule syntax errors that are caused
by terms being in the wrong order.
Terms in the expression are now re-arranged accross the whole of the
expression and not just the first two terms. So if there is a term that can be
indexed that can be moved to the front without changing the meaning of
the expression, then it should now happen.
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
rev 1498 has broken oneway handling: I put it here because the other
topic got pretty of-topic. So related to oneway=reverse handling broken:
I could lock down the problem(s).
1. with the new code, prefixing highway=* is needed for the
"continue" command to work properly (in case no highway=abc is
present in the line).
2. There is no difference in how mkmgap handles oneway=-1 and
oneway=reverse. The oneway code got broken with rev: 1498 however. It
is not possible to use "set oneway=yes" on ways that already had
oneway=-1 or oneway=reverse. No problem however with other oneway
values such as yes/true/1. Before my results were different, because
it got broken by 1. before. So there is simply a problem with turning
the direction around of oneway=-1 and oneway=reverse and "continue".
Now we shouldn't say the "continue" code is broken, but better would
be to ditch the old conditional rules without 0x?? and replace them
with [continue with_actions]. Then oneway=-1 and oneway=reverse
handling should be put into the stylefile as a simple line:
/highway=* & ( oneway=-1 | oneway=yes ) {mkgmap:turnhighway=yes}
[continue with_actions]/
to turn around the direction of a street. The alternative would be to
turn around streets before running the style-file, and then set
oneway=-1/oneway=reverse to oneway=yes. This was the way mkgmap
worked until rev 1497.
Being able to use [continue with_actions] instead of the old
conditional code, would be much better and more comprehensible.
Actually the style-branch should behave just like this. Alternatively
the behaviour of current conditional rules should be changed to be
handled as if [continue with_actions] without assigning 0x* were used.
Well now I noticed, that it does not matter much what you do. Oneway
handling got fucked up with 1498. I have rules to make additional
roads for cycleway=opposite and so on. None of them work at all anymore.
Based on discovering more and more about this, I think that rev 1498
was not a wise move to do, it broke much more than it corrected.
Before there were some pecularities. Now for oneway roads it is
complete mystery regarding the outcome. I'm unsure as to whether there
are even more problems introduced with 1498.
Also mkgmap slowed down by about 50% with 1498 vs 1497
Here is a rule that will truly fuck up mkgmap (and I'm not even sure
that is is related to continue at all, however before with less !=* one
did not have to write such stupid rules, can anyone identify why this
rule will break other rules for the same street?:
/( highway=primary | highway=secondary | highway=tertiary |
highway=minor | highway=unclassified ) & oneway=yes & copy!=* &
bicycle:oneway!=no & cycleway!=opposite & cycleway!=opposite_lane &
cycleway!=opposite_track & cycleway!=both & highway!=motorway &
highway!=construction & highway!=trunk & highway!=trunk_link &
highway!=motorway_link [0x10a02 resolution 24 continue]/
Strangely it will behave differently (well not correct either, by
blocking other rules to work) when given like:
/highway=* & oneway=yes & copy!=* & ( highway=primary |
highway=secondary | highway=tertiary | highway=minor |
highway=unclassified ) & bicycle:oneway!=no & cycleway!=opposite &
cycleway!=opposite_lane & cycleway!=opposite_track & cycleway!=both &
highway!=motorway & highway!=construction & highway!=trunk &
highway!=trunk_link & highway!=motorway_link [0x10a02 resolution 24
continue]/
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
