[Incomplete Patch] Validator complains about key: *:lanes:conditional (etc.)

[alv]

Since r6605 (see #9350) the validator has a too strict parser for any keys with the :conditional suffix. The conditional restrictions must be valid when combined with ":lanes" suffix, too?

e.g.:

goods:lanes:conditional = ||yes @ (Mo-Fr 09:00-15:00, 18:00-07:00; Sa-Su 24h)

(rightmost (bus) lane allowed for vans in the given timeframe. It could have :forward or :backward in the key, too. Also similar keys for other access modes. Example way: ​http://www.openstreetmap.org/way/29689100)

We also use:
traffic_sign:conditional = FI:361[100] @ (winter)
yet the validator complains about it. (They physically change the maxspeed sign for the winter.)

Another user ij_ wrote the attached patch, which fixes the test when ":lanes" is present in the key, and at least it compiled ok.

[simon04]

The lanes "subkey" is nowhere mentioned at ​http://wiki.openstreetmap.org/wiki/Conditional_restrictions.

Similar to traffic_sign:conditional: According to the specification, the first part (traffic_sign) must either be a <restriction-type> or a <transportation mode>, but it isn't any of those two.

I woudn't change JOSM's validator unless the specification does reflect the usage of your two examples.

[alv]

Even if it's not specified in that general syntax formula (which is stricter than the definition above it), it's a sensible combination of the accepted way to tag lane specific restrictions ​http://wiki.openstreetmap.org/wiki/Lanes (That even says "This suffix is applicable to any existing <key>=<value> tag pair" - that was even documented before conditional restrictions proposal). And certainly not a wrong tag to use ("wrong syntax in key"). It might be necessary to decide which order is preferred, :lanes or :conditional as the last suffix. Now that I had some time to look at the code, it seems it doesn't check them at all if the :lanes was last in the key. Then, however, the "not in presets" test matches.

I do see the point of this check (e.g. maxspeed:hgv:forward:conditional vs. hgv:forward:maxspeed:conditional), but as it is now, it's inhibiting sensible "extension by usage". Somehow the validator went straight from "values not in presets" to strict parsing of anything with :conditional part in the key. I'd say the better way to check these current conditional tags would include checking if the parts of the key are a sensible subset of those as listed in the "general syntax", and only then if the order and the value are valid or not. But I realize it would require possibly quite a lot more thought to what makes the keys a part of the general syntax "family", and effort to the current straightforward test.

[ij]

For the record: I realized later that the patches I made weren't complete as the :lanes values with | would need to be parsed too properly and the patches only solved the key part.

[simon04]

See comment:3

[simon04]

Ticket #13742 has been marked as a duplicate of this ticket.

[jc86035]

Why is this a wontfix? Lanes are mentioned directly in ​the Conditional restrictions wiki page § Evaluation of conflicting restrictions. (lanes:psv:conditional=* is used 132 times and lanes:bus:conditional 53 times. While that's not really a lot, we could always add more of them :P)

[simon04]

Still, the Wiki page lacks a description, see my comment:3.

[skyper]

See also #13651, #20832, #21163

[DodalerAfenger]

The patch in #21163 should solve that issue, too