The basic objection they voice is why need 2 tags, if 1 does the job. highway=bus_stop
is not exactly nonsensical. It's concise and expresses what is meant. (OK, it's not a highway and my preference is to map it next to the highway) public_transport=platform was designed at first to not need a mode of transport like bus=yes/tram=yes. I am the one who proposed adding it, so that it COULD start replacing highway=bus_stop back in 2012. There is not always a platform present, so it's a bit of a misnomer as well. Anyway, someone who wants to render a bus stop ideally wants to look at a single tag, not a combination of 2, apparently. For a long time it was supposedly a technical problem, but as soon as that was resolved somewhere around 2017, it was still considered problematic to look at 2 tags. I wish you good luck with proposing another way of mapping public transport. Many have tried before you. It's really hard to beat status quo. And the status quo is not the same across the planet. If you can propose something that is both simpler, more elegant and still expressive enough for all usecases, I'll vote yes on it. Polyglot On Tue, Apr 28, 2020 at 10:26 AM Robin Däneke <ro...@daeneke.at> wrote: > Indeed, these are good points. I would say, that the „platform“ is enough. > This could then mean either the „stop pole“ of the station (which I would > not say is the most important piece as that could also just be a sticker on > a shelter or a lamp post) close but not at the station (sadly there are big > inconsequent uses in real life), or the area of the visible platform, if > applicable. > > But the rest of the community will have to accept the death of (old) tags, > when it is voted for. If this mailing list could come up with a proposal > most users here could live with, we all vote for it (with the spelling of > the end to certain tags) and it is accepted that way, the community will > have to accept that. The first iteration was just to „nice“ to that > conservative fraction. Public transport can be complex, but this is why it > needs dedicated (own, simple) tags instead of legacy nonsense. > > This is, why I would be happy to have many people work on this „ideal“ > solution, that is simple on the one hand, but powerful on the other hand. I > will make a Document where I put in my personal critique and goal for a new > scheme, and am then looking forward to input on it. Will share it here when > I have a framework of what the current scheme says and have some changes in > it. Then, the specifying of the bus lines, the simplifying of the bus > stations (so that one or two tags can replace bus_stop but still do the > same thing functionally) and other points could be put in there. > Maybe we actually end up with a useful consensus, that one could propose. > > The more people get on board, the more acceptable it can become... > > KR > RobinD > > Am 28.04.2020 um 10:07 schrieb Jo <winfi...@gmail.com>: > > For years and years we have tried to convince the people working on carto, > our default rendering to start supporting public_transport=platform/bus=yes > instead of highway=bus_stop. > > They have clearly stated that this will never happen. Conclusion: > highway=bus_stop is NOT a legacy tag. > > That's my conclusion anyway. In Belgium I'm even considering to drop > public_transport=platform on the bus stop nodes, but that's not > straightforward either anymore,, since the editor software started to > depend on them. > > stop_position nodes, I have never considered them to be important, so I > never mapped them for ALL the stops. I do map them for initial and terminus > stops, was I want to split the way there anyway. What I will definitely not > do, the way I see it done in Germany is to duplicate information. > > I want to have a single object, preferably a node, that has all the > details of the stop AND I want to include this object in the route > relations. 1 object per stop, so not a sequence of > stop_position/platform/stop_position/platform. > > As I don't consider the stop_position nodes to be important enough to map > them everywhere I don't put name/ref/ etc on them. In Belgium most > stop_position nodes will have only 1 extra tag, the mode of transport. > > For me it's an advantage that highway=bus_stop can only be used on a node. > I want to map the object that represents the bus stop as a node anyway, > next to the highway on the side where the passengers wait. > > If there is a physical platform, then it makes sense to map it as a way or > a closed_way/area. In that case it gets highway=platform and possibly > tactile_paving=yes/wheelchair=yes, maybe a height as well. But no > repetition of name,ref,route_ref,operator,network, etc. > > If there is to be a next version of how we map public transport we should > think about making it simpler. What I see in Germany is way too complicated > and error prone, as information is duplicated across objects. > > Polyglot > > > > > On Tue, Apr 28, 2020 at 9:45 AM Robin Däneke <ro...@daeneke.at> wrote: > >> Hello everybody, >> >> I have lately been thinking about somehow reworking (or giving a new push >> to) the current p_t:v2 scheme. >> Especially for the fact, that, since it was first proposed and accepted, >> not a lot has changed in which tags are rendered, how certain things are >> hence mapped and the Wiki-Pages on the topic have also changed in the last >> years without any visible going through another proposal process. >> >> When I started mapping in 2011, and first read the german and then the >> english p:t:v2 wiki pages, it was: >> - highway=bus_stop is a legacy tag that should eventually be completely >> phased out >> - stop positions and platforms are to be both mapped >> and some other things I already forgot… >> Now, iD has a rule in its verifyer, that requires highway=bus_stop on >> platform nodes. The point of the public_transport tags is, among other >> points, to replace less dedicated highway tags. >> I think it would be time for a p_t:v2.5 proposal, where we take the >> innicial ideas of the v2, maybe refine a few small details (like is >> stop_position required, or just platforms, can relations of route-parts be >> used in route relations to save on redundancy…) and then put it forward for >> voting. If accepted, we would possibly now have more leverage to get the >> editor and render-programers to actually properly implement it this time >> around. >> >> Maybe I could find some time to write my suggestions into a document, and >> we could collect the ideas for those extra tags in there too. I think it >> would make more sense that way, than just the addition of a few tags to the >> current scheme, to then be ignored by the rest of OSM once again. >> >> Kind Regards >> Robin D. (emergency99) >> >> >> PS: The problem with bus_stop on platform: platforms can be nodes, lines, >> ways, even relations, highway=bus_stop can only be a node. This old tag >> should go the same way as the farm tag, which was (forcefully) abandoned a >> couple of years back. There it worked, why not for the „new“ p_t scheme? >> >> > Am 28.04.2020 um 00:12 schrieb Guilherme Braga Alves < >> gbragaal...@gmail.com>: >> > >> > I read your responses and I tend to agree that the opening_hours tag is >> enough to characterize services that are only operated during peak hours. >> > >> > On the other hand, it seems to me that there is also agreement on the >> relevance of having tags to differentiate bus services. >> > >> > How can we expand this debate and expand this discussion? It may be >> interesting for other members of the list to speak out, and then we can >> create or redeem a proposal for implementing new tags. >> > >> > P.S .: I don't know if this message will enter the reply queue >> correctly; I hope I'm not opening a new topic. I apologize for my >> inexperience with maillists. >> > _______________________________________________ >> > Talk-transit mailing list >> > Talk-transit@openstreetmap.org >> > https://lists.openstreetmap.org/listinfo/talk-transit >> >> >> _______________________________________________ >> Talk-transit mailing list >> Talk-transit@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-transit >> > _______________________________________________ > Talk-transit mailing list > Talk-transit@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-transit > > >
_______________________________________________ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
