[Tagging] Still RFC — Drop stop positions and platforms

Jo winfixit at gmail.com
Wed Mar 28 15:35:52 UTC 2018


I'm not very optimistic you'll manage to get that proposal to pass.

We'll probably keep double tagging everything for a long time to come. The
reason why I put public_transport=platform on bus stop nodes, is that JOSM
conveniently adds a platform role when they are added to relations. Also
because it felt like the right thing to do, after the public_transport
scheme was voted on. But as it doesn't seem that they will ever be rendered
on the standard rendering, we have to add
highway=bus_stop/railway=tram_stop anyway. I gave up on trying to change
that many years ago.

The reason why I add stop_position nodes at the start and end of the
itineraries, is because I want to split the way there. For me those nodes
don't serve any other purpose, but I'm mostly mapping bus routes (And the
tram routes according to the same scheme).

What we need to find a solution for is that some mappers want to add each
stop to the route relations multiple times for each and every variation of
the itinerary. Once as a stop_position node and once as the way they drew
for the platform. For "consistency" I sometimes see that platform ways are
added even where no platform is present in reality.

Representing the stops as nodes next to the way solves all that. It might
be easier to propose a new tag for those nodes though, could be
public_transport=passengers / halt / pole, than to try to abolish
platform/stop_position.

In the mean time I'll keep tagging them as;
highway=bus_stop
public_transport=platform
bus=yes
+ details

and
railway=tram_stop
public_transport=platform
tram=yes
+ details

I don't think they add a lot of complexity. It's a bit awkward we have
explain that we have all these shiny "new" tags for a consistent scheme,
but we have to keep using the "old" ones, if we want to get stops rendered
too. I don't mind dropping them, and at the same time I don't mind to keep
using them.

What I do mind is to add more than 1 object to the route relations per
stop. But I'll keep making sure tools like PT_Assistant can cope with that
added complexity.

Polyglot


2018-03-28 16:21 GMT+02:00 "Christian Müller" <cmue81 at gmx.de>:

> > Sent: Wed, 28 Mar 2018 16:53:28 +0300
> > From: "Ilya Zverev" <ilya at zverev.info>
> > To: tagging at openstreetmap.org
> > Subject: [Tagging] Still RFC — Drop stop positions and platforms
> >
> > Hi folks,
> >
> > A while ago I've made a proposal to deprecate some public_transport=*
> tags:
> >
> > https://wiki.openstreetmap.org/wiki/Proposed_features/
> Drop_stop_positions_and_platforms
> >
>
> In your proposal you complain about subjectively felt things like "history
> won't go away", but at the same time you are trying to revert a part of
> history itself - "the public_transport tags are seven years old now".  Many
> people were involved creating those tags, they are well understood and
> discriminate the features they describe in a thoroughly documented and
> plausible way.
>
> Just because a lot of deprecated tags have not vanished in favor of the
> new ones yet does not mean there is a preference on the deprecated tags.  A
> lot of users and apps have adopted the new public_transport tags.  It
> simply does not make any sense to do a rollback on these for the
> observation of a sluggish adoption/transition rate.
>
> The proposal has been long thought about and delivers, in itself, a
> coherent way of tagging public transport infrastructure.  It has learned
> from previous tags, it is thus a refinement of the previous tagging.  There
> will be lots of people -unheared and not- that oppose breaking a (slow
> moving) transition process at this point in time.  Just be patient and give
> it some more years.
>
> You could help and promote the adoption, instead of dilating it.  A lot of
> rural area data has not been touched for years, waiting for you to do
> research and remapping efforts.
>
>
> Greetings
> cmuelle8
>
> _______________________________________________
> 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/20180328/fa94dd29/attachment.html>


More information about the Tagging mailing list