That's what I would like to see happen. Last year I created a wiki page about it (with screenshots):
https://wiki.openstreetmap.org/wiki/JOSM/Plugins/PT_Assistant/Mapping_Public_Transport_with_JOSM#Downloading_data Polyglot 2018-03-29 13:09 GMT+02:00 Selfish Seahorse <selfishseaho...@gmail.com>: > > Otherwise, public_transport=stop_position could be abandoned, which > would make PTv2 tagging a lot easier and more time-efficient. > > Or at least exclude them from route relations. > > > On 29 March 2018 at 12:33, Selfish Seahorse <selfishseaho...@gmail.com> > wrote: > >> It seems that one major issue was that, given a simple > public_transport=platform situation, which icon should be used to render > it? In many cases there isn't a {mode}=yes tag. > > > > This is because according to the PTv2 proposal the transportation > > vehicle tags (bus=yes, tram=yes etc.) have to be put on the stop > > position node, not on the platform node. [^1] This problem could be > > solved if we agree to put them on platform node instead. > > > > [^1]: <https://wiki.openstreetmap.org/wiki/Proposed_features/ > Public_Transport#Stop> > > > >> My contribution to solving that issue is attached -- a generic transit > icon which I hereby put into the public domain. I think this icon should be > used (a) when there is no indicator of the transport mode, or (b) when > there are multiple modes, as in https://www.openstreetmap.org/way/66332939 > > > > If multiple transportation vehicles serve a platform, it would be > > useful to have an icon for every vehicle rendered next to one another, > > as here: https://www.google.ch/maps/@46.948,7.447,17z > > > >> It was proposed to NOT render public_transport=stop_position in all > cases, which frankly I agree with when the node is on a highway (not clear > to me when it's on a railway, as I don't have experience there). > > > > Even for trams/railways, I think, people looking at a map are > > interested in the waiting area (= platform) and not on the stop > > position. > > > > I'm wondering if there is any use for public_transport=stop_position > > apart from routing, which, however, should be solvable by calculation > > (projection of platform on highway/railway way). Otherwise, > > public_transport=stop_position could be abandoned, which would make > > PTv2 tagging a lot easier and more time-efficient. As a volunteer > > project with limited resources, we should try to be as efficient as > > possible. > > > > > > On 29 March 2018 at 09:43, Johnparis <ok...@johnfreed.com> wrote: > >> I have spent some time reading > >> https://github.com/gravitystorm/openstreetmap-carto/issues/435 > >> and > >> https://github.com/gravitystorm/openstreetmap-carto/issues/331 > >> > >> It seems that one major issue was that, given a simple > >> public_transport=platform situation, which icon should be used to > render it? > >> In many cases there isn't a {mode}=yes tag. My contribution to solving > that > >> issue is attached -- a generic transit icon which I hereby put into the > >> public domain. I think this icon should be used (a) when there is no > >> indicator of the transport mode, or (b) when there are multiple modes, > as in > >> https://www.openstreetmap.org/way/66332939 > >> > >> As I understand it, valid relevant mode tags are: > >> train=yes > >> light_rail=yes > >> tram=yes > >> subway=yes > >> monorail=yes > >> bus=yes > >> trolleybus=yes > >> ferry=yes > >> aerialway=yes > >> > >> ... and in hindsight, wouldn't it have been nice to have a "platform:" > >> namespace for these? Very difficult to track these, especially if/when > a new > >> mode arrives (self-driving vehicles, anyone?). > >> > >> (As a side note, one issue raised in another thread was that "bus=yes" > does > >> double duty as an overriding tag in combination with for "access=no" on > >> highways. This isn't an issue for the vast majority of platforms, as > they > >> are nodes not ways, but still... I'd prefer that the access overriding > tags > >> have an "access:" namespace anyhow: "access:bus=yes", "access:psv=yes", > >> etc.) > >> > >> Another major issue with rendering public_transport=platform tags was a > >> limitation in the database schema, which appears to have been lifted > with > >> the (relatively recent) addition of hstore. (Though the issue, > apparently, > >> was the ability to render based on the mode tags -- which could have > been > >> solved with a generic transit icon.) > >> > >> A third concern was double-rendering. If both a highway=bus_stop node > and a > >> public_transport=platform node exist, won't mappers want to remove the > >> duplicate? I would hope so! Alternatively, if a stop area is mapped with > >> both public_transport=platform and public_transport=stop_position, > won't > >> that make the map messy? That, it seems to me, is a valid > consideration. It > >> was proposed to NOT render public_transport=stop_position in all cases, > >> which frankly I agree with when the node is on a highway (not clear to > me > >> when it's on a railway, as I don't have experience there). > >> > >> The last issue, raised by kocio-pl, who I assume is Daniel Koć of this > >> thread, is that someone needs to write the code. > >> > >> > >> > >> > >> On Thu, Mar 29, 2018 at 3:56 AM, Daniel Koć <daniel@koć.pl> wrote: > >>> > >>> W dniu 28.03.2018 o 18:42, Jo pisze: > >>> > I've tried to accomplish that many years ago already, it failed. The > >>> > people at the helm of the rendering stack consider the 'old' tags > good > >>> > enough and the new scheme somehow not explicit enough, hence the > >>> > double tagging. > >>> > >>> I'm not sure who do you mean, but I certainly want to make it render on > >>> osm-carto. It wasn't possible before we have hstore few months ago > >>> (v4.0.0+) and I had to learn coding with this feature enabled, but now > >>> it's much closer to being reality - I need just some time probably, but > >>> any help is welcome. Related issue: > >>> > >>> https://github.com/gravitystorm/openstreetmap-carto/issues/435 > >>> > >>> > Dropping the tags you call obsolete from the data, is not an option > as > >>> > far as I'm concerned. Part of the reason for mapping bus stops, is to > >>> > get them rendered on the map. That's not tagging for the renderer, > >>> > that's merely being practical and adapting to the situation at hand. > >>> > >>> Tagging for rendering is confusing slogan. There's nothing wrong in the > >>> literal sense, the problem is with faking data just to show something > on > >>> the map. Double tagging is a problem too, but transition is always > >>> troublesome process. > >>> > >>> -- > >>> "My method is uncertain/ It's a mess but it's working" [F. Apple] > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
