(this comment is only regardinbg the "lanes" part of the thread) Date: Thu, 24 Sep 2020 09:30:15 -0500 > From: Paul Johnson <ba...@ursamundi.org> > To: OpenStreetMap talk-us list <talk-us@openstreetmap.org> > Subject: Re: [Talk-us] While we're fixing things in iterations >
> > > Can we finally fix two other longstanding problems, then? > > > > > > 1. The wiki being incorrect about not counting bicycle lanes. The wiki is correctly reflecting the practice in many places, for example in Italy. Almost all users here count the car lanes and not bicycle, foot, combined foot-cycle lanes. If there are different approaches prevalent in other places, then at worst the wiki is incomplete by not listing diverging approaches. > > >That's > > > not reflective of how validators deal with lanes, how data consumers > > > like Osmand or Magic Earth deal with lanes, Can you point more precisely where Osmand and Magic Earth differ from the wiki. or how ground truth works. > Ground truth depends on how you define lanes. If you count bike lanes this <https://www.mapillary.com/map/im/5ZIOO4PlfSIhbmfveSXnnw> is a 4-lane road, if not it's a two-lane road. > > The whole "but you can't fit a motor vehicle down it" argument is > > > facile, that's what access:lanes=* and width:lanes=* is for. > In this argument you forget that hundreds of thousends of roads have been inserted in the OSM database using the wiki definition. > I agree that width is a poor argument for the status quo, especially > > given the common practice (in California, anyways) of bike lanes that > > double as right turn lanes for cars. > As far as I know (rom riding a lot ib California, we are not talking about bike lanes, but, at best, about shared lanes. Example: bike lane <https://www.mapillary.com/map/im/5ZIOO4PlfSIhbmfveSXnnw> disappers, and becomes (unsigned) shared lane <https://www.mapillary.com/map/im/fXPRLaU0nxEtRp_93TYhgw>. > For what it's worth, the lanes=* documentation has long included a > > passage recommending that data consumers treat lanes=* as a minimum > > value rather than a reliable exact lane count. Yes but that statement " Many ways have not yet been tagged with the total number of lanes at all points, but only with the number of through lanes of a longer section. Therefore, data consumers can mostly treat the lanes tag as a minimum rather than an exact number." refers specifically to turn lanes and similar situations. > Apparently some mappers > > only count through lanes but exclude turn lanes. > That seems fine to me especially if the turn lanes are short (ike in the above example in LA. > > Fortunately, editors will automatically fix this and make lanes=* be the > total of lanes:forward=*, lanes:backward=* and lanes:both_ways=*, I think JOSM only complains in case of a n odd numberof lanes. and missing forward/backaward counts > so this > is something that isn't hard to solve long term. The editor won't solve the problem of existing mapping. Hopefully when id gets > lane tools, it does the same thing JOSM does in this regard. > > > I'm pretty sure existing routers would have no problem with including > > bike lanes in lanes=*, as long as bicycle:lanes=* and vehicle:lanes=* > > are both present. So I think a reasonable migration path would be to use > > the bicycle:lanes=* and vehicle:lanes=* tags to explicitly mark the > > non-auto-centric approach you're advocating. > There is no migration path. I would, from my European perspective at least, stick with the present usage and not count any bike/pedestrian lane/horse lanes. The number of lanes is a rough indication for the capacity for motor vehicles of a road. If you want to be more precise you can use the second version of the lanes key as described in this separate wiki page <https://wiki.openstreetmap.org/wiki/Lanes>. Volker Italy, Europe <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>
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
