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

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Stephen Sprunk
Dear fellow mappers,

First, GO-Sync and various JOSM plugins for transit do not seem to be
maintained anymore, with the last updates (other than minor API tweaks)
being several years ago.  They also _all_ crash or malfunction when I
attempt to import my local transit agency's GTFS feed, and most seem to
be oriented toward bus stops/routes only, with poor or no support for
other transit modes.

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.  Also, I think it'd be good to combine the JOSM
plugins so there's only one thing to maintain--and increase the odds
that someone will actually do so going forward.  And that/they should be
synchronized with GO-Sync, so using different tools in the same area
doesn't cause problems.

Second, I've noticed there's disagreement on what tags to use, e.g.
taginfo shows both gtfs_stop_id and gtfs:stop_id; the latter seems to
better match other imported tagsets (e.g. tiger:).  The GTFS wiki page
doesn't provide any hints on what should map where, and I'm happy to add
my ideas on that, but that implies someone updating the tools to match.

Third, what's the Transport layer supposed to show, and what tags does
it look for?  It seems to highlight and label only bus routes (using
relations, which I read elsewhere Mapnik can't do!) and highlight bus
stop areas; it doesn't seem to show anything related to rail, including
within a stop area it's obviously already highlighting for bus stops,
which seems rather odd.  Is this by design, and if so why?  If not, how
do we get it fixed?

Finally, I've noticed that a lot of areas have inconsistent tagging,
e.g. some stops/stations are tagged using the legacy scheme only, some
with the Oxomoa scheme only, and some with both.  This would seem to
make it very difficult for renderers to do their job right.  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?

S

--
Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

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

Roland Olbricht
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

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

Jo-2
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 <[hidden email]>:
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

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

Stephen Sprunk
In reply to this post by Roland Olbricht
On 2016-06-20 02:07, Roland Olbricht wrote:
> 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 wasn't around at the time, so I can't speak to how it happened, but
the result seems to be a partial implementation of Transmodel, which
distinguishes a _lot_ of different things (and the complex relationships
between them) in excruciating detail because the real world is, in fact,
that complicated.

If one is putting data in by hand, it certainly seems unwieldy.  It took
me over a week to do just a few rail routes in my area, and I'm still
not completely sure I got them right.  I can't imagine trying to do the
hundreds of bus routes too.

OTOH, this doesn't seem like a huge problem if we're importing the data
from elsewhere using automated tools and only tweaking by hand where
it's wrong--and ideally, there should be some sort of feedback mechanism
to get the source corrected so even that's a short-term problem.

I'm interested in GTFS because it gives us a wealth of data from
hundreds of transit agencies around the world.  It's not perfect, of
course, but I think better tools would solve a lot of the disagreements
over the tagging scheme and its complexity.

Also, like it or not, Google Maps (and hence GTFS) has set a bar for
what users expect from online maps.  I'd certainly like OSM to be
better, of course, but the current situation is that OSM is generally
far, far worse.

> 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".

I think it's fairer to say that the approved scheme allows either or
both--using different tags, so you know which you are dealing with.  
IMHO, that's an improvement over folks using the same tags for two
different things.

Unfortunately, GTFS _doesn't_ help solve this particular problem.  
Worse, each agency seems to have their own idea of what a "stop" or
"station" is, so local mappers might have to tweak things--and the tools
would need to respect those tweaks during future imports.

> 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.

I'll admit I was a bit annoyed at having to duplicate way data for
several routes where some trips run A-B-C-D, some A-B-C and some B-C-D;
it would have been handy to create segments A-B, B-C and C-D, and then
just include the right ones in each route.  But then I realized my real
complaint was that I had to do this _at all_ when there's a GTFS feed
that has _all_ of that information and could easily be used to
create/update all the relations.  If it's automated, only developers
should have to care how complicated or repetitive it is; the important
thing is that individual mappers don't, at least in the general case.

In my day job, our goal for most process is to automate 90% of "easy"
things because automating the last 10% would cost more than handling
them manually does.  I think we can aim higher than that here, at least
after the first pass, but I suspect that mappers who are doing 100% of
one thing today aren't likely to complain about doing 10% of two things
instead tomorrow.

> And: how to tell apart services that run a few times per day from those
> that have a headway of a few minutes?

That's starting down a slippery slope to including full schedule data.

> 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?

Isn't that what the current scheme is all about?

> - Where to start/end routing of vehicles?

Do our consumers really care about that?  Do we need to include
"deadhead" trips to/from service facilities or cases where one vehicle
switches from one route to another at a given stop?  The latter is in
GTFS, but I'm not sure I'd want that in a map.

> - How to obtain a name of a station?

How is this complicated?

> 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.

Of course.  Transmodel tries to be right 100% of the time, but that
means ridiculous complexity; GTFS isn't right quite as often, but it
seems to be good enough for the vast majority of places and with a lot
less complexity.

S

--
Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

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

Stephen Sprunk
In reply to this post by Jo-2
On 2016-06-20 03:33, Jo wrote:

> 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
> ...
> The other faction is in some regions of Germany and some regions of
> France. I don't see it in many other places.
> ...
>
> Needless to say I prefer the first way of tagging,

That's what my reading of the wiki page says to do; I don't get how
someone would think the second way conforms to the scheme, and as you
note, it has practical problems.

 From what I can tell, the "stops" in a GTFS feed match platforms (or
poles) or sometimes entire stations but never the stop positions.  OTOH,
the points in a GTFS shape are probably supposed to match the stop
positions.

> 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.

Agreed.  There is a slight ambiguity vs a real platform that isn't fully
mapped yet, but I don't think renderers (or other consumers) would care
about that.

> 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).

I puzzled over that for quite a while myself.

The best I've come up with so far is that it allows validating that all
of the stop positions are on the ways, and it helps render maps
correctly when giving directions to get on/off at an intermediate stop.  
At first, I thought it was needed when a single platform serves multiple
stop positions, but I think you could figure that out easily from the
ways.  There's still a problem where you have multiple stop positions on
the same way served by the same platform, but I suspect in such cases
the platform should be chopped up* to one per stop position.

One problem I've run into, perhaps unique to rail, is where to _put_ the
stop positions; I've been putting them beside the center of the
platform, but that probably isn't accurate.  In reality, the entire way
segment adjacent to the platform is the stop position, which has the
added benefit of moving the stop position into the way list rather than
being separate.  (IMHO, even if the stop position is a node, that should
be allowed if it's a node that joins the preceding and following ways,
without being considered a gap.)

* Incidentally, is there an easy way in JOSM to split a single area for
cases like this?  It already has a function to join two areas with a
shared wall, so you'd think adding a way through the middle of an area
would allow you to un-join it, but not that I've found...

S

--
Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

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

Paul Johnson-3
In reply to this post by Stephen Sprunk


On Mon, Jun 20, 2016 at 2:02 PM, Stephen Sprunk <[hidden email]> wrote:
On 2016-06-20 02:07, Roland Olbricht wrote:
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 wasn't around at the time, so I can't speak to how it happened, but the result seems to be a partial implementation of Transmodel, which distinguishes a _lot_ of different things (and the complex relationships between them) in excruciating detail because the real world is, in fact, that complicated.

If one is putting data in by hand, it certainly seems unwieldy.  It took me over a week to do just a few rail routes in my area, and I'm still not completely sure I got them right.  I can't imagine trying to do the hundreds of bus routes too.

I really wonder how TriMet ultimately accomplished this, since that would seem like a decent-ish starting point since that system is in charge of a fairly multimodal system with above and below ground stations, split-level stations, and transit centers of almost every description.

One thing that breaks things badly for me in the Tulsa area is the vast overwhelming majority of stops in the Tulsa Transit (and presumably other transit systems in the region) GTFS have...literally zero indication on the ground, there's no way to tell if there is an actual bus stop (which is typically just a signpost with a bus stop sign on it), and if it is, whether or not that's verifiable because the sign's gone missing.  Or the more likely case with mass transit in the southern midwest, no amenities whatsoever are provided, you just need to know the bus runs on that street and stand about a bus length after the downstream side of an intersection that doesn't have a signposted stop and flag down the driver to catch the bus (likewise, you have to be unusually precise at pulling the stop cord as the driver will automatically assume immediately after the next intersection, regardless of how minor).  Worse, there's a large number of duplicates with more than one stopID for the same stop position (this is a GTFS data issue, Tulsa Transit's feed is a hot mess to start with), and there's a significant portion (perhaps to the point of "almost all") major transfer points that fall into the category of totally unsigned stops, and another rash of locations that have no GTFS entry but are considered to be valid, totally unposted bus stops.

My completely shitty answer to this problem right now is to map only signposted stops I've verified.  I have no idea how many there actually are, nor do I have any reason to believe that Tulsa Transit has any clue how many there are in actuality either.  I'm also a big fan of the V1 tagging scheme as it's substantially easier to deal with.  

On the ground mapping should become easier with time as Tulsa Transit's starting to get more funding (Finally!), though focus right now is on getting more safe vehicles on the road more frequently, longer hours and to more places (currently any trip requiring more than one transfer, or even a particularly long trip involving no transfers and only one possible route, is a major test of patience, as it's annoyingly common for a scheduled bus to be cancelled completely without warning due to lack of usable equipment that has things like an intact floor that hasn't rusted out to the street below).  I would hope that the GTFS feed improves as ridership increases and stops get signposted, but I'm really not counting on the GTFS improving or bus stops to get maintained, much less posted more formally than someone scratching something like MTTA 3421 on a handy streetlamp or telephone pole at unposted stops frequented by people who figured out the stop ID for that location independently to look up when the next bus arrives via text message...
 
Also, like it or not, Google Maps (and hence GTFS) has set a bar for what users expect from online maps.  I'd certainly like OSM to be better, of course, but the current situation is that OSM is generally far, far worse.

It doesn't help that the only implementations of GTFS that actually are anywhere near complete are basically the reference implementations Google did in cooperation with TriMet and Tillamook County Transit, and adjacent systems that asked TriMet how they did that (like Clark County Transit, aka C-Tran).  The situation with GTFS data itself is so bad that Google stopped offering Navigation for the transit mode in it's own Maps service.  Which was actually a pretty slick thing, and I actually used it a lot for the last few months that feature was even available, since if your route suddenly became impossible to make a transfer because of a delay or the GTFS Live feed indicated there was a problem, it would automatically reroute you to an actually viable service.  This was fantastic since the whole reason I ended up stranded in Portland in the first place was I got laid off during a service call and had to find my own way back to Oklahoma, and my car was in the shop.  So temping often meant 3-5 transfer trips across three counties in two states on two different transit systems at varying hours and locations; when this feature stopped being a thing, getting around my hometown by transit became "plan the trip up front, and if anything goes wrong, replan the trip midway through" and "pray to God nothing happens to the C105 or 62 bus routes" as I simply wasn't familiar with alternative options for either of those routes.

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".

I think it's fairer to say that the approved scheme allows either or both--using different tags, so you know which you are dealing with.  IMHO, that's an improvement over folks using the same tags for two different things.

Unfortunately, GTFS _doesn't_ help solve this particular problem.  Worse, each agency seems to have their own idea of what a "stop" or "station" is, so local mappers might have to tweak things--and the tools would need to respect those tweaks during future imports.
 
I'm a proponent of it being the location where passengers wait for bus service, and the center of the position the train stops for rail halts, for what it's worth.  I don't know what makes the most sense for data consumers, which would help significantly.  Then would need to get JOSM on board with not barfing on routes that contain the same member multiple times in the same relation, another frequent issue I have with Tulsa Transit routes, particularly at the Denver Avenue Station where the station layout and the street grid can necessitate going in circles repeatedly to get to the correct bus platform and the correct exit (ignoring that some drivers Do Not Care and will pull into a more convenient (for them) bay anyway if the station's not busy).  Or for out and back legs where a route will turn off it's ostensibly named-for street to go a mile out of the way, turn around in a parking lot, come back up the other side of the same street, and then turn back onto it's named-for street to continue.  JOSM actively fights you in both cases, and god help you if you click "sort route"...

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.

I'll admit I was a bit annoyed at having to duplicate way data for several routes where some trips run A-B-C-D, some A-B-C and some B-C-D; it would have been handy to create segments A-B, B-C and C-D, and then just include the right ones in each route.  But then I realized my real complaint was that I had to do this _at all_ when there's a GTFS feed that has _all_ of that information and could easily be used to create/update all the relations.  If it's automated, only developers should have to care how complicated or repetitive it is; the important thing is that individual mappers don't, at least in the general case.

In my day job, our goal for most process is to automate 90% of "easy" things because automating the last 10% would cost more than handling them manually does.  I think we can aim higher than that here, at least after the first pass, but I suspect that mappers who are doing 100% of one thing today aren't likely to complain about doing 10% of two things instead tomorrow.

Hadn't learned of Route Master before, but this frustration with some routes not going full length or having optional loops or changed route based on time of day or whether or not it's snowing without changing the route name or number actually hit me as one of those, "are you actually kidding me?" kind of moments with Tulsa Transit.  There's one route that has something like six or eight different relations because of this.  
 
- How to obtain a name of a station?

How is this complicated?

A lot of cities name stops without signposting the name, often in the form of "The Street The Route Is On at The Cross Street We're Stopping At", such as "South Memorial Drive at East 56th Street" or some similar pattern.
 
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.

Of course.  Transmodel tries to be right 100% of the time, but that means ridiculous complexity; GTFS isn't right quite as often, but it seems to be good enough for the vast majority of places and with a lot less complexity.

Assuming the agency actually uses it correctly.  Which is almost certainly not the case. 


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

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

Mike N.
On 6/20/2016 5:18 PM, Paul Johnson wrote:
> I really wonder how TriMet ultimately accomplished this, since that
> would seem like a decent-ish starting point since that system is in
> charge of a fairly multimodal system with above and below ground
> stations, split-level stations, and transit centers of almost every
> description.

   I don't know for sure, but I think TriMet's system uses GTFS as a
primary transit planning reference in OpenTripPlanner, and OSM data is
maintained to facilitate public transit connection to  Pedestrian / Bike
/ Car.    A quick glance at OSM's public transit layer in Portland shows
that lots of bus routes have been entered into OSM, but I don't know if
they have any function other than "there is a bus route or stop here".


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

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

Stephen Sprunk
In reply to this post by Paul Johnson-3
On 2016-06-20 16:18, Paul Johnson wrote:

> On Mon, Jun 20, 2016 at 2:02 PM, Stephen Sprunk <[hidden email]>
> wrote:
>> On 2016-06-20 02:07, Roland Olbricht wrote:
>>> 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 wasn't around at the time, so I can't speak to how it happened,
>> but the result seems to be a partial implementation of Transmodel,
>> which distinguishes a _lot_ of different things (and the complex
>> relationships between them) in excruciating detail because the real
>> world is, in fact, that complicated.
>>
>> If one is putting data in by hand, it certainly seems unwieldy.  It
>> took me over a week to do just a few rail routes in my area, and I'm
>> still not completely sure I got them right.  I can't imagine trying
>> to do the hundreds of bus routes too.
>
> I really wonder how TriMet ultimately accomplished this, since that
> would seem like a decent-ish starting point since that system is in
> charge of a fairly multimodal system with above and below ground
> stations, split-level stations, and transit centers of almost every
> description.

Same here and many other cities I've looked, so I didn't think it was
that big of a deal.

> One thing that breaks things badly for me in the Tulsa area is the
> vast overwhelming majority of stops in the Tulsa Transit (and
> presumably other transit systems in the region) GTFS have...literally
> zero indication on the ground, there's no way to tell if there is an
> actual bus stop (which is typically just a signpost with a bus stop
> sign on it), and if it is, whether or not that's verifiable because
> the sign's gone missing.

*facepalm*

I have plenty of complaints about the transit agencies where I live, but
at least they manage to post signs properly and provide proper
maps/schedules.  Their GTFS data isn't as accurate as I'd hoped, but
it's obvious they're _trying_ to get it right.

>> Also, like it or not, Google Maps (and hence GTFS) has set a bar for
>> what users expect from online maps.  I'd certainly like OSM to be
>> better, of course, but the current situation is that OSM is
>> generally far, far worse.
>
> It doesn't help that the only implementations of GTFS that actually
> are anywhere near complete are basically the reference implementations
> Google did in cooperation with TriMet and Tillamook County Transit,
> and adjacent systems that asked TriMet how they did that (like Clark
> County Transit, aka C-Tran).

Really?  I've looked at a couple dozen feeds for major US and European
cities, and they seem to be reasonably complete and accurate.  Then
again, all of the ones I've looked at so far are ones that offer rail
services, and the nature of rail implies a high enough level of funding
that one can probably take things like a decent GTFS feed for granted.  
A small, bus-only agency can run on a shoestring budget where such
things may be seen as "unnecessary" or "too much effort".

> The situation with GTFS data itself is so bad that Google stopped
> offering Navigation for the transit mode in it's own Maps service.

It's still available where I live and several other major cities I
checked, so perhaps they just disabled it in your area because they
recognized the GTFS data there was so bad?

>>> 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.
>>
>> ...
>
> I'm a proponent of it being the location where passengers wait for bus
> service, and the center of the position the train stops for rail
> halts, for what it's worth.

Unfortunately, that could create problems if navigation tools think that
a person has to walk to the center of the platform to actually board the
train, whereas trains often run the full length of the platform but are
often shorter (or even longer!) than the platform.

Worse, some trains only allow boarding for mobility impaired persons at
certain points along the platform, and they may not be able to make it
from the center to that location within the dwell time.

Worse still, a short train may not even be _present_ at the center of
the platform if it's short and stops at one end or the other.  While
improbable, in theory that could lead a vision-impaired person to walk
off the platform and fall onto the tracks.

I'm not sure what the solution is, though, so I've been putting the stop
positions at the center of the platform until someone tells me better.  
FWIW, that seems to be what folks in other cities have done--if they
mapped any stop positions at all.

>>> 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.
>>
>> I'll admit I was a bit annoyed at having to duplicate way data for
>> several routes where some trips run A-B-C-D, some A-B-C and some
>> B-C-D; it would have been handy to create segments A-B, B-C and C-D,
>> and then just include the right ones in each route.  But then I
>> realized my real complaint was that I had to do this _at all_ when
>> there's a GTFS feed that has _all_ of that information and could
>> easily be used to create/update all the relations.  If it's
>> automated, only developers should have to care how complicated or
>> repetitive it is; the important thing is that individual mappers
>> don't, at least in the general case.
>
> Hadn't learned of Route Master before, but this frustration with some
> routes not going full length or having optional loops or changed route
> based on time of day or whether or not it's snowing without changing
> the route name or number actually hit me as one of those, "are you
> actually kidding me?" kind of moments with Tulsa Transit.  There's one
> route that has something like six or eight different relations because
> of this.

It's always baffled me that so many agencies are willing to give the
same designation to different routes just because they share several
stops.  IMHO, it'd be better to give each variant a suffix so they can
be easily identified (e.g. route 1A vs route 1B, rather than route 1 to
Wherever and route 1 to Elsewhere; references without a suffix could
still refer to the common section.  Worse, what appears to be the same
route can often be different variants depending on the time of day.  My
local agency has several routes where route A stops at certain places in
the off-hours but skips those stops during peak hours when route B
serves those stops instead--and route B doesn't go to all the _other_
places that route A does.

Part of the reason we _need_ transit navigation apps (and reliable
route/schedule data to feed into them) is to hide this sort of
complexity from users.

>>> - How to obtain a name of a station?
>>
>> How is this complicated?
>
> A lot of cities name stops without signposting the name, often in the
> form of "The Street The Route Is On at The Cross Street We're Stopping
> At", such as "South Memorial Drive at East 56th Street" or some
> similar pattern.

Oh, sorry.  I was assuming a decent GTFS feed, where every stop should
have an official name, even if it's only cross-streets (typical for bus
stops).  I thought the question was where to put that it in OSM and/or
where renderers should look for it.

One of the challenges I've run into is whether to name every part of a
stop area; if I do, platform or stop position names often get rendered
_instead of_ the station name, but if I don't, it's really hard to
maintain all the relations because all the elements of a given type look
the same, plus navigators can't direct pedestrians to the right
platforms.

S

--
Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

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

Paul Johnson-3

On Mon, Jun 20, 2016 at 10:51 PM, Stephen Sprunk <[hidden email]> wrote:
On 2016-06-20 16:18, Paul Johnson wrote:
On Mon, Jun 20, 2016 at 2:02 PM, Stephen Sprunk <[hidden email]>
wrote:

The situation with GTFS data itself is so bad that Google stopped
offering Navigation for the transit mode in it's own Maps service.

It's still available where I live and several other major cities I checked, so perhaps they just disabled it in your area because they recognized the GTFS data there was so bad?

I mean the realtime, stop-by-stop navigation that was formerly offered.  Even in areas with really good GTFS feeds, this functionality is Just Gone.  Closest you can get now amounts to basically a static listout of your trip similar to the paddle used by transit drivers in to familiarize themselves with the route and schedule; it doesn't follow you in realtime or take into account when your trip's fallen off schedule and won't make a transfer now.  Nor will it warn you your stop is coming up.  I remember this abruptly going away with the last version that had it was Google Navigation 6.9...
 
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.

...

I'm a proponent of it being the location where passengers wait for bus
service, and the center of the position the train stops for rail
halts, for what it's worth.

Unfortunately, that could create problems if navigation tools think that a person has to walk to the center of the platform to actually board the train, whereas trains often run the full length of the platform but are often shorter (or even longer!) than the platform.

Worse, some trains only allow boarding for mobility impaired persons at certain points along the platform, and they may not be able to make it from the center to that location within the dwell time.

Worse still, a short train may not even be _present_ at the center of the platform if it's short and stops at one end or the other.  While improbable, in theory that could lead a vision-impaired person to walk off the platform and fall onto the tracks.

Most stations I've seen have a canonical tactile map and seeing impaired users are not putting total faith in either the official tactile map nor any electronic aid they're using.  Mostly because people and furniture move, maintenance closes areas, pavement buckles, etc.
 
I'm not sure what the solution is, though, so I've been putting the stop positions at the center of the platform until someone tells me better.  FWIW, that seems to be what folks in other cities have done--if they mapped any stop positions at all.

Portland tends to put the stop position where the lead cab of the lead car will line up.  However, Portland hits me as a little odd (in terms of west coast light rail systems) in that there 
 
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.

I'll admit I was a bit annoyed at having to duplicate way data for
several routes where some trips run A-B-C-D, some A-B-C and some
B-C-D; it would have been handy to create segments A-B, B-C and C-D,
and then just include the right ones in each route.  But then I
realized my real complaint was that I had to do this _at all_ when
there's a GTFS feed that has _all_ of that information and could
easily be used to create/update all the relations.  If it's
automated, only developers should have to care how complicated or
repetitive it is; the important thing is that individual mappers
don't, at least in the general case.

Hadn't learned of Route Master before, but this frustration with some
routes not going full length or having optional loops or changed route
based on time of day or whether or not it's snowing without changing
the route name or number actually hit me as one of those, "are you
actually kidding me?" kind of moments with Tulsa Transit.  There's one
route that has something like six or eight different relations because
of this.

It's always baffled me that so many agencies are willing to give the same designation to different routes just because they share several stops.  IMHO, it'd be better to give each variant a suffix so they can be easily identified (e.g. route 1A vs route 1B, rather than route 1 to Wherever and route 1 to Elsewhere; references without a suffix could still refer to the common section.  Worse, what appears to be the same route can often be different variants depending on the time of day.  My local agency has several routes where route A stops at certain places in the off-hours but skips those stops during peak hours when route B serves those stops instead--and route B doesn't go to all the _other_ places that route A does.

Part of the reason we _need_ transit navigation apps (and reliable route/schedule data to feed into them) is to hide this sort of complexity from users.

Or obviate it.  Sight unseen, just trying to make sense of the situation based on just a map and what stops are handy, there's no way I'd figure this out for Tulsa's 101 Suburban Acres route.  Every other trip alternates which way the route goes through the eponymous neighborhood, so depending on which half hour it is, you might need to walk to one end of the neighborhood or the other to catch the bus.  Or wait up to an hour instead.  And then some trips make side trips to a clinic (during it's business hours) and some trips make an additional side trip to a alzheimer's treatment community (based on some arbitrary criteria, possibly when the patients are allowed to come and go).
 
- How to obtain a name of a station?

How is this complicated?

A lot of cities name stops without signposting the name, often in the
form of "The Street The Route Is On at The Cross Street We're Stopping
At", such as "South Memorial Drive at East 56th Street" or some
similar pattern.

Oh, sorry.  I was assuming a decent GTFS feed, where every stop should have an official name, even if it's only cross-streets (typical for bus stops).  I thought the question was where to put that it in OSM and/or where renderers should look for it.

Yeah, GTFS assumes every stop is named, even though this assumption is outright broken even in GTFS's hometown of Portland beyond just naming the intersection or block number ("6300 Block Southwest Murray Boulevard" as a hypothetical name example of a stop not near a corner).

_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

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

Roland Olbricht
In reply to this post by Stephen Sprunk
Hi,

> OTOH, this doesn't seem like a huge problem if we're importing the data
> from elsewhere using automated tools and only tweaking by hand where
> it's wrong--and ideally, there should be some sort of feedback mechanism
> to get the source corrected so even that's a short-term problem.

Well, that's explicitly deprecated in OSM. Please look in the wiki about
mechanical edits.

If you have useful and free data then the better approach is to mix them
up with OSM data outside OSM and give the OSM mappers a tool such that
each mapper can pick what he/she deems useful in OSM.

> Also, like it or not, Google Maps (and hence GTFS) has set a bar for
> what users expect from online maps.  I'd certainly like OSM to be
> better, of course, but the current situation is that OSM is generally
> far, far worse.

I think this is where local differences matter. In large parts of
Europe, the transit agencies themselves have already good information,
OSM is more or less on par with that, and Google lags significantly behind.

>> And: how to tell apart services that run a few times per day from those
>> that have a headway of a few minutes?
>
> That's starting down a slippery slope to including full schedule data.

Once again, please note that this is a huge difference in local culture.

All around the world, if there is a metro then people usually go there
without looking on a timetable and it as granted that the headway is a
few minutes. Next to nobody consults a timetable first, and some systems
don't even public precise timetables.

Believe it or not, there are quite a number of bus service mimicking
this concept:
https://fr.wikipedia.org/wiki/Bus_%C3%A0_haut_niveau_de_service

This is in contrast to a number of service that run once a day on
schooldays.

In between, there are a lot of services that have a fixed headway all
over the day:
https://fr.wikipedia.org/wiki/Horaire_cadenc%C3%A9

In practice here in Europe, reducing complexity would mean to send a
potential passenger to the next stop of a high frenquency service or
clock-face scheduled service and to ignore once-a-day services altogether.

And the right solution for this is not to delete these services from OSM
but to mark them as low-frequency service.

If you would like to improve relevance of OSM, discriminating between
these three levels of service would be a prime concern.

>> - Where to start/end routing of vehicles?

Sorry for the misunderstanding. I'm talking about getting a vehicle from
stop to stop. While the overall level of detail is often good enough for
routing, this doesn't hold always. To find and resolve the mapping
issues it makes sense to check whether you can route from stop to stop.
If not, this is always a strong hint that there are mapping issues.

I do notice as a benefit from this discussion that not all transit
agencies (Tulsa, Portland) care whether their routes can be lawfully
driven in reality. That's different here in, at least in Western Europe,
maybe all Europe.

>> - How to obtain a name of a station?

Please start trying to work with the data.

Names can come from the pole, the platform, the stop_position, a
connecting stop area. Or a combination of that, including contradicting
information. Factor in "local_name", "loc_name", "official_name",
probably others, and in countries like Switzerland and Belgium names in
multiple languages.

To make things more fun, some stations have different names for some of
their stops within the station. And add abbreviations to the equation or
the repetition of the municipality name in the name tag.

I would like to see a set of rules that answer questions like:
- Does a "name:en" tag on the pole override a "name" tag on the
stop_position, or vice versa? What about a "name:en" tag on a
stop_position versus "name" on a platform?
- Should "Hbf" be expanded to "Hauptbahnhof", or the suffix "(Westf)" to
"(Westfalen)"?
- Have the tracks in the station "Vaugirard" this name or the name
"Montparnasse"?

Paul has already mentioned that, to the contrary of these observations,
at some places the stops don't have explicit names and get their names
from nearby street features.

To sum up: if you set up a consolidation service to mix up GTFS data
with OSM data outside OSM, a lot of people would be grateful. If you
push somehow converted GTFS data into OSM then most mapppers will treat
this as more harm than good.

Best regards,

Roland


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

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

Stephen Sprunk
In reply to this post by Paul Johnson-3
On 2016-06-21 00:27, Paul Johnson wrote:

> On Mon, Jun 20, 2016 at 10:51 PM, Stephen Sprunk <[hidden email]>
> wrote:
>> On 2016-06-20 16:18, Paul Johnson wrote:
>> On Mon, Jun 20, 2016 at 2:02 PM, Stephen Sprunk
>> <[hidden email]>
>> wrote:
>>> The situation with GTFS data itself is so bad that Google stopped
>>> offering Navigation for the transit mode in it's own Maps service.
>>
>> It's still available where I live and several other major cities I
>> checked, so perhaps they just disabled it in your area because they
>> recognized the GTFS data there was so bad?
>
> I mean the realtime, stop-by-stop navigation that was formerly
> offered.  Even in areas with really good GTFS feeds, this
> functionality is Just Gone.  ... it doesn't follow you in realtime
> or take into account when your trip's fallen off schedule and won't
> make a transfer now.  Nor will it warn you your stop is coming up.

Ah, I never thought to try that since transit here is reliable enough to
set your watch by, so a static schedule is all I've ever needed.

I found a couple transit-specific apps, but they refuse to work until
I'm within some minimum distance of a stop.  In particular, they won't
tell me when I need to be _at_ the nearest P&R station until after I'm
_already there_, and with off-peak headways of up to an hour, I don't
want to arrive too early.  Google Maps will tell me when the next few
trains are leaving (and how long it'll take to drive there in current
traffic) so I know _when_ to leave home.

>> I'm not sure what the solution is, though, so I've been putting the
>> stop positions at the center of the platform until someone tells me
>> better.  FWIW, that seems to be what folks in other cities have
>> done--if they mapped any stop positions at all.
>
> Portland tends to put the stop position where the lead cab of the lead
> car will line up.  However, Portland hits me as a little odd (in terms
> of west coast light rail systems) in that there

Here, at stations where passengers either enter the platform from both
ends or from the middle, trains stop so the center of the train is in
the center of the platform, which means the cab's position varies with
the train's length.  At stations where passengers enter the platform
only from one end, trains stop so the front or rear (depending on
direction) of the train is at that end of the platform.

For the former, it makes sense to put the stop_position in the middle.  
For the latter, perhaps I should put it at/near the relevant end
instead?  If it matters at all.

>> It's always baffled me that so many agencies are willing to give the
>> same designation to different routes just because they share several
>> stops.  ...
>> Part of the reason we _need_ transit navigation apps (and reliable
>> route/schedule data to feed into them) is to hide this sort of
>> complexity from users.
>
> Or obviate it.  Sight unseen, just trying to make sense of the
> situation based on just a map and what stops are handy, there's no way
> I'd figure this out for Tulsa's 101 Suburban Acres route.  Every other
> trip alternates which way the route goes through the eponymous
> neighborhood, so depending on which half hour it is, you might need to
> walk to one end of the neighborhood or the other to catch the bus.  Or
> wait up to an hour instead.  And then some trips make side trips to a
> clinic (during it's business hours) and some trips make an additional
> side trip to a alzheimer's treatment community (based on some
> arbitrary criteria, possibly when the patients are allowed to come and
> go).

Exactly.  While a regular rider of the route can figure it out, or may
pick up a map/schedule for offline planning, the casual or tourist rider
will be baffled and is likely to end up in the wrong place.  Most
drivers I've talked to are very helpful, but there's only so much they
can do if you get on the wrong bus aside from leave you on the side of
the road praying for the right bus to come along before you get
heatstroke, frostbite, etc.  One simple mistake can easily cost you an
extra hour or two of travel time.

>> - How to obtain a name of a station?
>>
>> How is this complicated?
>
> A lot of cities name stops without signposting the name, often in the
> form of "The Street The Route Is On at The Cross Street We're Stopping
> At", such as "South Memorial Drive at East 56th Street" or some
> similar pattern.
>
>  Oh, sorry.  I was assuming a decent GTFS feed, where every stop
> should have an official name, even if it's only cross-streets (typical
> for bus stops).  I thought the question was where to put that it in
> OSM and/or where renderers should look for it.
>
> Yeah, GTFS assumes every stop is named, even though this assumption is
> outright broken even in GTFS's hometown of Portland beyond just naming
> the intersection or block number ("6300 Block Southwest Murray
> Boulevard" as a hypothetical name example of a stop not near a
> corner).

That's how nearly all bus stops here are named, aside from those part of
complex bus/rail stations that tend to have multiple bays/platforms.  I
don't see the problem with that.

It's when you get to those complex stations that you run into questions
of naming the individual pieces vs the station as a whole, but it still
doesn't seem that difficult until you get to rare cases, e.g. multiple
stations that have grown together into one confusing, amorphous blob.

S

--
Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

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

Paul Johnson-3
On Tue, Jun 21, 2016 at 2:02 PM, Stephen Sprunk <[hidden email]> wrote:
On 2016-06-21 00:27, Paul Johnson wrote:
On Mon, Jun 20, 2016 at 10:51 PM, Stephen Sprunk <[hidden email]>
wrote:
On 2016-06-20 16:18, Paul Johnson wrote:
On Mon, Jun 20, 2016 at 2:02 PM, Stephen Sprunk
<[hidden email]>
wrote:
The situation with GTFS data itself is so bad that Google stopped
offering Navigation for the transit mode in it's own Maps service.

It's still available where I live and several other major cities I
checked, so perhaps they just disabled it in your area because they
recognized the GTFS data there was so bad?

I mean the realtime, stop-by-stop navigation that was formerly
offered.  Even in areas with really good GTFS feeds, this
functionality is Just Gone.  ... it doesn't follow you in realtime
or take into account when your trip's fallen off schedule and won't
make a transfer now.  Nor will it warn you your stop is coming up.

Ah, I never thought to try that since transit here is reliable enough to set your watch by, so a static schedule is all I've ever needed.

I found a couple transit-specific apps, but they refuse to work until I'm within some minimum distance of a stop.  In particular, they won't tell me when I need to be _at_ the nearest P&R station until after I'm _already there_, and with off-peak headways of up to an hour, I don't want to arrive too early.  Google Maps will tell me when the next few trains are leaving (and how long it'll take to drive there in current traffic) so I know _when_ to leave home.

RideSystems (and yes, I'm calling them out on this, since I reported the problem a year ago via Google Play) won't even get past the "select your transit system" thing.  Plus it's basically one of those lame "browser in an app" deals, and it still doesn't work all that great in Chrome.  Especially versus holding the paper timetable in hand...seriously MTTA only charges 25¢ for the quarterly timetable, but they could probably charge $25 and they'd still sell just as fast simply because their online route planner and the RideSystems app is so horrible.

Though having the timetable and being able to text a stop-ID to a shortcode and wait a few seconds for which bus will show up first at the stop you already know is convenient is better than their old trip planner by a lot:  Tear out page 4 of the timetable, fill out the form printed on it, then mail it to the transit system's office and wait for them to mail you the answer.  No joke.  Also, that option's still available as of the Winter 2016 timetable I have in my glovebox, for situations where my friends miss their bus and call me up so I can basically track down their route looking for them if they're not sure where they are.

I'm not sure what the solution is, though, so I've been putting the
stop positions at the center of the platform until someone tells me
better.  FWIW, that seems to be what folks in other cities have
done--if they mapped any stop positions at all.

Portland tends to put the stop position where the lead cab of the lead
car will line up.  However, Portland hits me as a little odd (in terms
of west coast light rail systems) in that there

Here, at stations where passengers either enter the platform from both ends or from the middle, trains stop so the center of the train is in the center of the platform, which means the cab's position varies with the train's length.  At stations where passengers enter the platform only from one end, trains stop so the front or rear (depending on direction) of the train is at that end of the platform.

For the former, it makes sense to put the stop_position in the middle.  For the latter, perhaps I should put it at/near the relevant end instead?  If it matters at all.

I think Portland did this because everyone's device will pass through that point if they're remaining on the train, since regardless of whether it's a 1 car or 2 car MAX train, or a vintage streetcar (back when the Historical Society still had timetable slots), you'd touch that point on departure regardless.  I can't test this hypothesis since I'm not aware of any app that'll provide realtime navigation on that system anymore, and I'm like, 2000km away now.
 
It's always baffled me that so many agencies are willing to give the
same designation to different routes just because they share several
stops.  ...
Part of the reason we _need_ transit navigation apps (and reliable
route/schedule data to feed into them) is to hide this sort of
complexity from users.

Or obviate it.  Sight unseen, just trying to make sense of the
situation based on just a map and what stops are handy, there's no way
I'd figure this out for Tulsa's 101 Suburban Acres route.  Every other
trip alternates which way the route goes through the eponymous
neighborhood, so depending on which half hour it is, you might need to
walk to one end of the neighborhood or the other to catch the bus.  Or
wait up to an hour instead.  And then some trips make side trips to a
clinic (during it's business hours) and some trips make an additional
side trip to a alzheimer's treatment community (based on some
arbitrary criteria, possibly when the patients are allowed to come and
go).

Exactly.  While a regular rider of the route can figure it out, or may pick up a map/schedule for offline planning, the casual or tourist rider will be baffled and is likely to end up in the wrong place.  Most drivers I've talked to are very helpful, but there's only so much they can do if you get on the wrong bus aside from leave you on the side of the road praying for the right bus to come along before you get heatstroke, frostbite, etc.  One simple mistake can easily cost you an extra hour or two of travel time.

Fortunately, if a driver is aware of what's going on over his radio and familiar with the headways on the other buses that are on or cross his route, they can usually radio ahead to hold the correct bus to wait a few minutes for you to make a transfer.  Exception being nightline drivers on the last run of the night are dead set on dragging their feet on this because they just want to go home after driving since 4 in the afternoon.
 
- How to obtain a name of a station?

How is this complicated?

A lot of cities name stops without signposting the name, often in the
form of "The Street The Route Is On at The Cross Street We're Stopping
At", such as "South Memorial Drive at East 56th Street" or some
similar pattern.

 Oh, sorry.  I was assuming a decent GTFS feed, where every stop
should have an official name, even if it's only cross-streets (typical
for bus stops).  I thought the question was where to put that it in
OSM and/or where renderers should look for it.

Yeah, GTFS assumes every stop is named, even though this assumption is
outright broken even in GTFS's hometown of Portland beyond just naming
the intersection or block number ("6300 Block Southwest Murray
Boulevard" as a hypothetical name example of a stop not near a
corner).

That's how nearly all bus stops here are named, aside from those part of complex bus/rail stations that tend to have multiple bays/platforms.  I don't see the problem with that.

It's when you get to those complex stations that you run into questions of naming the individual pieces vs the station as a whole, but it still doesn't seem that difficult until you get to rare cases, e.g. multiple stations that have grown together into one confusing, amorphous blob.

The transit renderer doesn't seem to like to consider the same stop running different directions through the same intersection unless you bang the name up.  A stop might be 41st and Yale in one direction, and Yale and 41st going the other way through the intersection, for example. 

_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

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

Stephen Sprunk
On 2016-06-21 15:12, Paul Johnson wrote:
> On Tue, Jun 21, 2016 at 2:02 PM, Stephen Sprunk <[hidden email]>
> wrote:
>> I found a couple transit-specific apps, but they refuse to work until
>> I'm within some minimum distance of a stop.  ...
>
> RideSystems (and yes, I'm calling them out on this, since I reported
> the problem a year ago via Google Play) won't even get past the
> "select your transit system" thing.

I was going to say "at least they tried", but after a year, I agree.

> Plus it's basically one of those
> lame "browser in an app" deals, and it _still_ doesn't work all that
> great in Chrome.

I don't get why so many folks waste money on that, other than to tell
clueless execs that "we have an app" when all they really have is the
same old website with a app-like shortcut.

Building a custom app probably isn't cheap, but there _must_ be decent
off-the-shelf apps out there that can work from a standard GTFS feed.  
Or they could just make their regular web site work well on mobile
devices too; few riders would care it's not an "app".

> ... better than their old trip planner by a lot:  Tear out page 4 of
> the timetable, fill out the form printed on it, _then mail it to the
> transit system's office and wait for them to mail you the answer_.  No
> joke.

*boggle*

Here, they publish a 24x7 customer service phone number that works for
both trip planning and any other questions/complaints from riders.  
Their web/app trip planner isn't bad, but it doesn't seem to be any
better than Google Maps, which indicates it's using the exact same data
that's in the GTFS feed (maybe the feed itself).

>> [Cross-streets is] how nearly all bus stops here are named, aside
>> from those part of complex bus/rail stations that tend to have
>> multiple bays/platforms.  I don't see the problem with that.
>>
>> It's when you get to those complex stations that you run into
>> questions of naming the individual pieces vs the station as a whole,
>> but it still doesn't seem that difficult until you get to rare cases,
>> e.g. multiple stations that have grown together into one confusing,
>> amorphous blob.
>
> The transit renderer doesn't seem to like to consider the same stop
> running different directions through the same intersection unless you
> bang the name up.  A stop might be 41st and Yale in one direction, and
> Yale and 41st going the other way through the intersection, for
> example.

I'm not sure what you're referring to; the only bus stops I see in all
of Tulsa are the ones at or near Denver Avenue Station, and only one of
DAS's bays seems to be labeled.

Here, there'd be four distinct stops named something like "41st NB @
Yale", "41st SB @ Yale", "Yale EB @ 41st" and "Yale WB @ 41st".  The
only rendering challenge I see is if they're so close at low zoom that
the names would overlap, but since they're all pretty much the same name
anyway, it doesn't matter in practice.


S


--
Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

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

Stephen Sprunk
In reply to this post by Roland Olbricht
On 2016-06-21 11:40, Roland Olbricht wrote:

>> OTOH, this doesn't seem like a huge problem if we're importing the
>> data
>> from elsewhere using automated tools and only tweaking by hand where
>> it's wrong--and ideally, there should be some sort of feedback
>> mechanism
>> to get the source corrected so even that's a short-term problem.
>
> Well, that's explicitly deprecated in OSM. Please look in the wiki
> about mechanical edits.
>
> If you have useful and free data then the better approach is to mix
> them up with OSM data outside OSM and give the OSM mappers a tool such
> that each mapper can pick what he/she deems useful in OSM.

I'm sorry if I was unclear.  I didn't mean that one person should just
blindly dump every GTFS feed into OSM and leave it to others to clean
up.  I was thinking of something that an individual mapper could use to
import the feed(s) in their particular area and resolve conflicts or
errors before uploading, e.g. in JOSM.

One of my concerns is that if multiple people are working in the same
area with the same source data then they should respect each others'
corrections of that data.  Also, if there are multiple tools available,
e.g. GO-Sync and a JOSM plugin, they translate things in exactly the
same way so they're not constantly messing up each others' work.

>> Also, like it or not, Google Maps (and hence GTFS) has set a bar for
>> what users expect from online maps.  I'd certainly like OSM to be
>> better, of course, but the current situation is that OSM is generally
>> far, far worse.
>
> I think this is where local differences matter. In large parts of
> Europe, the transit agencies themselves have already good information,
> OSM is more or less on par with that, and Google lags significantly
> behind.

That seems odd; the GTFS feed should just be an export of the data that
the agency is using for their own tools; it shouldn't be worse somehow.  
I can see how a group of dedicated OSM mappers could improve the
geolocation or station amenities, but we could still free them up from
having to maintain routes/routemasters and such.

Perhaps it's different in Rightpondia, but here in Leftpondia, it's
common to see major (sometimes network-wide) changes to routes and
schedules every 3-6 months.  The thought of having to create hundreds of
routes and thousands of stops from scratch even once is daunting; that a
large chunk of my work would get wiped away before I even finished the
first pass makes it pointless.  OTOH, if tools could do most of the work
and then point me to a handful of places where they couldn't figure out
the right action, it could be done in a few minutes to maybe a few
hours, depending on the scope of a given change.

>>> And: how to tell apart services that run a few times per day from
>>> those
>>> that have a headway of a few minutes?
>>
>> That's starting down a slippery slope to including full schedule data.
>
> Once again, please note that this is a huge difference in local
> culture.
> ...
> If you would like to improve relevance of OSM, discriminating between
> these three levels of service would be a prime concern.

Hmm.  It still seems a slippery slope to me, but if folks in areas where
such a distinction exists find it relevant, I wouldn't stand in their
way.

> This is in contrast to a number of service that run once a day on
> schooldays.
> ...
> And the right solution for this is not to delete these services from
> OSM but to mark them as low-frequency service.

If someone were mapping school bus routes in the US (AFAIK, nobody is),
I'd probably have the same reaction.  Or I might suggest creating an
entirely new mode tag for them so there's no chance of being confused
with non-school bus routes; it seems a more significant distinction than
light_rail vs tram, for instance.

>>> - Where to start/end routing of vehicles?
>
> Sorry for the misunderstanding. I'm talking about getting a vehicle
> from stop to stop. While the overall level of detail is often good
> enough for routing, this doesn't hold always. To find and resolve the
> mapping issues it makes sense to check whether you can route from stop
> to stop. If not, this is always a strong hint that there are mapping
> issues.
>
> I do notice as a benefit from this discussion that not all transit
> agencies (Tulsa, Portland) care whether their routes can be lawfully
> driven in reality. That's different here in, at least in Western
> Europe, maybe all Europe.

Lawfully?  Non-lethally would be a good start!  Routes from many
agencies here, if taken literally, require you to go through buildings,
off bridges to a crossing road without using any ramps, across rivers
without a ferry, etc.  Bus stops can be in the middle of traffic lanes
or hundreds of meters from the road.  Such things are why it's critical
to _not_ undo someone else's manual corrections when importing
updates--yet somehow _not_ preserve old imported data that _wasn't_
corrected.

> I would like to see a set of rules that answer questions like:
> - Does a "name:en" tag on the pole override a "name" tag on the
> stop_position, or vice versa? What about a "name:en" tag on a
> stop_position versus "name" on a platform?

It seems the current behavior is to render the name for each element
independently, except that some (not sure it's deterministic) seem to
get dropped entirely if they'd overlap.

Within each element, which name to render (if any) should be
straightforward.

> - Should "Hbf" be expanded to "Hauptbahnhof", or the suffix "(Westf)"
> to "(Westfalen)"?

A renderer shouldn't have to know such things, and when people try to
add such clever tricks, it usually ends up making things worse, e.g. a
rule to correctly change "N Foo Ave" to "North Foo Avenue" also
incorrectly changes "Ave N" to "Avenue North".

> - Have the tracks in the station "Vaugirard" this name or the name
> "Montparnasse"?

Or the platforms or stop positions.  I've been trying to figure out what
to do on that front myself; so far I've simply left everything but the
station itself unnamed because otherwise the current rendering output is
unusable except at the highest zoom levels.  And that's for far simpler
cases than what you describe, e.g. a station named "Akard" with a pair
of platforms named (as signed) "North" and "South"!

S

--
Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

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

Roland Olbricht
> I'm sorry if I was unclear.  I didn't mean that one person should just
> blindly dump every GTFS feed into OSM and leave it to others to clean
> up.  I was thinking of something that an individual mapper could use to
> import the feed(s) in their particular area and resolve conflicts or
> errors before uploading, e.g. in JOSM.

Thank you for the clarification. Yes, I would agree to that. I could
image to let a JOSM plugin produce a layer of coordinates from the GTFS
stop data.

There could as well be a feature to do routing along the sequence of
stops that are provided with GTFS data.

> Perhaps it's different in Rightpondia, but here in Leftpondia, it's
> common to see major (sometimes network-wide) changes to routes and
> schedules every 3-6 months.

Thank you. This is indeed an important disctinction. Here, bus services
are stable always at least a year, usually five to ten years and
sometimes for decades. Services on rails are usually even more stable.

For example, my ancient home town Wuppertal introduced a new bus network
in 1994 and is mostly offering the same service right now.

Best regards,

Roland


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

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

Jo-2
Darya (a GsoC student) is actually working on a project to help with the routing. We haven't included conversion from GTFS and I'm not sure there will be time for that. What's most time consuming, especially because of changes/breakings caused by other mappers and PT itineraries subject to change, is to keep the routing up to date and that's what the new plugin aims to solve.

At the moment it hooks mostly into the validator (so less routes would be broken due to other changes made to the geometry of the ways), but it's still work in progress.

If you like, you can help with beta testing, of course. It does already help with routes going against one way traffic flows.

It's called PT_assistant.

Polyglot

2016-06-25 6:54 GMT+02:00 Roland Olbricht <[hidden email]>:
I'm sorry if I was unclear.  I didn't mean that one person should just
blindly dump every GTFS feed into OSM and leave it to others to clean
up.  I was thinking of something that an individual mapper could use to
import the feed(s) in their particular area and resolve conflicts or
errors before uploading, e.g. in JOSM.

Thank you for the clarification. Yes, I would agree to that. I could image to let a JOSM plugin produce a layer of coordinates from the GTFS stop data.

There could as well be a feature to do routing along the sequence of stops that are provided with GTFS data.

Perhaps it's different in Rightpondia, but here in Leftpondia, it's
common to see major (sometimes network-wide) changes to routes and
schedules every 3-6 months.

Thank you. This is indeed an important disctinction. Here, bus services are stable always at least a year, usually five to ten years and sometimes for decades. Services on rails are usually even more stable.

For example, my ancient home town Wuppertal introduced a new bus network in 1994 and is mostly offering the same service right now.

Best regards,

Roland



_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit


_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit
Reply | Threaded
Open this post in threaded view
|

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

Stephen Sprunk
On 2016-06-25 00:53, Jo wrote:
> Darya (a GsoC student) is actually working on a project to help with
> the routing. We haven't included conversion from GTFS and I'm not sure
> there will be time for that. What's most time consuming, especially
> because of changes/breakings caused by other mappers and PT
> itineraries subject to change, is to keep the routing up to date and
> that's what the new plugin aims to solve.

Import of GTFS is what I'm most interested in, particularly due to the
"subject to change" part of that.  Other mappers in my area (a metro
area of 5+ million) don't seem interested in transit routes; I'm
interested, but it's a monumental task for one person, hence my desire
for as much automation as possible.  I have to imagine there are others
like me elsewhere, and it's the kind of thing that can have huge impact
on non-mapping users by providing high enough quality data that
developers will add transit functionality to apps that currently ignore
it, e.g. OsmAnd, and that will in turn generate more people willing to
improve the data.

I'll admit my interest is more rail transit than buses, and rail doesn't
change much, but even rail routes aren't well done in many places--and
the standard map renderers seem to ignore rail almost entirely, perhaps
because the tagging isn't consistent.  That could be improved as well,
even if one ignores the GTFS import part, just by analyzing the existing
data in OSM and fixing its tags.  I"m willing to work on bus data too,
even though I rarely ride buses, for that reason, but that's a much
longer-term project due to the sheer number of stops.  Part of my
interest in importing them is I suspect other mappers (or users with
apps with feedback buttons) are more likely to improve existing stops
that are part of a network but not in exactly the right location than
create new ones in complete isolation.

> At the moment it hooks mostly into the validator (so less routes would
> be broken due to other changes made to the geometry of the ways), but
> it's still work in progress.

That's roughly what I was thinking: import the data, create a bunch of
new nodes/ways/routes, merge them with existing ones where certain tags
(e.g. gtfs:stop_id) match, and then let the validator scream about any
remaining suspected errors (e.g. a stop with gtfs:stop_id and one
without it within 400m).  The first time would likely be a mess,
particularly in places with preexisting data, but future imports should
only generate errors where there have been legitimate changes in the
imported data, e.g. a new stop is added.

> If you like, you can help with beta testing, of course. It does
> already help with routes going against one way traffic flows.
>
> It's called PT_assistant.

I'm happy to help test if it provides functionality that's useful.

S

--
Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

_______________________________________________
Talk-transit mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-transit