I’m trying to tag a parking area with accurate information about fees that only apply at certain times. I would like the solution to:
Have fee=yes (that seems like the safe solution, so that consumers not supporting fee:conditional will not erroneously belive parking is free always)
For maintainability, have specification of time windows in fee:conditional match whats on the signs, namely the hours with fee.
Some possible solution I can think of are listed below, but none appear ideal to me.
Questions:
Anyone with better ideas or suggestions for improvement?
Why doesn’t solution B) work?
Does the operator in D) exist already?
Thanks in advance for any feedback!
Solution A) Accept unsafe fee=no
fee=no
fee:conditional=yes @ (Mo-Fr 09:00-15:00)
(-) Doesnt have the safe fee=yes
(+) Nicely readable fee:conditional, matching the signs.
(+) Probably correct (at least Parking Lanes understands, see this example)
Solution B) Introduce explicit default in fee:conditional (doesn’t work?)
(+) Has the safe fee=yes
(+) Fairly readable fee:conditional, matching the signs.
(-) Maybe incorrect? At least isn’t correctly understood by Parking Lanes, see this example that is shown as free (i.e. green) also when time is within fee window.
Solution C (Manual complement)
Manually specify the complement of the time windows… Seems ugly, error prone, hard to generalize, but something like:
There is no solution D in specs (and we really shouldn’t be adding it, it is too complex as it is!).
Another alternative is to just drop that fee=no in Solution A (i.e. leave only fee:conditional=yes @ (Mo-Fr 09:00-15:00); parsers which support conditional fee should give right results, and those who don’t will return unknown which is much safer than incorrect no).
Note that while we have a way to tag those conditions, support of those tags by actual data users is still quite limited (probably not helped by complexity of conditional restrictions!)
And even those that support e.g. access:conditional might not support fee:conditional (yet). One might want to open wishlist tickets at data consumers they’d like to support those.
Also, while you’re reporting that unrecognized no @ 24/7, you may also open another issue suggesting that they register their usage of fee:conditional for taginfo projects (which doesn’t currently show it at fee:conditional - and the more support means more incentive to support it elsewhere too)
I guess that the increased complexity (of the spec) of adding such an operator, should be weighed against the potential decrease in complexity (in the tag database). But since I have no real overview of either, I have no opinion.
I somewhat like your idea of dropping fee=*… Though, I think some consumers (e.g. Parking Lanes) take lack of fee=* to mean no fee… Am also considering whether dropping fee=* might lead other editors (human/sw) (that maybe dont understand fee:conditional) to eventually/inevitably add fee=*, and whether that is a problem…
and it seems to say that @ 24/7must be there (shortly: things inside square brackets ([ and ]) are optional, things inside < and > are variables, and rest are literal characters. Everything that is not optinal must be present:
In your case (click to expand):
<restriction-type> - replaced by literal text fee
[:<transportation mode>] - skipped
[:<direction>] - skipped
:conditional = - fixed literal text :conditional =
<restriction-value> - replaced by literal text no (from no @ 24/7)
@ - fixed literal text @ (i.e. must be present always!)
<condition> - replaced by 24/7 (which also must be preset, as it is not optional!)
[;<restriction-value> @ <condition>] - skipped
It should be easy to check. Generally, if tag is missing, nothing should be assumed about it. But sometimes, if e.g. in 95% of cases it is fee=no, then data consumer might decide to assume that if nothing is tagged, such overwhelming majority will be the case there too, and just assume it.
Alternatively there is documented fee=unknown which should mean the same as missing fee=*, but it is two-edged sword: data consumer might not take note of that specific value, and decide that any fee which is notfee=no means that there is some fee (in attempt to handle things like fee=$3.50).
What I would do is check with Parking Lanes why is their support for no @ 24/7 seemingly broken. That seems like best course of action.
You could also try playing with other values which mean the same as 24/7, e.g. Mo-Su,PH 00:00-24:00. But I’d really recommend opening the issue with Parking Lanes to see where the bug is, so it can be fixed.
Your suggestions of fee=unknown made me consider fee=conditional. This seems like a great solution: It is meaningful and always correct by itself (not sometimes wrong like yes/no) and points the consumer to fee:conditional for more detail.
I also started reading the discussion page of fee=* and it appears that some mappers use fee=<interval> with a proper opening hours spec replacing <interval>. This usage is also suggested by the JOSM editor, but as far as I can read taginfo not as commonly used as yes/no (the many different <interval> values makes the picture not entirely clear, though).
So, now I see 3 ways to do this… Not yet sure which I like better:
Solution B from above (should be correct, and is fairly safe and explicit)
fee=<interval> (thousands of uses already, previously documented, but for some reason discouraged by some as far as I read the discussion page)
Solution B modified with fee=conditional (to me appears a bit better than B, only 6 uses in taginfo so probably not supported by any consumers yet)
I’d go with Solution B. If Parking Lanes does not handle 24/7 properly, it should be reported to them so they have opportunity to fix it.
Using undocumented and very rarely used values like fee=conditional is bound to create more problems than it would solve (as noted above, many data consumers would treat such values simply as fee=yes, and fixing that would take much more effort then fixing incorrect parsing of Solution B in Parking Lanes)
I understand, but to improve our ways we must at some point change our ways. As a preparation for (potentially) changing ways, evaluating concrete benefits and problems seem like a good thing to do, and this is what I’m trying to do here (and documenting this practice would take about 2 minutes in my estimate, so that shouldn’t be the issue).
So far I have found that dividing information between two tags (details in fee:conditional and default in fee) causes me and other mappers confusion, and leads consumers to present misleading information (e.g. OsmAnd misleadingly says fee=no (and nothing else) if using solution A that the wiki seems to recommend). fee=conditional would be better to show in isolation, I think, and even interpreting it as fee=yes would be fine (as it prevents someone unwarily getting a fine).
I very much appreciate you sharing concrete downsides/feedback, but also understand if that is not a discussion you’re interested in.
Your suggestion for me to open a ticket with Parking Lanes has been noted
Sure. I’m just not convinced that adding another way of tagging the same thing will improve the situation (I’m leaning towards the opposite side at the moment).
Sure. Just note that there are problems. Here are some general problems related to the subject - note that not all of them apply to this particular suggestion, but many of them do:
Documenting the new value the wiki is small (almost negligible) amount of work that needs to be done to improve the situation. The new wiki will mostly only be seen by new users. Most previous users (and tools) will continue to use old values they remember, as would those who consider low tag usage a barrier to implementing the new values. Then there comes the lobbying of editors (both programs and people) and other data consumers like renderers and routers and others (after all, the whole point is for those tags to provide some utility to the people) to not only allow, but prefer the new tags, which is huge job (I’d suggesting to look at previous issues for few most popular ones to get an idea of how much work and time it might take). And then there come long years of updating previous tagging schema to new one. And when new values are finally vast majority of tags, there comes deprecation of old values and their removal. Only after all of that is accomplished, would the tituation actually be improved. If the proponents will to push forward falters at any point, we’ll actually be left in worse position - both editors and data consumers having to support one more tagging schema, and handling potential conflicts between them (ObXKCD).
I’m interested in discussion of improvement. While I’ve noted some of the possible problems, if you are still considering that new tagging schema will solve more problems than it will create, I’d suggest following proposal process, as that has highest chance of actually succeeding - there is currently just two of us discussing, and while that is noticeably better then just single person, there should really be more people involved for best results.
There are some cases where I had to use something similar for parking signs referring to work days. Not really great for readability and I’d generally prefer variant A.
I wasn’t aware of the off modifier, maybe that works…
What makes you prefer solution A)? Don’t you think having fee=no on an object where you sometimes (maybe even most of the time) have to pay, seems 1) counterintuitive and 2) problematic for consumers/editors unaware of fee:conditional?
Data consumers should be well aware of data sources before giving any advice to the final user.
What do you mean by “safe”? Local residents will see fee=yes, but they had already paid the fee on a yearly basis or they had been excluded from paying like people with disabilities and so on.
This safe will be relevant to a portion of the users having badly written software.
In case fee is omitted and the data consumer can’t understand conditional syntax, fee=no should be implied, since no further action is expected anyway.
Any data consumer unaware of :conditional will run into problems one way or another. The same applies to a lot of other cases, where routers do questionable things (e.g. penalizing bicycles going into the wrong oneway-direction, instead of forbidding it, treating access=customer same as access=no, and so on). We can’t prevent them all from happening.
While I generally think, making things “fool=proof” is a good idea (i.e. use “safe” defaults, and handle “edge-cases” in :conditional, I wouldn’t want to kind of “bend” the tagging schema, only to behave like this, and fee:conditional=no @ (24/7; Mo-Fr 09:00-15:00 off) feels a bit like it, because it’s not intuitive. You really have to think a bit, before you know what it means, and this makes it likely to be screwed up later by other mappers. I come from a software programming background, and I learned to value readability over speed.
Earlier, I mentioned that I had to use the off modifier for parking restriction, and I just wanted to explain why and how. The sign said “Parking forbidden on working days Monday-Friday between 7:30 and 9:00”. A simple parking:left:restriction:conditional=no_parking @ (Mo-Fr 07:30-09:00) would forbid parking on public holidays - which is wrong. So I had to use parking:left:restriction:conditional=no_parking @ (Mo-Fr 07:30-09:00; PH off).
If we had a counter-concept like WD for “Working day”, then there would have been a different, and more elegant, way to write it, but sadly, this is one of these cases, where I couldn’t find a better solution. But I feel like parking:left:restriction:conditional=no_parking @ (WD Mo-Fr 07:30-09:00) would be a lot easier to read and understand. Sadly, there is no WD
Good question! I was probably not so clear on this. I think I mean two things by a safe tagging method:
Minimize likelihood of consumers misunderstanding the tagging (and consequently making unfortunate decisions)
Minimize likelihood of editors (including future me) misunderstanding the tagging (and consequently making edits that lead to an objectively wrong set of tags.
I have seen both happen:
OsmAnd showing fee=no for parking areas tagged using method A). This might lead someone to take a wasted detour to find free parking, or worse lead someone to not buy a parking ticket and get a fine. Both would be unsatisfying user experiences.
An editor (intending to improve data) changing fee=no to fee=yes in solution A) without modifying fee:conditional. Maybe this editor was not aware of fee:conditional, or maybe they misunderstood the syntax? Anyway, enlightened consumers aware of the both fee and fee:conditional would now probably(?) conclude that there is a fee always (i.e. yes both when conditions specified are satisfied and when they are not).
I also like the simplicity of that! Do you suggest leaving out the non-conditional fee entirely? I had not considered that solution. It is of course enticingly simple, but I’m not sure it is safe enough against misunderstanding for my taste…
Yes, I would write a single row fee:conditional=yes @ (...) instead of two rows.
Anyway fee=yes/no even safe is not correct, since we have a fee at times.
Mappers should take care of two tags i/o one (for example if fee conditions change in the future).
Data consumers like Parking Lanes should interpret all tags including conditional statements, not simply print tags on screen.
Would you expect the below simplified B) to also be legible, i.e. skipping the somewhat redundant “@ 24/7”?