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