I would advocate a more generic approach that remains open to other types of hazards (there are many, unfortunately). A generic hazard:bicycle=yes|dooring|pedestrians_on_cycleway|dangerous_exit|whatever (I have started using provisionally hazard:bicycle=yes plus description= but that needs improvement) Then you putthat that to whatever element is involved (way, crossing node, gate, ...)
In the same way you could create hazard:foot (or hazard:pedestrian), and hazard:wheelchair, and hazard:motorcycle, and hazard:motorcar ..... Or something along these lines ... On Sun, 3 May 2020 at 16:42, Andrew Harvey <andrew.harv...@gmail.com> wrote: > On Mon, 4 May 2020 at 00:30, Hubert87 <sg.fo...@gmx.de> wrote: > >> (Two replies is one) >> >> Am 03.05.2020 um 15:29 schrieb Andrew Harvey: >> >> On Sun, 3 May 2020 at 23:14, Hubert87 <sg.fo...@gmx.de> wrote: >> >>> I like the idea of using "buffered". >>> >>> "doorzone" to me, is a pretty laoded and subjective. >>> >> >> I don't see it as subjective. If there is parking directly next to the >> bicycle lane and if a parked car opening a door would intersect with the >> marked bicycle lane, then the bicycle lane is within a door zone. Is it the >> term that's the issue or the concept? Judging by the wikipedia page >> https://en.wikipedia.org/wiki/Doored it seems like a fairly widespread >> term globally. >> >> I'm familiar with that term and the concept. However 'doorzone' (to me) >> seems to have negativ implications (=> hazard), due to cyclists being >> doored. (If I remeber corectly, cyclelanes/paths next to parking cars don't >> seem to be a big problem in NL due to the "Dutch Reach", this is similar to >> cyclist being right-hooked as it is inherend of the position of the >> cycleway relativ to the carrigeway) >> >> So, I'd rather see the concept of "doorzone" be an emergend property of >> multiple other tags (buffer, position of cycle lane, ...) derived by data >> users/renderes/routers. >> > While that does sound better, it is also quite complex as you point out > taking into account buffer, buffer distance, position of lanes but also > relative ordering of the traffic, parking and bicycle lane, counterflow > cycle lanes. Because of this a quick and simply "doorzone" tag I think is > useful for mappers who don't want to go into such detail. It also makes it > clear, otherwise there could always be a slight difference between data > contributor expectation and data consumer given the complex evaluation > without a dedicated door zone tag. > > > > On Mon, 4 May 2020 at 00:19, Martin Koppenhoefer <dieterdre...@gmail.com> > wrote: > >> do you really need the lane component? >> Could be cycleway:doorzone=yes/no >> or with left/right when lanes on both sides exist that have different >> properties. >> > > Agreed. > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging