Any tag we could come up with is going to be a partial misnomer for what we are trying to model in the Database. In OSM, there are lots of those…
highway=bus_stop on the side of the road is somewhat trivially understandable, but that means we need railway=tram_stop, railway=train_stop, waterway=ferry_stop and many other tags too, that could all be made redundand by the „platform“ node/way/relation being in a route relation that is that mean of transport. The wonderful thing about databases is, that a lot of info kan be given on relational levels and inherited by all relation members. We can make a bunch of tags redundant by using one. And platform is the most truthful there. In Vienna, the Networks (Verkehrsverbunde) are working on only having bus stops, that have a visible, higher laying „platform“ (or some sort of sidewalk area) at each stop, and I can only imagine, the more public_transport gets, the more a bus stop is going to be the platform. I think we should not be tagging backwards here. The pole is a part of the stop, but never „the stop“ itself, even if some people tend to see it that way. Alternatively, call it public_transport=stop. That would mean one area where pt stops. Then that would be the same as a platform, unless it is a node, when that is possibly just the pole. But for that, a useful micro-mapping tag „public_transport=pole“ would make much more sense, once again then not needing bus=yes,tram=yes or something like „bus_stop_pole“ „tram_stop_pole“… This merging hw=bus_stop, rw=tram_stop into one platform or stop tag will make the database much more lean. And in terms of highway=bus_stop is difficult to remove: As this tag is the same as the platform (except if it is a node connected to a street, then that is a „stop_position" and can just be deleted) you could get one mechanical edit to take care f it (after getting it approved by the community and/or DWG) So that tag is the easiest to just purge from what it’s counterpart in p_t:v2 is! A stop/platform node on the side of the road does the same, so this is just redundancy, and as platform is the more versatile tag, it should take precedence in this „tag-fight“. Thanks for all the input. KR RobinD > Am 28.04.2020 um 12:20 schrieb Tony OSM <tonyo...@gmail.com>: > > I like node highway=bus_stop for the reasons polyglot gives. bus_stop is here > to stay cos there are too many to change, by the side of the highway they > give directionality depending on the customary side of the road for driving. > > public_transport=platform works well for train and some trams. To me a > platform is a construct to assist people to get on or off the transport > vehicle. As a waiting area - that use is secondary. > > In GB some authorities are raising the area around a bus stop to enable > wheelchair users easier access to buses - so yes a platform tag is > appropriate, but not for a pole placed in the ground or pedestrian part of > the road which is the default for buses where I live. > > stop_position node - to me has no function - for buses their stop position is > the bus stop; for trains they stop at the platform; where I live we have > 2,3,4,5,6 car trains, the front of the train stops at one of two defined > positions depending on the number of cars. > > Simplification of PTV2 may be helpful, but I have had no strong frustrations > when using it. > > Regards > > TonyS999 > > > > On 28/04/2020 09:46, Jo wrote: >> 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 >> <mailto: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 >>> <mailto: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 >>> <mailto: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 <mailto: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 <mailto:Talk-transit@openstreetmap.org> >>> > https://lists.openstreetmap.org/listinfo/talk-transit >>> > <https://lists.openstreetmap.org/listinfo/talk-transit> >>> >>> >>> _______________________________________________ >>> Talk-transit mailing list >>> Talk-transit@openstreetmap.org <mailto:Talk-transit@openstreetmap.org> >>> https://lists.openstreetmap.org/listinfo/talk-transit >>> <https://lists.openstreetmap.org/listinfo/talk-transit> >>> _______________________________________________ >>> Talk-transit mailing list >>> Talk-transit@openstreetmap.org <mailto:Talk-transit@openstreetmap.org> >>> https://lists.openstreetmap.org/listinfo/talk-transit >>> <https://lists.openstreetmap.org/listinfo/talk-transit> >> >> >> >> _______________________________________________ >> Talk-transit mailing list >> Talk-transit@openstreetmap.org <mailto:Talk-transit@openstreetmap.org> >> https://lists.openstreetmap.org/listinfo/talk-transit >> <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
