Commit: r1498: Reduces style rule syntax errors that are caused
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.
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 mkgmap-dev@lists.mkgmap.org.uk 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.
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 mkgmap-dev@lists.mkgmap.org.uk 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
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 mkgmap-dev@lists.mkgmap.org.uk 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]/
participants (2)
-
Felix Hartmann -
svn commit