[GTFS Fares v2] Area Set matching predicates.

[bdferris-v2]

Add support for matching "sets" of areas in fare_leg_rules.txt per this proposal.

[tzujenchanmbd]

For the intermediate stops, it seems they must be stops defined in stop_times rather than "geographical pass-through" stops. Could the current description cause misunderstandings? Would it be clearer to state this explicitly?

[bdferris-v2]

I attempted to add explicit language. Let me know what you think.

[tzujenchanmbd]

Looks good to me!

Just to confirm:

and intermediate stops as referenced by the trip's stop-time entries; belongs to the specified area as defined by [stop_areas.txt]

This means that entries will be included regardless of their pickup_type and drop_off_type values (e.g., value=1 - No pickup/drop_off available). Is this correct?

[bdferris-v2]

Yes, I suppose that's correct.

I think we discussed this briefly in the last meeting, yes? I think it's reasonable to make the default the simple case (passes through a stop).

[tzujenchanmbd]

Yes, got it. Just want to confirm if I correctly understand the semantics here (i.e. regardless of the pickup_type and drop_off_type values).

[halbertram]

Whilst we are far along in this proposal, I recently had the following thought. It may be overly pedantic (and doesn't come with a proposed solution), but it might be worth discussing.

There seems to be a bit of a variation between how eg areas are formed from stops, and how area sets are formed from areas.

Stops and areas / Routes and networks

• <element>s.txt – element data
• <collection>s.txt – collection data such as name
• <element>_<collection>s.txt – insertion into collection

Areas and area sets

area_sets.txt defines the collections and the insertion. It's not clear where any fields that an area set might gain down the line would go.

If we view the collection as 'set', then it does partially follow the above scheme, but that will cause issues once we have network sets, and sets.txt would be ambiguous.

However having area_sets.txt and area_area_sets.txt doesn't seem sensible. We could find a name for an area set (in the way that we call a 'stop set' an area), possibly 'region' – but may be hard to find a word that would be appropriate in all uses of area sets. (Also would eventually have to find one for the corresponding network and trip_group cases). Or further area set level fields could go in area_set_details.txt.

[tzujenchanmbd]

It seems reasonable to separate collections and insertions into collections into two files, which is consistent with the existing three cases (networks.txt + route_networks.txt, areas.txt + stop_areas.txt, location_groups.txt + location_group_stops.txt), and it seems like a normalized relational model.

[bdferris-v2]

Did we talk about this briefly in the Fares v2 meeting last week? Or did I just imagine talking about this? :)

Agreed that the naming is awkward here. A couple options:

1. We just keep area_sets.txt as-is. It's not clear what properties of an area set that we'd actually add (beyond a name?) and if we did need to add something after the fact, then I agree that area_set_properties.txt or area_set_details.txt could possibly work.
2. That said, I do acknowledge that this does deviate slightly from the pattern. If we really wanted to stick to the pattern, then I guess I'd actually suggest area_set_areas.txt for the collection file to map an area to an area set. A little clearer on what it means than area_area_sets.txt I think? But if we went with this option, would we want to then make area_sets.txt the element file now (and require an entry for each area set), even if we don't have meaningful fields to associate with it?

[tzujenchanmbd]

I assume an area_set can be a collection that contains multiple areas. A unique ID doesn’t seem suitable for mapping area to area_set?

[tzujenchanmbd]

Last week I mentioned that Hal raised this question, but it seems we didn’t dive into the discussion. :)

Currently, all similar files (e.g., areas.txt, networks.txt) only include a unique ID field and a name field. We could probably follow this pattern for now? and if additional properties are needed in the future, they can be added directly to the file.

Regarding naming, area_set_areas.txt does seem clearer than area_area_sets.txt to me.

How does this look?

area_set_areas.txt: The file maps area to area set, with the following fields:

• area_set_id (foreign ID referencing area_sets.area_set_id, required)
• area_id (foreign ID referencing areas.area_id, required)

area_sets.txt: The file defining area sets, with the following fields:

• area_set_id (unique ID, required)
• area_set_name (optional)