Station and stop amenities

[jfabi]

Describe the problem

Public transport stops and stations are often defined and identified by riders via recurring elements such as signage, seating, enclosed shelters, etc, depending on area and system. Many transit authorities list the presence of station (or even stop) facilities—such as restrooms, seating, lighting, and fare machines—on their websites and other publications. For agencies who base their schedule and stop data around GTFS, there exists no interagency standard with which they can distribute station features for use by third-party consumer applications, or for analytical comparison between agencies.

Use cases considered

• Make it easier for agencies to display official information about the presence of different types of stop, station, and dock facilities, on their websites, maps, or other rider-facing outlets.
  • Examples of agencies who surface these details on station-specific webpages include TriMet, WMATA, the MBTA, BART, the TTC, West Midlands Metro, and Transport for New South Wales.
  • Examples of agencies who surface certain facility types on system maps include LA Metro, San Diego MTS, Transport for London, Transport for Greater Manchester, ATAC Roma, and Transperth.
• Make it easier for agencies, of all sizes and technical abilities, to catalog simpler types of station/stop amenities.
• Data collection and crowdsourcing of stop and station amenities, whether conducted by agencies or third parties, would have a standardized format in which the data can be shared for validation and/or inclusion in public-facing feeds.
• In the United States, federal transit antidiscrimination guidelines (related to Title VI of the Civil Rights Act) require that agencies conduct and submit regular analyses on the geographic distribution of amenities including, but not limited to, seating, shelters/canopies, print/digital information, and waste receptacles.

Example: The Toronto Transit Commission website highlights facility-like information for each station.

Example: The Los Angeles Metro website includes a system map highlighting the locations of station restrooms.

Proposed solution

Together with @cal-itp (@evansiroky), @LACMTA (@matikin9), @mbta, and @TransitApp, we propose the addition of an optional stop_amenities.txt file to GTFS to denote the presence or absence of an amenity type at a station or stop.

stop_amenities.txt (New optional file) Primary key (stop_id, amenity_type)

Field name	Type	Presence	Description
stop_id	Foreign ID referencing stops.stop_id	Required	Specifies the stop_id with which the amenity is encompassed or otherwise associated. Common field with stops.txt. If this field refers to a station (location_type = 1), the amenity is associated with all its child stops.
amenity_type	Enum	Required	Specifies the direct type of an amenity, answering the question, "What is this amenity?" Current valid values are: elevators escalators elevated-subplatform (also known as a "mini-high") fully-elevated-platform lighting portable-boarding-bridges portable-boarding-lifts portable-boarding-ramps ramps restrooms seating shelter car-parking-areas car-parking-areas-lot car-parking-areas-garage car-pickup-dropoff taxi-stands bike-parking bike-parking-racks bike-parking-cages bike-parking-lockers luggage-storage-services luggage-storage-lockers fare-collection-validators fare-vending-machines ticket-windows customer-assistance-staff customer-assistance-phones paper-schedule-distribution static-information-displays digital-information-displays climate-control-cooling climate-control-heating payphones water-fountains waste-containers Note: This is a sample list of amenities that we expect further discussion on, including potential definitions. We especially welcome input from regions not covered by the initial authors.
amenity_status	Enum	Required	Identifies whether the specified type of amenity is present. Can be used, for instance, to definitively note that a particular feature is not present at a stop. The field can have the following values: 0 (or empty): indicates that there is no information available on the presence of the amenity at the stop 1: indicates that the amenity is present at the stop 2: indicates that the amenity is neither present at the stop nor clearly visible within close proximity of the stop 3: indicates that the amenity is clearly visible within close proximity of the stop but is not part of the stop itself

Use cases not considered

This Issue intentionally focuses on the simpler use case of ascertaining whether some type of amenity exists at a given station or stop. Once this use case is formally incorporated into GTFS, we will then consider expanding the specification further around other, potential use cases:

• Specifying the quantity, precise locations, fees, and other properties of station/stop features.
• Journey-planning routers and navigation apps routing people through certain types of features, such as restrooms or ticket machines, at appropriate points along their journey. This could include integration with GTFS-pathways data.
• Alerting or otherwise representing real-time changes to features.

These added use cases (including linkages with Alerts or other parts of the GTFS specifications) would be better in scope for a separate proposal.

An addendum document (bit.ly/gtfs-amenities) contains several sketches for a potential, future addition of either a facilities.txt file (inspired by the current MBTA-specific extension) or new location_type values to stops.txt. These additions are not mutually exclusive with stop_amenities.txt; the concepts may also be considered sooner, in parallel proposals, if desired by the community.

Additional information

Similar proposals and implementations:

• TriMet and Metro Transit (Madison, Wisconsin) currently publish a simple stop_features.txt extension that pairs a stop with one or more enumerated stop_feature values. TriMet designed this extension in 2007; see also subsequent discussion among the GTFS community.
• York Region Transit maintains an internal database of stop amenities and has expressed interest to Transit about how to get it into trip planners.
• 2023 proposal for denoting bike parking properties within stops.txt: issues/349. An approach extending stops.txt to allow for many amenity types, each with its own field, may significantly enlarge one of the core GTFS files. Metro Transit (Minnesota) has a similar proposal for supplemental fields in stops.txt to support its website.
• An alternative approach may be to rely on OpenStreetMap to model any relevant station or stop amenities in detail. While extensible to any number of amenity and facility types, and benefiting from community input, the approach may simultaneously dilute from the authenticity of agency-provided data as compared to the information already in GTFS (such as shapes, stop locations, and station entrances). Additionally, several GTFS consumers have expressed previous concerns about the ability to license and use OpenStreetMap data in their applications.

We look forward to hearing any feedback about this proposal or the general concepts for GTFS, either directly here or in the addendum document (bit.ly/gtfs-amenities).

[skinkie]

Can we have precise location (or better: surface) as optional included? This proposal feels as stop attributes, while it could be easily extended with map capabilities.

[stevenmwhite]

We at GMV would be in support of this proposal. It is clear and simple, which serves the needs of our agency customers well.

As for the potential amenities, should "digital" information be assumed to include real-time info? We may need a specific item for that.

I might also suggest flipping some of the names so the like items sort together alphabetically (even though you've already presented them together). For example:

information-displays-static (perhaps "printed" to generalize it and avoid assumptions that it is static [as in GTFS-Schedule] info?)
information-displays-digital
information-displays-realtime

[felixguendling]

Like for pathways, OpenStreetMap solved this problem already on a higher level of detail (e.g. with precise location, indoor modeling, opening hours, accessibility of each amenity, etc.) and way better coverage than GTFS will probably ever achieve. Most transit agencies are incapable to keep track of those details anyway (at least not consistently over a long time horizon) - so why not collaborate with the OSM community and crowd-source this information? In OSM I can even navigate to the rest-rooms/taxi-stands/etc., from any place - not just defined points like with GTFS path ways! Even if you would connect it to GTFS pathways (and add opening hours, accessibility information, etc.), you're just copying OSM and I don't see value in doing so. Open standards and open data become stronger if you connect them (i.e. "linked open data"; for example putting your stable stop_id as ref in OSM) instead of building competing solutions for already solved problems.

[leonardehrenfried]

While I am a very big fan of OSM and would like to see the information in there, I recognise that the types of websites you show are very common all over the world. The detailed station maps with micromapped locations are not so common (though they are of course highly desirable), as the level of mapping expertise to create them is rare.

For this reason I think there is room for this type of data in GTFS.

I agree with Stefan's point about coordinates.