[Talk-transit] GTFS, tools and pt tags generally

Jo winfixit at gmail.com
Mon Jun 20 08:33:31 UTC 2016


I've been looking around and I see two main divergent "factions".

Basically the differences stem from how bus stops were mapped before v2
came along. Are the stop_position nodes the bus stop, or is it that place
next to the road where the passengers wait. For those places where the
latter is considered the way to go, I see nodes with

highway=bus_stop (cause the rendering people never implemented the new
scheme)
public_transport=platform
bus=yes
name, ref, route_ref, operator, network

I added/reviewed 70000 of those for Belgium. I didn't bother to add
public_transport=stop_position
bus=yes

nodes for all of those. I did add them for the first and terminal stops (as
I want to split the way there anyway)

In some places the stop_position also get details. For me it becomes too
complex to keep them synchronised, so I won't even consider to do that.

If there is a platform, a way or area closedway gets tagged:
highway=platform (to make it render)
public_transport=platform

The other faction is in some regions of Germany and some regions of France.
I don't see it in many other places.

There all the details go on the stop_position node. And then they draw a
way to represent the waiting area and tag it:
public_transport=platform
bus=yes

regardless of whether there is an actual platform present or not (they seem
to need it in the route relations, because if you don't add those, you
can't determine on which side the passengers wait and in which direction
the bus will take off)

Needless to say I prefer the first way of tagging, even though those
platform nodes often represent the pole with the flag on it, but let's not
muddy the waters by introducing a public_transport=pole. Nodes with
public_transport=platform work just fine for the purpose.


Now if the details are mapped on those nodes next to the way, then I fail
to see why one would need to add the stop_position nodes over and over to
the route relations (also keep in mind they are not necessarily always
mapped in the first scenario).


Reconciling both scenarios will be hard to accomplish, as everybody thinks
they are doing it "the right way", myself included...

I do agree that we'll need a solution for the route segments. To enable
that, I think it's important JOSM's relation editor can show that a route
is continuous, even when segment relations are used to build it. That's
what I like about the current situation, a continuous line allows a visual
check.

Personally I'd also not add stops to those segment relations. Keep all the
stops in the route relations for all the variations of a line.

Polyglot


2016-06-20 9:07 GMT+02:00 Roland Olbricht <roland.olbricht at gmx.de>:

> Dear fellow mappers,
>
> Is anyone interested in updating these tools?  I can provide lots of
>> input and testing, but my Java skills aren't where they need to be to
>> attempt this alone.
>>
>
> I'm the author of the public_transport plugin. I would be interested in
> restarting development. It's not about Java skills, the problem is missing
> consent about tagging or, more precise, the general modelling.
>
> There had been a group that was very vocal for making a textbook example
> of design by committee, and the result is now known as "approved public
> transport scheme". They did not ask for input from experienced mappers or
> developers. I decided to consider it a waste of time and stopped developing.
>
> I'm not the only one. Tagging never really got traction, and only a tiny
> fraction of stops conforms to that approach. This is why we have now the
> mess we have.
>
> One example is the dissent on whether the bus stop should be a node on the
> vehicle's way or a node where the passengers wait. You will find all
> solutions implemented, because each local community decided different. The
> "approved scheme" will allow any variant. It's even worse for where to put
> the name: I got even within local communities incompatible answers, all
> referring to the "approved scheme".
>
> Another example are route relations. While there are wild constructions
> called route_master and network which are basically collection relations,
> the problem that bothers most people in practice has never been tackled: We
> would like to see per way segment only one or very few relations and need a
> construction to assemble itineraries from that. That would greatly reduce
> maintenance. And: how to tell apart services that run a few times per day
> from those that have a headway of a few minutes?
>
> Given that, it would help have an algorithm to answer the simple questions
> for real world examples and their current tagging:
> - Where to start/end routing of passengers?
> - Where to start/end routing of vehicles?
> - How to obtain a name of a station?
> There are probably more interesting questions. But it will be already hard
> enough to tell apart unusual tagging on purpose (because of a special
> situation) from mistakes and the various variants of taggings for these
> three, and adding complexity (like more questions) had killed a lot of
> prospective efforts.
>
> It's not enough if the solution works fine in your local area and
> hopefully works somewhere else, more or less untested. We need an algorithm
> to do the right thing in 95% or better 99% of all places around the world.
>
> Is this the right list to discuss mass edits to add the missing tags, or
>> would it be
>> local lists for each area, or somewhere else?
>>
>
> Note that the hard thing isn't to write a bot that processes a lot of
> objects. The hard thing is tell what we actually want. The bot has to
> answer the above mentioned questions to actually do more good than harm.
>
> To make it clear: We need rules how to understand what we have right now,
> changing at most 1% of all stops and stations or even less. Such a change
> we inevitably need local knowledge, hence it is unlikely that a bot will
> help. What we don't need is yet another standard.
>
> Best regards,
>
> Roland
>
>
>
> _______________________________________________
> Talk-transit mailing list
> Talk-transit at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20160620/7df47ff2/attachment.html>


More information about the Talk-transit mailing list