I'd like to set maxspeed to the minimum of maxspeed, maxspeed:forward, and maxspeed:backward. In my lines file, I use: |maxspeed:forward=*& maxspeed!=* { set maxspeed='${maxspeed:forward}' } maxspeed:forward=*& (maxspeed:forward<maxspeed) { set maxspeed='${maxspeed:forward}' } maxspeed:backward=*& maxspeed!=* { set maxspeed='${maxspeed:backward}' } maxspeed:backward=*& (maxspeed:backward<maxspeed) { set maxspeed='${maxspeed:backward}' }| That works only if exactly one tag is set. But when both forward and backward are available, I get the value of forward even if backward is less. An example is wayhttp://www.openstreetmap.org/browse/way/70594951. I played with additional / different rules, and my conclusion is that it is NOT POSSIBLE to compare the values of two tags with each other. For example, I tried: |highway=*& maxspeed!=* { set maxspeed=999 } maxspeed:forward=*& (maxspeed:forward<maxspeed) { set maxspeed='${maxspeed:forward}' } maxspeed:backward=*& (maxspeed:backward<maxspeed) { set maxspeed='${maxspeed:backward}' }| And you can guess the result: maxspeed=999, for that way with maxspeed:forward=60 and maxspeed:backward=40. Is my conclusion correct? And, if so, will there be a patch?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Bernd, did you tried something like: maxspeed:forward < '${maxspeed}' ? Henning -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJSdAbRAAoJEPFgsWC7jOeTwkAH/38JgeX1wG//YX3LA3k0edzT csc6jjOdvytbLg6eatKZlPc4FA47jkNVvD4RWaPo7Peab9HKsJhUQ1Q03tYR55Dy ca0QhOiQFV/ja8N3f861HkmOU8VLmAlL0fnTeyusijGupS6gfIZUpbwmhehZyOL1 3yO1KPX2iOTxFyL9r0IL80bX8E7svkDDiEfsQeKIfb4u/Zg9IXNo3LQJ+wRVuVao MfeEAFTIH/2U0rWBfoH2YOOOGHykdvn7QkemgZFOFXBagYqv6NGND0zWGjHMHtqP PtPT/5WaJfSVmr5a81cewWF+q7cS2ogjNE/FJc2jOsSUM8TnOoZxLiQdqfduT8s= =OYq9 -----END PGP SIGNATURE-----
On 01/11/13 12:50, Bernhard Hiller wrote:
it is NOT POSSIBLE to compare the values of two tags with each other.
That is correct. But it is now an easy thing to implement. There are a few syntaxes we could use such as: maxspeed < get_tag(maxspeed:forward) maxspeed < ${maxspeed:forward} The attached patch implements the dollar notation. So the first part of your example could be written as: maxspeed:forward=* & maxspeed!=* { set maxspeed='${maxspeed:forward}' } maxspeed:forward=* & maxspeed:forward < ${maxspeed} { set maxspeed='${maxspeed:forward}' } Note there are no quotes around ${maxspeed}. It's not limited to numeric comparisons, you could have: name != $name_int Currently you can't just have one of these by itself, it has to have another test first. I'm pretty sure that can be fixed, but that's one for later. (built jar: http://files.mkgmap.org.uk/download/161/mkgmap.jar) ..Steve
Am 01.11.2013 23:34, schrieb Steve Ratcliffe:
Note there are no quotes around ${maxspeed}.
would it be a problem to make it work also with the quotes? To make it consistent with the existing usage. The style rules are complicated enough. ;-) With this enhancment it is ready for committing. Chris
On 02/11/13 10:01, chris66 wrote:
would it be a problem to make it work also with the quotes?
To make it consistent with the existing usage.
After some thought I would rather not do that. In tag matches, the quotes remove the special meaning of special characters and I would like to preserve that. Also there is a big difference; it is not a string containing tag values and so something like: '${name} (${ref})' would not work, nor do any of the variable filters work. We could use a different notation such as get_tag(maxspeed) since it would be clearer that it could not be quoted. I could add a warning if a quoted string starts with "${" as that is unlikely to be intentional. I will only use the form $maxspeed in the documentation (without {}) to make it visibly different. ..Steve
Am 03.11.2013 13:23, schrieb Steve Ratcliffe:
We could use a different notation such as get_tag(maxspeed) since it would be clearer that it could not be quoted.
Hi Steve, I would prefer something like get_value(..) or value_of(..) or simply value(..) tag is in OSM a word for key=value, so get_tag doesn't make sense, because you'll just get the value from a given key. Henning
On 03/11/13 12:30, Henning Scholland wrote:
I would prefer something like get_value(..) or value_of(..) or simply value(..)
tag is in OSM a word for key=value, so get_tag doesn't make sense, because you'll just get the value from a given key.
Yes I agree, a name including 'value' would be better. ..Steve
Am 03.11.2013 13:23, schrieb Steve Ratcliffe:
On 02/11/13 10:01, chris66 wrote:
would it be a problem to make it work also with the quotes?
To make it consistent with the existing usage.
After some thought I would rather not do that. In tag matches, the quotes remove the special meaning of special characters and I would like to preserve that.
Also there is a big difference; it is not a string containing tag values and so something like: '${name} (${ref})' would not work, nor do any of the variable filters work.
We could use a different notation such as get_tag(maxspeed) since it would be clearer that it could not be quoted.
I could add a warning if a quoted string starts with "${" as that is unlikely to be intentional.
A warning is ok for me. Thanks for the explanation. Chris
Steve, thanks for the patch. I've just re-created the test map, and it works! When will that patch be included in future releases? Regards, Bernhard
On 02/11/13 07:43, Bernhard Hiller wrote:
Steve, thanks for the patch. I've just re-created the test map, and it works! When will that patch be included in future releases?
Great! There are a couple of things not implemented/bugs in the first patch which are fixed in the attached patch. - Fix crash in some cases, when a tag was not set - The comparison can be the only term in the expression. The second means that you can write just minspeed < $maxspeed and it will be converted automatically to: minspeed=* & minspeed < $maxspeed There should be no difference to anything that worked with the previous patch. There are also some tests. I also need to add to the documentation. But if there are no other problems noticed I think it is now good to go. ..Steve
Am 03.11.2013 12:56, schrieb Steve Ratcliffe:
The second means that you can write just
minspeed < $maxspeed
and it will be converted automatically to:
minspeed=* & minspeed < $maxspeed
Wouldn't it be more logical to convert it to: minspeed=* & maxspeed=* & minspeed < $maxspeed Henning
On 03/11/13 12:33, Henning Scholland wrote:
Wouldn't it be more logical to convert it to:
minspeed=* & maxspeed=* & minspeed < $maxspeed
OK perhaps I shouldn't have given a specific example. It is an internal detail of how the style system works that you have to have something like a=b or a=* first. If you don't have one, then the style system will create one for you that works without changing the meaning of what you wrote. It could pick minspeed=* or maxspeed=* it doesn't really matter and it might be different in the future. That rule is only used as an index to select the possible rules that could match and is then thrown away again. So the only thing that is actually run is the test for the minspeed value equalling the maxspeed value. ..Steve
participants (4)
-
Bernhard Hiller -
chris66 -
Henning Scholland -
Steve Ratcliffe