google / google/transit

GTFS-Fares v2 Zone-based fares

Open
#344 7 comments 0 reactions 0 assignees View on GitHub
Discussion Period GTFS Schedule GTFS-Fares
Dominant language
No language data
Stars
1.1k
Forks
225
Avg merge
7d 17h
Merged PRs (30d)
3

Description

Hi everyone - we ([MobilityData](https://mobilitydata.org/)) are looking to add zone-based fares to GTFS as part of GTFS-Fares v2.

This requires the following changes:
- Add the field `contains_area_id` to `fare_leg_rules.txt`
- Add the field `greater_area_id` somewhere

Below is an example of how we envision the files and fields being used to describe zone-based fares.

**Step 1: Define Zones**

Consider a system with four zones; A, B, C, and D:
- A → B costs 3 CAD
- B → C costs 2 CAD
- C → D costs 1 CAD
- A → C (though B) costs 4.5 CAD
- A → D (though B and C) costs 5.5 CAD

Use `areas.txt` to create the fare zones:

`areas.txt`
| area_id | area_name |
|--|--|
| A | Area A |
| B | Area B |
| C | Area C |
| D | Area D |

**Step 2: Group zones**

Grouping zones is necessary to describe zone-based fares that cross more than three zones. The origin zone is listed under `from_area_id`, the destination zone is listed under `to_area_id`, and the zones in between are grouped and listed under `contains_area_id`. In the [original proposal](https://docs.google.com/document/d/19j-f-wZ5C_kYXmkLBye1g42U-kvfSVgYLkkG5oyBauY/edit#heading=h.mhjuwqk2h5r3), the file `stop_areas.txt` is used to to assign stops to areas and to group areas together using `greater_area_id`. However, this would probably get messy with three different layers being present in one file (stops, areas, and greater areas).

One option would be to have a new file to assign areas to greater areas:
| area_id | greater_area_id |
|--|--|
|B|areaBC|
|C|areaBC|

Another alternative would be to use the file `areas.txt` to assign areas to greater areas - the only downside to that is that an area cannot be assigned to more than one greater area.

**Step 3: Define fare legs**

Use `fare_leg_rules.txt` to define the cost of travel between the different zones:

| from_area_id | to_area_id | contains_area_id | fare_product_id
|--|--|--|--|
| A | B | | 3_dollar |
| B | C | | 2_dollar |
| C | D | | 1_dollar |
| A | C |B | 4.5_dollar |
| A | D |BC | 5.5_dollar |

Any thoughts on how this example models zone-based fares? Is this in line with the expectations of data consumers and data producers? We would also like to hear your suggestions around `greater_area_id`.

Please share your thoughts here so we can come up with a way to move forward with zone-based fares.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.