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
