Aaron Antrim
`stops`.`stop_code` is a free text field for passenger-facing IDs. In most cases, `stop_code` needs to be unique in a dataset. (There may be some exceptions, for example, if stops within...
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...
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...
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...
Renaming **rider_trip.txt** to **ride.txt** may prevent people from confusing this data with vehicle trips.
rider_type and rider_type description could be synced with [GTFS+ concepts](https://www.transitwiki.org/TransitWiki/images/e/e7/GTFS+_Additional_Files_Format_Ver_1.7.pdf) (or another such approach to fare categories, as generally, it seems likely that rider types should map onto fare categories)....
@MobilityData ([MobilityData.org](http://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...