Proposal: Entrances File

[KevinChicago]

I would like to revisit and older proposal that pertains to the
concept of station entrances. Joe first proposed something a year and
a half ago for enhancements to the stops.txt file (http://
groups.google.com/group/gtfs-changes/browse_thread/thread/
49c180c99f5aff2c). The proposal then was to create the concept of
stations (which was implemented in the spec), but the other--
unimplemented--half of his proposal was to incorporate the concept of
entrances into the stops.txt.

A good healthy discussion then followed that lasted over a year and
then sort of fizzled. Entrances can be very complicated, in fact, I
was guilty of raising some of those complications.

I would like to propose something that is simple and hopefully solves
most of the problems with how pedestrian directions are provided when
entering or leaving grade-separated rail stations, or just any station
that has some form of barrier to entering/exiting the station.

Unlike Joe's original, that blended entrances into the Stops.txt
table, I propose a new file as follows:

***********
Proposal:
entrances.txt

entrance_id (Required). Unique Id.

entrance_name (Required).
- name that may be used to identify the entrance, particularly in
trip planner results. Whether it would appear in a mapping
application, may demand another name field, for instance,
entrance_long_name.

entrance_lat (Required).
entrance_lon (Required) It is presumed that the Lat/Lon best reflects
the location at ground level, closest to

street or pedestrian pathways.

stop_id (Required) The stop_id field contains an ID that uniquely
identifies a stop that this entrance makes a connection to. Multiple
entrances may use the same stop and mulitple stops may be associated
with the same entrance. The stop_id is referenced from the stops.txt
file. If location_type is used in stops.txt, a stop referenced in
entrances.txt must have location_type of 0 and the entrance_ids
associated with that stop are assumed to be the only methods of access/
exit to that stop_id. If mulitple stop_ids are associated with the
same entrance_id then transferring between the stop_ids can be done
without utilizing the entrance_id.

entrance_type (Optional). This field denotes the type of access this
entrance allows:
* 0 or null: entries and exits allowed.
* 1: entries only
* 2: exits only.

accessible (Optional). This field denotes the accessibility of this
entrance:
* 0 or null: is accessible
* 1: is not.

************

It has the possibility of many-to-many relationships, but that's how
entrances can be, so to keep it to one file, much of the data gets
repeated. Notice also, that an entrance has to be related only to a
stop--the child stop, never the parent station--because an entrance
could serve more than one station.

As far as use of the file, I would think that mapping applications,
like Google Maps, may not choose to show the entrances on the map,
except maybe in zoomed-in locations, but that's open. I do think,
however, that trip-planners, should show the entrance in a result, and
in fact, could include the entrance_name in the itinerary. I also
think that a trip-planner should create the rule that if a stop_id is
associated with an entrance, the entrance has to be used in the
results, unless there's a transfer to a stop_id that shares
entrance_ids.

As far as amenities, I proposed to keep it simple with the two things
I see as important, entry/exit and accessibility. There are other
features that I hope we could do some day, like hours of service and
fare options, and bikes amenities, etc, but I'd like to avoid getting
bogged-down in those. But, if folks want to advocate, feel free to.

Thanks for your thoughts,
regards,
Kevin O'Malley
Chicago Transit Authority

[J. R. Westmoreland]

Kevin,

I think, from a Sendero perspective, we would be able to use something like
this to aid our users in their navigation. We would consider this to be an
additional POI.

I would propose that the name somehow relate to the stop name. I.e.,
"Central Station" and "Entrance: Central Station", These would be short
descriptions maybe.

Sorry, I have taken examples from our own transit system here. :)

If we were to do something like this, Might it now be an idea to make this
into an amenities file and have the entrance be just another amenity?
The benefit to that, from our perspective, would be the ability to put a
lat/lon on other items as well.
I.e., "ticket vending machine".

This would be very useful from a non-sighted viewpoint. In the sighted world
you just look around to find the vending machine of other amenity but from a
non-sighted view that is much more difficult.
Sometimes you can locate things by their sound or with a cane or other
mobility aid but other times it can be very difficult.
Next time you go to a stop like this, with lots of amenities, try just
listening, rather than looking, to determine just what you could locate and
not.

Just a few other thoughts. Over all a great idea.

Regards,
J. R.

--------------------
J. R. Westmoreland
Custom Computers & Consulting
E-mail: j...@jrw.org

[Joe Hughes]

Hey Kevin,

Thanks for reviving this discussion, and contributing a detailed
proposal. The next step is for someone to build sample data
representing some of your tricky use cases in the proposed format to
see how it looks.

The Google Transit team has also been experimenting with some ideas
for addressing some of your previous concerns. Now that we have
transfers.txt, we could use it to express finer-grained connectivity
between entrances and individual stops/platforms in a station. I hope
to be able to post more details on this approach for discussion soon.

Thanks,
Joe

[David Turner]

I think this is perhaps a little too simplistic for New York or Tokyo.

Consider Canal Street station in New York. There are nine routes on
eight physical tracks (four up and four down), and fourteen entrances.
You can get to any of the tracks from any of the entrances -- but some
entrances are better for some tracks than others.

You could simply associate each stop with the entrances that are "best"
-- but this doesn't represent the physical reality accurately, and some
people really would rather walk up and down two flights of steps than
cross a street aboveground.

Also, there is a normalization problem -- if you have multiple stops in
entrances.txt for a single entrance, you need to repeat data.

The solution to both of these is stop_entrances.txt:

entrance_id,stop_id,wheelchair_accessible,distance

wheelchair_accessible is moved into this file because at Canal St, the 6
(and late-night 4) train is wheelchair accessible, but the other trains
are not. Distance is the length of the walk from the entrance to the
platform, in meters, as the ant walks. On a staircase, distance counts
the risers and the treads, but on an escalator, count only the treads.
I guess we could have distances include complex mapping information, but
for now this simplification should do.

wheelchair_accessible replaces just accessible, because we want to be
clear what sort of accessibility we mean. Canal Street, for example,
was renovated to comply with the ADA -- which meant that they put bumpy
things on the floor at the edge of the platform so that blind people
could more easily avoid falling onto the tracks.

Finally, I do have one more concern:

On Thu, 2009-11-05 at 19:45 -0800, KevinChicago wrote:
> If mulitple stop_ids are associated with the
> same entrance_id then transferring between the stop_ids can be done
> without utilizing the entrance_id.

This bit does not work for Tokyo, where one entrance at the street level
can enter into a station that serves multiple subway and train
operators, each with independent tickets and no free transfers.

transfers.txt describes transfers pretty well, so there is no need to
complicate the entrances/exits data with it.

[KevinChicago]

In general, I've noticed a lot of references to the transfers.txt
file I appreciate that some of the problems I'm seeing (less-than-
optimal stop-to-stop transfer itineraries being recommended to a
customer) could be solved with the Transfers.txt file. But also part
of the problem I am seeing is the recommended pedestrian path given to
the first or last stop of an itinerary. For Google, some of these can
be solved with further enhancements to their pedestrian network (which
they've been doing), but some I think may be helped if an entrance is
located near the street grid and the trip planner is forced to pick an
entrance/exit before routing the customer either to the stop_id or to
their eventual starting or ending point.

Most of the problems we have in Chicago are not the Loop elevated or
downtown subway stations, but our expressway media stations. The
following map shows a particular problem, where the station is on a 45
degree angle to the street grid and it has two entrances at both ends
of the platform, reaching two major arterials that both have buses on
them. It is also, though, near some residential neighborhoods and
customers can walk-up to this station, albeit underneath an
expressway--not very pleasant, but doable. The Lat/Lon of the stop_id
is not very close to the street grid, but I cannot move it closer to
one street, without moving it farther from the other street.

http://maps.google.com/maps/ms?hl=en&ie=UTF8&msa=0&msid=107684114076645034028.000478927e46ae67169ed&t=h&ll=41.95278,-87.729076&spn=0.002805,0.004812&z=18

This particular station I cannot actually get Google Transit to
suggest a 3-4 minute walk-up intinerary without it forcing a
ridiculously short bus ride. Try the following transit directions and
see what happens at the beginning of the itinerary. "4244 w irving
park rd, chicago to O'Hare Airport" I think it has something to do
with the Stop_id not being near the street grid. If anyone has a way
to deal with this in the current GTFS, I'm all ears. Or if Google
wants to approach it from the internals of their trip-planner, that's
fine too.

So besides solving the above-mentioned problem, I also thought that it
just might be a helpful enhancement to guide customers towards better
entrances or exits to save them time for crossing busy streets or
getting confused underground. As David Turner pointed out, however,
assuming what is the most "helpful" can get tricky real quick in a lot
of situations, like New York. We have some of those in Chicago, but
probably not as many. This is why I tried to start by only having the
entrances located where the entrances meets the street grid at ground-
level. Granted: not at all perfrect and not always reflecting
reality. But currently the GTFS is based on a 2-dimensional world,
there is no vertical (yet), so I was trying to come up with something
that reflected currently what GTFS is and tried to avoid the issues of
stairs, elevators, mezzanines, underground pedways, etc..

David Turner said:
>>This bit does not work for Tokyo, where one entrance at the street level
>>can enter into a station that serves multiple subway and train
>>operators, each with independent tickets and no free transfers.

I just wanted to clarify about my proposal on this point. The rule
for a trip planner would be: if a stop_id has an entrance_id, then the
entrance_id must be used in an itinerary, except in the case that a
trip planner wants to recommend a transfer between two stop_ids that
share an entrance_id. The second part of that isn't so much a rule as
an implied allowance that a physical transfer must be possible between
the stop_ids without exiting then re-entering an entrance. And to
point out, none of this as anything to do with the ticketing and fare
policies--just that the physical connections are there to move between
two stop_ids or the street network. If a trip planner is
incorporating fare rules into it's results, it still needs to include
those regardless of this entrances.txt proposal.

Lastly, David Turner said:
>>Also, there is a normalization problem -- if you have multiple stops in
>>entrances.txt for a single entrance, you need to repeat data.
>>The solution to both of these is stop_entrances.txt:

You are correct; I was aware I was proposing a non-normalized
solution. I guess I was wary of proposing two new files, versus just
one. I really have no problem with the two-file solution either.

Kevin

[David Turner]

On Tue, 2009-11-17 at 08:24 -0800, KevinChicago wrote:
> David Turner said:
> >>This bit does not work for Tokyo, where one entrance at the street level
> >>can enter into a station that serves multiple subway and train
> >>operators, each with independent tickets and no free transfers.
>
> I just wanted to clarify about my proposal on this point. The rule
> for a trip planner would be: if a stop_id has an entrance_id, then the
> entrance_id must be used in an itinerary, except in the case that a
> trip planner wants to recommend a transfer between two stop_ids that
> share an entrance_id. The second part of that isn't so much a rule as
> an implied allowance that a physical transfer must be possible between
> the stop_ids without exiting then re-entering an entrance. And to
> point out, none of this as anything to do with the ticketing and fare
> policies--just that the physical connections are there to move between
> two stop_ids or the street network. If a trip planner is
> incorporating fare rules into it's results, it still needs to include
> those regardless of this entrances.txt proposal.

Oh, that makes sense.

In the meantime, I've generated entrances.txt and stop_entrances.txt for
the New York City subway. They have wrong distances, because I haven't
actually measured any stations. Also, they may be attached to incorrect
stations, because I only used heuristics to match entrances to stations.

To make this work, I had to split almost all stops into uptown/downtown
stops, since in many stations, crossing the tracks inside fare control
takes a long time (and in some, it is impossible).

The subway GTFS with entrances.txt and stop_entrances.txt is at:

http://data.topplabs.org/data/mta_nyct_subway/subway.zip

My next step is to implement support for this in OpenTripPlanner.

On further thought, I think I was wrong to propose this:

> Distance is the length of the walk from the entrance to the
> platform, in meters, as the ant walks. On a staircase, distance counts
> the risers and the treads, but on an escalator, count only the treads.
> I guess we could have distances include complex mapping information,
> but for now this simplification should do.

I think distance should instead be min_time, in seconds, to match what
transfers.txt does. What do others think?

[Tom Brown]

On Tue, Nov 17, 2009 at 17:24, KevinChicago <koma...@transitchicago.com> wrote:

Most of the problems we have in Chicago are not the Loop elevated or
downtown subway stations, but our expressway media stations.  The
following map shows a particular problem, where the station is on a 45
degree angle to the street grid and it has two entrances at both ends
of the platform, reaching two major arterials that both have buses on
them.  It is also, though, near some residential neighborhoods and
customers can walk-up to this station, albeit underneath an
expressway--not very pleasant, but doable.  The Lat/Lon of the stop_id
is not very close to the street grid, but I cannot move it closer to
one street, without moving it farther from the other street.

http://maps.google.com/maps/ms?hl=en&ie=UTF8&msa=0&msid=107684114076645034028.000478927e46ae67169ed&t=h&ll=41.95278,-87.729076&spn=0.002805,0.004812&z=18

This particular station I cannot actually get Google Transit to
suggest a 3-4 minute walk-up intinerary without it forcing a
ridiculously short bus ride.  Try the following transit directions and
see what happens at the beginning of the itinerary. "4244 w irving
park rd, chicago to O'Hare Airport"    I think it has something to do
with the Stop_id not being near the street grid.  If anyone has a way
to deal with this in the current GTFS, I'm all ears.  Or if Google
wants to approach it from the internals of their trip-planner, that's
fine too.

In this case you can improve Google's walking model by reporting a map issue http://maps.google.com/support/bin/answer.py?hl=en&answer=162873 saying that it is possible to walk from Irving Park and Pulaski to the blue line station. If the walking model has ways (using the OSM term) inside the station marked as access-only/private they shouldn't be used for walking directions that don't start or end in the station.

Accurately representing the local connections between a walking network and stops in GTFS is tricky. Some paths, such as a pedestrian bridge outside the fare gates, clearly belong in the walking network. Other paths, such as a gate with limited hours and no use other than getting to a stop probably belong in GTFS. There is no reason a walking model couldn't represent all the details of a complex station such as Canal Street but GTFS is probably a better place for transfer constraints etc.