For a few years now, I've been considering to make a proposal for mapping PT in a simpler way. I haven't done it because it's a lot of work and there will always be quite a few mappers who prefer the status quo.
Anyway, I think we need 1 object which has all the properties of a stop as tags and which is used in the route relations. A single object per stop, preferably not 2 for each stop. That part I've been pushing it slowly all along. Regarding the itineraries, I think we should also start looking into how we can simplify that in such a way that maintenance becomes easier for the mappers. So what if a route relation would consist of an ordered set of stops and a link to another relation for the itinerary. This other relation contains only relations. Those relations contain the ways for a 'segment' or an 'edge'. It's these small relations that get broken occasionally when mappers split or combine ways. When this happens only those relations need to be fixed and the effect will be that all the itineraries that use them are fixed in one go. There is more 'indirection', which may seem more complex at first sight, but we can create tools to visualise the effect of the combined set of relations in JOSM and I guess it can be done in iD as well. As far as maintenance goes, this would simplify matters a lot. Let me know if you think it makes sense to start a proposal for this. The student who works on PT_Assistant this summer is laying the groundwork for going into this direction. Polyglot On Sat, Aug 3, 2019 at 11:33 AM Joseph Eisenberg <joseph.eisenb...@gmail.com> wrote: > Re: > The relation needs both stops and ways > > Sure, it's nice for rendering the have the ways, but it's not always > necessary. > > There are 2 cases where you can only do one or the other > > 1) Stops only: The buses don't always take the same route between > stops, but just take whatever way is fastest. This is common for > long-distance buses between towns, and in non-Western countries for > all sorts of buses. In this case, just the stops are needed. > > 2) Ways only: the bus follows the same streets, but will stop > anywhere. This is the standard for all minibuses in Indonesia, and in > many other countries. In this case there are no bus stops, except at > the start and end of the route. > > It's great to include both when possible, but I think it we should let > new mappers know that they can just start with stops or just start > with the ways, if that's all they know. > > On 8/3/19, Warin <61sundow...@gmail.com> wrote: > > On 03/08/19 11:19, Joseph Eisenberg wrote: > >> Yes, the only thing that needs to be changed is the documentation, in > >> my opinion. We don't need more tags, and it's not even necessary to > >> officially "deprecate" anything. > >> > >> Right now some pages suggest that a bus stop needs to be tagged > >> highway=bus_stop + public_transport=platform + bus=yes at the location > >> passengers wait, and that you also need a > >> public_transport=stop_position + bus=yes next to this point (on the > >> highway), and a type=public_transport relation with *=stop_area, which > >> includes the 2 features, and maybe they all need a name or ref? Oh, > >> and you need to make a type=route relation which includes at least one > >> of these features, or maybe all of them, in addition to highway ways? > >> > >> That's 3 features with at least 10 tags, to define a simple bus stop, > >> before you even make the route relation. > >> > >> But really all we need is highway=bus_stop + name=* or ref=* - 2 tags, > >> to define a bus stop. And the route relation needs either the stops or > >> the highways added (you could add both, but this isn't really > >> necessary), plus maybe a ref, duration and interval, if known. > > > > The relation needs both stops and ways. > > > > Not every stop along a route may be used by service. > > > > The simplest way that a router finds between 2 stops may not be the > service > > route. > > > > The stops don't need a name or ref .. but they could be handy. > > > > The route relation does not need an operator, a name etc... but the name > > would be appreciated, and other tags could be handy too. > > > > > >> More > >> complex tagging is only helpful at interchange stations - and maybe it > >> isn't even necessary there, if the routing application is developed > >> well. > >> > >> It would be nice if we could present this situation as the recommended > >> and sufficient method for mapping bus routes - which are by far the > >> most common type of fixed-route public transport globally - especially > >> for new mappers. > >> > >> The public_transport=* tags would still exist and still would be > >> documented clearly on their own wiki pages, but the main features > >> lists and the page Public Transport could make it clear that these are > >> optional, not required. > >> > >> On 8/3/19, Daniel Koć <daniel@koć.pl> wrote: > >>> W dniu 03.08.2019 o 02:28, Joseph Eisenberg pisze: > >>>> Consider also how you would route someone from a amenity=cafe node in > >>>> a building to a shop=* area in another building across the city, by > >>>> car. You have to jump from the node to the nearest highway, follow the > >>>> highways to the other side of the city, and then jump back to the > >>>> other node. So any router than can handle automobile directions can > >>>> also manage bus stops or tram stops or platforms at the side of the > >>>> road, without needing anything other than highway or railway ways and > >>>> platform or bus stop nodes. > >>> I guess this is the example where this simple analogy fails: > >>> > >>> https://www.openstreetmap.org/node/334559271 > >>> > >>> The route for personal journey might be undefined on the ends (drivers > >>> just use their eyes there), public transport routing is more strict. > >>> > >>> > >>>> I wasn't able to understand enough of the link about updating transit > >>>> features in Warsaw to see how the stop_position nodes were useful. I > >>>> understand that some transit agencies provide data about stop > >>>> positions, and that's the original reason that the stop_position nodes > >>>> were created. There's no problem with keeping them in your city if you > >>>> like them, but probably we shouldn't tell new mappers that they are > >>>> needed, for example in developing cities around the world that > >>>> currently lack any bus stops. > >>> Sorry for asking, but you probably know this documentation quite good - > >>> do we really tell people that every element of a public transport stop > >>> is needed just because it's documented somewhere? > >>> > >>> > >>>> The complexity of the current system, as described on the main pages > >>>> in the wiki, can discourage mapping anything (for example, I've been > >>>> discouraged from trying to add any of the minibus routes in my part of > >>>> Indonesia, since it seemed so complicated to make so many features and > >>>> routes). > >>> So maybe documentation should be just cleaned? And if I understand you > >>> wrong, could you describe what was your problem there? > >>> > >>> > >>> -- > >>> "Pojechałam truizmem, ale mogę, bo jestem trochę pierdołą" [P. Potocka] > >>> > >>> > > > > > > _______________________________________________ > > Tagging mailing list > > Tagging@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/tagging > > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
