Stop Amenities
Gill...@trimet.org
I would like to start a discussion about adding stop amenities to the
feed spec. My initial proposal is to include an optional file called
stop_amenities.txt. The file would include 2 fields: stop_id,
amenity_type. amenity_type would be similar to route_type in
routes.txt. Here is a limited list of amenities:
1 - Bench
2 - Shelter
3 - Lighting
4 - Crosswalk
5 - Schedule display
6 - Real time arrival display
7 - Bike storage device
8 - Starbucks :-)
etc...
I can submit a complete list of all amenities tracked by TriMet or it
could grow similar to the route_type enum.
-Mike Gilligan
Software Engineer, TriMet
Joe Hughes
> I would like to start a discussion about adding stop amenities to the
> feed spec. My initial proposal is to include an optional file called
> stop_amenities.txt. The file would include 2 fields: stop_id,
> amenity_type. amenity_type would be similar to route_type in
> routes.txt.
Hi Mike,
This sounds like a reasonable way to represent the amenities, since it
would allow for associating multiple amenities with a single stop.
I'd like to look at some real-world usage to understand how we can
create the most useful thing for agencies and applications that are
using the spec.
1) How is amenity data used in existing transit applications?
It seems like TriMet displays a list of amenity data on stop landing
pages like this one:
http://trimet.org/go/cgi-bin/cstops.pl?action=entry&Loc=9969
Is the "Grab a bite on the way" section on that page driven by the
same amenity data? Does TriMet display amenity data elsewhere on
their site, or in printed information? What other online transit
applications make good use of amenity data today?
2) Which amenities do data publishers tend to have good information
about?
Mike, would you mind making up a sample file of TriMet amenity data in
your proposed format and posting it to the files section of this
group? (I'm interested in all the amenity types you have in your
system.) Same goes for anyone else who's interested in providing stop
amenity information to GTFS applications.
3) Which GTFS-reading applications have a plan & desire to make use of
amenity information?
Frank, is TimeTable Publisher driving the amenity example that I
linked to on the TriMet site, or does it just know about stop landing
page URLs that are generated by another system?
Finally, a side-question that your example brought up: Mike, does
TriMet have more detailed information about the bike-storage amenities
in your service area (racks vs. lockers vs. staffed garage, number of
spaces, geocode, etc.), or is it just yes/no for each stop?
Joe Hughes
Google Transit
T Sobota
1- Bench (free-standing)
2- Shelter (no seating)
3- Shelter with internal seating
also, ADA amenities might be a possibility (i.e. curb ramp, sidewalk,
boarding pad or otherwise or generally an accessible path to the bus
stop location)
-Tim Sobota
Nicholas Albion
assigning the next integer value to the next specific mode of
transport (which could lead to confusion/misinterpretation such as
0=tram, 5=cable car) we could assign large blocks (split on either hex
or decimal boundaries?) to each general mode - rail, road, water etc.
The idea was that all values between (say) 100-200 might describe
various types of rail transport, but the specific definition of 101
might be defined by the agency's feed.
Another proposal within this discussion was the addition of a "locale"
column, so that agencies could provide locale-specific definitions for
each particular mode. eg:
401, 'cross walk', en-US
401, 'pedestrian crossing', en-GB
401, 'les crossing pedestrian', fr-FR (or whatever they call it) etc
The advantage of assigning large blocks of values for more general
groups rather than individual values for specific definitions is that
when new values need to be added, they can be added along side other
similar values. Users and applications would be able to examine/
ignore features/amenities of types which were of particular interest.
Mike Gilligan
stop_amenities.txt
---------------------------
stop_id, amenity_type, amenity_sub_type
Here is a limited list of amenities tracked by TriMet that may be
useful to the public:
amenity_type, amenity_desc
------------------------------------------
1, Bench
2, Bike Storage (sub types: bike locker, bike rack)
3, Crosswalk
4, Crosswalk Signal
5, Elevator
6, Lighting (sub types: exterior lighting, shelter light)
7, Pavement Features (sub types: backdoor landing, curbcut, frontdoor
landing, sidewalk)
8, Real Time Arrival Display
9, Schedule Display
10, Shelter
11, Ticket Machine
I will be adding a stop_amenities.txt file to the "Files" section
sometime in the next few days as an example.
-Mike
Bob Heitzman
within Google Transit(GT). It seems unlikely that GT would use the
data to do transit routing but only to provide information that would
be displayed somehow. If they data is just informational why would GT
codes be defined for each amenity? (I know agencies track this
information but I would guess this has more to do with asset inventory
and maintenance than public notice.)
If amenity codes are to be used perhaps a more flexible system
supporting annotation may be appropriate. Perhaps a two table system
with the agency defining the codes they will be using and the second
table would be the stop_amenities, N records per stop. GT wouldn't
know or care which amenities are available.
Or perhaps a single table with just N records of any detail text the
agency would like displayed for that stop.
Or maybe just use stop_description to display amenities and anything
else you would like the GT user to see per stop.
Any way, the point is, what is GT expected to do with the data?
Mike Gilligan
have faith in the bright minds at Google to find useful ways of
displaying the information or using it for trip planning purposes.
Here is a limited example of how an amenity could be used:
Riders in Portland have to deal with rain. GT could use a weather feed
to determine the current weather in the city you are planning a trip.
If it is raining, GT could then let the customer know, there is a stop
2 blocks further with a shelter because the closest stop does not.
Obviously, different regions will have amenities that are more
important to their riders, but I think a standard amenity code is
important. The list I supplied is not comprehensive but a first
attempt at supplying the data.
Tim Sobota (above) mentioned ADA amenities such as curb ramps,
sidewalk, etc that are essential for persons with limited mobility. GT
could add an "Advanced" search for customers to specify amenities that
their stop should have.
Hope this clarifies my intent,
-Mike
Joe Hughes
Don't forget that Google Transit isn't the only consumer of GTFS
feeds. Other applications have motivated extensions in the past--for
instance, the direction_id field was added to help static schedule
display applications like TimeTablePublisher.
That said, I agree that an extension shouldn't be made part of the
official spec until it has proven its usefulness in a real application
using real agency data. We can always add things to the spec but we
can almost never take them away once they're in.
In any case, stop amenities are important, particularly when it comes
to ADA, so I'm glad that Mike has taken the initiative to write up and
provide test data for a proposal. We'll have to see whether it's
useful for applications and whether it works well for the amenity data
that other agencies and operators have.
Joe Hughes
Google Transit
Mike Gilligan
description of the expected values:
stop_id, amenity_type, amenity_sub_type
1-Bench
2-Bike Storage (Sub Types: 1-Bike Locker, 2-Bike Rack)
3-Crosswalk
4-Crosswalk Signal
5-Elevator
6-Lighting (Sub Types: 1-Exterior Lighting, 2-Shelter Light)
7-Pavement Features (Sub Types: 1-Curbcut, 2-Sidewalk)
8-Real Time Arrival Display
9-Schedule Display
10-Shelter
11-Ticket Vending Machine
Comments and suggestions welcome. I would like to see what Google
could do with this data and amenities from other agencies.
If anyone knows of a standard that could be adopted when supplying the
amenities, it would be greatly appreciated.
-Mike
Nicholas Albion
I've also tried to group them together logically:
"Parking"
"Secure parking"
"Bus transfer"
"Rail transfer"
"Water transfer"
"Air transfer"
"Taxi rank"
"Wheel chair access" (Note: Access can be different for each platform
at the station)
"Wheel chair assistance"
"Help point"
"Accessible toilets"
"Toilets"
"Drinking fountain"
"Major stop" ("Major stops" may be listed in bold in timetables.
Perhaps "Timing point" would be a better name...)
"Shop" (News stand, convenience store etc.)
"Shopping centre"
"Tourist attraction"
"Other attraction"
"Video surveillance"
"Public phone"
"Ticket office"
"External links" External website links exist
"Other" For any other facilities not assigned to a bit field - perhaps
create a 2nd 32 bit field...
My recommendation for columns would be:
stop_id, amenity_type, text, url, locale
This would allow agencies to provide their own descriptions for "bike
storage" etc, eg: "20 bike lockers, $0.50/day or $20 key deposit".
The locales field could also be used to provide translations and to
allow for cultural/spelling differences between en_US and en_EN.
Whether we need an "amenity_sub_type" field in addition to
"amenity_type" and "text" depends on the way passengers would be
likely to submit searches; Would cyclists be likely to say "I'd like
to travel from A to B, but I need a bike locker and have no interest
in bike racks", or is it a purely informational thing as opposed to a
search criteria?
The "url" field would be useful for external links (wikipedia,
agency's site), shopping centres, tourist attractions and possibly
even parking.
When it comes to documenting this extra file(s) it would be helpful to
provide some notes on which amenities might be best related to the
platform "stop" and which to the "station" stop etc.
Perhaps the greatest challenge in modelling transit data is trying to
keep the model simple enough for the sake both agencies and
passengers, while at the same time including all of the information
that various parties may be interested in at some stage. It doesn't
seem that Google Transit are all that intersted in including this
extra amentities information in their application at this point in
time - their focus being on keeping the GTFS as simple and thereby
accessible for smaller agencies. (Even if there are only 6 required
files plus perhaps over a dozen extra optional files, it at first
might seem like an overwhelming spec and therefore frighten off some
smaller agencies).
I appreciate that CSV files are easy to manage by non-technical people
in Excel and even notepad, but my guess would be that most Google
Transit agencies would be exporting from databases programatically
anyway, and it would probably be those agencies who are beyond Excel/
notepad which would be likely to provide extra optional data. If
Google Transit were prepared to accept feeds in an XML representation
of the current GTFS as an alternative to the CSV format, perhaps this
would allow "advaned" agencies to publish additional and more
structured data superimposed onto the XGTFS. If XGTFS was similar
enough to TransXChange/TransModel (or if an XSLT file exsited) you
might even find that "over night" you've got most European cities
listed on GT.
Guillaume
As mentionned in this topic, it would be nice to be able to include bike-sharing systems in GTFS feeds, as this is an important complement of "classic" public transport in many cities around the world.
Nicholas Albion informed me of the "stop_amenities" proposal (thanks again), and indeed this could address a good part of this goal.
Therefore I would like to propose 3 additionnal amenity types, or one type with 3 subtypes :
- standard bikes sharing station
- electric bikes sharing station
- both standard and electric bikes sharing station
(And possibly :
- standard cars sharing station
- electric cars sharing station
- both standard and electric cars sharing station)
The distinction between standard and electric would allow GTFS consumers to represent these stations with different icons on maps.
Then it would be nice to be also able to describe how many bike racks (or car slots) are available at the sharing station.
Therefore my proposal would be :
stop_amenities.txt :
stop_id, amenity_type, (possibly amenity_subtype), parameter1, parameter2
Then we could define what each parameterN should contain, for some of the amenity types.
For instance, for the amenity type "bike sharing station", parameter1 could be the number of standard bikes racks (or standard cars for a car-sharing station), and parameter2 could be the number of electric bikes/cars racks.
What do you think about it?
Guillaume
stop_amenities.txt :
stop_id, amenity_type, (possibly amenity_subtype), parameter1, parameter2, parameter3, parameter4, parameter5
Then we could define what each parameterN should contain, for some of the amenity types.
parameter1 :
- 4 if it's possible to get a bike/car a this station directly (with a credit card), without having previously subscribed to the system
- 3 if, to be able to pick a bike/car, one needs to have previsouly subscribed to the system in an office (or by classic (snail) mail) or on the internet
- 2 if, to be able to pick a bike/car, one needs to have previously subscribed to the system in an office or by classic (snail) mail
- 1 if, to be able to pick a bike/car, one needs to have previously subscribed to the system in an office
parameter2 :
- 2 if no restrictions apply to be able to subscribe to the bike/car sharing system
- 1 if restrictions apply to be able to subscribe to the system (for example to subscribe to the bike sharing system in Barcelona, one needs to live in Spain (and provide a proof of residence))
parameter3 :
- 3 if the bike/car can be returned to a different station with no impact on the fare paid by the user
- 2 if the bike/car sharing system rules state that the bike/car can be returned to a different station, with a possible impact on the fare paid by the user
- 1 if the bike/car sharing system rules state that the bike/car must be returned to the same station where it was picked (I don't know bike sharing systems with this rule, but I know car sharing systems that have this rule)
parameter4 : number of standard bikes "slots" (or standard cars"slots" for a car sharing station)
parameter5 : number of electric bikes "slots" (or electric cars "slots" for a car sharing shation).
Any thoughts?