Ambiguities in fare_rules.txt and fare_attributes.txt

[Brian Ferris]

The GTFS spec allows for some basic modelling of fares through the use of fare_rules.txt and fare_attributes.txt.  Though the spec offers some basic guidance and the Fare Examples page (http://code.google.com/p/googletransitdatafeed/wiki/FareExamples) shows a few typical uses of the spec, there are a few things that aren't explicitly stated in the spec.

For example, if multiple rules match in fare_rules.txt, which should be used?  For example, if you have a origin-destination rule and a route rule that both match a particular itinerary, which takes priority?

In the Google Transit tripplanner, if we find multiple matching fare rules, we tend to present the rule with the cheapest fare to the user.  However, some agencies have interpreted the spec differently, where they might specify a generic origin+destination fare rule with a base fare, and then specify additional origin+destination+route rules that would "override" the base fare.  Depending on how you interpret the spec, you might apply those overrides (use the most specific match?) or you might not (use the cheapest fare?).

Thoughts?

[David Turner]

On Tue, 2012-07-10 at 15:23 +0200, Brian Ferris wrote:

> In the Google Transit tripplanner, if we find multiple matching fare
> rules, we tend to present the rule with the cheapest fare to the
> user. However, some agencies have interpreted the spec differently,
> where they might specify a generic origin+destination fare rule with a
> base fare, and then specify additional origin+destination+route rules
> that would "override" the base fare. Depending on how you interpret
> the spec, you might apply those overrides (use the most specific
> match?) or you might not (use the cheapest fare?).
>
>
> Thoughts?

OTP also implements the cheapest-fare rule.

I'm not sure that it necessarily makes sense to be having this
conversation right now, because we don't yet have a full list of what
fare systems we want to support. Maybe it will turn out that we need
some completely different format to handle, for example, the Zurich
multiple-route rules.

So I think we should finish trying to understand the scope of the
problem before we try to nail down the existing spec.

[Brian Ferris]

I brought it up only because we I have been attempting to highlight places in the fare doc where we have a fare system that can't really be handled by the existing spec.  One of the edge cases we (Google) ran into in the past when modeling a fare system had to do with one of these ambiguities so I wanted to be a little clear why something might not be covered by the current spec.