> 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
