Implements the framework for distance based fare calculation

[skinkie]

We would like to implement distance based fares in OpenTripPlanner, so we can support the Dutch OV-chipkaart infrastructure.

[thatsmydoing]

Is this part of the GTFS standard or just an extension? Do you have a link to the spec?

[skinkie]

Its a part of the fares proposal:

https://docs.google.com/document/d/1mK3--o5g4-3cCXaqmch92U63JTwChh0L2VCmcDViIlM/edit#

[bdferris]

What is this field? It's not included in the original proposal. The "units_traveled" value mentioned in the spec doc is just a place-holder variable that refers to a computed value from the actual trip itinerary (distance traveled in km, zones, etc)

[skinkie]

Is your suggestion that shape_dist_traveled is used for this? Given that these things never line up with operator values, my interpretation was that you would give a origin_id and destination_id and mention the number of units_traveled. In such way it would be possible to unambigiously port a A/B matrix into GTFS.

[bdferris]

Well, the distance calculation depends on the distance_mode enum:

1 - per-km - distance values will be computed by computing the length of the shape between the two stops. shape_dist_taveled values will be ignored (since they are unit-less) but instead the distance between lat-lon points belonging to the shape will be computed directly. This is necessarily a bit approximate, but should hopefully give the rider a reasonably close value.
2 - per-zone - compute the number of zones traversed by an intinerary
3 - per-stop - compute the number of stops traversed by an itinerary

I'm not sure it makes sense to include a "units_traveled" for each pair of origin_id and destination_id values. If you are going to be including the entire stop-to-stop fare matrix in the GTFS, why would you need distance-based pricing at that point? You could just specify the price as a fare_attribute directly.

[skinkie]

This 'approximate' will not work for many agencies. Firstly because some do not even publish shapes, secondly because the shape distance is not used in fare calculation, thirdly rounding errors.

The main reason why we can't publish the price is because of a "startup cost" encoded in "price". The distance-based price is a surplus to that.

[bdferris]

Can you describe when "startup cost" is used? If I take a trip from A=>B, with a transfer, followed by B=>C, do I pay the startup cost for the entire trip or just the first leg?

[skinkie]

Considering that you are using the same fare system, only the first leg given that your transfer is, within the transfer_duration period.

In the current allows to describe linear relations with respect to distance traveled, but not degenerative relations. The latter (Dutch Railways) we did implement with a cross-product operation on all stops.

[bdferris]

In that case, I'd propose the following:

Introduce an additional "distance_mode" enum value:

4 - user-defined distance unit is used, as defined in fare_distances.txt

And introduce a separate fare_distances.txt file with fields:

from_zone_id, to_zone_id, distance_traveled

which would be used to define the A/B matrix of distances.

The main issue here is that I think of fare_rules.txt as defining rules for matching legs and itineraries, while distance_traveled is more of a property of a leg to be matched.

[koch-t]

We could also add the fare units traveled to stop_times.txt
It has less impact as it doesn't create an extra file and most consumers end up bundling trips inside patterns anyway.

[bdferris]

I had a similar thought. I've actually already written up something to that effect in the GTFS Fares doc. Were you thinking of using the shape_dist_traveled column? Or some new "fare_dist_traveled" column?

[koch-t]

New column. I'm filling the the shape_dist_traveled column as well, but i'm noticing a difference of about 20 meters between shape_dist_traveled and the column where i keep the sum of link-distance. The latter is the one we would like to use for fare calculation.

Benefits of a new column:
1 Enable per-trip distance differences. Think of a certain service that will take a detour on Sunday or on a special event (marathon,roadworks etc.).
2 shape_dist traveled refers to actual length, wouldn't surprise if there would be a fare system which is linear base on distance but where some sectors are longer than the actual distance.

[bdferris]

I've updated the proposal to reflect your feedback.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}