odot-pts / gtfs-ride Goto Github PK

There is overlap in the rider_trip.transaction_type and rider_trip.fare_media fields. i.e. both list cash, transfer options (though slightly differently). If a traveler used a mobile payment "software flash pass" to make a transfer, then would transaction_type = 2 and fare_media = 4? It seems as though options 0, 1, 2 might be removed from transaction_type.

Quoting draft:

transaction_type	Optional	The transaction_type field indicates what entitled the customer to the trip.
		* 0 - customer paid cash/credit/debit.
		* 1 - customer used stored value or tokens.
		* 2 - customer used a transfer.
		* 3 - customer used a pass.
		* 4 - customer used a promotional coupon.
		* 5 - trip is a free trip.
		* 6 - customer was never charged the fare.
		* 7 - customer was charged a fare but did not pay.
		* 8 - Other.
fare_media	Optional	The fare_media field indicates what media was used to pay the fare.
		* 0 - Not applicable or unknown.
		* 1 - Cash.
		* 2 - Paper transfer, single-use paper ticket, or token.
		* 3 - Paper flash pass (visual inspection).
		* 4 - Software flash pass (visual inspection).
		* 5 - Proof-of-payment receipt
		* 6 - Magnetic strip card, agency-issued.
		* 7 - RFID or smart card, agency-issued
		* 8 - Magnetic strip card, open payment.
		* 9 - RFID or smart card, open payment

The load for the arriving bus is more useful to people at the stop than the load as it leaves the stop. Suggest replacing current_load with arriving_load.

In the spec, ridership.txt lists all of the GTFS identifiers (agency_id, route_id) are all listed as optional. If we don't have at least one of those fields filled in, is this useful?

So at the VTA our APCS are only on around 60% of the buses. Would it fit in this spec? Perhaps we create a board_alight file but not a ridership file?

The wiki links to https://groups.google.com/forum/#!forum/gtfs-ride-changes, but no group exists. The correct group is: https://groups.google.com/forum/#!forum/gtfs-ride

Current draft's definition of rider_trip.trip_id:

The trip_id field contains the ID of the trip associated with the unique rider, if this is known. If trip_id is empty, then the rider may have taken one of several trips, or several possible chains of trips, to travel between the origin and the destination.

"Origin-destination-transfer" (ODX) data is available from onboard passenger surveys, fare collection systems that require tap off, can be inferred in the case of "tap-on only" fare systems. It may also be available through mobile ticketing apps, though I am uncertain on this. It would be useful for GTFS-ride to be able to specify a rider trip across multiple vehicle trips.

One option:
Add a new file, ride_segment.txt (see issue #21) or rider_trip_segment.txt, which could associate rider trips to vehicle trips, i.e. with fields for rider_trip_id, trip_id (foreign key to trips.txt), boarding_stop_id, alighting_stop_id, etc.

bike boards/alights are ambiguous about whether the bike is inside or not. Suggest being specific.

rider_type and rider_type description could be synced with GTFS+ concepts (or another such approach to fare categories, as generally, it seems likely that rider types should map onto fare categories). Alternately they could map to something else like census designated categories.

More documentation and consideration of how this data should/would be managed, stored, and amended over the course of time would be useful.

• Should GTFS-ride consuming software be able to ingest multiple GTFS-ride feeds and show all data at the same time?
• Is the best practice to collect a growing feed representing all past calendars? Per service period? How does the management of a GTFS-ride feed link up with the ongoing history of a live GTFS feed, with merged calendars, edited calendars, etc.? If GTFS datasets are merged, IDs for calendars and trips may need to be changed.
• What are the implications for managing and publishing GTFS data? Should we have a way of differentiating between when a new dataset (aka feed version) corrects an error in previous data vs. describes an upcoming service change? For some thinking on this, see:
  • Elizabeth Sall's (@e-lo) presentation "Transit Network Version Control"
  • Matthew's (@ODOT-RPTD-mb) comments on GTFS feed start date and end date.

Problem statements

1. In our opinion, the rider_trip.txt file goes against the Mobility Data Privacy Principles of which Trillium is an endorsing organization. Specifically, it violates principles # 1, # 5, # 6, and in its current state is at risk of violating principles # 3 and # 7.
2. The use cases for this file are not apparent, and the ones I can think of do not justify the undo surveillance of riders’ travel patterns. In general, we would like to hear a case for this file’s inclusion that outweighs its privacy issues.
3. How feasible is it to implement this feature of the spec? How would alights be recorded? How would information about a rider (e.g. rider_type) be generated?
4. MDS has similar components that deal with the collection of rider trip data. These components have caused some very public controversy resulting in a blow to the spec’s reputation. There are valuable lessons to be learned from that history. For a discussion on rider trip data generated by GBFS and MDS and the surrounding privacy concerns, see this article.

Solutions considered

• (Recommended) Remove rider_trip.txt file from the spec altogether.
  • Pros
    • Solves all of the above problems.
    • Simplifies the spec.
    • Puts spec into a better position for adoption (removes the practical problem of implementing this file, less components to debate, less controversy)
    • rider_trips.txt is not currently in use, so there’s not much work lost if we were to remove it.
  • Cons
    • Would lose the ability for specific rider trip analysis (but as mentioned above, this is not necessarily desirable).
• (Also considered, but not recommended) Require a unique rider_id for both boarding and alighting, allow only board or alight for a single record, so start and end points of a single rider’s trip cannot be collected. This is similar to a solution regarding vehicle ids that GBFS implemented as a response to privacy concerns.
  • Pros
    • Retains the file while somewhat reducing the impact to rider privacy (would still include boarding and alighting info of a rider, but those data would be disconnected from one another)
  • Cons
    • Amount of data collected about riders is still superfluous.
    • While more difficult, still reasonably easy to re-identify a rider because there could still be matching fields between the parsed board and alight fields (e.g. rider_type, transaction_type, fare_media, etc.)
    • Would lose the ability for analysis of start-to-finish individual rider trips.
• (Also considered, but not recommended) Remove all of the alight fields, rename file to rider_boardings.txt
  • Pros
    • Retains the file while somewhat reducing the impact to rider privacy.
  • Cons
    • Amount of data collected about riders is still superfluous.
    • Would lose the ability for analysis of start-to-finish individual rider trips (would only show boarding information per rider).

Looking forward to discussing further!

Just a question: I stumbled upon this just now and was wondering if anyone is actively using this GTFS extension (looks like the repo hasn't been updated in a few years). Are there any sample datasets to play with? Can you give me a sense of the scale of adoption in the broader community?

Service_date in board_alight.txt could be changed to a required field as the trip_id alone is not sufficient to identify the date of travel.

Renaming rider_trip.txt to ride.txt may prevent people from confusing this data with vehicle trips.

An optional vehicle_id field could be added to trip_capacity.txt. This could be referenced by the GTFS-RT (real-time) feed.

Current draft:

* 0 - Entry contains complete ridership counts for the associated stop_id in the field(s) boardings and/or alightings as available.

Might "complete" be misleading or unnecessary? Might a count sometimes be provided which is technically incomplete? The current language appears to imply a standard of quality/accuracy.

@MobilityData (MobilityData.org) currently has a draft proposal to describe vehicle type characteristics. I am seeking to share this proposal with the GTFS-ride group.

GTFS-ride could reference these vehicle type characteristics instead of describing this in trip_capacity. Vehicles types could then be linked to trips or blocks.

Small change, but it seems appropriate to change the rider_trip.rider_id field name to ride_id. The field doesn't identify an individual rider, and GTFS-ride purports to provide anonymized data.

Since multiple versions of ridership data are often produced from the same time period [ various computing summary methods ] it might be useful to recommend or allow some sort of versioning or source.