Using stop_areas.txt instead of location_groups.txt

[omar-kabbani]

This issue relates to the GTFS-Flex proposal, and is opened following a series of roundtable discussion to resolve the outstanding issues with the proposal. These discussions were hosted by MobilityData and attended by various stakeholders within the GTFS community.

You can find the GTFS-Flex proposal here: https://github.com/MobilityData/gtfs-flex/blob/master/spec/reference.md

---

The files areas.txt and stop_areas.txt in the current spec serve the same purpose as location_groups.txt. To avoid duplication, stops and GeoJSON locations can be grouped using stop_areas.txt. A name can be assigned to the group using the file areas.txt.

Here’s an example:
Instead of this:

location_groups.txt

location_group_id	location_id	location_group_name
group1	stop1	Downtown
group1	stop2	Downtown
group1	zoneA	Downtown
group2	stop3	Suburbs
group2	stop4	Suburbs

We use this:

stop_areas.txt

area_id	stop_id
group1	stop1
group1	stop2
group1	zoneA
group2	stop3
group2	stop4

areas.txt

area_id	area_name
group1	Downtown
group2	Suburbs

[leonardehrenfried]

Having worked with both Flex V2 and Fares V2 I really like this idea.

[westontrillium]

This makes sense to reduce redundancy. Do we need to include areas.txt in the change? I do not think a "location group" needs a name.

[westontrillium]

Quick note that if we keep the location id primary key in locations.geojson (see my thoughts on the proposal to change this here), we will need to amend stop_areas.txt to allow reference to locations.geojson.id.

[tsherlockcraig]

+1

[e-lo]

LGTM

[NomeQ]

@westontrillium as much as I like simplicity and it feels nice to make the change as lightweight as possible, I think there are good cases for keeping location_group_name (or, area_name).

Some agencies might find it very useful, especially those building tools on top of the GTFS. Some possible examples I can think of include using the GTFS in website tools, and wanting to create consistent rider-facing information, e.g. if there is a fare table for different fares/different zones, and wanting to show those zones on a map with labels consistent with other materials.

Otherwise, I think moving fields into areas.txt and stop_areas.txt makes a lot of sense. The only part I'm wary of (which is a producer issue, and not really a good factor for guiding design) is that as it is, using location_groups.txt as a separate file helps enable sort of Frankenstein feeds where flex v2 and fares v2 data are cobbled onto an existing feed ad-hoc. Again, this isn't a reason to avoid good design—just a note for producers to think about in terms of production pipelines as they currently exist.

[omar-kabbani]

I agree with @NomeQ on keeping a rider-facing name if agencies want to use the field. areas.txt is where data producers can optionally provide an area name.
+1 I do not think having fare areas and flex areas in the same file should be an issue.

[tzujenchanmbd]

Closing this issue because of the consensus in the previous comments, and the subsequent commit to the proposal has been done by @westontrillium at this PR.

We can reopen this issue if there is any concern during adoption process later.

(MobilityData has opened issue#382 to cover the service discovery of GTFS-Flex)