Proposal to allow specification of entrances for large stations

[Stuart Heinrich]

For stops contained within large stations, either above ground or underground as in a subway, there may be multiple entrances that are far apart from each other or from the actual location where the vehicle stops within the station. 

For an example, please see the following screenshot:
http://img844.imageshack.us/img844/7852/stationentrances.jpg

This results in several problems:

1) Bad routing instructions and/or decisions, or inability to give specific instructions.  Because the routing algorithm has only the stop coordinates, it may wrongly direct a person to a location above ground where there is no entrance.  It will not be able to determine what side of the street the station is on, if crossing the street is necessary, etc.  In the above example, it might take 4-5 minutes to walk from one entrance to the other.  Ignoring this walking time might cause an algorithm to suggest a route that cannot be physically reached by the walker, or to ignore a good route when the walker is right next to the entrance (but far from the center of mass stop location).

2) Ambiguity in the assignment of lat/lon on behalf of the transit authority.  Should the stop lat/lon be set at the approximate station center of mass, or where the vehicle is most likely to stop, or at one of the various entrances of the station?  And if so, which one?  Currently, this is unclear.

I propose to solve these problems in a backwards compatible way by adding two new optional files.  First, I propose the optional entrances.txt file:

entrances.txt
entrance_id,stop_id,entrance_lat,entrance_lon,entrance_type,entrance_heading, entrance_street

The first four fields are required.  entrance_id is database unique identifier for the entrance.  stop_id associates this entrance with the stop.  The optional entrance_type would allow to specify what type of entrance it is.  ie, doorway, staircase, elevator, escalator.  The optional entrance_heading parameter would specify the orientation (this might be useful for showing a streetview image that faces the front side of the entrance rather than the backside).  The optional entrance_street field would list the name of the street that the entrance is on or most accessible from.

In some cases, it may be the case that a large station has multiple entrances, and certain trips are only accessible through certain entrances.  It will be assumed by default that any entrance that is linked to a stop can be used to physically access that stop.  However, the following optional exceptions file would allow transit authorities to specify exceptions:

entrance_exceptions.txt
entrance_id,route_id,trip_id

route_id and trip_id are both optional fields.  However, one of the two must be specified.  By specifying a entrance_id and route_id pair, it means that this route is NOT accessible by this entrance.  This is the preferred method of specifying exceptions.  However, in some cases it may be that exceptions have to be listed at the trip level, in which case exceptions can also be listed by entrance_id and trip_id, leaving route_id blank.

Lastly, I would like to point out that each "stop" in stops.txt is either a location where a transit vehicle stops, or it is a more abstract "station" that contains other stops.  Going forward, it would be nice if stations could be described more clearly in their own table...specifying station name, whether or not the station is above or below ground, etc.

[David Turner]

Have you seen the prior work on this?
http://groups.google.com/group/gtfs-changes/browse_thread/thread/241013e6216a0256/2ca7b3327c396d9c?lnk=gst&q=pathways#2ca7b3327c396d9c

> --
> You received this message because you are subscribed to the Google
> Groups "General Transit Feed Spec Changes" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/gtfs-changes/-/YFAPOMRv7YMJ.
> To post to this group, send email to gtfs-c...@googlegroups.com.
> To unsubscribe from this group, send email to gtfs-changes
> +unsub...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/gtfs-changes?hl=en.

[Brian Ferris]

As David has pointed out, there has been some previous work on a proposal for handling entrances and I'm wondering if some of that proposal might be ready for formal adoption into the spec?  Specifically, I believe the proposal for specifying station entrances (stops.txt - location_type=2) might be worth another a look.

There are a number of feeds using this convention already.  For example, Los Angeles Metro includes station entrance information in their public GTFS feed using the proposed extension.  In addition, there are a number of feed consumers who can use this information.  OpenTripPlanner appears to have support for entrances and Google Maps does as well (see http://g.co/maps/tjytt for a Los Angeles Metro example).

I think the main question is whether we can move forward with the entrances proposal without adopting the full pathways.txt proposal at the same time.  My thoughts say "yes" but I'd be interested in hearing what others have to say.

Another question: right now, "stop_name" is a required field in stops.txt.  It has been proposed that "stop_name" potentially be optional for entrances.  I'm a little torn by this, because it'd be nice to have consistent semantics for "stop_name" (and not break backwards compatibility for existing parsers) but at the same time, some agencies have expressed concern that they don't have meaningful names for all their station entrances.  Thoughts?

Just to summarize, here is the entrances proposal as I currently understand it:

stops.txt (existing file) 

location_type - A new value “2” is added, denoting a location that is 
an entrance and/or exit for a station or stop. For brevity, this type 
of location is called “entrance”; this is not meant to exclude its use 
to exit the station. 
An entrance is a physical structure, like a subway entrance, that 
provides access from the streets to stops or vice versa, in a way that 
allows to speak of “entering the station” or “taking the exit to leave 
the station”.  It is very common, but not required, that all stops 
connected to an entrance have the same parent_station. 

For rows with location_type 2, the other columns of stops.txt are 
interpreted as follows. No new columns are added: 

stop_id - unchanged: Required. An unique ID for this row (stop, 
station or entrance). 

stop_code - Optional. Not used for entrances. 

stop_name - Required. The name of the entrance, as seen by riders 
inside the station, or empty if not available (?). Use only for names that 
are meaningful to riders. 

stop_desc - unchanged: Optional. A description of the entrance 
(analogous to the use for stops and stations) for display to riders. 

stop_lat, stop_lon - unchanged: Required. The geographical position of 
the entrance as latitude and longitude (WGS84, in degrees). 

zone_id - Optional. Not used for entrances. 

stop_url - unchanged: Optional. The URL of a web page about this 
particular entrance. This should be different from the stop_url values 
of the station and stops this entrance leads to. 

parent_station - Optional in general, but required for entrances. The 
stop_id of the station to which this entrance is belongs. This 
high-level connection helps with painting entrances on maps. It also 
provides default pathways according to the rules explained after the 
pathways.txt file, but the pathways.txt file can be used to replace 
these defaults with explicit pathways. 

wheelchair_boarding - unchanged: Optional. Indicates 
the wheelchair accessibility of the entrance (0 or empty = unknown, 1 
= yes, 2 = no). 

Thanks,

Brian

To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.

[Stuart Heinrich]

Detailed information about internal pathways within the station is a whole other can of worms, more difficult to specify and less likely to be useful from a routing perspective.  However, in some stations, it is not possible to reach certain stops within a station from certain entrances.  That is why I proposed a simple mechanisms for specifying exception cases where entrances cannot be used to access certain stops.  This allows for the minimal level of complexity (ie, avoiding intenal pathway specification) while still leading to accurate routing instructions in all types of stations.

 

Although entrance level information is very important to us, I am strongly opposed to the previous proposal with location_type=2 for several reasons.  First, stops, stations, and entrances are all fundamentally different things.  It is confusing enough that the current standard has stops and stations listed under the same table.  Not only is this confusing but it makes it more inflexible and difficult to adapt to changing needs, because any additional station-specific information is unlikely to make sense as a field for stops, and vice versa, thus leading to disagreement over whether or not a new field should be added at all...not because the field is unimportant, but because it highlights the disorganized nature of the spec.

 

Now that there is a clear need for entrance level information, we have a choice: we can either incorporate this information the right way, which is to put it into its own table, or we can go even further down the path of convolution...having each field name be optional or mandatory or have different meanings based on the type.  At that point, we might as well just throw all the GTFS tables into one big table with a supeset of columns, and then have a "row_type" field that tells you if its a stop, a station, an entrance, a trip, a calendar, a fare, etc...

 

By making entrance as an additional row type within stops.txt, people will be hesitant to add the appropriate fields necessary to describe entrances because they make no sense for stops or stations.  For example, in my proposal, I identified an "entrance_type" field that identifies whether or not it is stairway, elevator, escalator, ramp, etc, as well as a direction field that tells which way the entrance is facing.  That information is important to us.

 

Having read both proposals, I think that adding an explicit wheelchair accessibility flag to entrances is a good idea (in addition to entrance_type).  However, I feel that the structure I have proposed is simpler, less confusing, and more flexible for the future.

--
Stuart Heinrich, Ph.D
Head of Computer Vision
Lumatic, Inc
(802) 922-0731

[StuartJReynolds]

I would +1 the principle of adding entrances, but along the lines that Brian has outlined. Note that I haven't reviewed the full detail of that proposal, and may want to add comments to it. However, in the UK we have our entrances within the stops file, which helps us keep them all together (and we also use an extension of the stop ID to help in that e.g. 9100LHONSEA is a station, 1580LHONSEA0 is it's entrance, with LHONSEA being common - but that is a data discipline and nothing to do with the spec). Most of the information that you would need for an entrance is the same as you might want for a stop (location, streetname [in our systems], etc)

We implemented enrtances without pathways. It works ok. However, pathways would be better in the long run, as you can specify different lengths of time (some entrances are a LONG way away) and also the accessibility (so this path from A to B has stairs and takes 3 mins, this other path from A to B has a lift and takes 5 mins, which means that A is an accessible entrance for station B. On the other hand, entrance C to station B only has a "stairs" route, so entrance C is no good for accessible planning)

Cheers,

Stuart

To unsubscribe from this group, send email to gtfs-changes+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/gtfs-changes?hl=en.

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To post to this group, send email to gtfs-c...@googlegroups.com.

To unsubscribe from this group, send email to gtfs-changes+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/gtfs-changes?hl=en.

[Stuart Heinrich]

As I pointed out in my previous comments, there is additional information about entrances that doesn't make sense for stops or stations, which can be encoded in a simpler way in a new table.  I am afraid that if we implement stops in the ad-hoc fashion of another row that people will be disinclined to add the optional fields that are relevant for entrances only, and would make a big difference in the kind of routing quality that we can provide.  Do you have any specific objections to my alternative proposal?

[StuartJReynolds]

Stuart,

In terms of the proposals, what Brian has proposed maps better onto what we already do. So that was my driver for preferring Brian's proposal over yours. However, I can see that there is merit in having different tables/files to include extension information - you might want to include information about seating at a bus stop, about toilets at a bus station, and so on. So, as long as the proposal allowed us to map what we have onto the GTFS tables easily, I don't have any strong feelings either way. But I do think that as we take it forward, we need to consider pathways and not create something where these cannot be used/implemented, even if at a later date. And I am a little nervous about too many tables - they might look like database tables, and they relate like database tables, but they aren't. Cross referencing flat text files is always tricky.

The other points you make about the inherent unstructured-ness of the GTFS spec are of interest to me, though, because I agree! It isn't helped that some of the language is confusing; for example, "station" could just as easily be a pair of stops or a cluster of stops on the street, where interchange is practical, without the overheads attached to the concept of a physical "station" (the spec clearly mentions "physical structure"). That is why we use the term "stoparea" in our own work. Over here on the right hand side of the pond, we have been developing structured stop models for years. I made the point in a post under a different topic that rather than gingerly dipping a toe into the water here and there, it would be good to take advantage of the work that has been done already and to take GTFS forward with a leap. I'm not trying to sell a particular model (although IFOPT is comprehensive and likely to become a European [CEN] standard), but I am rather suggesting that it would be good for the community here to consider the concepts inherent in the models and look to their applicability to GTFS. But that is somewhat off topic, so I'll get off that particular hobby horse!

[Brian Ferris]

Stuart H (just to be clear on my Stuarts), I appreciate your comments and I'll freely admit that there is potentially more modeling power to be had by encoding entrances in a separate file.  However, I wonder how many of the additional parameters you have specified (entrance_type, entrance_direction) are appropriate for an entrances specification vs a full-on pathways specification.  When you ask if an entrance is an elevator vs an escalator vs a door vs stairs, I'd argue that this is more of a property of the pathway leading from the entrance as opposed to the entrance itself.  To me, it's less useful to attempt to model that information to the entrance itself vs simplifying the entrance with a basic wheelchair accessibility indicator for the entrance and modeling more complex information about stairways, elevators, escalators, etc with something like a pathways specification.

At the end of the day, I do think entrances do have a lot in common with other common fields in stops.txt and I think the simplification is acceptable given the stop-station hierarchy model already available in stops.txt.  It's not perfect but I think it covers a use case that many agencies will be able to use in practice (specifying their station entrances with basic accessibility info).  It's less clear to me that lot of agencies have additional pathway-level data for their stations, but I think a pathways proposal is the way to go for modeling it.

Brian

[Stuart Heinrich]

In my opinion, there are three issues at play here that can be ranked in order of importance:

 

1) The ability to generate basic routing instructions that are correct.
2) The ability to optimize those routes for special interest groups (such as the disabled).
3) Much much lower down on the list, the ability to calculate accurate walking times between stops inside a station, or perhaps to give specific walking instructions inside of stations.

Do people agree with that overall prioritization?

As it stands, first base isn't covered yet: it is not possible to generate correct routes when embarking or disembarking from a large station (ie, subway) because the internal subway stops do not correspond to streets above.  This results in incorrect directions telling you to go down the wrong street in order to get on the subway, or to exit onto the wrong street when leaving the subway, which can be extremely confusing to consumers who are relying on routing instructions.

In order to fix this first priority, we need to know entrance locations.  If we JUST had entrance locations, that would be an improvement.  However, it wouldn't fully solve #1, because we also need to know whether or not these entrances can be used to get to the internal stops in question.  It is not always the case that every entrance can be used to reach every internal stop.  If we simply add entrances without giving any way to specify exceptions, then routing algorithms will specifically direct users into the wrong entrance (which may be on the wrong street), and this may be even more infuriating to a user than not being directed to an entrance at all.

If transit authorities all provided graphs for their internal walkways, then that would solve the problem.  However, the spec for this is a long way off, and generating this information would be a lot of work...possibly causing a lot of transit authorities to not provide the information even after the spec is (someday) completed.  Therefore, I find it preferable if we can specify the critical information now without being reliant on the pathway spec, in a way that also does not hinder the creation of a future pathway spec.

An exception table is extremely simple to specify (literally, juust 3 columns), its usually not even needed, and when it is, it would be a small amount of work that is easy to make without the need for detailed floor-plan information, so I think its much more likely that transit authorities would be willing to provide this.

In addition, it is unlikely that the additional complexity of internal pathways would be used for much.  Routing algorithms are unlikely to be providing extremely detailed directions inside of a station, so the only tangible benefit is slightly improved estimation of walk times between stops, but this could already be approximated sufficiently based on the  surface distance between stops.  In the future, if we have both a pathway graph and an exception table, a transit agency could choose to implement one or the other -- if they have pathways, its going to supercede the exception table, but some agencies may prefer to go the simpler route of listing an exception table if they don't have all the necessary and complex pathway info.

Given stop locations (and exceptions), it would then be possible to generate correct routing paths -- but a routing protocol also needs to communicate that route to the user in an understandable way.  If the entrance is a street elevator, but the user is expecting to see a staircase, simply saying "Enter the station" may be ambiguous and confusing.  It would be much better if the directions could say "Take the elevator down to the station."  For this reason, I feel that it is important to keep entrance type as a field that can be easily specified along with the entrances, rather than burying it into some future complex internal pathway specification that is going to be a long time coming, and which most agencies will probably not use anyway.

In a future pathway spec, I suspect that the most natural way to represent this information is with a graph structure, where edges correspond to walkways which can be given a type such as "walkay," "stairs", "escalator" etc that are all linked together.  These edges would be linked to nodes, one of those nodes would be the entrance/exit node of the station, which means that if we store entrance type as part of the pathway structure, it would need to be looked up by the convoluted means of first searching for a pathway edge that connects to the specified entrance node, then getting the type of this edge...and that method might break down when there are multiple internal pathways leading to the same entrance that have different types.  Yet another reason why I feel that entrance type should be specified on the entrances themselves, before the pathway spec is here.

Stuart J, as you point out, the GTFS structure does look and relate like database tables.  Well, if it walks and talks like a Duck, maybe best to call it a Duck?  Honestly, I find that the typical relational database model is the simplest and most famiiliar structure.  When we start having multiple types of records stored in the same table, that's translated into additional complexity for both writing and reading the data.

You have noted that your organization already has put entrances in the stops table, and I understand your desire to have a convenient mapping to whatever the new format may be.  However, whatever the new format comes out to be, it's not going to be exactly what you had before (at least not for everybody), and when it comes down to it, it's easier to map into a simple relational model than to map into an ad-hoc non-relational model, even if it bears some similarity to your present system.

[Brian Ferris]

It's been a month since we last discussed entrances in GTFS. To
quickly summarize the conversation to this point, we have an existing
entrances proposal that's been around for a while that some agencies
and feed consumers are starting to use. Stuart H raised concerns that
entrances should not be specified in stops.txt because we'd
increasingly have a mismatch between the types of fields we'd like to
specify for stops and stations vs the fields we'd like to specify for
entrances.

I'll willing to admit that there are some potential advantages to
putting entrances in a separate file, but most of my reluctance boiled
down to the number of agencies already using the original proposal.
However, after some internal discussion, I'm willing to consider the
new proposal along with tackling the job of potentially helping to
convert existing feeds.

That said, I'm curious if anyone else is -1 on the proposed separate
entrances file. Stuart J? Anyone else?

Brian

> --
> You received this message because you are subscribed to the Google Groups
> "General Transit Feed Spec Changes" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/gtfs-changes/-/ju4hEAp9wnoJ.

>
> To post to this group, send email to gtfs-c...@googlegroups.com.
> To unsubscribe from this group, send email to

> gtfs-changes...@googlegroups.com.

[Stuart Heinrich]

My company couldn't afford to wait around for the spec to change so we've just gone ahead and started implementing internally the spec for entrances that I already suggested, and have augmented the feeds for a few cities with this information.  Some cities such as the NYC MTA do publish a separate file listing all the subway entrances, see here:

 

http://mta.info/developers/download.html 

https://nycopendata.socrata.com/Transportation/Subway-Entrances/drex-xx56

 

However because it is not part of the GTFS standard these entrances are not directly linked to GTFS stopID's.  We were however able to link them without too much trouble by using a combination of spatial distance, intelligent string matching of names and some manual review.

 

One of the complications that arises is the fact that multiple stations can be connected via underground walkways, which raises the question of whether or not the entrances of one station should be listed as entrances for another station if there is some underground pathway between them.  It seems best not to do this for routing reasons however it does highlight the fact that this approach is imperfect.

 

Given that agencies do usually have some documents detailing the internal walkways inside of stations I have started to doubt my initial argument that the protocol should first be amended to allow entrances before the internal pathway spec -- I'm starting to think that perhaps it's better to really hammer out a good standard for internal pathways + entrances that does it right.