May I injection another complication: In many jurisdictions the width available to the moving traffic is defined by white lines on the tarmac creating an additional safety/buffer zone between the marked parking spaces and the flowing traffic.
On Tue, 29 Sep 2020, 12:52 Pieter Vander Vennet, <pieterv...@posteo.net> wrote: > Hey Alex, > > First of all, I didn't consult the community for this project, I just > wanted to get it rolling. We pondered a long time about how to measure > for our local situation, not about what would be the most appropriate > tag for use worldwide. Sorry for that and again, if in these discussions > a better consensus pops up, I'll retag. > > I included parking lane width, as in some cases there are no lines on > the ground indicating where the parking lane begins. We just have a > traffic sign indicating that parking is allowed. As a result, the area > available for traffic can vary when a very small car or very wide car is > parked - the main reason we went with a curb-to-curb distance - > including parking-lanes. > > The actual width available for traffic is then calculated based on OSM > data. Can cars go in one or two directions? Can bicycles go in one or > two directions? Are sidewalks present? > > I understand that 'width:carriageway' is confused with the room > available for traffic. On the other hand, parked cars are a 'carriage' > as well ;) > Furhtermore, in my opinion, saving a 'width:traffic_area' directly into > OSM is unnecessary (as an indicative value can be calculated from the > other, more objective properties) and is even a bit subjective and prone > to change (e.g. due parked cars). Did you know that the avarage car has > gotten ~30cm wider since 1960? This means that the calculation of > 'traffic_area' should be changed every few years. > > Also keep in mind that in the city center of Bruges, where we did those > measurements, we don't have the 'half-on-curb' rules and have only a few > perpendicular/diagonal parking lanes (which I conveniently ignored). > > Anyway, I'm not planning on getting too involved in this discussion (I > have other things to do). However, Alex, I would propose to turn around > your logic: not to map the traffic area, but to map 'width:carriageway' > as 'curb-to-curb' distance, and mapping the 'parking:lane:left:width' > and 'parking:lane:right:width'-values. If the parking lane doesn't have > lines (and thus the width isn't well defined), software can choose a > sensible default for the region. This would also work for > 'half-on-kerb': if there is a line, one can use the line to determine > the width. If not, software can use a sensible default. > > The drawback of this scheme is that software which wants to work with > this data should be somewhat complicated right from the start. > > -- > Met vriendelijke groeten, > Pieter Vander Vennet > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging