Motivation:
Most underground transit stations have multiple entrances that are
significant distances apart. Adding station and entrance information
would make it possible for GTFS-using applications to display station
entrances on map views and incorporate entrance information into
travel instructions.
Proposal:
The stops.txt file would be expanded to refer to more location types.
(You could imagine it as becoming "locations.txt", though we don't
actually want to change the file name for compatibility reasons.) The
following columns would be added:
--------------------------------
location_type (optional):
This identifies the type of location that this entry represents:
0 (or blank) - stop: a location where passengers board or disembark
from a transit vehicle
1 - station: a structure that that's associated one or more stops, and
zero or more entrances
2 - station entrance: a location where riders can enter a station from the
street or public walkway
parent_station (optional):
This identifies the station associated with this item, if applicable:
* For stations, must be empty (stations can't contain other stations).
* For stops, may contain a the stop_id of a station if the stop occurs
within a station structure.
* For entrances, must contain the stop_id of the station that the
entrance provides access to.
--------------------------------
stop_name remains required for all rows in stops.txt, including
stations and entrances, so that directions using those locations will
have a way to refer to them.
zone_id should only be set for stops, and ignored for stations and entrances.
Only stops (rows with location_type 0 or empty) may be referenced in
stop_times.txt.
Example:
stop_id, stop_name, stop_lat, stop_lon, stop_url, location_type, parent_station
1, 24th St. Mission Station, 37.752240, -122.418450, , , 2
2, 24th St. Mission Station, 37.752240, -122.418450,
http://www.bart.gov/stations/stationguide/stationoverview_24st.asp, 1,
3, Southwest Entrance, 37.751942, -122.418812, , 2, 2
4, Northeast Entrance, 37.752477, -122.418096, , 2, 2
Open Questions:
* Should the spec provide guidance on naming stops, entrances, and
stations relative to each other? Specifically, should entrances and
stops that are associated with a station include the name of the
station in their name, or not? This depends on whether we expect
GTFS-using apps to typically display the name of the associated
station (when applicable) when using the names of stops and entrances.
Joe Hughes
Google Transit
One random thought: there exist transit stations so grand that they
use multiple-layered organizational schemes to identify stops: a
transit station with multiple islands, an airport with multiple
concourses, multi-floored maze-like subway stations, or ferry
terminals with multiple docks and disembarkation stations. For that
reason, and to keep spec documentation simple, I recommend that
parent_stop should apply to all stops of any type.
> Open Questions:
> * Should the spec provide guidance on naming stops, entrances, and
> stations relative to each other? Specifically, should entrances and
> stops that are associated with a station include the name of the
> station in their name, or not? This depends on whether we expect
> GTFS-using apps to typically display the name of the associated
> station (when applicable) when using the names of stops and entrances.
How about: if the parent_stop field is filled, then the stop_name is
merely appended to the stop_name of it's parent. Thus, you would
describe a stop two different ways:
stop_id, stop_name, stop_lat, stop_lon, stop_url, location_type,
parent_station
1, 24th St. Mission Station, 37.752240, -122.418450
2, Southwest Entrance, 37.751942, -122.418812, , 2, 1
or
stop_id, stop_name, stop_lat, stop_lon, stop_url, location_type,
parent_station
1, 24th St. Mission Station, 37.752240, -122.418450
2, 24th St. Mission Station - Southwest Entrance, 37.751942,
-122.418812
-B
Hi Joe,
I am going to provide some of these features for our next feed. How
would you suggest naming stop_name for items such as the following?
If I don't have an example of how the entrances will be shown, then I
don't know what kind of wording to use to name these entrances.
Please ignore lat/longs, many are the same because they're there only
to provide an example in the correct format.
1) staircases. i.e.
stop_id, stop_name, stop_lat, stop_lon, zone_id, location_type,
parent_station
1,Grossmont Transit Center,32.7817027986,-117.011136097,,1,
75030,Grossmont Transit Center,32.7817027986,-117.011136097,75030,0,1
75031,Grossmont Transit Center,32.7817518473,-117.011204847,75031,0,1
1-sc,Staircase from Grossmont Center Drive,
32.7817518473,-117.011204847,,2,1
2) elevators. i.e.
stop_id, stop_name, stop_lat, stop_lon, zone_id, location_type,
parent_station
2,SDSU Transit Center,32.773287945,-117.071009153,,1,
75062,SDSU Transit Center,32.773287945,-117.071009153,75062,0,2
75063,SDSU Transit Center,32.7731263965,-117.07009021,75063,0,2
2-elev1,Elevator to trolley platform,32.7731263965,-117.07009021,,2,2
2-elev2,Elevator to trolley platform,32.7731263965,-117.07009021,,2,2
2-sc,Staircase to trolley platform from Student Union,
32.7731263965,-117.07009021,,2,2
-Devin Braun
San Diego MTS
- It's not likely that many agencies will be providing urls for stair
cases or entrances.
- a seperate table would make it easier to add extra columns to each
in the future.
- JourneyWeb allows for InterchangeNodes to be described in great
detail, with several stairs, ramps, elevators, dark passages etc in
series. Would this single table/file describe all stairways,
elevators, escalators, travelators internal to each station or only
external stairways?
- Why treat stairs etc as stops/locations but toilets, phones etc
differently (facilities)? Toilets, phones, news stands etc have
locations, but I hope you wouldn't suggest that they belong in the
stops/locations table also.
I can understand that it would be useful for a pedestrian planning
algo to have gateways specified (but certainly, it is a different
problem domain). We should also make sure that it's possible for
wheel-chair bound & blind people etc to be able to navigate and access
stations and platforms (or perhaps state that they can't in some
cases).
Thanks for helping test this proposal. The sample data you provided
looks decent; do the staircase and elevator names come straight from
your database? I think they'll be good for an initial trial; we'll be
looking forward to seeing the updated feed.
I'm curious, does MTS currently display staircase/elevator locations
on its website, schedules, or other rider-facing materials?
Joe Hughes
Google Transit
Our database doesn't handle the staircases and elevators at all. I'll be updating the file by appending records to the stops.txt file from a secondary system for testing only. I can't GPS the station entrances on our entire system for this project, but I can do it for a few stations where the station entrance isn't off of a road and where a "shortcut" would be helpful to passengers.
We don't display staircase or elevator information on our website. We have very few stations with elevators or staircases.
Regards,
Devin Braun
San Diego MTS
Would it be useful if "traveline south east" in the UK submitted data for
your testing, even though our data still remains hidden from general view on
Google Transit right now? The UK data standards means that our source data
contains a robust structure for stoppoints [poles in the ground], stopareas
[clusters of stops] and station entrances within our data - not just for
what we would all call "Stations" but also for clusters and pairs of
roadside stops which are close to each other and generally share the same
"commonname".
I will be discussing with a colleague today how best we could do this - it
might take a few weeks, as I know my colleague is about to go on holiday for
a couple of weeks. But I am sure we can get you additional data soon after
he is back. But it will make our data set (currently 28Mb zipped) even
larger.
Roger Slevin
For traveline south east (UK)
-----Original Message-----
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]
On Behalf Of Joe Hughes
Sent: 18 July 2007 06:16
To: gtfs-c...@googlegroups.com
Subject: [gtfs-changes] Re: proposal: allow stations and associated
entrances to be defined
Hi Devin,
Joe Hughes
Google Transit
--
This email has been verified as Virus free
Virus Protection and more available at http://www.plus.net
Yes, we would be interested in working with stop/station information
for Traveline South East; we think it would a useful hint for how best
to cluster stops on maps at lower zoom levels.
Thanks,
Joe Hughes
Google Transit
Fine. My colleague who needs to do the work to achieve this has just gone
on holiday - but we should have something with you soon after he is back. I
guess that means we should have data for you in about a month from now.
Best wishes
Roger
I like where this discussion is going, but one problem I have with
Joe's concept of a parent station is that it is a parent to both the
entrances and the stops, which means that the only relationship
between an entrance to a stop is via the station. Here in Chicago a
typical rail station has two platforms (two stop_ids) and maybe a
couple of entrances. That is fine, but we do have some stations where
there is an auxiliary entrance that only reaches one of the two
platforms (stops). (Well, ok, someone could enter that entrance, then
walk to the main area, take stairs down to a mezzanine, then back up
to the other platform, but we would have done the customer a much
better service if we had navigated them to a more direct entrance.)
We do have locations where one entrance actually serves two stations.
So I'm inclined to say the concept of entrances needs to be carved out
into another table of some sort.
This gets complicated: Some of these entrances have fare equipment
that only handles certain types of fare media. Some are closed for
part of the day (usually night). Most entrances are at the street
level, but some are subterranean, part of an underground pedway
system, some of this comes from private buildings either underground
or one-floor up. Some from public buildings. We have stations that
are connected via pedestrian tunnels within the paid area, allowing
free transfers. We also have station exits that cannot be entered
into, but by pointing a person to one of these exits we can save them
from having to cross a busy street to catch a bus. food for thought.
I think the issue of elevators, ramps, etc. is very important all
throughout the GTFS. Basically, the issue of accessibility, is very
useful for not just the disabled/injured community, but for the
seniors, expecting mothers and people with strollers, luggage, and
bicycles. I suggest that if there is going to be entrances in GTFS in
order to provide a more precise and detailed recommended pedestrian
route into a station, then it really needs to have at least whether
it's accessible.
K
We're both recent joiners to this group ... and I bring a lot of experience
of the European standards in this area, as well as the British
implementation of those standards. A couple of days ago Nick Knowles posted
a message to the Googletransit group ... and uploaded a paper which reflects
on the link between the GTFS and European / British experiences and
standards.
In Europe we are developing an extension of Transmodel to handle more
complex location referencing issues (under the name of IFOPT -
Identification of Fixed Objects in Public Transport) which establishes the
necessary data model to underpin the complexity which you speak about.
The question for GTDF, therefore, is whether it wants and is able to adopt
the more complex data models necessary to handle all the variables which you
refer to. Experience in GB to date is that it is possible to model most
"stopareas" (interchanges or clusters/pairs of stops) using a simpler data
model, and get reasonable results - but the characteristics of some North
American transit system stations are such that I can see you would need to
link platforms with specific entrances - rather than linking them with the
cluster of platforms. This is not a situation that applies to most European
systems - and this sort of issue demonstrates the importance of having a
universal datamodel to handle all such relationships, particularly in a
standard which seeks to be fully international.
As chairman of the European sub-group that is working up the IFOPT standard,
and of the sub-group that is responsible for maintaining the Transmodel
standard (Reference Data Model for Public Transport), I am more than willing
to share experiences and provide advice based on the relevant data models
that have been developed over the past 10-15 years within Europe.
Best wishes
Roger
-----Original Message-----
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]
On Behalf Of KevinChicago
Sent: 27 July 2007 03:43
To: Google Transit Feed Spec Changes
Subject: [gtfs-changes] Re: proposal: allow stations and associated
entrances to be defined
K
Let me say first off that I'm grateful for the transit-related
experience that you and the other group members bring to this
discussion.
On 7/29/07, Roger Slevin <ro...@slevin.plus.com> wrote:
> The question for GTDF, therefore, is whether it wants and is able to adopt
> the more complex data models necessary to handle all the variables which you
> refer to.
As I mentioned in the welcome message for this group, the charter of
GTFS is to represent the information that GTFS-consuming transit
applications can use and that data publishers are willing and able to
provide, with as little work as possible on the part of the data
publisher.
More broadly, it's Google's aim (and mine) to encourage every transit
agency and operator in the world to share usable schedule information
in some free-to-use, well-documented format, whether it's GTFS,
TransXChange, or something else.
On 7/27/07, KevinChicago <koma...@transitchicago.com> wrote:
> I like where this discussion is going, but one problem I have with
> Joe's concept of a parent station is that it is a parent to both the
> entrances and the stops, which means that the only relationship
> between an entrance to a stop is via the station. Here in Chicago a
> typical rail station has two platforms (two stop_ids) and maybe a
> couple of entrances. That is fine, but we do have some stations where
> there is an auxiliary entrance that only reaches one of the two
> platforms (stops). (Well, ok, someone could enter that entrance, then
> walk to the main area, take stairs down to a mezzanine, then back up
> to the other platform, but we would have done the customer a much
> better service if we had navigated them to a more direct entrance.)
> We do have locations where one entrance actually serves two stations.
>
> So I'm inclined to say the concept of entrances needs to be carved out
> into another table of some sort.
These are good points; I've certainly frequented stations in other
systems (the MBTA, for instance) that had entrances which only
accepted certain fare media and which only served one platform.
Assuming that you have this entrance/platform relationship information
in your database already, the next step would be to post an alternate
proposal for representing entrances, and to try representing your data
using the proposed format.
Joe Hughes
Google Transit
Google has been testing some stop/station hierarchy information from a
few of you, and the results are looking good so far, so we plan to
include this change in an upcoming revision of the spec.
Note that this would only include location_type values 0 (stop) and 1
(station). The entrances part of the proposal remains untested, and
has significant shortcomings--namely, there's no way to encode
information about entrances which only serve a subset of the platforms
(stops) in a station. Because of this, I propose that we defer
dealing with entrances for a future extension, perhaps with more
detailed interconnection information.
Are there any more comments on the part of this proposal that
expresses the hierarchy between individual stop points and the larger
stations/transit centers that they're a part of?
Joe
"Joe Hughes"
<joe.hug...@gmail.com>
Sent by: gtfs-c...@googlegroups.com 04/09/2008 02:14 PM
|
|
|
Take a look at how it works in San Diego. We GPS every bus stop and
light rail platform at a station, but then we group them all into one
station. Then, when a user clicks on any bus stop or light rail
platform icon, all of the routes that serve the station are shown
instead of just the routes at that stop/platform. It is also my
understanding that eventually, a single tile will be shown for each mode
of transit to serve a station, reducing clutter on the map. Some of our
stations are pretty crowded because they have so many bus bays.
Devin Braun
San Diego MTS
-----Original Message-----
From: gtfs-c...@googlegroups.com
[mailto:gtfs-c...@googlegroups.com] On Behalf Of Tom Hixson
Sent: Wednesday, April 09, 2008 3:38 PM
Subject: [gtfs-changes] Re: proposal: allow stations and associated
entrances to be defined
I think that the proposal matches the Transmodel structure of "stop points"
within "stop areas" ... and this applies not just to platforms at stations,
but also to nearby bus stops which serve a particular location (these would
be a pair of stops serving two directions, or a cluster around a road
intersection, or whatever). The European experience is that entrances can
be handled within the structure - but you may need more attributes to give
specific access information within the station to handle the situation where
an entrance only gives access to certain "platforms" (stop points). These
can then be conditioned by time conditions as well.
What I have not been aware of is how this is being used in the demo systems
that are providing this information. We were one of the experimental
systems in traveline south east, but had to remove "stop area" information
from our feed because it was damaging the outputs (and it has continued to
do so ever since - as information about services from many "stop points" at
busy locations still cannot be accessed from the maps interface. I hope
this is being resolved very soon!
Best wishes
Roger
-----Original Message-----
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]
On Behalf Of Joe Hughes
Sent: 09 April 2008 19:14
To: gtfs-c...@googlegroups.com
Subject: [gtfs-changes] Re: proposal: allow stations and associated
entrances to be defined
I have to disagree with your view on this - users of public transport want
to see the individual stops, and not what we would call the "stoparea" -
that is, a single location for a cluster of nearby stops that serve
different directions of travel. And that is particularly important when
setting out an itinerary, or when asking for imminent departure information
using the "transit bubble" on maps.
Traveline south east continues to suffer from your experiment several months
ago to show "stopareas" ... and that has resulted in incomplete information
being shown at the most important locations within the network.
You also showed bus stop icons at the top two zoom levels at that time - but
we note that this has now been reduced again to only show at the top level.
We have received adverse comments about this - as I suspect you have. Maybe
this is once again a difference between intensive European public transport
networks and the less dense ones that (until recently) you have been dealing
with in the US.
I don't disagree that the "stoparea" can be a useful concept for accessing
details of services that operate in a general area ... and this is probably
appropriate at less detailed zoom levels. But this is only for accessing
details of services in that area, not for information that is schedule-based
...ie: not upcoming departures or journey planning.
Roger
-----Original Message-----
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]
On Behalf Of Chris Harrelson
Sent: 10 April 2008 00:09
To: Google Transit Feed Spec Changes
Subject: [gtfs-changes] Re: proposal: allow stations and associated
entrances to be defined
Thanks - we can also offer this sort of hierarchy in the traveline south
east area. Although it is not held in NaPTAN for all parts of our area, we
actually create the missing parts of the hierarchy on-the-fly using
proximity and naming rules - so that every stop in a cluster has the
identical "commonname" and is within a certain distance of other stops with
that same name (150m from another stop, and a max span of a cluster of
250m). I am sure we would be able to push this data into NaPTAN with a
little bit of effort - and thence into our GTDF feed. But I will only do so
when there is a UI to handle the information - and one we are sure doesn't
damage the information (as has unfortunately been the case with the previous
test which has lasted about 6 months, to our detriment).
I agree that there is a benefit when searching for a stop to be able to pick
up the "stoparea" record - but when you are wanting to look for imminent
departures you need the "stoppoint" record ... and that is the "conflict"
that we have had over the past six months - but at last all our stoppoints
have now been restored to Google Maps again this week. Your suggestion that
the map might display a "bubble" for the stoparea which then allows
sub-bubbles for the individual stoppoints and their departures, is a good
one if you can make it work well. I suggest that this would need a bubble
with its own stop icon, so it can point to the correct location for the
stoppoint ... and not just point to the arbitrary location that will have
been given for the stoparea.
Best wishes
Harlan,
For now, I would recommend adding a "generic" Capitola Mall stop that
belongs to the Capitola Mall station for the time being, as you
proposed. As for locations, the stops should be placed where they
should be drawn on the map, and the same with stations.
Are there others here that would find it useful to be able to specify
that a trip stops at a station (without specifying an exact stop
within the station)?
Joe
On Thu, Jul 10, 2008 at 11:34 AM, scmetro <SantaCr...@gmail.com> wrote:
> Hi Joe,
>
> I have been asked by Fred Fang to modify our stops.txt as described in
> this discussion.
> (Fred) - If possible can you group the following stops
> Capitola Mall (2800R)
> Capitola Mall Lane 1 (2801R)
> Capitola Mall Lane 2 (2802R)
> according to this specification proposal.
> http://groups.google.com/group/gtfs-changes/ browse_thread/
> thread/49c180c99f5aff2c
>
> I am concerned with your statement:
> "Only stops (rows with location_type 0 or empty) may be referenced in
> stop_times.txt.
>
> Is this an unbendable rule?
> If not for the statement above, this would be straightforward, please
> advise.
>
> In our Hastus model, 2800R is a "generic reference place" that 2801R,
> and 2802R are associated to, but it is also sometimes used as a
> legitimate endpoint of a trip.
> This convention is also used for 2700R - 2704R (Santa Cruz Metro
> Center), and for 2900R - 2902R (Watsonville Transit Center)
>
> Our convention is for a trip to start "lane-specific" and usually end
> lane-generic.
> That allows the arriving lane to be determined downstream by the next
> trip in the blocking solution. In specific cases, we break that rule
> and end lane-specific at Capitola Mall to solve routing issues.
>
> If stations CANNOT be stops, then the only workaround I see is to
> create a fictitious 2*99R as the "station" and allow 2*00R to be a
> type 0 stop.
> That would work okay, but then a) is it's coordinate the centroid of
> the building? b) where do I physically place the 2*00R coordinate? c)
> is there a better solution?
>
> Here's the modified data (but NOW 2*00R are not legitimate stops!)
> stop_id,stop_code,stop_name,stop_desc,stop_lat,stop_lon,zone_id,stop_url,location_type,parent_station
> 2700R,,"Santa Cruz Metro Center (Pacific Station)",,
> 36.970918,-122.024944,,1,
> 2701R,,"Santa Cruz Metro Center (Pacific Station) Lane 1",,
> 36.971022,-122.024575,,0,2700R
> 2702R,,"Santa Cruz Metro Center (Pacific Station) Lane 2",,
> 36.970886,-122.024551,,0,2700R
> 2703R,,"Santa Cruz Metro Center (Pacific Station) Lane 3",,
> 36.970776,-122.024447,,0,2700R
> 2704R,,"Santa Cruz Metro Center (Pacific Station) Lane 4",,
> 36.970635,-122.024436,,0,2700R
> 2800R,,"Capitola Mall ",,36.975549,-121.966142,,1,
> 2801R,,"Capitola Mall Lane 1",,36.975453,-121.966231,,0,2800R
> 2802R,,"Capitola Mall Lane 2",,36.975557,-121.966035,,0,2800R
> 2900R,,"Watsonville Transit Center ",,36.909697,-121.759920,,1,
> 2901R,,"Watsonville Transit Center Lane 1",,
> 36.909837,-121.760099,,0,2900R
> 2902R,,"Watsonville Transit Center Lane 2",,
> 36.909771,-121.760183,,0,2900R
>
>
>
> On May 22 2007, 3:35 pm, "Joe Hughes" <joe.hughes.c...@gmail.com>
>> 2, 24th St. Mission Station, 37.752240, -122.418450,http://www.bart.gov/stations/stationguide/stationoverview_24st.asp, 1,
Joe Hughes <joe.hug...@gmail.com>
Sent by: gtfs-c...@googlegroups.com |
07/10/2008 04:00 PM
|
|
|
Putting that aside (and focusing only on station vs. stop), what's
interesting about Harlan's case is that they do have information about
the exact location of the platforms, but that they might not know
which of the platforms the vehicle will stop at at the time the feed
is written.
If that's a common case, then it seems like it would be nicer to allow
the station itself as the stop point (it would express more
information about the situation than a spurious "stop" that
represented the station in general).
Do other feed providers find themselves in this situation? Other thoughts?
Joe