> 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
