# How to best tag time conditional parking fees?

Hi,

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?)

``````fee=yes
fee:conditional=no @ 24/7; yes @ (Mo-Fr 09:00-15:00)
``````

(+) 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:

``````fee=yes
fee:conditional=no @ (Su-Sa; Mo-Fr 00:00-09:00; Mo-Fr 15:00-00:00)
``````

(+) Has safe fee=yes
(-) Has hard to maintain conditional specification, that does not match sign.
(+) Works (if you get it right)

## Solution D (Hypothetical complement operator)

Use a complement operator (does it exist already?), for example “~”:

``````fee=yes
fee:conditional=no @ ~(Mo-Fr 09:00-15:00)
``````

(+) Has safe fee=yes
(+) Allows specification of time windows as signed
(small -) Has double negative in conditional

3 Likes

I agree that `option B` should be the best, it looks to me like it should work, so you should report bug at Issues · zlant/parking-lanes · GitHub

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)

4 Likes

Ok, at least I understood the syntax then Would you expect the below simplified B) to also be legible, i.e. skipping the somewhat redundant “@ 24/7”?

``````fee=yes
fee:conditional=no; yes @ (Mo-Fr 09:00-15:00)
``````

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…

For the record, it seems like someone else has already found the conditional/default combination complex: Tagging conditional parking restrictions seems very uncomfortable/error-prone · Issue #139 · zlant/parking-lanes · GitHub

Probably not. I thought it should work too at first and even almost recommended it, but then I took a closer look at that extended BNF syntax at https://wiki.openstreetmap.org/wiki/Conditional_restrictions:

``````<restriction-type>[:<transportation mode>][:<direction>]:conditional
= <restriction-value> @ <condition>[;<restriction-value> @ <condition>]
``````

and it seems to say that `@ 24/7` must 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 not `fee=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.

2 Likes

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)

1 Like

Thanks for staying with me

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

1 Like

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.

Stupid question: would the `off` modifier not work like a negation?

``````fee=yes
fee:conditional=no @ (24/7; Mo-Fr 09:00-15:00 off)
``````

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.

Thanks for the response, it sounds like we agree on the general principles!

Very interesting!

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?

1 Like

I prefer single tagging like:

``````fee:conditional=yes @ (Mo-Fr 09:00-15:00)
``````

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

2 Likes

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).
2 Likes

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…

I think I agree! We cannot solve all problems for consumers. Then, I guess, it comes down to a balancing of various desired qualities in a solution:

• readability (for a human editor)
• compatibility with legacy consumers (e.g. unaware of `fee:conditional` and `fee` now changed to being the default for that)
• exact representation of the real world

What do you think of the `fee=conditional` + `fee:conditional=...` idea?

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.

1 Like