> routes without fixed stops can easily be represented using only via points > and stop positions
I think you mean "bus stops" (or railway platforms), not "public_transport=stop_position", since those nodes are usually unnecessary, and are not added by most mappers for bus routes. Routing apps can easily calculate the location where the bus stops based on the location of the "highway=bus_stop" next to the way. Creating "via points" seems more cumbersome than adding the highway ways to the relation when the route is "hail-and-ride", especially since a via point would not represent a real-world feature in that case. I understand why user Stereo would like a clean, simple solution. But realistically, both mapping methods are going to co-exist (this is already the case). It is most likely to be accepted if the proposal does not attempt to call anything "deprecated" or force anyone to use the new mapping style. It would be enough to say that "adding all the bus stops or platforms and all the highway or rail ways to the relation is not necessary, one or the other is enough", and for database users to be prepared for handling both types of route. - Joseph Eisenberg On 3/8/20, John Doe <music.kash...@gmail.com> wrote: > > As mentioned in the Caveats section of the proposal, hail and ride _has_ > been in our thoughts. 🙂 > > (Buses operated by NMRTC in Noida are all hail and ride, and so are all > share autos in Delhi, making it quite important for me personally.) > > My idea, initially, was to have this proposal serve as an extension to PTv2, > falling back to PTv2 (way-based relations) for hail and ride routes. > However, Stereo leans towards it replacing PTv2 [1] - routes without fixed > stops can easily be represented using only via points and stop positions. A > single tag (say, hail_and_ride=yes) on the relation can establish it as > such. Nice and simple - hail and ride with no icky way segments 🙂 > > Now that might suffice for most situations, but I for one liked the > flexibility of marking specific sections of a route as hail and ride - I > like to mark intersections, for instance, as places where hail and ride > vehicles won't stop under normal conditions. To cater to this - _if_ the > community considers it worth catering to, because I wouldn't be surprised if > some consider it unnecessary micromapping - Stereo suggested making new > roles for via points, e.g. begin_hail_and_ride and end_hail_and_ride. This I > find somewhat inelegant. > > What do you think? > > [1] I'm personally quite undecided on this. There are numerous upsides and > downsides to both approaches. > > 07-Mar-2020 19:44:34 Paul Allen <pla16...@gmail.com>: > >> On Sat, 7 Mar 2020 at 02:30, Joseph Eisenberg < joseph.eisenb...@gmail.com >> [mailto:joseph.eisenb...@gmail.com] > wrote: >> >> > However, there are also public transit services where the bus can stop >> > anywhere along the route. This is the most common type of bus here in >> > Indonesia. In this case there are no fixed stops except for the 2 end >> > points, but the minibus follows the same streets and passengers can wave >> > their hand or request a stop anywhere along the route. >> >> Rural routes in the UK are often similar, except there are designated >> stops (sometimes with a shelter, sometimes just a sign, sometimes >> unmarked) along the way. Most (sometimes all) of the route is "hail and >> ride." This can even happen in small towns (well, at least one town I >> know of) where much of the route is also "hail and ride." In that >> particular town, some of the new timetabled stops lack shelter and sign >> (but that's OK because that part of the route operates as "hail and ride" >> anyway). >> >> > >> > So, I support the idea of allowing mappers to just add the bus stops to >> > the relation when this is the most verifiable and easiest to maintain, >> > but there are some cases where this will not work, so it should still be >> > permitted to map the ways for non-fixed-stop services. >> >> +1 >> Not just permitted, but the documentation should explicitly state this. >> Not just for legacy routes (I don't see a mass upgrade happening) but >> also for new routes. This must be an alternative, for use where the >> mapper feels it is easier and/or gives better results. Maybe even a >> preferred alternative, but still just an alternative. >> >> -- >> Paul >> > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
