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