The way that I’m currently doing it is I have dog=leashed on the enclosing park, and then for the specified lawn and beach areas I have dog=no. I feel like the surrounding park should have something that gives notice that that some areas are not permitted to dogs, but I’m not sure.
It’s for this park.
The conditional syntax allows for free text for detailed description.
dog:conditional = no @ "on lawns, beaches, playgrounds and within 5 meters of them"
Now this makes me wonder how do applications distinguish between *:conditional= comments only, and comments as an opening_hours= syntax. In the latter, comments-only is specified as unknown , so those need to be be open "on lawns, beaches, playgrounds and within 5 meters of them" (the open means it’s in effect, ie on / opposite of off ).
I don’t think a comment-only conditional is valid. The specification requires “value @ condition” where ‘value’ is a valid value of the main key.
Yes, I know. It’s about the conditions part.
The opening_hours syntax is extremely complicated and is only used for that key. Everywhere else uses a different syntax and should not be parsed like the opening_hours key.
There are similarities, but it is not advisable to mix those two.
Something else I’ve noticed is that the only rule that is directly applicable to this park is “no dogs permitted on beach or lawn areas”. The second section that states “Dogs must be leashed at all times, except in designated dog off-leash areas” and “Dogs are not permitted on or within 5 meters of playing fields, sports surfaces, children’s playgrounds, sports courts, or waterplay parks” is actually the result of City of Maple Ridge Bylaw No. 7854-2022 §12.1 and is applicable to the entire municipality. So what I’m thinking is that this park would be tagged with dog:conditional=no @ "lawns, beaches" and then the entire city would have the access tags dog=leashed (although that doesn’t account for the off leash areas) and dog:conditional=no @ "on or within 5 meters of playing fields, sports surfaces, children's playgrounds, sports courts, or waterplay parks"
The question is opening_hours="The comment" being a valid opening_hours= syntax, which means =unknown "The comment" . It needs to be =open "The comment" to specify it’s always active. Then how should you interpret *:conditional=* @ ("The comment") ? An application running an opening_hours= parser on *:conditional= would need an extra check and handle these differently. Do they know this now?
is doing something seriously wrong.
There is some overlap where time based conditions are concerned, but that’s it.
I think they do, given they’d have to interpret stuff like maxspeed:conditional= 80 @ (wet) or motor_vehicle=destination @ (weight > 3.5). How would an opening_hours parser deal with that? It’s not part of the syntax.
Not neccesarily. It is something that I have been intending to do, but I haven’t received the necessary “round tuit” yet.
The problem with comment-only conditionals is that almost no non-humans will be able to parse them. They’re still useful for humans, but what would be far more useful here would be if they were written as actual access values on the areas affected.
Again, how would that parser deal with non-time-based conditionals?
You can’t just take a parser for the opening_hours syntax and apply it to :conditional tags. You need an entirely different parser that goes beyond
anyway, so there isn’t any discussion about potential confusion.
As a human, when "The comment" is true (with some room for interpretation, being unstructured text), <value> is the value.
As such, the comment isn’t even a comment, because a comment can by definition be ignored. The text in quotation marks is a human-readable (but not necessarily machine-readable) condition.
I’m not asking whether they know conditions. A freeform text condition is valid both as an unknown in opening_hours= on its own, and as that documented for *:conditional= as always active (depending on the comment). By parsing opening_hours= , I’m referring to checking whether the condition is time-based. The application would need to decide which to use.
Then would you prefer a dog:description= (as inwheelchair:description= ) more than such dog:conditional= ?
A big downside to the “free text conditional comment” approach is that it’s not machine-readable and can’t be used for styling the different areas.
When a feature has a clearly defined geographic boundary, surely we should be able to express it directly with nodes/ways? Burying it in a free-text comment doesn’t seem ideal to me.
Could someone articulate the downsides to using areas? (E.g. a smaller dog=unleashed area within a larger dog=leashed one?)
…just realised I’ve perhaps misinterpreted the thread. I guess the suggestion was to use the conditional comment as well as (not instead of) areas? If so, ignore my comment above 
That was my intention and the way I understood the first post.
