>To me it seems obvious that width values, independently on how they are >measured, are at best estimates, as measuring them is in most cases >dangerous or requires good technical equipment.
I don't think this is true anymore. Did you try out "Measure" or any other ARCore/ARKit-based measuring app? Example: https://m.youtube.com/watch?v=qz0YJ0s4JLM Am 20. September 2020 00:01:00 MESZ schrieb Volker Schmidt <vosc...@gmail.com>: >Some thoughts that trouble me... > >To me it seems obvious that width values, independently on how they are >measured, are at best estimates, as measuring them is in most cases >dangerous or requires good technical equipment. I guess that most width >values in the database are reality estimates (I don't think that this >is an >unjustified extrapolation from my own mapping - 99.9% of my width >tagging >based on estimates). Estimates are relatively easy for narrow roads if >you >have street-level photographs. They become much more unreliable for >wider >roads. I solve this by using only lanes count for wider roads. Precise >width measurements are difficult to impossible, but fortunately they >are >also less important than the lanes count for the end user. > >The discussion about including/excluding sidepaths/sidewalks becomes >also >irrelevant if we were only to use the lanes count as that counts only >motor >traffic lanes. > >Would also overcome another aspect of the width definition: If we use >width >for the entire road, i.e motor-traffic lanes, shoulders, sidewalks, >cycle >lanes/tracks/paths, tree rows between foot and cycleway, ... we do in >the >end not know enough about the the actual widths of the different >component >"lanes". > >Width values are useful and easy to estimate from street-level >photographs >for sidewalks, cycle paths/lanes/tracks, certainly to within 0.5m >precision. > >We need in any case a good system for regrouping parallel ways that >belong >to the same street. >A relation seems to me the better option, but in any case, whatever >approach we pick now, we will face an nearly impossible amount of >retrofitting work. Anything we do on this from now will not make the >problem go away with the existing stock of data. > >Volker > > > > > > > > ><https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> >Virus-free. >www.avast.com ><https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> ><#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > >On Fri, 18 Sep 2020 at 22:35, Tobias Knerr <o...@tobias-knerr.de> wrote: > >> On 17.09.20 02:35, Taskar Center wrote: >> > This is yet another example why "sticking" the sidewalks onto the >> > highway (as a tag) rather than mapping them as separate ways is >> > appearing to be less and less practical. Please see our sidewalk >schema >> > proposal >> > ><https://wiki.openstreetmap.org/wiki/Proposed_features/sidewalk_schema> >> > from several years ago. >> >> Your sidewalk proposal unfortunately doesn't really address the >crucial >> shortcoming of separately mapped sidewalks: The lack of a reliable >> mechanism for figuring out which section of road a given sidewalk way >> belongs to. >> >> I agree that we should be able to give sidewalks their own geometry, >but >> we _also_ need the relationship between sidewalk and road. So far, >all >> the proposals attempting to support the former end up sacrificing the >> latter. >> >> There have been some promising discussions recently around the >> sidepath_of idea, but that's still just brainstorming. Until a >practical >> solution is found and actually used in the database, sidewalk mapping >> will remain a choice between two options that are broken in different >ways. >> >> As for the main issue of the thread: I would welcome a clear >definition >> for the meaning of width. In my own mapping and when writing the >> relevant code in OSM2World, I have counted sidewalks etc. as part of >the >> road's width if they are mapped as tags on the main way. But I would >of >> course change that if there finally was a documented and widely >> agreed-upon recommendation. I don't care so much which one it is - >but >> we need one. >> >> _______________________________________________ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
