Talk:Key:parking:condition

Part time paid

How one is supposed to tag cases where paid parking applies to only part of the day? See say https://commons.wikimedia.org/wiki/File:Murnikova_street_01.JPG

Would it be fine to use parking:condition:both=disc ? Mateusz Konieczny (talk) 18:01, 10 December 2021 (UTC)

The complex examples on the page should be of help. I tried to decipher it to my best knowledge.

parking:lane:right=parallel

parking:lane:right:parallel=on_street

parking:condition:right=free (Assuming it is free all other times.)

parking:condition:right:conditional=ticket "Cona 2" @ Mo-Fr 07:00-17:00 (You need a ticket for "Cona 2" on Monday-Friday 7-17.)

parking:condition:right:maxstay:conditional=6 hours @ Mo-Fr 07:00-17:00 (You can only stay 6 hours during the same time.)

--Riiga (talk) 08:13, 28 January 2022 (UTC)

Simplifying the whole thing

parking:condition:*:conditional=* indeed looks really ugly. We have :lane=* and :condition=* and :condition:conditional=* for same the thing - parking on the street. Is it possible to abandon parking:condition and parking:lane at all? Considering this counter-proposal can we end with something more simple like the code below:

parking:right = parallel

parking:right:position = on_street

parking:right = free (free should be implied and not needed, everything is free by default)

parking:right:conditional = no_stopping @ (Mo-Fr 06:00-18:00) (inserting here all conditions)

parking:right:surface = sett

What you think?--Plamen (talk) 12:44, 27 January 2022 (UTC)

How do you plan to tag both parking:right = parallel and parking:right = free on the same object? Mateusz Konieczny (talk) 14:10, 27 January 2022 (UTC)

OK, ':condition' or other suffix is needed indeed unless there is some way to write parking:right:conditional = residents-only-at-all-times-with-no-time-restiction

Parallel or diagonal is also a kind of condition, you can't park freely as you want.

But shortening the whole key looks much better:

parking:right:conditional = no_stopping @ (Mo-Fr 06:00-18:00)

--Plamen (talk) 14:38, 27 January 2022 (UTC)

EDIT:

:lane=* could be substituted with :type=*. (In this case we will abandon only one suffix - :condition=*, not two).

If we have parking = right (on highway) we can omit :right and keeping :condition, but in case different conditions on each side of the street we will use :left and :right.

parking = right

parking:condition = residents; ticket (two categories can park at the same place, so we may need separate :conditional for each one)

parking:type = parallel (all have to park parralel and on the street)

parking:position = on_street

parking:ticket:conditional = yes @ (Mo-Fr 09:00-19:00; PH off) (ticket is needed only at specified times, but residents can park free anytime)

parking:ticket:maxstay:conditional = 3 hours @ (Mo-Fr 09:00-19:00; PH off) (maxstay is for ticket only, not for residents)

parking:residents = A (residents need special permit named "A" to park free)

parking:capacity:disabled = 1 (there is one parking space reserved for disabled persons)

parking:disabled:maxstay:conditional = 3 hours @ (Mo-Fr 09:00-19:00; PH off) (there is a time limit for disabled persons during working hours for free parking)

parking:surface = sett

:: EDIT END --Plamen (talk) 19:28, 27 January 2022 (UTC)

*:type=* is a useless suffix that shouldn't be introduced --- Always be specific. You are still combining 2 conditions in a semi-colon separated multi-value, which is inferior to separate tags.

parking=right doesn't show what it is. Their use in sidewalk=* and shoulder=* is from history. This doesn't work nicely with *=separate.

(To me, an unfortunate result of using *:disabled:*=* in the key is it looks like the attribute is "disabled" turned off)

--- Kovposch (talk) 04:49, 28 January 2022 (UTC)

parking=* + parking:conditional=no_* @ (*) is wrong. You will replace the default parking=* values with parking=no_* at those situations. The purpose of parking:conditional:*:condotional=* is to keep compatibility with parking:condition=*. parking:lane=* has further led to parking=lane, aside from parking=street_side. Any major improvements should take this into consideration. (Cf my User:Kovposch/Proposed features/Parking lane conditionals) --- Kovposch (talk) 04:41, 28 January 2022 (UTC)

parking:conditional=no_parking @ (*) could be wrong, but it could be right if no one is allowed to park at times specified.

parking:ticket:right:conditional = yes @ (Mo-Fr 09:00-19:00; PH off) is specifiyng :ticket mode only. Since we can't add ticket inside the value as per the current wiki for conditional, it should be in the key part. Besides backward compatability what alse keep :condition suffix? --Plamen (talk) 15:39, 30 January 2022 (UTC)

Overall, we still need separate keys to distinguish between the physical presence of parking infrastructure and the rules for how to use that infrastructure. I'd advise against reviving a shortcut akin to the now-deprecated parking:lane=no_parking, which prevented us from expressing situations where parking was only sometimes allowed but there was always a parking lane. But removing the condition/conditional redundancy would be a great thing to tackle in the next round of parking reform. Many jurisdictions apply the same kind of restrictions to street parking that they do to parking lots, so ultimately we need to unify the two schemes. – Minh Nguyễn ^💬 03:50, 9 February 2022 (UTC)

parking:condition for amenity=parking

Question specially to Riiga: I appreciate the changes that took place after the approved proposal on January 22, but I do not understand one: Why was every note removed that "parking:condition=*" can also be used for parking spaces tagged with "amenity=parking" (specially areas) ? And furthermore: onArea for the “Used on these elements” information was changed from yes to no. Why?

I always thought that the proposal only affected the case of tagging parking spaces on a highway=* way – at least it does not say a single word about the use of the tag with amenity=parking areas (or nodes). Was it been forgotten? Or was this perhaps discussed somewhere? But any way: why does the wiki page takes a reduction in the possibilities of use now? I see no need – the changes required by the proposal could have been made without such a restriction, or am I wrong?

I see very good reasons to allow and encourage the use of "parking:condition=* for amenity=parking (of course without the suffix :left|:right|:both) and no reason against it. And IMO this tag is a perfect link between these two tagging methods of parking spaces (on a way/on an area). And it is a very good tagging pair based on the term “parking”.

In my tagging practise I had a lot of cases where I needed parking:condition=* with amenity=parking, specially when parking for residents or parking spaces with "no_parking" conditions in certain time intervalls comes into play – you simply cannot express this clearly with access tags or other tags for amenity=parking, you need parking:condition=*.

A good example is if you explicitly want to draw a street side parking as an area (as a refinement) which was properly tagged before with the parking:lane=* and parking:condition=* tags on a highway way, and of course you want to keep all information including the information given by parking:condition=*.

It is perhaps not very widely used (not yet), but an overpass turbo query found 3577 ways globally. And it could grow I think …

So the simple question is: could it not simply be mentioned again, that it can also be used for amenity=parking (and set onArea=yes again – and onNode=yes for amenity=parking, too)? Or should all the 3577 tags (although not every parking:condition=* key has clean values … as far as I could see) be considered as wrong/deprecated tagging now? I think the status "in use" was correct and OK for this before – and that it does not really need its own proposal (or would this be necessary?), because it's so obvious and all the definitions can be used one to one. Maybe the wording would have to be easily adapted (for me, one sentence at the beginning would do all the job). --Goodidea (talk) 23:10, 10 February 2022 (UTC)

Not sure, wonder if @Riiga: considered parking=lane, aside from parking=street_side and amenity=parking_space. But resident carparks are basically only expressed by generic access=private, and there's already access=customers. There's no parking:condition=employees either.

(Which was why I would like to deprecate parking:condition=* once and for all before, in order to unify with access=*.)

--- Kovposch (talk) 03:24, 11 February 2022 (UTC)

I didn't know parking:condition=* was being used for regular parking areas, I've never come across it myself. For regular parking I've used the fee=* and access=* tags. My intention was to introduce conditional tagging for parking lanes, which led to a cleanup of parking lane tagging. Kovposch had some reservations which I partly agree with, but I didn't want to widen the scope of my proposal. In time, I hope to unify tagging for all kinds of parking by reworking the entire parking scheme, but at the moment I'm working on (finally) tagging the parking lanes in my city. If you do use the tagging of parking areas together with parking:condition=*, feel free to add back that to the wiki. --Riiga (talk) 14:06, 11 February 2022 (UTC)

Also amenity=parking_space, for when individual spaces are marked with the same parking regulatory signs as you'd find along the street. – Minh Nguyễn ^💬 23:21, 12 February 2022 (UTC)

The existing parking:condition=* values should be replaced with parking:fee=* and parking:access=*, so that the parking conditions can be tagged the same way weather as roadside parking tags on the highway=* way or on the parking lot amenity=parking. --Aharvey (talk) 00:40, 19 February 2022 (UTC)

@Aharvey: If parking:access=* is analogous to access=*, then it isn't nuanced enough to distinguish between no parking, no standing, and no stopping restrictions. On the other hand, parking:condition=* also comes with some other nuances, such as indicating the resident zone or permit zone, that would be useful in a broader context as part of a general access tagging scheme. – Minh Nguyễn ^💬 02:22, 23 February 2022 (UTC)

Minimum acceptable tagging

There is road with parking lanes which allows parking and you need to buy a ticket

• only for parking from 10:00 to 20:00 (parking is free after 20:00 and before 10:00)
• except weekends (it is free)

Is it fine to tag it parking:condition:both=ticket?

Or is it better to leave it empty and not tagged? And only allowed solution is to tag it fully ( parking:condition:both=ticket parking:condition:both:conditional=free @ (Su, Mo-Fr 20:00-10:00) )?

(Asking question due to designing support for this in editor and I am considering what is the minimum viable plan for supporting tagging that would be both usable and acceptable)

Mateusz Konieczny (talk) 13:30, 31 March 2022 (UTC)

Tagging it with only parking:condition:both=ticket would be inaccurate, so the minimum tagging would be to add the appropriate conditions or not tag at all. A somewhat acceptable alternative could be to tag parking:condition:both=free;ticket which is accurate, but not precise data. --Riiga (talk) 14:21, 31 March 2022 (UTC)

I agree with Riiga, if you know it's paid during particular hours and free other times it's better to tag both or none at all. --Aharvey (talk) 00:02, 1 April 2022 (UTC)

parking:lane:right=no vs parking:condition:right=no_stopping

Is it fine to tag just parking:condition:right=no_stopping without marking parking:lane:right=no? Mateusz Konieczny (talk) 15:27, 13 May 2022 (UTC)

Yes, it is. Condition and lane are separate properties. --Riiga (talk) 16:38, 14 May 2022 (UTC)

As per my reply on Slack, I would say that based on the wiki, “ No regular road user is allowed to stop their vehicle, except when traffic conditions require them to do so. In addition this also implies that neither waiting* nor parking is allowed.” *Changed to waiting from standing. That the way you tagged it is correct. IanVG (talk) 15:49, 13 May 2022 (UTC)

Standing is the term used on the road signs disallowing this though, so I'm changing it back, unless you have a very good reason to use "waiting" instead. --Riiga (talk) 16:38, 14 May 2022 (UTC)

Multiple conditional parking conditions

On one of the parking examples on https://wiki.openstreetmap.org/wiki/Key:parking:condition/complex we see the following sign:

(With a ticket at the indicated times, except for residents with permit A, and also only in the marked zones on the street)

Then on the page we have the following from this page (among others):

• parking:condition:right=free; residents
• parking:condition:right:conditional=ticket @ (Mo-Fr 09:00-19:00, Sa 09:00-16:00))

Shouldn't the conditional statement be parking:condition:right:conditional=(ticket; residents) @ (Mo-Fr 09:00-19:00, Sa 09:00-16:00))? Otherwise it appears that residents would require to buy a parking ticket according to the logic of the conditional statement

--Popball (talk) 14:27, 7 July 2022 (UTC)

Oh, you are correct. This shows why I want to deprecate parking:condition=*. In *:conditional=*, you should be able to use *:conditional=* @ (residents), so this can at least be *:conditional=* @ (Mo-Fr 09:00-19:00, Sa 09:00-16:00)); * @ (residents). --- Kovposch (talk) 06:54, 8 July 2022 (UTC)

parking conditions on separately mapped parking areas / harmonise access and parking:condition tags

For your information, and because I don't know if all the interested followers of this page are frequent readers of the tagging mailing list: I have started a discussion that addresses ambiguities between tagging at linear and area street level parking features and once again that raises the question of whether the parking:lane/condition scheme needs a fundamental reworking or just some minor pragmatic adjustments. Please feel free to participate with your opinion there:

Mail on Tagging Mailing List | Wiki proposal/discussion page.

--Supaplex030 (talk) 13:42, 2 September 2022 (UTC)

Using strikethrough for all deprecated tags

What do you think about formatting all deprecated tags on this page with strikethrough? This could also be done with parking:lane=*. When getting linked to a section of such page there is no indication you should not keep using these tags. In places like tables you could also suggest the new alternative tags, which are not deprecated. --Pasui (talk) 13:18, 15 June 2023 (UTC)