Proposal: Entrances and Simple Pedestrian/Wheelchair Pathways
Arno Eigenwillig
I would like to reopen the discussion on station entrances that was
started by Joe Hughes on Feb 5th and subsided in March, because there
is a real need for GTFS producers and consumers to exchange this data.
I have compiled a proposal that tries to cover the main points
encountered during the last round of discussion - except multi-step
routing and modeling station interiors. Please see my other posting
why I believe that is best kept separate.
This proposal builds on Kevin O’Malley’s description of the pathway
data, which he posted on March 24th, and incorporates discussions with
David Turner, but includes several new twists. All mistakes and
modeling blunders are mine.
Motivation:
Until now, GTFS has only provided locations for the points (”stops”)
at which a rider boards or alights from a vehicle. However, recent
discussions have shown interest to exchange richer data that includes
information on
(1) the location of entrances/exits, especially for underground and
elevated stations,
(2) pathways inside stations between stops and entrances/exits,
(3) pathways inside stations for transfers, a necessary complement of (2),
(4) pathways for transfers between nearby stations, a small
generalization of (3); and
(5) accessibility of pathways for wheelchair users.
Providing this data helps GTFS-consuming trip planners to achieve a
better quality of results that integrate public transit and with
walking or wheelchair directions.
Scope:
This proposal is about representing entrances and simple end-to-end
connections between stops and entrances, not about modeling a
station’s interior. While the latter information would also be of high
value, feed providers today usually do not have it, and feed consumers
mostly are not ready to process it. However, the proposal aims to
represent entrances in a way that remains upward-compatible to a
possible future replacement of pathways by multi-step walking paths.
This proposal addresses wheelchair accessibility between the outside
world and the stop (i.e., bus stop, platform, etc.) and between stops
during transfers on a par with the respective information on walking.
Wheelchair accessibility while boarding/alighting and inside the
vehicle are the subject of complementary proposals (notably Igor
Kulkin’s proposal on “simple wheelchair accessibility (extended)”
posted 2010-02-26) and therefore not covered here.
Proposal:
stops.txt (existing file)
location_type - A new value “2” is added, denoting a location that is
an entrance and/or exit for a station or stop. For brevity, this type
of location is called “entrance”; this is not meant to exclude its use
to exit the station.
An entrance is a physical structure, like a subway entrance, that
provides access from the streets to stops or vice versa, in a way that
allows to speak of “entering the station” or “taking the exit to leave
the station”. It is very common, but not required, that all stops
connected to an entrance have the same parent_station.
For rows with location_type 2, the other columns of stops.txt are
interpreted as follows. No new columns are added:
stop_id - unchanged: Required. An unique ID for this row (stop,
station or entrance).
stop_code - Optional. Not used for entrances.
stop_name - Required. The name of the entrance, as seen by riders
inside the station, or empty if not available. Use only for names that
are meaningful to riders.
stop_desc - unchanged: Optional. A description of the entrance
(analogous to the use for stops and stations) for display to riders.
stop_lat, stop_lon - unchanged: Required. The geographical position of
the entrance as latitude and longitude (WGS84, in degrees).
zone_id - Optional. Not used for entrances.
stop_url - unchanged: Optional. The URL of a web page about this
particular entrance. This should be different from the stop_url values
of the station and stops this entrance leads to.
parent_station - Optional in general, but required for entrances. The
stop_id of the station to which this entrance is belongs. This
high-level connection helps with painting entrances on maps. It also
provides default pathways according to the rules explained after the
pathways.txt file, but the pathways.txt file can be used to replace
these defaults with explicit pathways.
wheelchair_boarding (not in GTFS yet, part of Igor Kulkin’s proposal
on simple wheelchair accessibility) - unchanged: Optional. Indicates
the wheelchair accessibility of the entrance (0 or empty = unknown, 1
= yes, 2 = no).
[[ NOTE: The usage of this column in this proposal suggests that the
name wheelchair_boarding is too narrow and perhaps should be replaced
by wheelchair_accessible. ]]
pathways.txt (new file) - Optional. This file defines pedestrian
pathways between stops and entrances.
The pathways file is optional. It describes three types of
pedestrian/wheelchair pathways between stops and/or entrances.
Pathways of type 1 connect stops and the entrances that give them
access from/to the streets. A stop referenced by a pathway of type 1
can no longer be accessed directly from the streets (i.e., without
using an entrance), unless a circular pathway from the stop to itself
is given to reinstate direct access. Pathways of type 2 describe
pathways for transfers between stops that are separate from the
streets (e.g., a tunnel between two subway platforms). Pathways of
type 3 provide information about transfers on the streets, for use by
transit trip planners instead of, or in addition to, walking
directions from other sources.
Pathways are directed, that is, the pathway from A to B is distinct
from the pathway from B to A (unless A equals B).Therefore, it is
necessary to specify two separate pathways if a stop can both be
entered and left through an entrance; typically, pathway_desc and
signposted_as will be different for the opposite directions.
Pathways are not composed by route planners: The entrances of a stop
are only those attached directly to it, pathways to another stop and
further on to that stop’s entrance are not considered. Likewise, for
transfers from stop A to stop B, only pathways from A, or an entrance
of A, to B, or an entrance of B, are considered, but no detours via
another location.
from_stop_id, to_stop_id - Required. The stop_id of the source or
target, resp., of this pathway, referenced from file stops.txt. It may
be a stop, station, or entrance. Specifying one station is equivalent
to repeating this row for all stops of the station. Specifying two
different stations is equivalent to repeating this row for all
combinations of a stop from the first and a stop from the second
station. The remaining description assumes this expansion of a station
into stops has already happened. Each pair of (from_stop_id,
to_stop_id) may occur at most once, including the occurrences of stops
expanded from stations.
pathway_type - Required. The type of pathway, encoded as one of the
following numbers.
1: A pathway from an entrance to a stop or from a stop to an entrance,
stating that the entrance gives the stop access from/to the streets.
These can be thought of as pathways inside a station building,
although there is no requirement for source and target to have the
same parent_station.
As a special case, a pathway of type 1 may also connect a stop to
itself to describe its direct access from/to the streets at its own
location. This allows to reinstate direct access from the streets even
if the stop has entrances, or to modify the properties of direct
access (such as wheelchair accessibility).
2: A pathway from a stop to another stop for transfers off the streets.
3: A pathway for a transfer on the streets. It can connect two
different entrances, or an entrance with a stop that has direct access
to the streets, or two different stops that have direct access to the
streets.
traversal_time - Required. A non-negative integer giving the number of
seconds needed to traverse this pathway on foot, or -1 to indicate
that this is not possible.
For a pathway from a stop to itself, this must be -1 (to remove direct
access on foot) or 0 (to allow direct access on foot).
wheelchair_traversal_time - Optional. A non-negative integer giving
the number of seconds needed to traverse this pathway in a wheelchair,
or -1 to indicate that this is not possible, or -2 or empty to
indicate that possibility and traversal time are unknown. It is not
required that the pathway traversed in the wheelchair is physically
the same as on foot, as long as it connects the same source and
target.
For a pathway from a stop to itself, this must be -2 (accessibility is
unknown), -1 (is not accessible) or 0 (is accessible).
pathway_desc, wheelchair_pathway_desc - Optional. Textual instructions
to the rider how to traverse the pathway on foot or in a wheelchair,
resp., or empty if unavailable.
[[ NOTE: Google Transit will ignore these, because they cannot be
translated for an internationalized user interface, but they make a
lot of sense for GTFS consumers with a fixed user interface language
which is also the feed’s language. ]]
signposted_as - Optional. The inscription on signposts along the
pathway, or empty if inapplicable. Leave empty for pathways from a
stop to its entrance if equal to the entrance’s stop_name. This field
helps to generate schematic directions like “follow the signs
<signposted_as>” whose fixed part can be translated and whose variable
part can remain as seen on signposts.
pathway_id - Optional. If this column is present, it must contain a
unique id for each row. These are not referenced from anywhere yet but
developers are advised early on that this column may find future use
for attaching additional information, such as traversal_times varying
by time of day, without violating the uniqueness of (from_stop_id,
to_stop_id).
[[ NOTE: The informational nature of this column definition probably
makes it unsuitable for actual inclusion in the spec. ]]
To simplify feed creation in easy cases, such as subway stations in
which every stop is connected to every entrance, default pathways are
supplied according to the following rules. Default pathways are
interpreted as if given in additional rows of the pathways.txt file.
A default pathway has empty text fields, its wheelchair accessibility
is inferred from the wheelchair_boarding values of its endpoints, and
traversal times are estimated from the locations of endpoints.
A default pathway of type 1 from a stop to an entrance or from an
entrance to a stop is supplied if the two endpoints satisfy the
following conditions:
- The two endpoints have the same parent_station.
- Neither of them is referenced in any row of pathways.txt with pathway_type 1.
Typically, this implies: If you give any pathway between an entrance
and a stop in a station, you need to give all.
A default pathway of type 2 from a stop to another stop is supplied if
the two endpoints satisfy the following conditions:
- The two stops have the same parent_station.
- Both of them have a pathway from or to a common entrance.
- Neither of them is referenced in any row of pathways.txt with
pathway_type 2 or 3.
Typically, this implies: If you give any pathway for transferring
between stops inside a station, you need to give all.
In the rare case that the conditions for a default pathway of type 2
are met but a transfer is actually not possible, you can specify a
pathway with traversal_time and wheelchair_traversal_time set to -1
(impossible) in order to suppress this default pathway (and others,
due to the “not referenced in any row” condition).
No default pathways of type 3 are supplied. Estimations for walking
durations on the streets are applied anyway.
For use in transfers (see below at the transfers.txt file), walking
durations from a stop A to a stop B are calculated as follows:
- If there is a pathway of type 2 or 3 from A to B, this is used. If
the pathway is impossible, i.e., its traversal_time is set to -1, the
transfer is impossible.
- Otherwise, the best connection from A to the streets, through the
streets, and from the streets to B is sought. The connection through
the streets can be a pathway of type 3; or it can be a walking
connection estimated by other means from the locations of endpoints,
unless forbidden by an impossible pathway of type 3.
A wheelchair transfer is calculated likewise, with
wheelchair_traversal_time in place of traversal_time. It is up to the
feed-consuming application how to treat cases of
wheelchair_traversal_time = -2 (unknown accessibility); feed providers
are strongly encouraged to give the actual values to avoid that.
[[ NOTE: As support for wheelchair accessibility becomes more
widespread, one possible behaviour of trip planners is this: Search a
trip both among the accessible and the accessible and unknown routes;
display the second if it is much better, but include a warning, else
display the first. ]]
If there are pathways of type 1 from a stop to an entrance and from
the same entrance to another stop, it is required that there also is a
pathway from the former stop to the latter. (Otherwise, an absurd
routing result -- take the exit and enter again -- would ensue.)
transfers.txt (unchanged, clarification only).
Rephrase the introductory paragraph as follows:
The transfers file is optional. Trip planners normally use the
proximity of stops and/or the walking durations from the pathways file
to calculate possible transfer points between routes and the transfer
time needed (adding buffer time, if appropriate). 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.
Add a sentence to the explanation of min_transfer_time:
The min_transfer_time overrides any transfer time calculated from stop
locations or from traversal times in the pathways file.
[[ NOTE: This resolves the previously disputed relation between
pathways and transfers in a way that is consistent with existing
practice: The transfers file defines rules (”policy”) how transfers
are to be calculated; the pathways file can provide information
(”facts”) that is otherwise estimated from stop locations by the feed
consumer. ]]
Examples:
1) A pair of bus stops on opposite sides of the road:
Two stops, one common parent_station, no entrances, no pathways. Each
stop can be accessed from the streets right at its own location. Its
wheelchair_boarding value applies to access from/to the streets,
boarding/alighting, and transfers.
2) A tram station consisting of a northbound and southbound platform
on the street level; both platforms can be used in a wheelchair for
transferring but the southbound platform is inaccessible form the
streets (say, a ramp to climb the 6’’ curbstone is missing):
Two stops, one common parent station, no entrances, one pathway: The
pathway of type 1 connects the southbound stop to itself with a
traversal_time of 0 and a wheelchair_traversal_time of -1
(impossible). The stops themselves have wheelchair_boarding enabled.
3) A subway station with a westbound and an eastbound underground
platform, a common mezzanine, two entrances from the streets to the
mezzanine, stairs from the mezzanine to each of the platforms, and an
agency that wants to specify entrances but no pathways:
Two stops, two entrances, one common parent_station, no pathways. The
entrances’ wheelchair_boarding is set to 2 (impossible), because the
stairs further down are not wheelchair-accessible. Ten default
pathways (namely 2x2x2=8 of type 1 between each entrance and each stop
in either direction and two of type 2 for transfers between the two
stops) will be supplied automatically by the feed consumer. Notice how
the default pathways to entrances satisfy the “common
entrance”-condition for transfer pathways.
This example assumes that boarding/alighting at the stops is not
possible with a wheelchair, so that wheelchair_boarding disabled. If
it was enabled, the default transfer pathways would erroneously be
wheelchair-accessible, and it would be necessary to explicitly give
them as non-accessible.
4) A subway station as in example 3), combined with one overground bus
bay close to one entrance, and with an additional exit-only escalator
from the westbound platform to a third entrance somewhere else:
Three stops (two subway platforms and one bus stop), three entrances
(two as before, plus the new exit-only escalator), one common
parent_station, and 11 pathways:
One pathway of type 1 from westbound platform to the third entrance
(without a counterpart in the opposite direction), and the eight
pathways of type 1 that were formerly supplied by default, which makes
9. In addition, a pair of pathways of type 3 between the bus stop and
the nearby entrance, totaling 11. The pathways for transfers between
the subway platforms continue to be supplied by default. (Notice how
the relevant conditions are fulfilled only between the two underground
stops.)
5) A subway station with a westbound and an eastbound platform
underground, both wheelchair-accessible, and a tunnel between them
with fare gates that can only be passed when transferring. Each
platform has an elevator and a pair of escalators to a street
entrance:
Two stops, two entrances, one common parent_station, 6 pathways: Each
stop has a pair of pathways of type 1 from and to its entrance that
are wheelchair-accessible. (Note how one pathway covers both the
accessible elevator and the inaccessible escalator.) In addition,
there is a pair of pathways of type 2 for the transfer tunnel (one in
each direction), yielding the total of 6. (Default transfer pathways
do not apply for lack of a common entrance.) Without the pathways for
transfer tunnel, transfers would be by exiting to the street and
entering the other stop.
6) A small commuter rail station with two tracks and a platform on
either side; each platform has direct access from/to the nearby
street; and there is an underpass to get to the other side:
Two stops, two entrances, one common parent_station, and 8 (or 10) pathways:
Each stop has a pathway to itself of type 1 to assert its direct
access from the streets, which makes two. In addition, each stop has
a pair of pathways of type 1 from and to the entrance of the underpass
on the other side, which gives four more. Finally, there is a pair of
pathways of type 1 for transferring between the stops. (Depending on
the precise description wanted, there could instead be two pairs of
pathways of type 2 connecting each stop to the other stop’s entrance.)
Arno Eigenwillig, Google Transit
--
Google Switzerland GmbH
tompw
anotehr enrance would be useful?
John L
Between transit entities, for instance Penn Station in New York services New Jersey Transit, Amtrak, Long Island Rail Road, NYC Subways and NYC Bus.
On Jun 1, 2010 1:40 PM, "tompw" <to...@hotmail.com> wrote:
Would there be any occasion where specifying an path form entrance to
anotehr enrance would be useful?
--
You received this message because you are subscribed to the Google Groups "General Transit Feed...
Roger Slevin
It might be useful where there is a route through a transit terminal that avoids the need to walk around it ... so the route becomes part of the pedestrian network that may not otherwise be mapped
Roger
--
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.
Jakob Eriksson
- Jakob
> --
> 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.
>
Jakob Eriksson
Assistant Professor of Computer Science
University of Illinois at Chicago
phone: 312-77-JAKOB
David Turner
the rest as data becomes available from agencies and as we have time.
So naturally, I'm in favor of this.