Proposal talk:Key:cycleway:doorzone

From OpenStreetMap Wiki
Jump to navigation Jump to search

Adding a few examples

--Hubert87 (talk) 13:04, 14 February 2021 (UTC)

First one would still be cycleway:doorzone:left=yes as I think keeping it all prefixed with cycleway is best. I can try to add more examples, but feel free to add them yourself too. --Aharvey (talk) 21:37, 15 February 2021 (UTC)

Subjective tag

For reference, the link to the older discussion (on a similar proposal) http://gis.19327.n8.nabble.com/Doorzone-bicycle-lanes-tt5964651.html#none

  • I still think this is an emergend property and a subjetive one.
  • while initally more work, I would rather tag a combination of

and maybe something like

--Hubert87 (talk) 13:04, 14 February 2021 (UTC)

Yes, I don't see how this will work with cycleway:separation=* yet. Apparently, Proposed_features/cycleway:separation#Forms_of_physical_separation rasied the idea of hazard:bicycle=door_zone. ---- Kovposch (talk) 04:26, 15 February 2021 (UTC)
1. I think the subjectiveness only comes into play when it's close. Many of the times though it's either obviously in the doorzone (because the whole door overlaps the whole lane) or obviously not (no parking).
2. buffer/buffered doesn't describe if there is a risk of being doored because it doesn't say if there are parked cars on the other side of the buffer or not. It could just be buffered from the gutter or shrubs etc.
3. You could think of it as a hazard I guess, generally I think of it as a property of the cycle lane as being a "doorzone" cycle lane. Is the hazard tag any better though? --Aharvey (talk) 21:44, 15 February 2021 (UTC)
Doorzone is objective : if a cyclelane is narrower than the width of a cyclist + safety width to avoid an opening door, the cycle lane is in the doorzone.--Florimondable (talk) 09:12, 22 February 2021 (UTC)

Deprecation

I would like to suggest to include deprecation of cycleway:lane=doorzone and its retagging to new format into the proposal. Although there are currently only few cases, there is still a chance that some would continue using this old tag and it would become another case of double tagged feature. Better to pull the weeds before they spread. --Mashin (talk) 17:01, 14 February 2021 (UTC)

Have added that, so if approved can mark the current tag as deprecated. --Aharvey (talk) 21:23, 15 February 2021 (UTC)

Should not be explicitly mapped

In my opinion, this should not be mapped as a property of the cycle lane as it is a result of the proximity of two different features (the parking area and the cycle lane). To me this feels like adding a tag "near_primary_road=yes" to a building when it sits on a primary road. If the fact that the cycle lane is dangerous cannot be established by looking at the existing features then we should improve the tagging to a point where the danger of "dooring" accidents can be computationally derived from the data, rather than having mappers put a thumb in the air and take a guess. Additionally, there are two people involved in a dooring accident, and while the motorist will not suffer injuries, they would certainly prefer to avoid the accident too. If the cycle lane is explicitly marked as being subject to risk of dooring, should the parking area not also be marked? But as I said, to me it would be preferable on improving the data to a point where we can deduct the risk, rather than mapping the risk explicitly. Willing to accept if this was clearly marked as an interim solution until such time that automatic deduction is possible (like is_in which is now obsolete because we have enough data to compute it). --Woodpeck (talk) 12:53, 21 February 2021 (UTC)

If a cycleway isn't being mapped as a separate way, I don't think "near_primary_road=yes" would be a good analogy. However, this proposal does provide for a cycleway:doorzone=buffered, which is an objective attribute. – Minh Nguyễn 💬 22:38, 21 February 2021 (UTC)
But all cycle lanes are mapped on the same OSM way as the road way. And this makes sense, cause it just as much belongs to the carriageway as the individual (car) lanes. In particular, sometimes the cycle lane is not even the right-most lane (at intersections). I mean, what else do you suggest? How could it be automatically derived if the parking lane is too close to the bicycle lane, i.e. there is no buffer? The cycle lane width? That's not enough, because the cycle lane may not be directly adjacent to the parking lane (there may be a buffer).
What could maybe work would be something like cycleway:width=* (proper width of lane) + cycleway:buffer_width=* (width of buffer to gutter/parking lane). For the case that there is a parallel parking lane, data consumers could look at whether there is a buffer, and if not, whether at least the cycle lane is broad enough so that cyclists do not need to enter the doorzone of parking cars --Westnordost (talk) 01:06, 22 February 2021 (UTC)
Correction, I noticed that there is already cycleway:buffer=*, which describes the width of a buffer to the left (in countries with right-hand traffic, otherwise to the right), i.e. the buffer width to the next car lane. So it would be very confusing to have another similarly named tag that is supposed to be the buffer towards the other side. --Westnordost (talk) 19:20, 15 July 2021 (UTC)
There are standard specifications which describe the necessary distance between the cycle lane and the parking lane. In Germany, a distance of 50 cm to parallel parking cars is seen to be sufficient, a distance of 100 cm, if the cars park in an angle to the cycle lane. The distance depends also on the type of the cycle lane. A complication arises from 'lazy parking' cars, or SUVs, which are bigger than the standard size of a parking lane, which is 200 cm in Germany. Therefore, I would follow User Woodpeck, to deduct the security level of a cycle lane by other means. --Mhaelsig(talk) 07:12, 22 February 2021 (UTC)
Well, so you are basically saying that cycle lanes that are too close to the doorzone do not exist. In Germany. Fair enough. But then, this tag doesn't need to be used in Germany then. In other countries, there may be less strict rules what the traffic planning department may declare as a cycle lane and what not. Though I would say... for Schutzstreifen (~advisory cycle lanes), those rules do not apply because their use is not mandatory - so those advisory lanes might as well be in the doorzone, actually. --Westnordost (talk) 19:20, 15 July 2021 (UTC)

Specific Key vs. general approach

I agree that we need tags to describe more aspects of cycleways, especially regarding their (not existing) safety features. But, there needs to be a common approach that fits to all needs and not several proposals of different tags in parallel.

Especially the last link looks like a well designed scheme that should be put into a proposal, instead of introducing single tags individually.--Mueschel (talk) 08:54, 22 February 2021 (UTC) This seems

This seems a more sane and usable approach to me that a simple "doorzone". --Gileri (talk) 10:50, 25 February 2021 (UTC)
I read through the Verkehrswende page. It's in German. I am really looking forward to the stuff that is proposed there to be put into a proposal! It's not that much new stuff but it is a very thorough explanation with examples and also incorporates all the things we already have, f.e. Key:cycleway:buffer. Go Verkehrswende guys, we need this as official documentation! --Westnordost (talk) 19:38, 15 July 2021 (UTC)
A while ago we created a proposal to document the cycleway:separation scheme (which is the most important innovation of the Berlin cycle lane scheme). I already use it to evaluate dooring zones in my area by searching for adjacent parking lanes (*separation:right=parking_lane*) and missing buffers (*buffer:right=no/none/0/<x). In some cases, the parking lane can also be on the left, i.e. between the cycle lane and the traffic lane, so it is also worth looking to the left ;) --Supaplex030 (talk) 21:14, 20 January 2022 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Key:cycleway:doorzone&oldid=2514902"