You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
Reporter: stevage [Submitted to the original trac issue database at 12.58am, Tuesday, 8th February 2011]
It's not currently possible to define a map feature covering multiple top-level tags, like railway=spur and railway=rail. As a result, we get a few too many entries in the feature list, when they would be better specified as sub-options.
The text was updated successfully, but these errors were encountered:
Author: stevage [Added to the original trac issue at 1.46pm, Tuesday, 8th February 2011]
I have implemented this in 25255, and welcome discussion on its merits. The final syntax/semantics I went with:
Means that any traffic_calming=* will be recognised, and the default value (unless set explicitly by the included dropdown) will be "yes"
If vmatch is not "*", it is interpreted as a regular expression, so this works:
or, more simply:
I think this is a useful extension, to solve a few peculiarities in the tagging scheme and to give us a bit of flexibility in decoupling the interface from the underlying tags. (With appropriate caution exercised...)
It doesn't quite solve the highway=proposed, proposed=..., but it's a step closer.
The same mechanism could also be used for elements of drop downs:
Reporter: stevage
[Submitted to the original trac issue database at 12.58am, Tuesday, 8th February 2011]
It's not currently possible to define a map feature covering multiple top-level tags, like railway=spur and railway=rail. As a result, we get a few too many entries in the feature list, when they would be better specified as sub-options.
The text was updated successfully, but these errors were encountered: