zone-based fare improvement
David Turner
region) fare system, even ignoring peak and round-trip fares. I may
send a separate email about fare_attributes.txt which deals with
round-trip fares, and I see that there is already some discussion of
peak/off-peak fares elsewhere.
My apologies if I missed a prior discussion of this -- the Google Groups
search feature seems to be returning no results for a query of "zone".
The structure of the Regional Rail System is that all lines run into
Center City, so any trip between two stops on different lines must pass
through Center City. There are six concentric zones, and fares depend
not only on on starting and ending zone, but on whether those zones are
on the same line. So from zone 6 on the Paoli/Thorndale to zone 3 on
the R5 Paoli/Thorndale costs less than from zone 6 on the R5
Paoli/Thorndale to zone 3 on the R3 Media/Elwyn. While these trips can
be distinguished from each other by what zones they pass through, the
latter cannot be so distinguished from a trip that ends at Center City.
Here are some documents describing the various fares:
http://www.septa.com/fares/train_tickets_intermediate.html <-- this link
describes the case of fares on one line
http://www.septa.com/fares/train_tickets_viaCCP.html <-- and this one
describes the case of fares on different lines -- that is, trips that
pass through Center City
GTFS currently allows fares which depend on which zones a route passes
through -- but it does not allow a zone to be specified more than once
in an ordered list, which is what would be required to handle SEPTA. An
ordered list might require backwards-incompatible changes, so I have
another idea:
I propose that fare_rules.txt include an optional column same_route,
which is used to determine whether the a stop is treated as belonging to
the destination_id's zone for the purposes of a given fare rule. The
same_route column would have three possible values, true, false, and
any. A true value means that a destination stop is only considered to
belong to a given zone if it is part of the same route as the origin
stop. A false value means that a destination stop is only considered to
belong to a given zone if it is part of a different route as the origin
stop. A value of any means that route is not considered in determining
what zone a stop belongs to -- this is what GTFS currently does, and
would be the default.
So to implement SEPTA's fare system, here would be the lines from
fare_rules.txt for zone 1 to zone 1 trips:
fare_id,start_id,end_id,same_route
F1,1,1,true
F2,1,1,false
F1 would be $3 (according to the first link above), while F2 would be $5
(according to the second link above).
I guess you could define each station as its own zone, but this means
that instead of 42 fares rules, there would be one rule for each pair of
stations -- over 10,000 rules. I guess you could also do each pair of
zone-lines, but that is still over 3000 rules.
Joe Hughes
You mentioned making each station a zone as a possibility (which is
done in some feeds but has the combinatorial explosion problem you
mentioned). If you created a unique GTFS zone for each zone + line
combination, would that help you encode this situation with fewer zone
IDs?
Joe