[GTFS-Flex] Remove referencing location.geojson ids in stop_areas.txt (formerly location_groups.txt)?

[westontrillium]

Two use cases that we have historically used to justify including areas.txt/stop_areas.txt in the Flex spec are:

1. Routes with a zone and stop(s) operating as a single pickup/drop-off service area
2. Routes with multiple zones acting as one contiguous service

areas.txt/stop_areas.txt is not needed to describe these two scenarios.

zone+stop(s)

Example: A service that allows travel within a single zone and travel from that zone to a single stop outside that zone. We can describe this by splitting up the scenarios in multiple trips, like so:

• trip1: from ZoneA (pickup 8:00-17:00…) to ZoneA (drop-off 8:00-17:00…)
• trip2: from ZoneA (pickup 8:00-17:00…) to stop1 (drop-off 8:00-17:00…)

multiple zones=one contiguous service.

Example: Bidirectional travel between two towns is allowed, and travel within each town is allowed. This can be described either with a MultiPolygon that contains all the zones:

• trip1: from Multi_Zone (pickup 8:00-17:00…) to Multi_Zone (drop-off 8:00-17:00…)
• trip2: from Multi_Zone (pickup 8:00-17:00…) to Multi_Zone (drop-off 8:00-17:00…)

or by describing each scenario with multiple trips for each specific town, like the example above:

• trip1: from ZoneA (pickup 8:00-17:00…) to ZoneA (drop-off 8:00-17:00…)
• trip2: from ZoneA (pickup 8:00-17:00…) to ZoneB (drop-off 8:00-17:00…)
• trip3: from ZoneB (pickup 8:00-17:00…) to ZoneB (drop-off 8:00-17:00…)
• trip4: from ZoneB (pickup 8:00-17:00…) to Zone A (drop-off 8:00-17:00…)

Given that these use cases can be covered without the use of areas/stop_areas, should we remove the ability to reference a polygon/multipolygon location.geojson id in stop_areas.txt?

Now before we say "why not just remove the inclusion of areas.txt/stop_areas.txt in Flex altogether?", there is actually a third use case that would still require a solution: Completely on-demand stops, or "point deviation"–routes with a collection of stops as the service area that a rider can be picked up/dropped off at in any order within a timeframe. This is currently covered with a stop_times.stop_id referencing an area_id containing multiple stops. I've posted another issue here to discuss this topic specifically, as the possible need for an alternative solution has recently been brought up and could have implications for the wider Flex architecture.

[isabelle-dr]

After a discussion with @tzujenchanmbd, I am closing this issue, it has been included in #433