Proposal: Provide a way to indicate entrances and pedestrian pathways

[Joe Hughes]

Motivation:
Until now, GTFS has only provided locations for the points at which a
rider boards or alights from a vehicle ("stops"). However,
underground and elevated stations have specific entrances that allow
the user to reach them from the street network, which are often in
significantly different locations than the stops themselves.
Providing detailed entrance information would allow GTFS-consuming
routing engines to improve their routing results and to generate
clearer travel instructions.

Proposal:

stops.txt:

location_type - A new value "2" is added, to indicate that that this
location represents an entrance/exit for a station or stop. All other
fields in stops.txt apply to entrances, except for zone_id, which is
ignored for entrances.

parent_station - An entrance can have its parent_station value set to
a station, or left empty

pathways.txt (new file):

The pathways.txt file defines pathways that a rider can take between
locations defined in stops.txt. (Technically speaking, each entry in
this file is an edge in a directed graph.) A given pair of locations
can have any number of pathways between them, as some pathways might
have restrictions on their use. When there are multiple possible
pathways, a routing engine should choose the pathway that's most
advantageous for the rider (for instance, the path with the least
traversal_time given the user's accessibility constraints).

If one of the endpoints of a pathway is a station, it means that this
pathway applies equally to all stops and entrances whose
parent_station value is set to the given stop_id.

If any pathways at least one entrance to a particular stop (or its
parent station), a client that knows how to process entrances must
only route a rider between the street network and the stop through the
entrances.

An entrance must be used by at least one pathway to be usable to a
routing engine; put another way, simply assigning a parent_station to
an entrance does not connect it to the rest of the locations with the
same parent_station.

pathway_id (required) - ID string which uniquely identifies this
pathway

from_stop_id (required) - contains the stop_id value of a stop,
station, or entrance defined in stops

to_stop_id (required) - contains the stop_id value of a stop, station,
or entrance defined in stops

one_way (required) - specifies whether this pathway can be traveled
both ways. The values allowed:
1 - the pathway can only be traveled in the direction from_stop_id ->
to_stop_id
0 - the pathway can be traveled in both directions

wheelchair_accessible (optional) - indicates whether this pathway can
comfortably and safely be traversed by a rider in a wheelchair. The
possible values are:
0 - the pathway is not wheelchair-accessible
1 - the pathway is wheelchair-accessible
(empty) - no information is available about the wheelchair-
accessibility of this pathway

traversal_time (optional) - Indicates the typical amount of time it
would take (in seconds) for a rider to travel between the location
indicated by from_stop_id to the location indicated by to_stop_id (or
vice-versa, if one_way is 0). If the traversal_time value is the
empty or 0, that indicates that no traversal time estimate is
available for this pathway (in this case, a routing engine would
typically use an estimate based on geographical distance).

Discussion:
This proposal builds a great deal upon previous proposals by Kevin
O'Malley and David Turner in the following thread:
http://groups.google.com/group/gtfs-changes/browse_thread/thread/cac0f8c52e0e8e46/

Here are some of the rationales for the approach in this proposal.

1) Defining entrances in stops.txt. Other proposals on the table use
a new table to define entrances, but the advantage of using stops.txt
is that it allows entrance IDs to be in the same namespace as stops
and stations, which simplifies the specification of pathways.

2) Using a new file for pathways instead of transfers.txt. In
general, it's not a good idea to overload the semantics of an existing
table without a strong benefit, and in this case, I believe that the
semantics of pathways are different enough from transfers (for
instance, a "timed" pathway wouldn't have a well-defined meaning).

3) Providing a traversal time rather than a distance. This is
predicated on the assumption that it's much easier to collect a
traversal time (using a stopwatch) than a distance, particularly if
the pathway goes through fare gates, elevators, escalators, etc.

Given the complexity of this problem, I expect that we'll have a
healthy debate about the details of this proposal and its merits
relative to previous entrance proposals.

Thanks,
Joe Hughes
Google

[tompw]

This proposal has the advantage that one can define walking times
between stops, even those without explicit "entrances". This would be
of benefit where the roueting software has insufficient information
about pedestrian links (like any software working purely on the GTFS
data).

[David Turner]

This looks like it would work for OpenTripPlanner.

On Thu, 2010-02-04 at 17:13 -0800, Joe Hughes wrote:
> If any pathways at least one entrance to a particular stop (or its
> parent station), a client that knows how to process entrances must
> only route a rider between the street network and the stop through the
> entrances.

This sentence should probably be rewritten:

If a stop (or its parent station) with location_type not equal to 2 ever
is a to_stop_id in pathways.txt, a client that knows how to use

[Devin Braun]

Thanks Joe for this comprehensive proposal!

In some cities (NYC comes to mind), entrances are only open during
limited times of day. A slight improvement/additional functionality
of the proposal could be two more fields in stops.txt which would be
valid for any location_type = 2 describing the opening hours of the
entrance (entrance_opening_time and entrance_closing_time).

Devin Braun
San Diego MTS

[KevinChicago]

Joe, yes, thanks for going forward with this.

Another thing I like is that with the directionality, one could set-up
an entrance to only be in the to_stop_id field of pathways.txt, hence
becoming just an exit-only point, which is good.

You said: "Using a new file for pathways instead of transfers.txt."
So to clarify, many data providors may migrate some of their use of
the transfers.txt file to the pathways.txt file, but transfers.txt
will still exist.

Following up on David Turner's reponse. It may be need to be more
descript. Forcing an entrance to be used in route engines is required
when routing the person from the street/pedestrian network to the
transit network. But when making a transfer between two stop_ids, we
don't want the route engine to force the entrance to be used, most of
the time, but sometimes, we might. We in Chicago have transfer
opportunities that are completely within one station and we have one
that is within two stations and both do not require going through an
entrance (there's a tunnel in second example). But we have some
transfers that are between two stations but you do have to leave the
station, walk on public streets, hence need to exit and entrance and
go through an entrance to make the transfer.

So it seems to me that to allow a route engine to transfer between two
stop_ids, where one or both of the stop_ids has an entrance, the data
providor needs to take some extra care in getting this right. So
possibly a requirement would be that if you don't want a route engine
to use an entrance on a transfer, then you must code the stop_id-to-
stop_id pathway in pathways.txt. In other words, once an entrance is
added to a stop/station, then all the possible transfers that don't
use the entrance need to be coded into pathways.txt as well (and
probably don't need to be coded in transfers.txt anymore).

For my situation in Chicago where a customer needs to leave the
entrance and enter another station, then those do NOT get coded in
pathways.txt, but instead are coded only in transfers.txt, allowing
the transfer to still be recommended, but forcing the entrances to be
used (and the street/pedestrian network in between ) in the route
engine results.

I'm still thinking some of this through, so maybe I'm missing a big
piece of logic here, but I think, in general, we have a winner.

Kevin

[Joe Hughes]

On Feb 5, 8:17 am, Devin Braun <devin.br...@sdmts.com> wrote:
> In some cities (NYC comes to mind), entrances are only open during
> limited times of day.  A slight improvement/additional functionality
> of the proposal could be two more fields in stops.txt which would be
> valid for any location_type = 2 describing the opening hours of the
> entrance (entrance_opening_time and entrance_closing_time).

Hey Devin,

I agree that in the future we'll probably want to specify days and
times-of-day where pathways apply. However, I left it out of this
draft, since it already has quite a lot of complexity for us to
debate. I also think that time-of-day information could be helpful
for fares.

Anyway, to help convince you that this proposal would allow adding
time restrictions later, here's a sketch of how it could work:

1) We define a set of time_ids that describe date + time-of-day
ranges, either by extending the existing service period mechanism, or
something new

2) We add a new column to pathways.txt that indicates which time_id a
given pathway is restricted to.

That's just a sketch, but hopefully it's enough to convince us that we
could add the time restrictions at a later date.

Joe Hughes
Google

[Joe Hughes]

On Feb 5, 9:32 am, KevinChicago <komal...@transitchicago.com> wrote:
> You said: "Using a new file for pathways instead of transfers.txt."
> So to clarify, many data providors may migrate some of their use of
> the transfers.txt file to the pathways.txt file, but transfers.txt
> will still exist.

Yes, transfers.txt would still exist. GTFS extensions should always
be backwards-compatible--there would be no point in removing a file
that was already in the spec, since it would make existing feeds
instantly invalid.

> Following up on David Turner's reponse.  It may be need to be more
> descript.  Forcing an entrance to be used in route engines is required
> when routing the person from the street/pedestrian network to the
> transit network.  But when making a transfer between two stop_ids, we
> don't want the route engine to force the entrance to be used, most of
> the time, but sometimes, we might.  We in Chicago have transfer
> opportunities that are completely within one station and we have one
> that is within two stations and both do not require going through an
> entrance (there's a tunnel in second example).  But we have some
> transfers that are between two stations but you do have to leave the
> station, walk on public streets, hence need to exit and entrance and
> go through an entrance to make the transfer.
>
> So it seems to me that to allow a route engine to transfer between two
> stop_ids, where one or both of the stop_ids has an entrance, the data
> providor needs to take some extra care in getting this right.  So
> possibly a requirement would be that if you don't want a route engine
> to use an entrance on a transfer, then you must code the stop_id-to-
> stop_id pathway in pathways.txt.  In other words, once an entrance is
> added to a stop/station, then all the possible transfers that don't
> use the entrance need to be coded into pathways.txt as well (and
> probably don't need to be coded in transfers.txt anymore).

Yes, it's good that you're digging into this point. The interaction
between transfers and pathways/entrances definitely needs more
clarity. I look forward to hearing proposals from this group about
how that should work (or whether there's a better way to represent
this stuff in general).

Joe Hughes
Google

[Louis St-Amour]

As a bit of an outsider/lurker, I'm totally in favour of this proposal, but I'm curious as to how it might be used by a routing engine. 

Similar to the hours suggestion earlier-- in Toronto we've entrances which are only staffed at certain times, but at other times while the station is open, you can still enter using a token or MetroPass. But you can't use a day pass or get directions. So you might want to describe the entrance in the desc field, perhaps saying if it has an escalator, what type of fare media it accepts and its hours. You could also suggest what entrance to take for which subway line, or which entrances are closest to buses. One entrance at the Yonge-Sheppard subway station is perfect for the Sheppard line, but it's farther than another entrance if you want to take a bus. Which is ironic since buses are actually right next to it by distance. And oddly enough, if you want an accessible route, we've a few street-level elevators for that stop, which can be inconvenient if you don't want to wait for an elevator.

None of this is a problem if you take the time to inspect the entrances on the map, but if routing picks stairs when you really wanted an elevator, there should be a way for it to suggest or highlight the alternate entrances in the routing. A better idea might be to somehow provide PDFs or images of subway stations, such that people could see the outlines of the station and where the buses, trains, washrooms, are, etc. That way with this suggestion, you could draw the best entrance, but let people see the alternates in a visible manner.

I haven't really thought about this enough, but ... I'm in favour of the idea as is, at least.

Louis.

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To post to this group, send email to gtfs-c...@googlegroups.com.
To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gtfs-changes?hl=en.

[J. R. Westmoreland]

From a visually impaired perspective.

PDF is probably not the best way to handle the alt route idea.

 

I like the idea on the whole.

 

Maybe one could figure out how to generate, from the data provided for routes, the input needed to work with one, or several, of the common data mapping engines.

 

Best,

J. R.

 

--------------------

J. R. Westmoreland

Custom Computers & Consulting

E-mail: j...@jrw.org

Twitter: GeneralJR

Skype: j.r.westmoreland

[Arno Eigenwillig]

Hi Joe,

thanks for the proposal. Please let me ask for a few clarifications.

2010/2/5 Joe Hughes <joe.hug...@gmail.com>:

> stops.txt:
>
> location_type - A new value "2" is added, to indicate that that this
> location represents an entrance/exit for a station or stop.  All other
> fields in stops.txt apply to entrances, except for zone_id, which is
> ignored for entrances.

Shouldn't stop_code be ignored for an entrance as well?

> parent_station - An entrance can have its parent_station value set to
> a station, or left empty

When should a feed producer specify a parent_station at all? (After
all, it does not influence routing as described below for
pathways.txt.)

> pathways.txt (new file):
>
> The pathways.txt file defines pathways that a rider can take between
> locations defined in stops.txt.  (Technically speaking, each entry in
> this file is an edge in a directed graph.)  A given pair of locations
> can have any number of pathways between them, as some pathways might
> have restrictions on their use.  When there are multiple possible
> pathways, a routing engine should choose the pathway that's most
> advantageous for the rider (for instance, the path with the least
> traversal_time given the user's accessibility constraints).

If there are two pathways, one from location A to location B, and
another from location B to location C, but none from A to C directly,
should a routing engine consider the combined pathways A-B-C as
information on how to get from A to C?

If there is a pathway from stop A to stop B with duration t1, and also
a transfer from A to B of type 2 with given min_transfer_time t2, how
do these two play together in determining the minimum time needed for
a transfer from a trip arriving at A and another trip departing from
B?

Thanks,
Arno

--
Google Switzerland GmbH

[Joe Hughes]

On Feb 7, 1:55 pm, Arno Eigenwillig <arnoegw.c...@gmail.com> wrote:
> Hi Joe,
>
> thanks for the proposal.  Please let me ask for a few clarifications.
>

> 2010/2/5 Joe Hughes <joe.hughes.c...@gmail.com>:

>
> > stops.txt:
>
> > location_type - A new value "2" is added, to indicate that that this
> > location represents an entrance/exit for a station or stop.  All other
> > fields in stops.txt apply to entrances, except for zone_id, which is
> > ignored for entrances.
>
> Shouldn't stop_code be ignored for an entrance as well?

Good point. Unless there's a good candidate for a useful
interpretation for an "entrance code", we should say for now that a
"stop code" for an entrance doesn't have a meaning in the spec. Do
any of the feed publishers here have numbered/lettered entrances in
their stations?

> > parent_station - An entrance can have its parent_station value set to
> > a station, or left empty
>
> When should a feed producer specify a parent_station at all?  (After
> all, it does not influence routing as described below for
> pathways.txt.)

Similarly, unless we have a clear meaning for this, let's disallow
it. You can also add a meaning to a field combination in the future,
but not remove an existing one, so we might as well be conservative on
this.

> > pathways.txt (new file):
>
> > The pathways.txt file defines pathways that a rider can take between
> > locations defined in stops.txt.  (Technically speaking, each entry in
> > this file is an edge in a directed graph.)  A given pair of locations
> > can have any number of pathways between them, as some pathways might
> > have restrictions on their use.  When there are multiple possible
> > pathways, a routing engine should choose the pathway that's most
> > advantageous for the rider (for instance, the path with the least
> > traversal_time given the user's accessibility constraints).
>
> If there are two pathways, one from location A to location B, and
> another from location B to location C, but none from A to C directly,
> should a routing engine consider the combined pathways A-B-C as
> information on how to get from A to C?
>
> If there is a pathway from stop A to stop B with duration t1, and also
> a transfer from A to B of type 2 with given min_transfer_time t2, how
> do these two play together in determining the minimum time needed for
> a transfer from a trip arriving at A and another trip departing from
> B?

These are good questions. Do you have proposals on how we should
define the semantics for these situations?

Thanks,
Joe Hughes
Google

[David Turner]

On Mon, 2010-02-08 at 10:07 -0800, Joe Hughes wrote:
> On Feb 7, 1:55 pm, Arno Eigenwillig <arnoegw.c...@gmail.com> wrote:
> > Hi Joe,
> >
> > thanks for the proposal. Please let me ask for a few clarifications.
> >
> > 2010/2/5 Joe Hughes <joe.hughes.c...@gmail.com>:
> >
> > > stops.txt:
> >
> > > location_type - A new value "2" is added, to indicate that that this
> > > location represents an entrance/exit for a station or stop. All other
> > > fields in stops.txt apply to entrances, except for zone_id, which is
> > > ignored for entrances.
> >
> > Shouldn't stop_code be ignored for an entrance as well?
>
> Good point. Unless there's a good candidate for a useful
> interpretation for an "entrance code", we should say for now that a
> "stop code" for an entrance doesn't have a meaning in the spec. Do
> any of the feed publishers here have numbered/lettered entrances in
> their stations?

Tokyo.
http://www.tokyometro.jp/global/en/service/using.html#u08

[Joe Hughes]

Yes, there are certainly stations in the world with numbered/lettered
exits, but the key thing in the GTFS process is finding feed
publishers in the community who are willing to help test all the
aspects of new proposals with real data.

Joe Hughes
Google

[Fred]

RE: Ignore stop_code for entrances.

Consider MTR (Hong Kong). Their entrances are often labeled with a
code (e.g. A1) and a landmark (e.g. Time Square).

Using the above example, should:
- stop_code = "A1"
- stop_name = "Time Square" (i.e. the associated landmark)?

[Peter Ludemann]

A few quick comments and questions from Tokyo -- I think that some of these comments would also apply to metro systems in other large cities.

I would extend the accessibility types:

  - requires taking stairs all the way

  - requires taking stairs and escalator

 [or how many vertical meters of stairs and escalators]

  - has escalator all the way

  - has elevator

  - has wheelchair lift on stairs

  - has moving horizontal pathway

  [or: how many horizonal meters of walking and moving pathway]

And for an entrance, I think it should be marked whether a wheelchair can pass through the turnstile or not.

Turnstiles should be marked as to whether they are manned or not and for whether you can buy tickets at them or not (i.e., need to buy a ticket on the train).

Walking time would depend on time of day (rush hour is much slower) and also on where in the station you are going.

A train platform is more than a "stop". For example, in Shinjuku station, there are 16 platforms, and it takes several minutes to walk from one side of the station to the other. Also, the time to get to an entrance from a platform depends on where you are on the platform (it can take several minutes to walk from one end of a platform to the other -- this can be important when trains arrive every few minutes and the trains are long).  Even for a small station, it can take a minute to take an underground passage from one side of the tracks to the other, which is important if you're trying to make a tight connection (in Japan, people routinely work out transit plans that depend on train timings accurate to within 30 seconds).

Some online transit planners take into account walking speed (fast/normal/slow/leisurely).

Can this design handle entrances within a station? For example, in Tokyo station, to get to the Shinkansen, one must first go through a regular entrance, and then through another ticket entrance to get to the Shinkansen (the same ticket is used for both entrances).

In the case where a station has multiple lines, sometimes an entrance can get to only some of the lines. I suppose this could be modeled by having multiple pseudo-stations for the multiple lines, but perhaps there's an easier way? (I think that the inverse, where an entrance goes to multiple stations, can be handled by the proposal).

For the situation where it takes a minute to go from the platform to the turnstile, then 3 minutes to the turnstile of the transfer line (another company's train, but the station name is the same), then another minute to the 2nd line's platform, would we model this as three rows in pathways.txt, with the two turnstiles being modeled as stops? Or would we have to work out all the pairs of trips between platforms and outside entrances? (It's quite common in Japan to have 20 or more entrances, some several blocks from the turnstiles, and then have 2 or 3 entrance turnstiles to different companies, and each of those with multiple lines ... Shibuya station has 8 lines run by 5 companies, at least 30 exits and a dozen turnstiles, with each line having 2-4 platforms. Here's a map: http://jorudan.co.jp/eki/cgi/eki.cgi?eki1=%BD%C2%C3%AB&Dym=201002&Ddd=08&Dhh=14&Dmn=51&Sok=1&rf=eki&pg=1 (this is the 4th busiest station in Japan). This adds up to a lot of point-to-point combinations.

Shinjuku station has 200 exits (I've been told), with 5 companies, 12 lines, dozens of turnstiles ... the combinations get pretty large.

- peter ludemann  (Google Japan)

[Fred]

Add description field to pathways.txt.

It may be useful for agencies to construct human readable pathway
descriptions as it may be too difficult to code the various machinery
and their permutations.

I'd guess that the pair (traversal_time,description) would provide
enough information for most riders.

For example,
"Take escalator to the basement of Times Square." with an estimated
traversal_time.

[Joe Hughes]

Hi Peter,

Thanks for the comments--these are all issues worth considering,
though we'll need to balance thoroughness with the increased potential
for complexity in the spec. Would you mind taking a crack at
defining concrete representations for the things that you mentioned?

Thanks,
Joe Hughes
Google

> station<http://en.wikipedia.org/wiki/Shibuya_Station> has

> 8 lines run by 5 companies, at least 30

> exits<http://jorudan.co.jp/eki/cgi/eki.cgi?Sok=1&Dym=201002&Ddd=07&Dhh=19&D...>
> and
> a dozen turnstiles, with each line having 2-4 platforms. Here's a map:http://jorudan.co.jp/eki/cgi/eki.cgi?eki1=%BD%C2%C3%AB&Dym=201002&Ddd...

> (this
> is the 4th busiest station in Japan). This adds up to a lot of
> point-to-point combinations.

> Shinjuku station <http://en.wikipedia.org/wiki/Shinjuku_station> has 200

> exits (I've been told), with 5 companies, 12 lines, dozens of turnstiles ...
> the combinations get pretty large.
>
> - peter ludemann  (Google Japan)
>
> On Fri, Feb 5, 2010 at 21:34, J. R. Westmoreland <j...@jrw.org> wrote:
>
> >  From a visually impaired perspective.
>
> > PDF is probably not the best way to handle the alt route idea.
>
> > I like the idea on the whole.
>
> > Maybe one could figure out how to generate, from the data provided for
> > routes, the input needed to work with one, or several, of the common data
> > mapping engines.
>
> > Best,
>
> > J. R.
>
> > --------------------
>
> > J. R. Westmoreland
>
> > Custom Computers & Consulting
>
> > E-mail: j...@jrw.org
>
> > Twitter: GeneralJR
>
> > Skype: j.r.westmoreland
>

> > *From:* gtfs-c...@googlegroups.com [mailto:
> > gtfs-c...@googlegroups.com] *On Behalf Of *Louis St-Amour
> > *Sent:* Friday, February 05, 2010 2:17 PM
> > *To:* gtfs-c...@googlegroups.com
> > *Subject:* Re: [gtfs-changes] Re: Proposal: Provide a way to indicate

> > On Fri, Feb 5, 2010 at 2:05 PM, Joe Hughes <joe.hughes.c...@gmail.com>

> > gtfs-changes...@googlegroups.com<gtfs-changes%2Bunsu...@googlegroups.com>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/gtfs-changes?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "General Transit Feed Spec Changes" group.
> > To post to this group, send email to gtfs-c...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > gtfs-changes...@googlegroups.com<gtfs-changes%2Bunsu...@googlegroups.com>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/gtfs-changes?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "General Transit Feed Spec Changes" group.
> > To post to this group, send email to gtfs-c...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > gtfs-changes...@googlegroups.com<gtfs-changes%2Bunsu...@googlegroups.com>
> > .
> > For more
>
> ...
>
> read more »

[Peter Ludemann]

Joe:

I'll definitely work on this, but I won't be able to do anything for at least a week because I'll be traveling.

How do transfers and pathways interact? Does it make sense to add a transfer_type to pathways, so that pathways become a more precise form of transfers?

I don't see anything in the current spec that prevents having stops such as "Shinjuku JR Platform 15" (as long as the trips also use the same precision for their stops) --- do I understand this correctly? If so, then I think that adding a stops.location_type for ticket barriers will do much of what I'd want. (For best navigation through a station, we would need even more details, but I want to investigate how walking directions are modeled in some other systems first -- and it might be overkill at this stage of GTFS design anyway, as long as we can easily extend it later.)

- peter ludemann (Google Japan)

To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.

[KevinChicago]

I agree with Fred, that the pathways.txt should have a pathway_desc
field that gives the agency the option of providing connection
directions. The field can be left blank for some records if need be.

Kevin

> > > Google- Hide quoted text -
>
> - Show quoted text -

[KevinChicago]

Although I guess I should add that if the pathway description needs to
be different depending on the direction of travel then a Stop A to
Stop B combination would need to have two records in the pathway.txt
file, each coded as one-way:

pathway_id,from_stop_id ,to_stop_id,
one_way,pathway_desc,traversal_time

1,A,B,1,go up the stairs,60
2,B,A,1,go down the stairs,60

Or, I guess we could have two pathway_desc fields, letting the pathway
remain coded as two-way:

pathway_id,from_stop_id ,to_stop_id,
one_way,pathway_desc_to,pathway_desc_from
1,A,B,0,go up the stairs,go down the stairs,60

Any preferences?

[KevinChicago]

Oh no. Three in a row from KevinChicago....

Joe had laid out the following rule:

>> An entrance must be used by at least one pathway to be usable to a
>> routing engine; put another way, simply assigning a parent_station to
>> an entrance does not connect it to the rest of the locations with the
>> same parent_station.

Why can't an entrance be associated with a parent_station and not have
a pathway? Why can't it be connected to the other locations
associated with that parent?

It seems to me I could see a feed providor who isn't as interested in
providing their own traversal times or path descriptions, so why can't
the logic be that if an entrance has a parent_station, but no records
in the pathway file, then the routing engine is still forced to use
that entrance, but it assumes it's a two-way path and it falls back on
its default travel time calculation ("as a crow flies")?

Maybe there's a scenario that I'm not thinking of that would throw-off
a route engine; please advise.

Kevin

[Arno Eigenwillig]

Also Hong Kong (and probably many more places) use short alphanumeric
identifiers for entrances:
http://www.mtr.com.hk/jplanner/images/maps/cab.pdf

But are these entrance codes or names? By analogy to stop names and
stop codes, we should probably adopt the following rule: The primary
way of designating an entrance as used on signs and maps in the
station and as understood by passengers should be given as the
stop_name. If, in addition to that, an entrance carries a short,
passenger-visible code, that should be given as the stop_code.

That means, if there really is no other name for an entrance like
"C2", that should be its name, not its code. On the other hand, if an
entrance is mostly signposted as "Main Street" and additional with a
code like "17", these should be name and code, respectively. However,
I suppose the latter case will be rare, because the main use of
additional stop codes is sending the code form your mobile to get a
schedule for the stop; this makes less sense for entrances.

--
Google Switzerland GmbH

[Arno Eigenwillig]

On 8 February 2010 19:07, Joe Hughes <joe.hug...@gmail.com> wrote:
>> > pathways.txt (new file):
...

> These are good questions.  Do you have proposals on how we should
> define the semantics for these situations?

I believe we should give up the idea of multi-hop routing in a more of
less general graph of pathways between stops/stations and entrances.
I see three main reasons against it:

1) It is better for feed providers to declare the pathways that make
sense in their specific setting than for us to try and come up with a
model of how to compute them, because that model will have to be quite
involved to be sufficiently expressive (just remember the turnstiles
and concourses that Peter described). GTFS should be mostly about
transit and not grow an extra part on indoor or road network
navigation.

2) Once you have computed a multi-hop pathway, how do you assemble the
textual information from its "nodes" (stop names, entrance names) and
"arcs" (pathway descriptions) to an English sentence? You need
semi-structured data (types of connections and names of items, much
like we have for transit), and that again means a whole lot of extra
entities in GTFS.

3) It's better to put the burden of expanding a complicated network of
pathways inside a station into simple GTFS data on the few agencies
that actually have it (if any -- none came forward here) than to
complicate GTFS for everyone. Even if that means hundreds of pathways
for a huge station, that's still quite small compared to the schedule
data of such big agencies.

Here is my sketch of a counter-proposal:

In pathways.txt, have the following columns (and some more from this thread):

from_stop_id, to_stop_id, from_entrance_id, to_entrance_id, duration,
pathway_desc

Three types of rows are allowed:
1) Transfer pathways: They have from_stop_id and to_stop_id
referencing stops and optionally ..._entrance_id referencing an
entrance on the respective end. They declare one pathway that can be
used for transfers between the given stops.
2) Exit pathways: They have from_stop_id referencing a stop,
from_entrance_id referencing an entrance, and the to_..._id fields
being null (empty). They declare a possibility to leave a stop
through an entrance to the streets, either at the end of a journey, or
to reach a transfer stop to which no pathway is given.
3) Entry pathways: Conversely, they have to_..._id set and from_...id
null and declare a possibility to enter a stop from the streets
through an entrance, either at the beginning of a journey or to make a
transfer for which no pathway is given.

Pathways are never concatenated.

duration is the number of seconds to traverse the pathway. It
modifies the walking duration estimates ordinarily used in GTFS
consumers as follows: If exit or entry pathways apply, these parts of
the walk between the stops are excluded from the ordinary walking
duration estimation and their duration(s) are added afterwards. If a
transfer pathway applies, its duration replaces the ordinary walking
duration estimation.

(To be discussed: What if there is a transfer with a min_transfer_time
(transfer_type 2) less than the applicable duration(s)?)

pathway_desc is an optional human-readable string that explains how to
traverse the pathway. If it is given, the names of the involved
entrances are *not* displayed; the string must say it all. (However,
entrance locations may still be used to draw the pathway on a map.)

In all of the above, where a station appears in place of a stop, the
respective row is to be interpreted as if it appeared multiple times,
with each stop of the station occurring once in its place (as for
transfers.txt).

Like I said, this is just a sketch and details may be wrong, but let's
use it to discuss if this rigid form of pathways (stop-centric, with
entrances as attributes) is simpler and cleaner than Joe's original
proposal with free-form pathways.

Kind regards,

[Arno Eigenwillig]

On 12 February 2010 11:24, Arno Eigenwillig <arnoeg...@gmail.com> wrote:
> Like I said, this is just a sketch and details may be wrong, but let's
> use it to discuss if this rigid form of pathways (stop-centric, with
> entrances as attributes) is simpler and cleaner than Joe's original
> proposal with free-form pathways.

Here is another way to reach more or less the same goal, but keep the
syntax closer to Joe's original proposal:

pathways.txt keeps the proposed format, but only pathways between a
stop and an entrace to it are supported. Pathways are not
concatenated. Effectively, pathways is restricted to describing
walking between the stops of a station and the entrances of the same
station.

transfers.txt is extended with new optional fields from_entrance_id,
to_entrance_id that describe which entrance (if any) is to be used at
either end of the transfer to leave/enter the station.

[Kevin Branigan]

Hey Kevin / non-Kevins,

In Toronto we have had these exact problems with internal station
routing and have solved it in a fashion similar to what is being
discussed, though we call them station edges.
Basically we keep entrances in the stops table and have station edges
with the following fields: from_id, to_id, type, length, start_time,
end_time, service_id and disabled.
Type is currently limited to: stairs, elevator, hallway, escalator
away, escalator towards and escalator off. Length is the number of
stairs or equivalent length (or feet for hallway) - we calculate
traversal_time on the fly.

There are a few more exceptions that we've encountered, such as
escalator schedules (going up from 6am-10am weekdays, down the rest of
the time). When necessary, we create several station edges to
describe a full schedule. Entrance schedules are also managed this
way.

As there are four possible ways to describe escalators (up-away, down-
toward etc), we create a strict lower level to upper level rule so
that edges like stairs do not require to be duplicated and so we can
also produce better diagrams of a station.

There are also the disabled escalators, elevators and entrances - our
planner needs to be able to change these details while running but
maintenance is scheduled and can take months and should be considered
in the static graph. Keep in mind also, a disabled escalator is not
the same as a turned off escalator.

Kevin Branigan
refactory, (myttc.ca)

On Feb 12, 8:42 am, Arno Eigenwillig <arnoegw.c...@gmail.com> wrote:

[Joe Hughes]

Thanks for this analysis & proposal, Arno--I feel like it's really
helpful to explore these kinds of alternatives in the level of
concrete detail that you provided.

On Feb 12, 2:24 am, Arno Eigenwillig <arnoegw.c...@gmail.com> wrote:
> I believe we should give up the idea of multi-hop routing in a more of
> less general graph of pathways between stops/stations and entrances.

I like it, simplicity is good.

> Three types of rows are allowed:
> 1) Transfer pathways: They have from_stop_id and to_stop_id

> 2) Exit pathways: They have from_stop_id referencing a stop,

> 3) Entry pathways: Conversely, they have to_..._id set and from_...id

I think this section illustrates a problem with this form of the
counterproposal: the fact that you need a long-ish section to define
three alternate sets of semantics (each with a different set of valid
fields) for a row in pathways.txt. It seems to me that your following
variant (where pathways.txt is only used for entrance/exit paths, and
transfers.txt can just be annotated with entrance to use) requires
less explanation, and thus is preferable.

Thanks,
Joe Hughes
Google

[Joe Hughes]

Kevin B.,

Thanks for sharing your experience. It's great to be able to inform
this discussion with empirical results from your work. Would you be
willing to post some examples of how you've expressed various things
in your private extension?

Thanks,
Joe Hughes
Google

[Arno Eigenwillig]

2010/2/12 Joe Hughes <joe.hug...@gmail.com>:

> It seems to me that your following
> variant (where pathways.txt is only used for entrance/exit paths, and
> transfers.txt can just be annotated with entrance to use) requires
> less explanation, and thus is preferable.

Right... So let me work it out to some more detail. To summarize,
the point here is to (i) have a clear separation between pathways.txt
and transfers.txt, (ii) only allow 1-hop pathways between a stop and
an entrance to steer clear of the challenges of indoor routing.

Proposal:

stops.txt

location_type - A new value "2" is added, to indicate that that this

location represents an entrance for a station or stop (where
"entrance" also means "exit"). All other fields in stops.txt apply to
entrances, with the following modifications:

zone_id is ignored and should be empty.

stop_name (required) contains the name of the entrance that is used to
identify it from within the station (usually, a street or landmark
where the entrance is located, or a synthetic name, like a short
alphanumeric code, used on signs inside the station).

If an entrance has a short code that can be displayed non-redundantly
in *addition* to its name, it can be specified in column stop_code
(optional).

If an entrance belongs entirely or primarily to one station, it should
set parent_station accordingly. Feed consumers can then display it as
belonging to this station. (E.g., Google Maps could put the station's
icon and name at the location of the entrance, as is currently done in
Moscow for close zoom levels.)

[[ NOTE: It is stations (not stops) that are advertised as the logical
nodes of a transit network at large, and here I want to capture the
static, high-level relation of entrances to stations, even if the
don't actually connect to all stops. ]]

pathways.txt (now restricted to walking *inside* a station only;
should it be renamed?)

[[ NOTE: I deleted pathway_id; I saw no use of it. ]]

stop_id (required): A stop_id from a row of stops.txt with
location_type 0 or 1, specifying the stop or station to which this
pathway gives access. If a station is specified, this pathway applies
to all of its stops.

entrance_id (required): A stop_id from a row of stops.txt with
location_type 2, specifying the entrance through which this pathway
gives access.

can_enter (optional): If 1 or absent, the pathway can be used to enter
through the entrance to the stop; if 0, it cannot.

can_exit (optional): If 1 or absent, the pathway can be used to exit
the stop through the entrance; if 0, it cannot.

traversal_time (optional): The time in seconds (0 or more) to traverse
the pathway; if empty, the feed consumer is left to estimate itself
(typically, based on geographic distance).

[[ NOTE: A time of 0 seconds may make sense in boundary cases. If we
want an illegal value to denote "empty", I suggest -1. ]]

pathway_desc (optional): Instructions how to traverse the pathway.
NB: If specified, it must make sense in both directions, unless one of
can_{enter,exit} is 0.

wheelchair_accessible (optional): indicates whether this pathway can
comfortably and safely be traversed by a rider in a wheelchair. The
possible values are:
0 - the pathway is not wheelchair-accessible
1 - the pathway is wheelchair-accessible
(empty) - no information is available about the wheelchair-
accessibility of this pathway

[[ NOTE: For now, I consider wheelchair_accessible an attribute that
marks a routing result as accessible or not, not as an additional
criterion in searching routes, because it would sidetrack us into the
question of how to support multiple specified transfers for accessible
and non-accessible (but faster) paths. ]]

If a stop (or its station) appears at least once in pathways.txt, it
can be entered or left *only* through the entrances specified in
pathways.txt, except for transfers specified in transfers.txt. That
means, walking from a source location to the first stop, walking from
or to a stop to do a transfer not specified in transfers.txt, and
walking from the last stop to a target location have to go via
entrances and can no longer start from the stop location.

For each triple of stop, entrance and direction (can_enter /
can_exit), only one pathway may be specified, including the
specifications obtained by expanding stations into all their stops.

To be discussed:
- If an entrance has a parent_station but does not appear in
pathways.txt, should it be attached by default to all stops of the
station with unknown traversal_time as if there was a single row in
pathways.txt to that effect? [[ KevinChicago suggested that. ]]
- Feed providers will need guidance: When is the entrance's name shown
next to pathway_desc? I'd say: never, because it's hard to mix the
two; the entrance name is just a fallback for the common case that
there is no pathway_desc.
- Should we give up can_{enter,exit} and instead replace stop_id,
entrance_id by an ordered pair from_id, to_id in which exactly one
must be an entrance? It's easier for feed consumers, and with
pathway_desc, having one row for both directions gets questionable.
- Do we want to be more permissive about having more than one pathway
per stop-entrance pair?

transfers.txt:

Add new columns that provide additional attributes on transfers. (The
applicability of transfers to routes is not changed.)

from_stop_entrance, to_stop_entrance (optional): If non-empty, a
stop_id from a row of stops.txt with a location_type 2, specifying the
entrance (if any) to be used at the beginning or end, resp., of the
transfer. The pathway between a stop and its entrance must be defined
in pathways.txt [[or be implied by parent station?!]] and have
can_{enter,exit} set such that it is usable in the direction it
appears here.

The traversal_time of pathways at the beginning or end of the transfer
modifies the walking duration estimates ordinarily used by a GTFS
consumer as follows: The parts of the walk between the stops that are
covered by pathways are excluded from the ordinary walking duration

estimation and their duration(s) are added afterwards.

Even if a stop has entrances and therefore can no longer be accessed
without using an entrance "from the streets", it is still permissible
to omit an entrance for the transfers it is involved in. This
represents transfers that bypass the ordinary way of entering or
leaving a station; be it for two stops inside the same station, or for
a transfer across stations that uses, say, a tunnel without access to
the streets). [[KevinChicago mentioned this.]]

[[ NOTE: A transfer of transfer_type 2 can specify min_transfer_time
and helps in the case that tompw mentioned: GTFS consumers without
on-the-side information about walking durations. ]]

To be discussed:
- What if there is a transfer with a min_transfer_time (transfer_type
2) less than the applicable traversal_times of pathways on its ends?

[Kevin Branigan]

Joe,

I'll give in full detail how we model something like Greenwood Station
in Toronto (it's a small station, serving the Danforth line)

I made 5 'stops' for it:

- 'Greenwood Station Eastbound Platform'
- 'Greenwood Station Westbound Platform'
- 'Greenwood Station Mezzanine'
- 'Greenwood Station Bus Bay'
- 'Greenwood Station Linsmore Entrance'

As for stop times, the subway uses the Eastbound and Westbound
Platforms and the 31 Greenwood bus stops at the Bus Bay.

There are several station edges here, including:

- 20 Stairs from Westbound Platform to Mezzanine
- Escalator up from Westbound Platform to Mezzanine
- 20 Stairs from Eastbound Platform to Mezzanine
- Escalator up from Eastbound Platform to Mezzanine

- 32 Stairs from Mezzanine to Bus Bay
- Escalator up from Mezzanine to Bus Bay

- Door from Bus Bay to Linsmore Entrance

All station edges are 'up', as in from downstairs to upstairs, though
I only did that to reduce the number of edge types.

Linsmore Entrance is the only stop that we connect to our OSM graph
(street graph for walking directions).
When Iroquois (our trip planner) is restricted to walking and using
only elevators, it can't get to the subways because it can't traverse
the stairs or escalators. (We start and end all trip requests from
street level) It can however get on a bus from here, because it can
access the bus bay.

This is a really simple station however and it isn't accessible.
There are no scheduled edges, no elevators and nothing is broken or
disabled.

If one of the Escalators is scheduled like at Bloor-Yonge, we just put
in multiple edges with start and end times (and service_ids)
- Escalator up from Mezzanine to Bus Bay between 6am and 10am
weekdays
- Escalator down from Mezzanine to Bus Bay between 10am and 2am
weekdays
- Escalator up from Mezzanine to Bus Bay saturday/sunday/holidays

Hopefully this all makes sense,
Kevin

[Joe Hughes]

Thanks for a very clear and concrete write-up, Arno. I've inlined a
few comments:

On Feb 15, 9:00 am, Arno Eigenwillig <arnoegw.c...@gmail.com> wrote:
> If an entrance has a short code that can be displayed non-redundantly
> in *addition* to its name, it can be specified in column stop_code
> (optional).

Upon further reflection, this blurring of semantics makes me a little
uncomfortable. Specifically: stop_code is intended to be something
that the user can input into some other system (i.e. realtime dial-up
UI). If we're going to use this value for entrances, its semantics
should be very similar so that we don't end up with two different
types of values in the same field.

> [[ NOTE: It is stations (not stops) that are advertised as the logical
> nodes of a transit network at large, and here I want to capture the
> static, high-level relation of entrances to stations, even if the
> don't actually connect to all stops. ]]

Since stations are a relatively new addition to the spec, it's often
true in practice that many clients would be advertising GTFS "stops"
as the logical nodes of a transit network. I agree that going
forward, stations are more desirable to use, but the distinction is
important.

> pathways.txt (now restricted to walking *inside* a station only;
> should it be renamed?)

I guess this begs the question of what you mean by "inside"; not all
stations will be covered/underground.

> [[ NOTE: I deleted pathway_id; I saw no use of it. ]]

Well, this is one of those things where if it's not a required field
at the beginning, it'll be hard to add later in a meaningful way. I
expected that an ID/primary key would be useful for debugging and
later add-ons, but it's true that it's something of a speculative
thing (typically discouraged in discussions here). I'm interested in
the group's thoughts here.

> can_enter (optional): If 1 or absent, the pathway can be used to enter
> through the entrance to the stop; if 0, it cannot.
>
> can_exit (optional): If 1 or absent, the pathway can be used to exit
> the stop through the entrance; if 0, it cannot.

What is the meaning of specifying 0 for both of these? Would an
"enum" of "enter only"/"exit only"/"both enter and exit" make more
sense to enforce this? Do we anticipate any other values for
can_enter/can_exit in the future?

> [[ NOTE: For now, I consider wheelchair_accessible an attribute that
> marks a routing result as accessible or not, not as an additional
> criterion in searching routes, because it would sidetrack us into the
> question of how to support multiple specified transfers for accessible
> and non-accessible (but faster) paths. ]]

I applaud your effort to keep the discussion focused, but if we tackle
accessibility at all, I'm not sure we can avoid this discussion. I
believe that the OpenTripPlanner folks are very keen on supporting
accessibility features in route planning; could someone from that
project comment on whether you could help test this aspect of
entrances/pathways in the near term?

> For each triple of stop, entrance and direction (can_enter /
> can_exit), only one pathway may be specified, including the
> specifications obtained by expanding stations into all their stops.

This may be reasonable for the initial iteration of this proposal, if
we exclude accessibility info. We should also make sure that this
restriction could be dropped in the future, if we wanted to add time-
dependent paths (such as in NYC, where some entrances become exit-only
at night).

> - Should we give up can_{enter,exit} and instead replace stop_id,
> entrance_id by an ordered pair from_id, to_id in which exactly one
> must be an entrance?  It's easier for feed consumers, and with
> pathway_desc, having one row for both directions gets questionable.

Good point about pathway_desc; let's make sure that pathway_desc gets
exercised in the testing of this proposal. It may be that no one uses
bidirectional pathways because of this.

Joe Hughes
Google

[Joe Hughes]

Thanks, Kevin.

Is it possible to post snippets of the relevant data tables for this
example, to put things in the most concrete terms?

Joe Hughes
Google

[David Turner]

On Tue, 2010-02-16 at 11:08 -0800, Joe Hughes wrote:
> > [[ NOTE: For now, I consider wheelchair_accessible an attribute that
> > marks a routing result as accessible or not, not as an additional
> > criterion in searching routes, because it would sidetrack us into the
> > question of how to support multiple specified transfers for accessible
> > and non-accessible (but faster) paths. ]]
>
> I applaud your effort to keep the discussion focused, but if we tackle
> accessibility at all, I'm not sure we can avoid this discussion. I
> believe that the OpenTripPlanner folks are very keen on supporting
> accessibility features in route planning; could someone from that
> project comment on whether you could help test this aspect of
> entrances/pathways in the near term?

Yes, we're extremely interested in supporting accessibility features,
and we are prepared to implement, do some testing of, and perhaps offer
a public demo instance, entrance data including accessibility.

In particular, once there is a proposal and some test data for the
proposal, I'll put in the engineering time to implement it pretty
quickly.

I'm not sure that I understand Arno's comment fully, so my comment may
not be quite on-point. But I think that if we mark pathways using
wheelchair_accessible as proposed, that's sufficient for the
pathways.txt proposal.

We do at some point need to add wheelchair_accessible column to
transfers.txt, but that is, I think, fully separable from pathways.txt.
If we don't do it, pathways will, at minimum, give the exit-then-enter
transfer, which provides an upper bound on accessible transfer time. In
practice, if an exit-then-enter transfer is available, and an
internal-only transfer of unknown accessibility is available, it is
unlikely that the internal-only transfer is unaccessible. We are,
however, unlikely to implement this bit.

As for multiple transfer options, as yet there is no rule constraining
the pair of (from_stop_id, to_stop_id) to be unique in transfers.txt.
That means that we could add a wheelchair_accessible to transfers.txt
without breaking existing applications. OTP could also support this
quickly if there were both a concrete proposal and test data.

[KevinChicago]

It may seem to be getting complicated, but I do think this is
progressing fairly well. I like where Arno took this; particularly in
trying to demarcate the differences between pathways and transfers.
Ironically, however, as it has progressed it seems that the two tables
also start to look and act very similar to each other as well. It's
making me wonder if we should just keep transfers.txt as is, for
backward compatiblity, but instead add all the new functionality we
want into this schema based on pathway.txt. If a provider wants to
use pathway.txt file, they cannot use the transfer.txt file. Or maybe
the pathway.txt always takes precedent over the transfer.txt.

Simply, the pathway.txt file represents all of the required,
recommended or not allowed passenger movements and connections related
to the transit network and services, that are not part of riding a
transit vehicle . So entrances to/from stops and stations are in
pathways.txt, as well as transfers.

The current GTFS describes the transfer.txt file as "Trip planners
normally calculate transfer points based on the relative proximity of
stops in each route. For potentially ambiguous stop pairs, or
transfers where you want to specify a particular choice, use
transfers.txt to define additional rules for making connections
between routes." Chnage the last words "between routes" to "to
stops and between stops" and I think it's getting closer to a
defintion of pathways.txt.

I hope that's not too much of a curve to everyone?

Lastly:

>> [[ NOTE: For now, I consider wheelchair_accessible an attribute that
>> marks a routing result as accessible or not, not as an additional
>> criterion in searching routes, because it would sidetrack us into the
>> question of how to support multiple specified transfers for accessible
>> and non-accessible (but faster) paths. ]]
>
>I applaud your effort to keep the discussion focused, but if we tackle
>accessibility at all, I'm not sure we can avoid this discussion. I
>believe that the OpenTripPlanner folks are very keen on supporting

>accessibility......

I hope Google's "keen" on it too! :)

I think to avoid multiple rows, the pathways.txt file could have a
wheelchair_accessible field AND a wheelchair_traversal_time field.
That supports route engines that utilize the presumably longer
travel times via a wheelchair they can, but we don't have to repeat
rows in the file.

Kevin

[Arno Eigenwillig]

Kevin, let me add to Joe's response; this looks like a great example
to learn from.

On 16 February 2010 20:09, Joe Hughes <joe.hug...@gmail.com> wrote:
> Is it possible to post snippets of the relevant data tables for this
> example, to put things in the most concrete terms?

...and could you also describe how the best route in the station is
presented to the user? Does your route planner actually explain "take
the escalator to the mezzanine, then leave through the Linsmore
entrance and walk to the bus bay"? Or does it just use the
information to compute a transfer duration for internal use, without
messaging to the user?

[Arno Eigenwillig]

On 16 February 2010 20:08, Joe Hughes <joe.hug...@gmail.com> wrote:
> On Feb 15, 9:00 am, Arno Eigenwillig <arnoegw.c...@gmail.com> wrote:
>> If an entrance has a short code that can be displayed non-redundantly
>> in *addition* to its name, it can be specified in column stop_code
>> (optional).
>
> Upon further reflection, this blurring of semantics makes me a little
> uncomfortable.  Specifically: stop_code is intended to be something
> that the user can input into some other system (i.e. realtime dial-up
> UI).  If we're going to use this value for entrances, its semantics
> should be very similar so that we don't end up with two different
> types of values in the same field.

Agreed, so we're back at "stop_code is ignored and should be empty if
location_type is 2 (entrance)". That's fine with me.

>> [[ NOTE: It is stations (not stops) that are advertised as the logical
>> nodes of a transit network at large, and here I want to capture the
>> static, high-level relation of entrances to stations, even if the
>> don't actually connect to all stops. ]]
>
> Since stations are a relatively new addition to the spec, it's often
> true in practice that many clients would be advertising GTFS "stops"
> as the logical nodes of a transit network.  I agree that going
> forward, stations are more desirable to use, but the distinction is
> important.

That's a valid point. However, the connection between entrances and
stops will most often be many-to-many, and that needs a table to
represent it (like pathways.txt). A "stop-centric" trip planner will
have to look at that; a single "parent" (of any type) will be
insufficient for it. A station, on the other hand, will often be
unique for an entrance, so I think it makes sense to have a single
field per entrance, parent_station, in which feed producers can easily
declare and feed consumers can easily learn this high-level
connection.

>> pathways.txt (now restricted to walking *inside* a station only;good

>> should it be renamed?)
>
> I guess this begs the question of what you mean by "inside"; not all
> stations will be covered/underground.

You are right; this needs a better term. But you understand what I
mean, right? I want to limit pathways.txt to the short pieces of
walking between entrances and the stops they belong to. I want to cut
out the freedom from your original proposal to specify pathways from
one stop/station through the streets to another stop/station. For
that, I only want the existing possibility to specify a
min_transfer_time and otherwise leave it to a general-purpose "walking
module" in a GTFS consumer (in the simplest case, just drawing a
straight line).

>> For each triple of stop, entrance and direction (can_enter /
>> can_exit), only one pathway may be specified, including the
>> specifications obtained by expanding stations into all their stops.
>
> This may be reasonable for the initial iteration of this proposal, if
> we exclude accessibility info.  We should also make sure that this
> restriction could be dropped in the future, if we wanted to add time-
> dependent paths (such as in NYC, where some entrances become exit-only
> at night).

OK, let's think through how we can restrict pathways (the links
between entrances and stops) by accessibility and by time (a
time-of-day interval and a service_id).

Looking at pathways.txt alone, it seems pretty clear: We allow
multiple pathways for the same stop-entrance pair and introduce
additional columns to express the restrictions. We retain the rule
that if a stop has any connection to an entrance (at any time, with
any accessibility status), it loses the "default access" from the
streets at its own lat/lng. Feed producers must make sure they
provide all entrances at all times. Feed consumers are left with the
optimization task of finding the best entrance for a given time and
accessibility need.

As an aside, one question comes to my mind: We are talking about
adding restrictions (more columns) in the future that are not part of
the proposal we are formulating now, and this process may iterate to
even more restrictions (even more columns) after that. Do we want to
add a rule how a feed consumer can disambiguate between two rows that
have equal restrictions in the columns it knows but differ in columns
from a later spec version? We could add a row_priority column and
say: all known restrictions being equal, take the one with the lowest
(or highest) number there. This way, feed providers can guide older
feed consumers towards using the "safest guess".

The tricky thing I see is the interaction between pathways.txt and
transfers.txt. I believe we must enable feed providers to specify in
a transfer between stations with entrances which entrance, if any, is
to be used on either side. (Letting the feed consumer choose will
often yield inferior results.) The from_ and to_stop_entrance columns
I mentioned achieve this. But now entrances, and therefore also
transfers, inherit accessibility and time restrictions from pathways.
So we need to allow multiple rows in transfers.txt for the same pair
of from_ and to_stop_id, and feed consumers will have to choose among
them according to the accessibility need and time for using the
transfer. Once we are there, it's just natural to allow transfers
themselves to be restricted by accessibility need and time, so we
would add respective columns to transfers.txt as well.

What does this bring upon us?
- If a transfer specifies time and accessibility restrictions, they
must not be more permissive than those of each entrance is has.
- If, among all transfers for a pair of stops, two or more are
permissible (in terms of accessibility and time) for use in one
journey, which one applies? How are different transfer types and
possibly a min_transfer_time weighted against each other?
- If there are transfers specified for a pair of stops but none if
them is permissible (in terms of accessibility and time) for use in
one journey, is this presumable oversight on the side ofthe feed
producer a violation of the spec, or is the feed consumer expected to
fall back happily to the behaviour as if no transfer was specified?

I'm not shy to propose answers, but already the questions make me
wonder if we have left the range of keeping things reasonably simple
for GTFS.

Looking for a flash of inspiration that makes it all easy again,
Arno

[Arno Eigenwillig]

On 16 February 2010 22:35, KevinChicago <koma...@transitchicago.com> wrote:
> It may seem to be getting complicated, but I do think this is
> progressing fairly well.  I like where Arno took this; particularly in
> trying to demarcate the differences between pathways and transfers.
> Ironically, however, as it has progressed it seems that the two tables
> also start to look and act very similar to each other as well.

Thanks for the kind words, but I'm afraid I have to disagree.

A main difference between pathways.txt as I see it and transfers.txt
is that the latter sits "one level above" and can have entrances (or
pathways, doesn't matter) as attributes on the transfer. To do that,
it has four columns (from_stop_id, from_stop_entrance,
to_stop_entrance, to_stop_id), and if you want to put both stop-stop
transfers and stop-entrance connections under the same umbrella, you
end up with those different types of half-filled rows (stop, entrance,
- , - ) that Joe rightly criticized in what I wrote on the 12th.

Also, its transfer_type values do not make too much sense for
connections between entrances and stops; likewise the restriction by
route_id that some feeds use as a private extension.

> It's
> making me wonder if we should just keep transfers.txt as is, for
> backward compatiblity, but instead add all the new functionality we
> want into this schema based on pathway.txt.  If a provider wants to
> use pathway.txt file, they cannot use the transfer.txt file.  Or maybe
> the pathway.txt always takes precedent over the transfer.txt.

I'm curious about Joe's opinion. ;-) It seems a bit like versioning;
something that GTFS has successfully avoided so far.

Arno

[J. R. Westmoreland]

I'm only interjecting a couple of high level concerns here.
These are big picture items from a spec and programming concern.
Therefore, I am keeping the initial part of the thread and dragging off a
new thread to consider versioning and backward compatibility.
As I understand things, this is supposed to be a living document and as part
of life you sometimes have to consider BIG changed. :) Is this maybe the
time, in light of the pathways proposal, to consider this kind of a
modification?

1. Is versioning such a bad thing? I'm not convinced that it is. In fact, as
things move forward we will eventually run into issues that will so
complicate the spec that we are better off to have a new version of the spec
than try to continue adding and backward patching things.

2. In terms of backward compatibility, This is a good thing but should not
hamstring the process such that we make bad decisions in the name of
backward compatibility.

Having expressed the two above issues, I find myself wondering if we
shouldn't consider a revision of the spec in light of new items and
proposals. I don't say this lightly because it has ramifications on the code
I have already written and the code others have produced as well.

Sometimes we have to consider breaking the mold so we can simplify the
overall result.
Personally, I would rather see backward compatibility sacrificed than over
complicating the files and their layout. I would be willing to live with
versioning to accomplish this goal.
In a previous life, and a galaxy far far away LOL, I worked on an error
handling specification for a real-time metering system. We had to go through
three versions of the spec, and implementation, before we completely got it
right. It was something we didn't take lightly because it required many
man-hours to make it happen. But, in the end, we wound up with a far
superior specification and implementation than we would have if we had just
added on the original spec.

Doing something like the pathways part seems to fit in the realm of a
watershed issue. It appears to add so much new stuff, and take us toward a
need to have or interface with a mapping engine that I find myself asking
the above questions.
I'm not shooting down the idea, it would benefit the things that Sendero
Group is trying to accomplish, making a better way to communicate travel
information to the non-sighted community.

Regards,
J. R.

--------------------
J. R. Westmoreland
Custom Computers & Consulting
E-mail: j...@jrw.org
Twitter: GeneralJR
Skype: j.r.westmoreland

Phone: (801) 201-2439

-----Original Message-----
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]

On Behalf Of Arno Eigenwillig
Sent: Thursday, February 18, 2010 10:50 AM
To: gtfs-c...@googlegroups.com
Subject: Re: [gtfs-changes] Re: Proposal: Provide a way to indicate
entrances and pedestrian pathways

Arno

--

[Joe Hughes]

Hi J.R.,

Thanks for bringing this up; it's an interesting discussion.

I agree that there are cases in which it might be possible to improve
and/or simplify some things in GTFS by breaking backwards-
compatibility.

However, a primary goal of GTFS is to improve the number and quality
of transit applications that are available to riders by creating a
format that's supported by as many data providers and consuming apps
as possible. Any backwards-incompatible change effectively fragments
the community, and leads towards a situation where resource-
constrained transit agencies would need to re-do data export work in
order to "keep up". Because of the costs that this could incur among
the existing GTFS user base, it's been my personal opinion that any
backwards-incompatible "cleanups" would do more harm than good at this
point.

That said, so far this community has managed to add and improve
functionality in the spec without implicitly breaking the hundreds of
feeds that are already out there, and I'm hopeful that we'll be able
to do this for quite some time going forward.

Joe Hughes
Google

[KevinChicago]

I guess I'm envisioning that pathways.txt becomes simply a description
and feature (and restrictions) of a connection between two nodes in
the network. So a providor may have the following combos....
entrance - stop
stop - entrance
entrance - parent station (to govern all the stops in the station,
to simplify, if so desired).
parent station - entrance (ditto).
stop - stop (what we call a transfer today)
entrance - entrance (to describe a recommended transfer that
requires exiting and re-entering the system).

It seems very elegant and simple to me.

The only transfer.txt element lost in my mind are the transfer_types
that are about the nature of the transfer: timed etc.

Kevin

> > For more options, visit this group athttp://groups.google.com/group/gtfs-changes?hl=en.- Hide quoted text -

[J. R. Westmoreland]

Kevin,

I think I understand what you are saying.
My concern is that the spec not eliminate data that is most valuable to a
segment of the population that relies on, or could rely on, this data to aid
them in navigating independently and safely in the system.
Currently, it seems that all the data that describes movement in the system
is just lines dropped on a map. This is all Graphic and therefore useless to
those without sight. I can understand this problem from a very personal
perspective. In places where the provider generates these graphics there is
nothing that can help someone who can't see their pretty picture. This may
not be a simple nut to crack but might be worth the effort as part of the
specification.

You seem to have given a good part of this some thought and therefore could
possibly shed some good ideas here.

I've not seen hundreds of agencies jumping on this issue yet so making some
hard changes here might not be as difficult as it will be in the future when
the number of agencies has increased by a factor of 5 or more.

GPS can guide a blind user from stop to stop if they are outside. If, on the
other hand, they are inside one of these large stations, they many times
have nothing to really guide them but a sighted assistant.
Even a semi-closed station can render the GPS assist not valid because of
the radio opaque nature of the roof over head.

Ideas? Is this something the agencies have thought about and I have missed
in my reading and implementation of the spec?

If you'd like to contact me off list please feel free to do so.

Thanks,
J. R.

--------------------
J. R. Westmoreland
Custom Computers & Consulting
E-mail: j...@jrw.org
Twitter: GeneralJR
Skype: j.r.westmoreland

[Louis St-Amour]

Hey, this reply on in-station accessibility really made me pause--
Some thoughts:

1. You could use RF frequency mapping or Microsoft PhotoSynth-style
photo mapping or edge and clear path/feature detection or some
combination of the above to assist both people who are visually-
impaired or merely directionally challenged.

2. Anything like the above would require detailed mapping possibly
outside the scope of GTFS as currently implemented.

3. However, if one can also use something like Nike+, perhaps
distances could be calculated, and with a compass, perhaps direction
also.

My fear lies in the unexpected or malfunction--E.g. Construction,
unknown obsticles. But then, for those who can perhaps see enough to
navigate or again, are merely lost, any kind of mapping assistance is
better than nothing. At this point I'd rather hear directions than see
them, however-- GPS unit style but for pedestrians.

Louis.

P.S. While theoretically possible with an iPhone, many of the
futuristic bits of the above can't appear in the App Store due to how
restrictive Apple is. But it might be happen on other devices or in
future.

Sent from my iPhone

[KevinChicago]

I have posted a set of test data at the following location.
http://www.transitchicago.com/downloads/sch_data/tdev/testdev.zip

In it contains the following sets of data and/or additions to the
current spec. It is based on the basic set-up Joe proposed, with some
alterations, pretty much to the pathways.txt proposal. It is also
based on the assumption that some feed providers may choose to use
the pathways.txt file to code transfers, instead of the transfers.txt
file. Transfers.txt file would remain for timed transfers and
backward compatibility.

The data are of the following:

stops.txt
in the stops.txt file, I have added rail station entrance/exits as a
location_type = 2. All the same required and optional fields apply.
The parent_station field can be populated with stop_ids that are
either stops or stations. When the parent_station is populated, then
the providor is opting for a very simple usage of the entrance, namely
that the stop or station can only be accessed from outside the
transit network via this entrance or another entrance that also shares
the same stop or station. but that traversal_time will be determined
by the trip planner. Connection, in this case, is considered to be
two-way. By using the parent_station, the feed provider is opting to
not use the pathways.txt file for this entrance.

pathways.txt
to be used to describe the connectivity among station, stops and
entrances. Each pathway is one-directional, meaning it describes the
pathway from a location to another, but not the other direction. The
other direction, if available, has to be
coded as a separate pathway. Characteristics are traversal time,
customer directions and wheelchair accessibility.. Pathways can be
used to describe entrances-to-stops, entrances-to-stations, and even
entrances-to-entrances. But if a data provider does not have a need
to code for entrances, they can still use the pathways.txt file to
describe connectivity for stops-to-stops, stop-to-stations and
stations-to-stations.

-- pathway_id (required): unique ID
-- from_stop_id (required): station, stop or entrance of the
beginning of the pathway
-- to_stop_id (required): station, stop or entrance of the ending of
the pathway
-- traversal_time (required): time in seconds it takes to traverse the
pathway. if the value is null then this pathway cannot be accessed at
all. Feed providers may choose to use the null value to restrict a
connection, instead of using the transfers.txt.
-- wheelchair_traversal_time (required): time in seconds it takes to
traverse the pathway in a wheelchair. If the value is null, then the
pathway is not traversable in a wheelchair
-- path_desc (optional): Instructions as to how to traverse the
pathway.
-- wheelchair_path_desc (optional): Instructions as to how to
traverse the pathway in a wheelchair.

Kevin

[StuartJReynolds]

I would like to offer a revised proposal. In it's execution, it looks a lot like Kevin Branigan's proposal, but with added bits.

The problem with what has been proposed so far is that it takes no account of how you get between levels - something that is absolutely critical. If you are going to be transferring from, say, a subway platform and you need to use a wheelchair, you must know that you have got an elevator - and that it is generally slower than an escalator, because you might have to call it first. Equally, if you can't use stairs you will want an escalator or elevator. For that reason, I had been working up something very like Kevin B's, and as it also happened to be for Toronto it was very interesting to see his views. But I found that I needed to extend it. A short walk around Union Station in Toronto demonstrated that many entrances are themselves not accessible. Some are, with ramps or level access, but some have steps. So it is essential to understand that part of the geometry as well.

So here is my proposal. 

The concept here is one of "spaces", and a space can either be a transit space (somewhere that a vehicle arrives or departs), or it can be a transfer space - one that exists only to move you between places. Stops are attached to transit spaces, and transfer spaces link the different transit spaces, and the entrances which are now coded as a special type of space. There are two new files, spaces.txt and space_transfers.txt, and an extension to stops.txt

spaces.txt:

     - space_id                   required, the ID of the space

     - space_name              optional, an understandable name that you can give the space e.g. "Mezzanine"

     - level                          required, -N...0...+N, denoting where in the station hierarchy this space sits

     - type                          required, 1=transit space, 2=transfer space

     - doorway                    optional, denoting whether this is an entrance or not, and if so what type of entrance, 0 or missing=no door, 1=non-accessible doorway (steps), 2=accessible doorway (level access)

     - doorway_dir               optional, 0 or missing=entrance and exit, 1=entrance only, 2=exit only

space_transfers.txt:

     - space_txfr_id             required, the ID of the transfer

     - type                          required, the type of transfer, 0=level transfer, 1=stairs, 2=escalator, 3=elevator, 4=ramp

     - type_ext                    optional, extension data depending on type. Type=1 (stairs), type_ext=number of stairs. Type=4 (ramp), type_ext=percentage slope e.g. 10

     - duration                     required, time to transfer (one time for all users - according to people I have worked with, wheelchairs aren't necessarily slower than non-wheelchair users)

     - from_space                required, the ID of the space the transfer is from

     - to_space                   required, the ID of the space the transfer is to

     - transfer_desc            optional, a description of the route to be taken

stops.txt extension

     - space_id                   optional, mapping transit stops onto transit spaces

I did also consider the piece about date and time availability for spaces, but haven't made a formal proposal for that here. I think that it would be best handled in a separate file, because then you can specify a range of dates/day types/times for spaces without having to replicate the space every time that you want to make a new date & time range - it's both inefficient, and confusing to do that.

To see how this works in practice, consider Kevin's Greenwood Station example. It would perhaps look like this:

spaces.txt

     space_id,space_name,level,type,doorway,doorway_dir

     Entr,Greenwood Station Linsmore Entrance,0,1,2,0

     BusBay,Greenwood Station Bus Bay,0,2

     Mezz,Greenwood Station Mezzanine,-1,1

     WB,Greenwood Station Westbound Platform,-2,2

     EB, Greenwood Station Eastbound Platform,-2,2

space_transfers.txt

     space_txfr_id,type,type_ext,duration,from_space,to_space,transfer_desc

     WayIn,0,0,Entr,BusBay

     WayOut,0,0,BusBay,Entr

     StrsDn2Mezz,1,32,2,BusBay,Mezz

     StrsUp2BusBay,1,32,2,BusBay,Mezz

     StrsDn2WB,1,32,2,Mezz,WB

     StrsWBUp2Mezz,1,32,2,WB,Mezz,"Turn right on exiting subway car and proceed to end of platform"

     EscDn2WB,2,,1,Mezz,WB

     EscWBUp2Mezz,2,,1,WB,Mezz,"Turn right on exiting subway car and proceed to end of platform"

     StrsDn2EB,1,32,2,Mezz,EB

     StrsEBUp2Mezz,1,32,2,EB,Mezz,"Turn left on exiting subway car and proceed to end of platform"

     EscDn2EB,2,,1,Mezz,EB

     EscEBUp2Mezz,2,,1,EB,Mezz,"Turn left on exiting subway car and proceed to end of platform"

stops.txt:

     stop_id,..........,space_id

     GwdBus,........,BusBay

     SubwyE,........,EB

     SubwyW,.......,WB

Regards,

Stuart

[StuartJReynolds]

...and to round it off, here is a proposal for date & time validities of the pathways or spaces. Very similar to calendar.txt in construction, but with added times:

space_transfer_dates.txt:

     - space_txfr_id                required, the ID of the space transfer

     - monday                        required, binary 1 or 0 for validity between the dates given, or if no dates given then on all dates

     - tuesday

     - wednesday

     - thursday

     - friday

     - saturday

     - sunday

     - start_time                    optional, the (inclusive) time from which this transfer is valid on the days/dates sepcified, HHMM (0000 to 2359). If omitted, validity applies to all times, and end_time to be omitted as well

     - end_time                     optional, the (inclusive) time from which this transfer is valid on the days/dates sepcified, HHMM (0000 to 2359). If omitted, validity applies to all times, and start_time to be omitted as well

     - start_date                    optional, the (inclusive) date from which this transfer is valid, YYYYMMDD. If omitted, validity applies to all dates, and end_date to be omitted as well

     - end_date                     optional, the (inclusive) date until which this transfer is valid, YYYYMMDD. If omitted, validity applies to all dates, and start_date to be omitted as well

Each entry only allows one time range and one date range. If there are different times on different days or different dates (e.g. public holidays or special events), then separate entries will be required.