Proposal talk:Parking:position

Not the problem

While I understand the want is to preserve compatibility, I will explain my view that the opposite that should be done: Move *=parallel, *=diagonal, and perpendicular=* to parking:orientation=*. There are several reasons:

1. The position is more important to me as a pedestrian, and likely drivers, on the comfort and physical layout in using the streets. Especially *=on_street "could be easily converted to a travel lane.", and others matters in whether they block the sidewalk or carriageway
2. *=separate is currently separated from *=street_side. This is a break in the concept. Cf cycleway:*=track, cycleway:*=sidepath, and cycleway:*=separate belongs together. Similarly, *=shoulder belongs to them, as in cycleway:*=shoulder.
3. More practical issues exists in the overlap from *=marked and *=painted_area_only that should be eliminated.
4. *=yes and *=no means there exists or doesn't exists parking. *=yes is naturally closer to *=street_side, *=on_street, *=half_on_kerb, and *=on_kerb. It is almost usually *=parallel. The main difficulty is in determining that when unsigned.
5. Their meaning "There is parking space" is more naturally elaborated by where they are, not how they are pointed. Following this, since it is not strictly defined as how the parking spot is laid out, but how vehicles are parked, it may semantically be possible to have a mix when unmarked, eg *=parallel + *:motorcycle=perpendicular, or *=parallel + *:motorcar=perpendicular.

--- Kovposch (talk) 14:50, 11 October 2022 (UTC)

I think, this proposal is not about compatibility, but about (slight) simplification. I know and agree with your thoughts on a fundamental renewal of the parking lane scheme, but (for me) I have decided in the meantime to not further follow this "renewal" approach, because in my opinion the effort for this is no longer in balance with the seriousness of the problems or the consequences of a rewrite (especially since the new StreetComplete overlay has in a way led to a "foundation" of the status quo). Basically, the scheme does work, it just has logical weaknesses and goes its own way in some aspects (since it comes from an very early time of OSM development). Therefore, I now prefer to take the path of slightly changes and additions (the impact of the proposed change is low for users and developers, but the benefits may be significant). The points you have mentioned are therefore, in my opinion, out of scope of this proposal (because they would require this fundamental revision). --Supaplex030 (talk) 16:10, 11 October 2022 (UTC)

Deprecations

That will deprecate many existing uses, right? I would suggest contacting main users (or at least ones listed on taginfo as tag users + AB Street + StreetComplete + JOSM lane rendering (if they support parking lanes)...) Mateusz Konieczny (talk) 17:01, 11 October 2022 (UTC)

Ah, JOSM Presets are a good hint, thanks! The others are already on my list to involve (StreetComplete Parking Lane Overlay/Quest, AB Street, Zlant Parking Lane Editor/Viewer, our own Project in Berlin). If Vespucci etc. are not in the TagInfo Project List, does that mean, that there is no Vespucci preset that need an updated? --Supaplex030 (talk) 18:54, 11 October 2022 (UTC)

It may also mean that its taginfo listing is broken/incomplete/missing (I know that SC one is incomplete and lists only tags added by quests) Mateusz Konieczny (talk) 20:17, 11 October 2022 (UTC)

mechanical edit after deprecation?

It is true that it will be (slightly) easier to parse. However, for any data consumer that wants to support both this new and the old scheme, it instead increases complexity. Having implemented the "old" scheme in StreetComplete, I am not too enthusiastic about this for this reason. But on the other hand, I acknowledge that this probably makes it a bit easier for mappers who add this tag by hand.

Is the plan to do a mechanical edit to upgrade all the old tags to the new ones so the above is not necessary? --Westnordost (talk) 19:31, 11 October 2022 (UTC)

Note that previous changes had not received global bot edit so far (I have run one in Poland - see Mechanical Edits/Mateusz Konieczny - bot account/retag old style parking conditions in Poland) Mateusz Konieczny (talk) 20:18, 11 October 2022 (UTC)

We are currently talking about around 50,000 uses (see table below) - mechanically (under manual supervision) this is hardly manageable. The hurdles for full automated edits are high and I have no experience on this scale. That's why I haven't thought about automated editing so far. However, I would be happy to get hints/support if this could be possible.

When parking:condition was reworked, the JOSM preset, for example, was quickly adjusted so that "old" tags became visible. But this is rather something for local PowerMappers. Maybe it would also be something for a StreetComplete quest?

Number of uses of the previous tagging:

              left    right   both
parallel      11.945  15.733  14.280
diagonal      1.240   1.211   225
perpendicular 2.022   2.059   805
marked        202     204     103            Σ 50.029

--Supaplex030 (talk) 20:58, 11 October 2022 (UTC)

Technically it is simple. The problematic part is getting bot edit permission (which is why almost all bot edits are done in violation of Automated Edits code of conduct - but I am not planning to do this) Mateusz Konieczny (talk) 21:10, 11 October 2022 (UTC)

parking:<left|right|both>

Since you already propose to deprecate an "old style" of tagging (parking:lane:left:parallel=* etc.) and thus necessitate from all data users and editors to implement supporting the new scheme, why not go one step further and remove "lane", i.e.

parking:left=* <- on_kerb, separate, half_on_kerb, on_street, ....

parking:left:orientation=* <- parallel, diagonal, perpendicular

and...

parking:left:maxstay:conditional=2 hours @ (Mo-Fr 08:00-17:00) parking:left:fee=yes parking:left:access:conditional=no @ (Mo-Fr 16:00-18:00)

etc... (i.e. use normal tags for left/right conditions and not an own syntax)

If you think, nah, that's too big, let's refine this tagging scheme bit by bit... well... keep in mind that every such refinement means one more different style to tag the same thing as long as no mechanical edit is made to "upgrade" everything (which is unlikely), driving the parking tagging deeper and deeper into the mud because it becomes more and more complex to parse it. See PTvX schemas. So, tagging schemes are really not something that is fit for continuous refinement. Only when it comes down to adding more detail, but not when it comes down to reforming the scheme --Westnordost (talk) 19:40, 11 October 2022 (UTC)

Oh, I'm very surprised to read that from you :) Because I was actually on the point of proposing such a fundamental rework recently (or join the counter-proposal by Kovposch), but then the StreetComplete overlay came along and I realised that it is too late for that. Because basically the scheme is usable and effort/benefit are no longer in a practical balance (see my reply above to Kovposch).

As someone who works a lot with the parking:lane scheme, I see no further need for changes on the existing tagging apart from the one proposed here (which is also not absolutely necessary, but is an easily implementable improvement). Merely for additions that do not require any changes to the existing syntax (e.g. an additional tag for alternating left and right parking, standardised documentation of how certain situations and restrictions are tagged...).

But if there is a strong tendency in the community to start the "fundamental approach", I wouldn't close my mind to that. But I don't feel that at the moment, do you? --Supaplex030 (talk) 20:58, 11 October 2022 (UTC)

That's jumping one level from what I imagine. User:Kovposch/Proposed features/Parking lane conditionals#Physical Primarily I want to see *=lane, *=street_side, *=separate, and *=shoulder grouped together to match parking=* in parking=lane and parking=street_side.. As a side effect, parking:lane:side + parking:lane:side:attributes will be kept in a different form, to retain a sense of tagging familiarity. If this is not needed or unwanted (or even counterproductive to resemble the old format), I will suggest parking:side:lane:attributes (this is to allow double parking restrictions), with possibility to simplify into parking:side:attributes. --- Kovposch (talk) 09:15, 12 October 2022 (UTC)

Simply using parking:side would be the perfect synchronisation with other highway attributes such as cycleway=* and is very easy to use (parking:right=street_side + parking:right:orientation=parallel + ...). In fact, "double parking" would be difficult to map, as is the existence of a cycle lane and a cycle track at the same time. The most common case is street side parking, and in between there is parking on the lane: Just tag the parking lane and map the street side parking separate. In my opinion, this rather rare case is not worth to break the scheme and thus make it complicated again/desynchronising it again from other common schemes.

The problem is rather how half_on_kerb, on_kerb and shoulder would be mapped correctly. I see three possibilities:

a) Deprecating parking=lane in favour of parking=on_street, parking=half_on_kerb etc. (I don't like that)

b) Keep parking=lane and add parking=half_on_kerb/on_kerb/shoulder

c) Just use parking:right=lane + parking:right:position=half_on_kerb and parking:right=street_side + parking:right:position=on_kerb/shoulder. A bit dirty, but works fine. --Supaplex030 (talk) 10:16, 12 October 2022 (UTC)

I might want B, but we need to think about what to do with amenity=parking + parking=lane areas. ---- Kovposch (talk) 13:10, 12 October 2022 (UTC)

Higher value (not the problem v2)

When I think of the primary value of annotating parking in the map, it is for people who are unfamiliar with an area to find parking. The distinctions of parallel, diagonal, and perpendicular are not as valuable as knowing where I can find parking that I can use. The attributes I suggest you focus on is recording parking policies, e.g. 15-minute parking only, no parking 9am--5pm, pay meter parking, free parking, parking by permit only, private parking, etc. This is orthogonal to the distinctions currently being considered.

(Another more minor point: computer vision techniques could easily classify a parking area as parallel, diagonal, or perpendicular just by looking at some aerial images or street-view images, whereas the parking policies are much harder to obtain. Thus, there is higher value in people's time if they add that information.)

Good proposal, could be even bolder

This is a good proposal. I was maybe a bit too careful with my proposal last year, and I would like to unify the tagging of separately mapped parking spaces and those of parking lanes. I will support this proposal, but I would also support a complete rework of parking tagging to unify both worlds. My main focus was on adding support for conditionals (which succeeded), but like this proposal shows there is still room for improvement. --Riiga (talk) 06:59, 12 October 2022 (UTC)

Ok, I see, the "fundamental renewal" approach still might have a chance (see also the comments of Kovposch and Westnordost). Hands up: Who else would support a fundamental renewal of the parking:lane scheme and perhaps even participate? As stated above, however, the question then arises of how to deal with the old scheme: replacing it automatically might be almost impossible. The consequence would be that for years both schemes might be in use, until the old one slowly disappeared... Developers (StreetComplete, AB Street, Zlant Parking Projects, Berlin Parking Project...) then have to decide whether they want to/can support both schemes or lose data. --Supaplex030 (talk) 07:45, 12 October 2022 (UTC)

I support that. --Matheusgomesms (talk) 14:01, 12 October 2022 (UTC)

Proposal for street parking revision

Since some mappers have stated that a fundamental revision of the parking lane scheme might still be a good idea, I have now started to draw the outlines for it - taking into account earlier ideas that already exist. I am happy about participation or comments:

Proposed features/street parking revision

--Supaplex030 (talk) 14:57, 13 October 2022 (UTC)