Stations: modeling facilities

[Developer at MBTA]

We're planning to add a model of "facilities" to our GTFS file. A "facility" is an object or collection of objects at a fixed location that facilitates travel on the transit service by providing access to and from other modes, providing information, collecting fares, providing shelter from the elements, etc. 

Some of the "facilities" we plan to model include parking lots, bike racks, taxi stands, elevators, portable wheelchair lifts, places where fare media is available, etc. Other examples include fare vending machines or gates, a bench or bus shelter, a place where paper schedules are available, wi-fi, etc. 

The MBTA has several goals in adding facilities to its GTFS data: 

1. Publish information such as what stations have bike racks or parking and where fare media is available

2. Have data to reference when publishing information about changes to facilities (i.e. letting customers sign up for alerts about a station's elevators)

3. [future] Provide a basis for the agency to model changes to other fields -- i.e. changing the wheelchair_boarding value of a platform when the elevator serving it is out of service (functionality supported by, but not built into, this proposal)

4. [future] Provide a means for customers to report problems -- i.e. represent each fare vending machine in data so that customers can report a failure over an API 

Our proposal and a link to a sample can be found here: 

https://docs.google.com/document/d/17M0mso9NTQ2da7zsHnDxpUlrs4jMbFQE0fhOw5Q1ufY/edit?usp=sharing

(Scroll down to "facilities.txt;" this document contains some other proposed changes which we're covering in a separate post)

Some of the open questions we have right now are:

1. Should facility "tags" be presented in one space-separated list, or in their own file so each facility-tag relationship gets a row? 
   
2. What breakdown of facility_types would be most useful? 
   
3. Is there a value in having a “parent facility” following the parent stop model? 

Do people have feedback or input on the above questions?

Thanks, 

developer@mbta

[Patrick Greenwell]

Wow this looks like a great addition to the information feed and will hopefully allow for even better informational displays for people utilizing apps as well as which platform and station to proceed to!

In regards to the open questions:

1. I would like to see tags in their own file as the variability of tag lengths could potentially make it harder to arrive on a standard length for a tags field in whatever data store you'd use for your app or website as the number of tags could be quite lengthy.  Not to mention you'd want to extract these tags into some sort of list anyways for processing and putting them in separate file allows them to be in that format already. It also allows you to only include facilities and tag them later. A separate file also allows for the addition of extra fields to tags themselves in the future like if your tags needed a specifier.  e.g. static-information-display might have a map version tied to it but is a part of a platform facility, or a platform might have a platform-length tag with a value in feet as well as a platform-length-units specified as ft.

2. On facility types I'd say the current breakdown seems pretty good, I might suggest a couple, Retail (for a name or listing of the retail operations in a station), and Restrooms, also in private mode share please include which stations have a bike share facility.

3. I think having a parent facility is a good idea as you'll be able to group all the non-fare controlled areas into one "facility" and the fare-controlled facilities into their own as well. A descriptive tag for fare-controlled area might be good to have too (unless that's what the is-requires-fare-media tag is for, but I think having the fare control info on the facility itself, much like the accessibility info helps)

In regards to tag naming I've got a few questions as to why we've got to put is- in front of everything for the descriptive tags. Using is-requires,is-dispensenses, is-accepts, "is-" is clunky and redundant for tagging purposes. Using a specific verb at the beginning like, requires-, dispenses-, accepts-, is- ,provides a more clear understanding to people who will utilize the tags.  I also feel like you should continue with your the building pattern for descriptive tags in the same manner as the informational. 

e.g. accepts-payment

 accepts-payment-cash

 accepts-payment-credit-card

 accepts-payment-debit

 accepts-payment-contactless

 accepts-payment-fare-media

 dispenses-fares

 dispenses-fares-passes

 dispenses-fares-single-ride

 dispenses-fares-stored-value

 is-climate-controlled

 is-climate-controlled-heated

 is-climate-controlled-air-conditioned

 requires-payment

 requires-payment-fare-media

 requires-payment-fare-media-contactless

 requires-payment-fare-media-scannable-barcode

etc. 

Using this methodology you could then apply a standard negator to a more specific tag while still applying the collective version of the tag. e.g. accepts-payment & not-accepts-payment-contactless & not-accepts-payment-credit-card-american-express would mean that this facility would accept all payment types under the accepts-payment-* except for contactless and american express credit cards.

Another solution would be to resolve all the informational tags into an is-, has- or defines- style tag so that descriptive and informational tags are easily discernable

eg. 

has-wifi

has-highsubplatform

is-parking-area

has-parking-payment-kiosk

has-parking-payment-cash-box

is-restroom-male

is-restroom-female

is-restroom-genderless

has-baby-changing-station

is-bike-share-station

defines-platform-length

defines-platform-length-unit

defines-ceiling-height

etc

So something like verb-general-specific-more-specific-even-more-specific

Also if you're going to include mini-highs as a tag then you really should include low-level platforms and high level-platforms as tags too.

Thanks,

Patrick Greenwell

[Developer at MBTA]

Thanks for your feedback Patrick! A lot to think about. You make good points about string length being another reason to put tags in their own table. A three-column facility_properties.txt file that lets one both assign tags and flexibly assign different values associated with those tags is very interesting. It would provide great flexibility, but in a way it's also one step further from the normal organizing principles of GTFS, which we'll have to consider. 

Retail and restrooms are both good ideas for additional categories. 

The is- and not- naming convention was intended to avoid having one tag be the opposite of its substring for descriptive tags, given that substrings are synonymous with identification tags (a station with a tag that begins with "parking-area" has parking, regardless of whether that tag is "parking-area-garage" or "parking-area-garage-underground" etc.)  The two ideas aren't actually incompatible, it's just a complication we were hoping to avoid. If the a three-field facility_properties file was added as you suggested, another approach would be setting "requires-payment-fare-media" to true or false. 

Sincerely,

developer@mbta

[Developer at MBTA]

Dear developers,

We would like to inform you of progress made in our GTFS station modeling and facilities effort. An updated specification for facilities and changes to stops.txt can be found at https://docs.google.com/document/d/1UZOIofN_STZnhhqnj2NEkC8x1XqSyfIxSuX3_clpVVQ/edit?usp=sharing, where you can find a link to download updated sample files containing the information for various stations, including an updated transfers.txt.

As you will notice, there are a number of changes we made since considering the previous proposal. These include, but are not limited to, the following:

• Facility description tags have been moved to a separate facilities_properties.txt file. The file facilities.txt is for obtaining basic information on a facility’s name, nearest stop, and type. A facilities_properties_definitions.txt file is also included to define allowed properties and values.
  
• Facilities now have separate facility_type and facility_class fields to better help users show only the desired information to passenger, as well as separate facility_long_name and facility_short_fields. The name field will function much like similar fields in routes.txt for display purposes, providing a verbose name which may include the station name and facility type, as well a a short and concise name.
  
• Addresses can be added to locations by way of the new stop_address field in stops.txt and the address property in facility_properties.txt.
  
• Station entrances which are represented in stops.txt include the name of the entrance in the stop_desc field. The stop_name field for children stops of parent stations, just as in our platforms in stops.txt, will include the name of the parent station. So, for example, Harvard Station may have an entrance/exit at Brattle Square with stop_id “door-harsq-brattle”, stop_name “Harvard”, and stop_desc “Brattle Square”.
  
• Some additional bus-to-subway transfers with estimated travel times are added to transfers.txt based on our internal station surveying efforts. We are currently unable to add subway/rail platform-to-entrance transfers to the file at this time, but may add travel times for these in the future. Note that the proposed changes to transfers.txt from the previous station modeling proposal have already been implemented.
  
• Generic/other facilities are now created for parent stations. The purpose of these auxiliary facilities are to disseminate service alerts concerning facilities which have not been cataloged in GTFS. A user who may sign up for all alerts related to the amenities at a particular station would receive such alerts.

One complicating factor affecting the facilities (and updated transfers) data presented is that other agencies and GTFS users are exploring some of the same ideas. We don’t want to wait an undetermined amount of time until consensus is reached, but we also don’t want to settle on a custom framework for something at the same time that a standard framework is introduced; we are attempting to balance these two priorities.

More facilities and station entrances from additional stops may be added before these new files and formats go into production in the MBTA GTFS file—we will announce on this thread if the sample files linked in the above are updated. We will also update this group in the coming week to announce a production date for facilities and updated stops.txt in production.

As always, we appreciate any questions, comments, or concerns you may have about the latest proposal.

Sincerely,

developer@mbta

[Developer at MBTA]

Dear developers,

Please note that the facilities.txt and facilities_properties.txt files have been updated to show bike storage information at MBTA stations.

Sincerely,

developer@mbta