On Fri, Sep 25, 2020 at 11:49 AM Volker Schmidt <vosc...@gmail.com> wrote:
> (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. > They actually treat all lanes as lanes when all lanes are mapped. They're automatically providing incorrect lane guidance when tagged to the wiki, as the wiki specifically asks people to omit lanes. > 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. > It's a 4 lane road. That's how lanes works in the real world. > > > 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. > Just because it's time consuming to fix doesn't mean we shouldn't bother fixing it. Or we'd have just thrown in the towel after the OBDL relicensing. > > 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>. > It didn't disappear so much as it became motor_vehicle=yes. Probably a good situation where mode:turn:lanes (ie, bicycle:turn:lanes, motor_vehicle:turn:lanes) may need to come into existence. > 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. > Except this breaks data consumers from being able to provide accurate lane guidance. > The editor won't solve the problem of existing mapping. > Maproulette can help organize fixing this. > 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. > "Fuck accuracy, fuck ground truth" --you.
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
