proposal: add preferred transfer points
Mike Gilligan
points.
Example:
route_id,direction_id,stop_id,transfer_route_id,transfer_direction_id,
transfer_stop_id
117,0,6850,70,1,6849
Both direction_id and transfer_direction_id would be optional.
-Mike Gilligan
TriMet
Joe Hughes
Thanks for posting this. As I mentioned before, the Google Transit
team has been experimenting with preferred transfer points as a way to
improve the routing results in some circumstances, so we're happy that
you already have some data along these lines.
I'm curious about the cases that led you to incorporate route IDs and
direction IDs into your preferred transfers. At first blush, it would
seem like a pair of stop IDs would be sufficient to express most
cases. Could you give some examples to help clarify this?
Joe Hughes
Google Transit
Mike Gilligan
I am going to attempt to describe the problem with stop pairs (hard
without a map/diagram).
Route A and Route B travel on Street 1 serving the same stops. Route A
continues on Street 1 but Route B turns onto Street 2, also served by
Route C. The last shared stop on Street 1 is the transfer point from
Route A to Route C, but it is not the preferred transfer for Route B.
The first shared stop on Street 2 is the preferred transfer from Route
B to Route C.
I know this is confusing but I can't think of a better way to describe
it. I could post a schematic to "Files", if you would like.
-Mike
Mike Gilligan
Devin Braun
Hi Joe,
Some of our trip plans are also experiencing transfer time issues. We
have a guaranteed transfer between two of our trolley lines at the Old
Town Transit Center (between Green and Blue), but GT won't give the
guaranteed transfer we prefer, instead giving the next departure and a
long wait. Here is an example:
http://tinyurl.com/3x6d56 (option 3)
The passenger is told to wait 20 minutes for the next train, but the
next train departs in just 5 minutes directly across the platform.
I'm guessing this is due to walking directions because the trip
planner will give a transfer to Route 44 within 5 minutes, like in
this trip plan:
http://tinyurl.com/2lotto (options 1 and 3)
I'd be glad to make any changes or additions to our feed to fix this
issue.
Thanks!
Devin Braun
San Diego MTS
On Jul 29, 3:43 pm, "Joe Hughes" <joe.hughes.c...@gmail.com> wrote:
> Hi Mike,
>
> Thanks for posting this. As I mentioned before, the Google Transit
> team has been experimenting with preferred transfer points as a way to
> improve the routing results in some circumstances, so we're happy that
> you already have some data along these lines.
>
> I'm curious about the cases that led you to incorporate route IDs and
> direction IDs into your preferred transfers. At first blush, it would
> seem like a pair of stop IDs would be sufficient to express most
> cases. Could you give some examples to help clarify this?
>
> Joe Hughes
> Google Transit
>
> On 7/23/07, Mike Gilligan <Gilli...@trimet.org> wrote:
>
>
>
>
>
> > Add an optional file to the feed spec to define preferred transfer
> > points.
>
> > Example:
>
> > route_id,direction_id,stop_id,transfer_route_id,transfer_direction_id,
> > transfer_stop_id
> > 117,0,6850,70,1,6849
>
> > Both direction_id and transfer_direction_id would be optional.
>
> > -Mike Gilligan
> > TriMet- Hide quoted text -
>
> - Show quoted text -
Joe Hughes
Thanks for the concrete examples; we definitely need to be able to
represent timed transfers like these in GTFS. Are there any other MTS
routes that have guaranteed transfers, or are green --> blue and blue
--> green at Old Town Transit Center the only ones?
Do you think Mike Gilligan's proposed format would allow you to
express the transfers?
Joe
Devin Braun
I think that Mike's specification works for preferred transfer points,
but there needs to be a way to specify the minimum transfer time at a
location. To simplify transfer time at a station, a possibility would
be to refer to stations listed in the stops.txt file format proposal:
stops.txt
stop_id, stop_name, stop_lat, stop_lon, location_type, parent_station
1, Old Town Transit Center Platform 1, 37.752240, -122.418450,0,3
2, Old Town Transit Center Platform 2, 37.752240, -122.418450,0,3
3, Old Town Transit Center, 37.752240, -122.418450,1,
4,La Jolla Village Dr / Genesee Av,32.8726453969,-117.214512545,
5,Genesee Av / La Jolla Village Dr,32.872043111,-117.214206296,
6,UTC Transit Center,32.8702936108,-117.21227529,
transfers.txt
from_stop_id,to_stop_id,from_route_id,to_route_id,transfer_type,min_transfer_time,service_id
3,3,510,530,1,,
3,3,530,510,1,,
3,3,510,44,2,120,
4,5,921,960,3,,
5,4,960,921,3,,
6,6,921,960,0,,
6,6,960,921,0,,
from_stop_id / to_stop_id
required - can be the stop_id of a stop (location type 0) or of a
station in which case all stops at the station are taken into account
unless a specific pair of station stops are defined in the file
from_route_id / to_route_id
required - if blank, all routes at the stop/station follow the
transfer guideline
transfer_type (required)
0 or blank preferred transfer point between two routes
1 guaranteed transfer point (head-on transfers allowed)
2 minimum time required for transfers
3 forbid transfers between two routes at this location
min_transfer_time
required only if transfer_type is 2, specified in seconds
service_id
optional-if blank, applies to all service periods
The different types of transfers could help the algorithm decide which
stop is best to provide a transfer when two routes share several
stops. The route_direction fields could also be added to further help
specify transfers, but I agree that they should be optional.
Devin
On Oct 3, 5:54 pm, "Joe Hughes" <joe.hughes.c...@gmail.com> wrote:
> Hi Devin,
>
> Thanks for the concrete examples; we definitely need to be able to
> represent timed transfers like these in GTFS. Are there any other MTS
> routes that have guaranteed transfers, or are green --> blue and blue
> --> green at Old Town Transit Center the only ones?
>
> Do you think Mike Gilligan's proposed format would allow you to
> express the transfers?
>
> Joe
>
> On Oct 3, 2007 3:49 PM, Devin Braun <devin.br...@sdmts.com> wrote:
>
>
>
> > Some of our trip plans are also experiencing transfer time issues. We
> > have a guaranteed transfer between two of our trolley lines at the Old
> > Town Transit Center (between Green and Blue), but GT won't give the
> > guaranteed transfer we prefer, instead giving the next departure and a
> > long wait. Here is an example:
>
> >http://tinyurl.com/3x6d56(option 3)
>
> > The passenger is told to wait 20 minutes for the next train, but the
> > next train departs in just 5 minutes directly across the platform.
> > I'm guessing this is due to walking directions because the trip
> > planner will give a transfer to Route 44 within 5 minutes, like in
> > this trip plan:
>
> >http://tinyurl.com/2lotto(options 1 and 3)
Joe Hughes
Nice work, I think that your modifications below make a good proposal
even stronger. A couple questions for Mike and the rest of the group:
1) Would it be useful to allow you to (optionally) express individual
trips for guaranteed transfers? I'm thinking of the way that the MBTA
holds the last Red Line train of the night for connecting Green Line
trains, for instance.
2) Would the omission of direction in the transfer rules (see Mike's
original proposal) prevent you from expressing some of the transfers
that you'd like to encode?
Joe
Mike Gilligan
meets" are scheduled 5-7 minutes apart and we have not noticed
transfer problems in Google Transit or our trip planning software.
2) At TriMet, we would be misrepresenting 42 transfer points with the
omission of direction. See my comment above from August 3rd.
On Oct 4, 9:23 am, "Joe Hughes" <joe.hughes.c...@gmail.com> wrote:
> Hi Devin,
>
> Nice work, I think that your modifications below make a good proposal
> even stronger. A couple questions for Mike and the rest of the group:
>
> 1) Would it be useful to allow you to (optionally) express individual
> trips for guaranteed transfers? I'm thinking of the way that the MBTA
> holds the last Red Line train of the night for connecting Green Line
> trains, for instance.
>
> 2) Would the omission of direction in the transfer rules (see Mike's
> original proposal) prevent you from expressing some of the transfers
> that you'd like to encode?
>
> Joe
>
> > > >http://tinyurl.com/2lotto(options1 and 3)
Devin Braun
> trips for guaranteed transfers? I'm thinking of the way that the MBTA
> holds the last Red Line train of the night for connecting Green Line
> trains, for instance.
1) MTS does have some trips where routes are held for a guaranteed
transfer with a "wait note." They are almost always the last trip of
the night for one or both of the routes. I can see this kind of
feature being useful.
>
> 2) Would the omission of direction in the transfer rules (see Mike's
> original proposal) prevent you from expressing some of the transfers
> that you'd like to encode?
2) We would require the direction field in the specification for
routes that use the same stop in both directions, but where we only
schedule a transfer for the "peak direction" of connecting routes.
All other possible transfers would be by scheduling coincidence.
--Devin
Devin Braun
On weekends and holidays, many frequencies are reduced and we schedule
accordingly for better transfers as opposed to weekdays - that's why I
proposed including the service type. However, we could get away with
specifying transfers without the service type as long as the
trip-specific transfers are included.
Devin
-----Original Message-----
From: Joe Hughes [mailto:joe.hug...@gmail.com]
Sent: Monday, October 08, 2007 11:57 AM
To: Devin Braun
Subject: Re: proposal: add preferred transfer points
On Oct 5, 1:24 pm, Devin Braun <devin.br...@sdmts.com> wrote:
> > 2) Would the omission of direction in the transfer rules (see Mike's
> > original proposal) prevent you from expressing some of the transfers
> > that you'd like to encode?
>
> 2) We would require the direction field in the specification for
> routes that use the same stop in both directions, but where we only
> schedule a transfer for the "peak direction" of connecting routes.
> All other possible transfers would be by scheduling coincidence.
Good point. It's kind of tricky because direction is an optional field
for trips, but we should define an interpretation of this format in the
cases where there are no directions in the data. For simplicity's sake,
I would be inclined to make the timed transfer apply to all instances of
those routes through that stop unless direction (or specific trip)
information is provided.
Another question: would your data use the schedule_id field that you
proposed? Does anyone else in the group have timed transfers that are
present in some service types (i.e. weekday) but not others?
Joe
Jordan Hess
I'm jumping in the conversation a little late, but I wanted to mention
that the transfers.txt will serve our transfer needs quite well. Our
primary concerns are being able to:
1. Permit or disallow transfers on a stop by stop basis,
2. Guarantee head-on transfers without a window of time
Our system is a smaller pulse system with routes that converge on a
downtown transfer center. I will be submitting our data for preview
later this week, and I'd be happy to submit the transfers.txt file if
it would be of use.
Thanks,
Jordan Hess
> > >http://tinyurl.com/2lotto(options1 and 3)
Joe Hughes
seeing how you would use a transfers.txt file to represent your
system.
Joe
Joe Hughes
this proposal, as detailed below. A few questions:
1. The to_route field is proving tricky to integrate into the current
Google Maps routing cost model. Would its absence significantly
hamper your ability to express the transfers that you want to encode?
2. Which information are you more likely to be able to provide in a
feed: the time that it takes for a rider to get between two stops for
a transfer, or the exact distance between those two stops (including
stairs, escalators, and elevators) in meters?
Thanks,
Joe Hughes
Google
Devin Braun
If I may comment on my own proposal...
1) The routes might not need to be specified if their stops are
specified. Here at MTS, we'd probably only specify minimum transfer
times for a stop/station. For our in-house trip planner, we are
currently only specifying a system-wide minimum transfer time, however,
it is able to take into account walking times along paths within the
station.
2) It is important to specify the time required for transfering at a
location since this is frankly how we schedule. But, if the cost model
takes into account the walking distance and therefore time from one stop
to another and this distance can be specified, it should be sufficient
to specify the meter distance. However, we are _most likely_ to provide
the times.
Devin Braun
San Diego MTS
Chris Harrelson
From what I can see, the most important information that an agency
needs to be able to express is the minimum time between the arrival of
a trip at stop A and
the departure of a connecting trip at stop B. For this reason, the
following interpretation of min_transfer_time is proposed, which will
remove the need to specify distance or time between stops explicitly:
min_transfer_time = estimated_walking_time + safety_buffer
Here estimated_walking_time is Google Transit's (or some other
application's) estimate of how long it takes to walk, and
safety_buffer captures the notion of an amount of padding needed in
order to make the transfer reliable. This allows agencies to provide
the primary benefit - improving reliability and efficiency of
transfers - without having to obtain detailed information about
estimated transfer times or distances. I believe this is what Devin
was getting at as well?
Roger Slevin
Can I reflect on the practice within the data I am responsible for within
traveline south east (Great Britain)?
First, all potential interchange locations need to be defined - we do that
either explicitly (relatively rarely - generally only to deal with unusual
circumstances) or implicitly. The implicit interchange is created by
looking at the proximity of stops and their "commonnames" - stops with the
same commonname that are up to 150m apart are considered to be a potential
interchange - and if there are more than two such stops, the overall span of
the implicit interchange will include all those other stops that are within
an overall span of 250m. So we don't hold the definition of most
interchange locations as raw data in our system - these are created on the
fly when the data is built each week. And that, therefore, will severely
restrict our ability to supply such information to Google.
Whether or not the interchange is created explicitly or implicitly, we give
a flat default interchange time of 5 mins (with only rare exceptions) within
every interchange for all BUS services ... and this combines the two
separate elements that you are proposing to use within the GTFS spec. We
only add walk links if there is an explicit interchange allowed between
stops which are outside the span of a normal interchange. However, some BUS
stops are also used by long-distance COACH services - and we have to allow a
longer margin for interchange to and from COACHES ... with a default of
10mins (but with many having a location-specific value that can be
significantly higher, and with many having a prohibitive setting of 999
mins).
I suggest that each data supplier should have explicit control of the
default value for the interchange "safety buffer" used with his data [I
don't think we even know what this is set at within the GT transit planner
right now, do we?] - which can then be over-ridden by a location-specific
value where necessary. The addition of walk times between stops within an
interchange should also have a default value (which in our case we would set
to 0 mins) but again should be capable of being over-written by a
location-specific value where needed. However I should note that at most
locations we do not hold walk times as data as the value is created on the
fly, based on the airline distance between the two stops involved.
That would still leave us needing to find a way of specifying how these
values can be changed for specific types of service - and how we can
transform that information from a location-specific value which we have at
present to a service-related value which is proposed for GTDF. That may not
be easy to achieve - bearing in mind that the different values will apply to
all arrivals and departures of specified service(s) at a given stop. Right
now, of course, Google-generated itineraries can be unrealistic in offering
connections for these services which are too tight - so the facility to
change the connection times by service in the data would be helpful, as long
as it can be applied to both arrivals and departures of those specified
services at specified stops. What we could not do is to create a list of
stop-to-stop service-to-service interchange times - the range of stop and
service combinations involved could run into significant numbers at some
locations.
I hope this gives a little insight into the complexities of this in a region
with a very large and complex network of routes in which interchange is an
important feature - but which needs careful handling.
In the above I have made no reference to other modes - but interchange
penalties associated with changing between trains at rail stations in
Britain are specified by the rail industry, almost always as a single value
that is location specific (and again there is a national default of 5 mins
that applies to a large number of stations). Connections between a rail
station and adjacent bus stops, however, have to be defined locally - and
these would be one of the cases where a walk time is added in the
calculation (that walk time being based on the airline distance between
station and bus stop).
With best wishes
Roger Slevin
Traveline south east
Hi all,
--
This email has been verified as Virus free.
Virus Protection and more available at http://www.plus.net
Joe Hughes
Thanks for providing additional context. The transfers.txt proposals
here aren't intended to enumerate every possible transfer/interchange;
as you say, most can be easily determined in real time based on the
geographic distance between stops. Explicit transfer declarations
will help when you have timed/guaranteed transfers, special
connections between stops, and the like.
You raise an interesting point about specifying a different time
buffer for connections between different route types (local bus and
long-distance coach, for instance). Am I right in thinking that you'd
want his because the coaches are less likely to adhere to schedule
over the longer distances that they cover?
Joe
Roger Slevin
Thanks - and apologies if I had lost the context of the discussions, which
appear to have started a long time ago. I hope my contribution, though, is
useful to set the situation in context, given the challenge that we have to
handle with 300+ operators and extensive geographical coverage just within
the traveline south east region of Great Britain.
The main reason for the greater margin required for coaches is indeed
because they can be subject to quite significant variations from schedule as
a result of traffic incidents en route. Many are also infrequent (sometimes
just one a day) operations - and therefore the main operator seeks to take
care that passengers don't miss connections ... so they only allow
connections at supervised locations (hence the 999 at other points) and they
build in realistic but generous allowances for interchanges where they are
permitted.
The secondary reason for having a default value of 10 rather than 5 mins for
coach is that they are not appropriate for short-distance journeys - and we
therefore need to have a penalty which suppresses the use of coach for such
journeys, making more local services the better option in such situations.
We also use pick up and set down restrictions where they are relevant - but
that is not always possible - hence the "boarding/alighting" penalty, which
then ties in with the relative uncertainty of departure and arrival times
for these coach services.
Best wishes
Roger
Devin Braun
Could you clarify something for me?
If an agency specifies a min_transfer_time at a station of 5 minutes,
and Google Transit calculates a 4 minute walking time plus a 2 minute
buffer, the transfer won't be given. Will the agency be able to specify
that 5 minutes is actually the time needed at the station and override
the formula? In other words, no matter what, a transfer from Route A to
Route B at a station is guaranteed if the arrival of Route A is within 5
minutes of the departure of Route B?
Thanks,
Devin
-----Original Message-----
From: gtfs-c...@googlegroups.com
[mailto:gtfs-c...@googlegroups.com] On Behalf Of Chris Harrelson
Sent: Tuesday, February 12, 2008 11:31 AM
To: Google Transit Feed Spec Changes
Subject: [gtfs-changes] Re: proposal: add preferred transfer points
marc.f...@trapezegroup.com
Transfers.txt should include a way of specifying the minutes bias the
buffer or to specify the absolute transfer time. Depending on the
specifics of the individual transfer you may need to negate the buffer
or add to the buffer. In most cases in San Diego and Portland the
transfer is "at grade" so you could just walk across the tracks.
In other cases, NY or DC for example, you may have to go up and over
to get to the other platform. There may be examples in other cases
where you have to climb stairs or walk from the tracks to the street,
the linear distance doesn't match the real amount of walking.
I would "second" Devin's proposed format for transfers.txt
from_stop_id,to_stop_id,from_route_id,to_route_id,transfer_type,min_transfer_time,service_id
How transfer_type gets used will depend on what you want transfers.txt
to do. If it is meant to provide GT with hints in the generation of
transfers then the various codes seem sufficient. If you want GT to
apply the same rules as the existing trip planner, then the
Transfers.txt file becomes a list of only the transfers to use.
Joe Hughes
implementation of Devin's transfer proposal, and I thought the answers
would be of use to this discussion:
On Wed, Mar 12, 2008 at 4:19 PM, Tom Hixson <THI...@sacrt.com> wrote:
>
> Transfers: How is 'Guaranteed' different from type 2 (Minimum Time) with 0
> minutes? Can Min Time be negative?
In the current Google Maps implementation of this proposal, a route
with a zero-minute minimum-time transfer (type 2) would get penalized
more than a route with a guaranteed/timed transfer (type 1), when
ranking them to determine which routes are offered to the user. As I
understand the proposal, a guaranteed/timed transfer is supposed to
signify that the departing vehicle will wait for the arriving vehicle,
so there's no uncertainty for the rider about whether they'll miss the
connection.
I wouldn't recommend using a negative minimum time; I'm not sure what
that would mean as the proposal is written.
Joe
Marc Ferguson
There are some other permutations of transfers that may need to be considered.
1) large, multi level, structures where the time required to transfer between platforms exceeds the buffer and any walking distance calculated by the difference in "coordinates." Subway stations in NY are a good example. Also, transfers from rail stations, i.e. NY Penn Station, Newark Penn Station, Boston's North Station all require several minutes of walking to get from the rail platform to the subway or bus stops. The general case is any situation where more time is required between routes for the passenger to get from the drop off stop to the boarding stop.
2) The opposite situation where you might want to offset the walking distance and/or the buffer time because of the timing of the vehicles. This is not a guaranteed/timed transfer.
3) Interlined routes. This is a "stay in your seat" transfer when the vehicle changes it's schedule route but the passenger can stay put.
Depending on where the transfer data is coming from the data might be recommendations for transfers or they could be the only transfers to be used. In the case of data coming from a site which uses Trapeze's ATIS as the trip planner, the transfer data provided would be the only transfers to consider.
Marc
| "Joe Hughes"
<joe.hug...@gmail.com>
Sent by: gtfs-c...@googlegroups.com 03/13/2008 12:33 AM
|
|
|
Tom Hixson
Joe Hughes
On Thu, Mar 13, 2008 at 10:42 AM, Marc Ferguson
<Marc.F...@trapezegroup.com> wrote:
>
> There are some other permutations of transfers that may need to be
> considered.
>
> 1) large, multi level, structures where the time required to transfer
> between platforms exceeds the buffer and any walking distance calculated by
> the difference in "coordinates." Subway stations in NY are a good
> example. Also, transfers from rail stations, i.e. NY Penn Station, Newark
> Penn Station, Boston's North Station all require several minutes of walking
> to get from the rail platform to the subway or bus stops. The general case
> is any situation where more time is required between routes for the
> passenger to get from the drop off stop to the boarding stop.
>
> 2) The opposite situation where you might want to offset the walking
> distance and/or the buffer time because of the timing of the vehicles.
> This is not a guaranteed/timed transfer.
It seems like both of these could be expressed in type #2 of Devin's
proposal (minimum time required for transfer). Can you tell me more
about why Devin's "min_transfer_time" field might not be sufficient
here?
> 3) Interlined routes. This is a "stay in your seat" transfer when the
> vehicle changes it's schedule route but the passenger can stay put.
This is already expressible in GTFS using block transfers (via
matching block_id in trips.txt). For example, see this route in
Portland:
http://tinyurl.com/yp2y5l
Halfway through, the logical route changes from 17 - Holgate to 17 -
NW 21st Ave/St Helens Rd (to TriMet and its riders, those are two
separate routes). Google Maps advises the rider of the change but
says that they should "(stay on board)". Is this what you were
referring to?
Joe
Tom Hixson
-Tom
>>> Marc Ferguson <Marc.F...@trapezegroup.com> 03/13/2008 10:42 AM >>>
Marc Ferguson
I can't disagree with Tom about transfers being a pain to maintain. On the other hand, we have some agencies that are very, very picky about their transfers so we have had to provide the capability. It would seem that the pickiness is inversely proportional to the size of the agency.
The min_transfer_time does apply to cases 1) & 2) provided that min_transfer_time is what will be used in place of the "buffer" time used by the Google algorithm.
As for interlining, there may be situations where the route interlines but "continues" message is not desired. I can't think of a good example of this.
Marc
| "Joe Hughes"
<joe.hug...@gmail.com>
Sent by: gtfs-c...@googlegroups.com |
03/13/2008 02:36 PM
|
|
|
Tom Hixson
Marc Ferguson
The situations you describe is why there should be a way of indicating that a particular transfer is a S-I-S/interline transfer. There are a number of agencies where S-I-S transfers are "free." There are also cases where the customer has no choice but to wait at the layover because the bus is making a "one way" loop through an area. In these cases the layover is fairly short +/- 5 minutes.
| "Tom Hixson"
<THI...@sacrt.com>
Sent by: gtfs-c...@googlegroups.com 03/13/2008 06:26 PM
|
|