proposal: allow stations and associated entrances to be defined

[Joe Hughes]

Summary:
Add the ability to define _stations_, which can contain _stops_ (where
vehicles stop) and _entrances_.

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

[bad...@gmail.com]

I like the idea parent_stop and the stop_type fields in the stop.txt.
It would allow for the trip planner to express in-station transfers
differently than transfers between stations, and for walking
directions to be targeted at entrances instead of potentially
unreachable stops. That said, I fear spec bloat, and these features
may not be strictly necessary.

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

[Devin Braun]

On May 22, 3:35 pm, "Joe Hughes" <joe.hughes.c...@gmail.com> wrote:
> Summary:
> Add the ability to define _stations_, which can contain _stops_ (where
> vehicles stop) and _entrances_.

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

[Nicholas Albion]

Should entrances be broken out into a table of their own?

- 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).

[Joe Hughes]

Hi Devin,

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

[Devin Braun]

Hi Joe,

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

[Roger Slevin]

Hi Joe

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

[Joe Hughes]

Hi Roger,

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

[Roger Slevin]

Joe

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

[KevinChicago]

Hi all. I'm new to this group, but not necessarily new to the GTFS...

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

[Roger Slevin]

Kevin

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

[Joe Hughes]

Hi Roger and Kevin,

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

[Joe Hughes]

Update on the station/stop hierarchy proposal:

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

[Marc Ferguson]

I think the basic structure for entrances is ok provided the entrance is always presented in the output along with the name of the parent station.

Stations & Entrances can have a many-to-many relationship.  There are a few in NYC where this true.  Granted in some cases it is a bit of a hike but you can get there.

A wrinkle for future consideration is hours of operation.    In NYC there are entrances that are only open certain hours.  If the ultimate goal is to be able to tell the customer which entrance to use, the hours of operation are very important.

Marc Ferguson
marc.f...@trapezegroup.com
757-961-9224 x304

"Joe Hughes" <joe.hug...@gmail.com> Sent by: gtfs-c...@googlegroups.com 04/09/2008 02:14 PM Please respond to gtfs-c...@googlegroups.com

To gtfs-c...@googlegroups.com cc

Subject [gtfs-changes] Re: proposal: allow stations and associated entrances to be defined

[Tom Hixson]

How will Maps show the hierarchy? Stops, as the interface between
rider and transit, are points. But stations, as structures, are
areas. Should a station have multiple records, one for each polyline
vertex? Just adding a station icon that looks like a stop but
represents an area sounds confusing. Also, how will these stations
relate to the station icons already on Maps?

[Devin Braun]

Hi Tom,

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.

http://tinyurl.com/59x2gx

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

[Chris Harrelson]

Replies inline:

On Apr 9, 3:37 pm, Tom Hixson <THIX...@sacrt.com> wrote:
> How will Maps show the hierarchy?

When drawing icons on the map, we (Google) will show only the station
icon at all but possibly the most zoomed-in view. This makes sense
since users want to find stations, not stops, and also won't be
confused about which icon to click on for a desired line's schedule.

Yes - each point stopped at by a trip should be a stop, and those
stops should be logically grouped into stations as appropriate.

The station location is only used for drawing icons on the map and
indicating grouping of stops; it would not impact the directions UI
directly. For example, if you had a bus depot witih bays A-F, it
would still say something like "Bus - X ... Arrive Station Y, Bay A"
if the stop's name was "Station Y, Bay A".

Chris

[Tom Hixson]

In Devin's Old Town example, the station appears to get no icon, and
serves only as a grouping mechanism. If so, this feature might be
better called 'transit center' instead of 'station', since it does not
involve the structure normally associated with a real station.

The two icons labeled 'Old Town Transit Center' are not really transit
centers; they are Light Rail stops (platforms). [BTW the northern one
is grouped with Amtrak, not the TC-why?.] Also, we plan to add some
Amtrak. Will we then have 3 icons--2 from my feed (for the platforms)
and one from Maps (for the station)?

Although the grouping done in the stop bubble is superb, the map
aspects are somewhat confusing, due to trying to use stops (platforms)
to represent stations/TCs. But short of adding polygons, I think this
will do.

[Roger Slevin]

Joe

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

[Roger Slevin]

Chris

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

[Chris Harrelson]

Hi Roger-

I agree with you that the actual stop location is very useful
information to show to users. The use case I was discussing, and
that we're trying to make easy to use, is when a rider wants to find
out about a transit stop and clicks on it. Asking the rider to
figure out which of a number of bus bays to click on is confusing.
Instead, information about the individual stops could be
shown inside the window that appears after the click. While that
breakdown is not implemented in our current user interface,
we hope to have it be so soon, and it is not incompatible with the
proposed change to the spec.

I've also seen some great examples of the descriptive power of station-
stop hierarchies in Europe. For example, the Zurich
transit system is very well organized, with each cluster of stops
being given the same station name. Riders know that if
they need to get on or off at a particular station, they need to find
out on their own which of the stops in that area is the
one for their desired transit line.

best-
Chris

[Roger Slevin]

Chris

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

[Joe Hughes]

(copying the group because others will find it relevant)

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,

[scmetro]

So to clarify, since I'm already using my generic as a stop, I create
a new "generic to the generic" 2800R (call it 2899R, type 1, parent
location of 2800R,2801R,2802R)?
But later you might lift the limitation of "station can't be a stop",
if there is sufficient feedback in that direction?

On Jul 10, 12:58 pm, Joe Hughes <joe.hughes.c...@gmail.com> wrote:
> (copying the group because others will find it relevant)
>
> 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
>

[Marc Ferguson]

What Harlan described is very common.

This doesn't strike me so much as a station entrance issue but an issue with closely spaced and similarly named stops and the ability to differentiate or ignore them as need be.

An example of a Station Entrance issue is when there are multiple street entrances for a station complex.   Most NY City subway stations in Manhattan are like this as well as train stations such as Newark's Penn Station, Grand Central Station and Boston's north and south station.   There are multiple street entrances that lead to one or more platforms.  For "walking" you need to know which entrance to use.  For "navigation" within the complex you need to know which platform (stop) to use.

It is complicated to say the least.

Marc Ferguson
marc.f...@trapezegroup.com
757-961-9224 x304

Joe Hughes <joe.hug...@gmail.com> Sent by: gtfs-c...@googlegroups.com

07/10/2008 04:00 PM Please respond to gtfs-c...@googlegroups.com

To scmetro <SantaCr...@gmail.com> cc Google Transit Feed Spec Changes <gtfs-c...@googlegroups.com>

Subject [gtfs-changes] Re: proposal: allow stations and associated entrances to be defined

[Joe Hughes]

I agree, the entrance/internal navigation issue is complex and needs more work.

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

[Harlan Glatt]

Hi, and thanks for all your collective attention to this issue.

I have finished a workaround with a bunch of extra code to trap and
massage these cases to produce a compliant stops.txt, and would agree
this is a cludge in my particular case. The new "station" I've named
2899R has to borrow it's location from the untouchable 2800R, and
serves no real purpose, other than being a clone that is not a stop.
Lifting the "station can't be a stop" rule, would be much simpler.

I have explained the reason why we were taught to model it this way.
In summary, to allow a flexible blocking solution. Our schedules show
"trip arrives at *Station*" without naming lanes. Passengers need to
know specifically where to get on, but not where to get off (our
transit centers not vast architectures). Operators look at their
block sheets to determine lane placement based on the next trip's
designated departure lane. Simple.

Stepping out beyond "Stations", what I would like to suggest here is
to borrow a simple construct from the Hastus model, called a
"reference place". You are nearly there with "location_type", and
"parent_station". Why not rename the latter to "parent_location"?
The type is already stated in location_type, perhaps add a new
location_type ID for "place". That would be the simplest case. You
could also have additional location_types for schools, hospitals,
fire, police, etc., leading to special icons on the map?

The Hastus model allows each stop to have a single reference place
(when useful, or else null). Many stops can point to the same
reference place, that way it is known that they are really "at the
same place" without resorting to inferences gleaned by ambiguous
geoproximity thresholds, puts the agency in control of this
designation, and is probably faster and more reliable to compute, and
provides the google trip planner algorithm with yet another solid clue
for connectivity. This applies to stops at intersections in each
direction, or on opposite sides of the same street, etc. In Hastus,
places are objects used to describe each location used for a
timepoint. Places may also have their own reference places, allowing
complete flexibility in tying them all to one definitive reference
place. Hastus uses this construct for blocking, and operator reliefs
in runcutting, without requiring any geospatial data layer.

Thanks for listening...

On Jul 11, 10:18 am, Joe Hughes <joe.hughes.c...@gmail.com> wrote:
> I agree, the entrance/internal navigation issue is complex and needs more work.
>
> 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
>
> On Fri, Jul 11, 2008 at 9:51 AM, Marc Ferguson
>

> <Marc.Fergu...@trapezegroup.com> wrote:
>
> > What Harlan described is very common.
>
> > This doesn't strike me so much as a station entrance issue but an issue with
> > closely spaced and similarly named stops and the ability to differentiate or
> > ignore them as need be.
>
> > An example of a Station Entrance issue is when there are multiple street
> > entrances for a station complex.   Most NY City subway stations in Manhattan
> > are like this as well as train stations such as Newark's Penn Station, Grand
> > Central Station and Boston's north and south station.   There are multiple
> > street entrances that lead to one or more platforms.  For "walking" you need
> > to know which entrance to use.  For "navigation" within the complex you need
> > to know which platform (stop) to use.
>
> > It is complicated to say the least.
>
> > Marc Ferguson

> > marc.fergu...@trapezegroup.com
> > 757-961-9224 x304
>
> > Joe Hughes <joe.hughes.c...@gmail.com>

> > Sent by: gtfs-c...@googlegroups.com
>
> > 07/10/2008 04:00 PM
>
> > Please respond to
> > gtfs-c...@googlegroups.com
> > To

> > scmetro <SantaCruzME...@gmail.com>

> > cc
> > Google Transit Feed Spec Changes <gtfs-c...@googlegroups.com>
> > Subject
> > [gtfs-changes] Re: proposal: allow stations and associated entrances to be
> > defined
>
> > (copying the group because others will find it relevant)
>
> > 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
>

[Tom Hixson]

The feed comes AFTER the blocking solution (so it includes stay-in-seat transfers).  If Hastus blocking resolves the generic stop to a real one, it should be available to the feed.  Otherwise it violates the trip planner's assumption of 'fixed-route', meaning the stop sequence of each trip pattern is known and invariant.

 

Remember that a primary product of scheduling systems like Hastus and Trapeze is a runcut for drivers based on timepoints (a place for a time, not a real place).  Getting stop-based trip planner data out of them can be... inelegant.

 

In general, a stop is the interface between the customer and the service (that is, the train) and therefore must be real.  That normally means two stops per station, one for each direction.  We nominally use the first door of the first car (which translates to the platform).

 

A station is a building which should be projected onto the map as an area, not a point.  Station entrances are points that relate to the station, not the transit service.  Therefore stops and entrances are different animals.

 

Short of including a full station navigation schematic, the best that station-as-a-point can provide is a logical grouping of stops, which the current spec does nicely.

 

Tom Hixson

Sacramento RT