[Tagging] Still RFC — Drop stop positions and platforms

[Jo]

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 <selfishseahorse at 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 <selfishseahorse at 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 <okosm at 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 at 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 at openstreetmap.org
> >>> https://lists.openstreetmap.org/listinfo/tagging
> >>
> >>
> >>
> >> _______________________________________________
> >> Tagging mailing list
> >> Tagging at openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/tagging
> >>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180329/adad0c8e/attachment-0001.html>