Proposal talk:More parking

Compact

parking_space=compact might be tricky because its semantics vary from country to country (as mentioned on the ML). I think it would be good to define this value as pertaining to parking spaces that are explicitly marked as being such (e.g., by signs or marks on the ground), to prevent mappers from using their own judgement. Any app that wants to do really clever stuff such as 'can I park my 6m long pickup truck here?' should just use the drawn dimensions of the parking_space=*. JeroenHoek (talk) 09:42, 9 August 2020 (UTC)

Also as discussed on the mailing list, that is, in fact, the plan. I'll update the proposal to make this more explicit. Mwoehlke (talk) 12:31, 10 August 2020 (UTC)

Charging

Dedicated parking spaces for charging electric cars are rapidly becoming more and more common. Excellent plan to commit to one variant for that (parking_space=charging). JeroenHoek (talk) 09:45, 9 August 2020 (UTC)

Woman

Dedicated parking spaces for women. After Germany, places like Korea and China also adopted this policy. It soon became a law in some regions of Germany that at least 30% of parking spots must be for women and they were made for safety reasons and to reduce the risk of sexual assault. (cit. Wikipedia) --Aury88 (talk) 17:07, 16 August 2020 (UTC)

Expectant Mothers

Some parking areas have some of their parking slots reserved for women in the later or more intense stages of their pregnancy, so something different from a parent_and_child parking slot --Aury88 (talk) 17:07, 16 August 2020 (UTC)

Necessity

Is there any case where this can't be handled by access restriction, conditional restriction (a text comment would resolve unknown dimensions and "Note also that such spaces typically do not have a defined time limit, so trying to shoehorn them into time-limited parking is not really appropriate"), and existing key such as maxlength=* if the dimension is known? parking_space=compact and capacity:compact=* show values would easily conflict as well. -- Kovposch (talk) 08:43, 17 August 2020 (UTC)

If mapping can be done this way, shouldn't we deprecate capacity:handicapped=* too? How would you tag a carry-out parking space using only access restrictions? It seems like such an approach would just be more difficult for both mappers and consumers. Any approach relying on free-form text is a recipe for being practically unusable. As for "parking_space=compact and capacity:compact=* show values would easily conflict as well", I don't understand how? Can you please clarify? Mwoehlke (talk) 13:54, 17 August 2020 (UTC)

On the contrary, how do you tag a "compact" or motorcycle parking spot for takeaway or charging under this scheme? I know there are even attention to making sure handicapped parking spots have charging facilities. I doubt this is flexible enough.

motorcycle=* and disabled=*are more or less common legal access keys. It isn't a good idea to mix them in under parking_space=*. I won't rush to endorse parking_space=disabled by this chance. Purely numerically, there are combined ~14k disabled=* + access:disabeld=* (not to mention ~80k capacity:disabled=*), compared to ~22k parking_space=disabled. While I like *:conditional=* more overall, this is preferrable to parking_space=disabled. Let's consider how to construct the syntax of capacity=* later.

Ttreating "compact" as a general physical description of the parking spot is the most reasonable value to propose for parking_space=* I see here, for the "unknown dimension" situation I mentioned.

Whether a parking spot is equiped with or designated for charging should be dealt separately.

My note is if there's no established syntax, conditional restriction will allow more complicated conditions to be tagged relatively standardly, or text can be used as a final fall-back. You can obviously put takeaway or anything recognized as a condition.

-- Kovposch (talk) 07:55, 18 August 2020 (UTC)

Park&Ride, Kiss&Ride

There are some spaces signed as Park&Ride (P+R) or Kiss&Ride (K+R), which are designed for people going to work from subarbian area. First one is to get to public transport, the second one is to stop for a moment just to let your passenger get on the public transport. - Kocio (talk) 08:59, 17 August 2020 (UTC)

For "(Of course, this begs the question whether we should also add parking_space=pick_up or some other mechanism for indicating standing spaces?) ", I have found parking:lane=no_standing in use for on-street parking before. -- Kovposch (talk) 08:43, 17 August 2020 (UTC)

(I moved talk's comment in order to reply to both of these...) I'm rather strongly inclined to not get into the whole "parking" vs. "standing" vs. "stopping" debate for this proposal. This proposal has enough moving pieces already. IMHO it would be better to try to address these questions in a separate proposal. Mwoehlke (talk) 13:54, 17 August 2020 (UTC)

It looks to me that P+R is really a parking feature (vehicles are there for hours), while K+R belongs to stopping/standing. --Kocio (talk) 14:03, 17 August 2020 (UTC)