Consider incorporating TNCs/Ride-hail services

[sdrewc]

Given that TNCs are typically considered to be part of a "mobility-as-a-service" package, and currently the most impactful, they seem like a natural extension to this data standard. The key changes would be to add 'automobile' as a vehicle_type, and to create an out-of-service API analogous to the trip API. Or even more simply, a field for 'in-service' or 'out-of-service'.

[migurski]

This is a great idea, 👍 to vehicle_type=automobile. One wrinkle would be the device ID: it doesn’t identify any person for a scooter, but TNC vehicles are privately owned cars with drivers who have an expectation of privacy. The device_id should be optional in this case.

[hunterowens]

I'm going to try and assemble a draft PR for this today.

One question I am struggling with - how to represent shared trips, ie, when the trip has more than one passenger.

[migurski]

I spoke with Stephanie Dock from DDOT about this on Wednesday and she helped me see that shared trips represent a big change to the MDS trip data model. Maybe MDS should set TNCs aside for the moment to ensure that it’s successful for single-occupant micromobility devices?

[hunterowens]

Yeah. My thought would be to have each mode have its own directory in provider, as such, in provider.

├── auth.md
├── micromobility
│   ├── README.md
│   ├── status_changes.json
│   └── trips.json
└── tnc
    └── README.md

We could then use the common datatypes from JSONSchema in generate_schema to share datatypes, enums, etc.

[chursaner]

I like that. In the future, we could also have directories for goods_delivery, air... I'd suggest using simply "vehicle" above "tnc" to encompass taxis, limos, tncs, as well as private vehicles if there were to be an incentive or reason for individuals to share data via MDS. I think we need to be careful not to create a sense that shared mobility has all these requirements that you are immune to if you own your vehicle-- small differences in language can make a big difference in how people weigh the decision of owning a car.

├── auth.md
├── micromobility
│ ├ README.md
│ ├ status_changes.json
│ ├ trips.json
├── vehicle
│ ├ README.md
│ ├ trips.json

[chursaner]

@hunterowens Drafted vehicle trips on my fork here https://github.com/chursaner/mobility-data-specification/blob/0.2.x/provider/vehicle/trips.json . I can add it as a pull request once you reorganize the directory!

A few differences from micromobility-

1. Vehicle type is a combination of vehicle type and propulsion type - includes things like automobile, taxi, carshare, electric; allows multiple values
2. New field for occupancy that has values "single", "shared" and "high". The spec defines high as >4 passengers- this is something that individual agencies will decide on
3. Allow vehicle ID to be null (ie optional)

[chursaner]

Would the Accuracy field still be applicable? Also need to switch time to be in minutes rather than seconds, though I wonder if that's something we could calculate on the back end using start and end time rather than ask for the information from the provider

[sdrewc]

@migurski "TNC vehicles are privately owned cars with drivers who have an expectation of privacy. The device_id should be optional in this case."
The vehicles are privately owned, but they're providing a commercial service. Taxi medallions and vehicles may also be privately owned, but don't have a similar presumption, and in fact often report both the vehicle and driver. Definitely IDs should be anonymized, but there is analytical value in being able to link trips since research shows there is almost as much deadhead VMT as in-service VMT.

[sdrewc]

@chursaner "I'd suggest using simply "vehicle" above "tnc" to encompass taxis, limos, tncs, as well as private vehicles if there were to be an incentive or reason for individuals to share data via MDS."
I don't think it makes sense to include private vehicles in the same category as for-hire vehicles for a few reasons:

1. for-hire vehicles are providing a service and necessarily have different operating profile. Mixing these with regular cars would confuse any potential analysis.
2. private vehicles aren't a mobility service, as I understand the term
3. individuals are unlikely to be contributing their data. When a mobility service provider reports its data, it's descriptive of the "universe" of activity, while individuals would be a sample with unknown bias.
4. I think that soliciting data from private individuals not engaged in a commercial activity is potentially fraught.

[sdrewc]

@chursaner thanks for adding occupancy! Why not simply ask for the number of passengers instead of a categorical?

[schnuerle]

FYI we are looking at creating a group of community members which will look at the possibility of this, either as part of MDS or elsewhere under the OMF, and try to get some more voices and use cases currently in use from cities.

[alexdemisch]

SFMTA staff have reviewed the feature-modes-passenger-services feature branch and compared it to the latest version of the SFMTA taxi spec. We have the following general thoughts and specific fields in the Taxi API for which we don’t see obvious mappings in MDS. I’ll note that the taxi spec has evolved over the last few months so some fields may have been added after our initial post.

General thoughts

• Journey_ID: Could define an entire driver shift. Do we have to define taxi uses in the spec, or can this be left for each implementer to define? Can be a useful tool with various purposes so perhaps better to leave it flexible for now.
• The SF telemetry spec contains a vehicle and driver state with each record. We have general questions about how state changes could be associated with telemetry records. Might be worth discussing again during Provider/Agency unification.

Fields in Taxi API we didn't see mappings for in MDS

• License Plate: SFMTA requires both VIN and license plate to be reported for each vehicle. The VIN field seems like the appropriate place, but we need another field to capture the other.
• Dropoff_Address: SFMTA requires pickup_address and dropoff_address. The dropoff_address is collected for the same investigation purposes as pickup_address.
• Is_wheelchair_transported: In MDS, there is the accessibility_options value for vehicle properties, but that describes the capability of the vehicle, not necessarily if it was used for a trip. We think a flag describing wheelchair use could be added to the trip_attributes array.
• Fare_time: Similar to wait_time, fare_time indicates in integer milliseconds the time the vehicle was moving > 12mph, which is subject to a different fare calculation than wait_time. However, upon further reflection fare_time may be a superfluous field. It can be derived from trip_duration – wait_time; and (unlike wait_time) it’s not explicitly used in the calculation of meter fare.
• Upfront_pricing: This should only be populated for trips that charged an upfront price rather than using the meter – there is a separate meter_fare field that should report what the meter rate would have been in the case of upfront priced trips (so that we can compare the upfront prices to meter rates as part of the evaluation of the upfront fare pilot program).
• Taxi_company_id: We've already discussed this at a few meetings, but still wanted to flag here.
• Total_fare: Would this be actual_cost in the MDS Provider Trips endpoint?

[schnuerle]

Per @alexdemisch's comments:

General thoughts

Journey_ID: Could define an entire driver shift. Do we have to define taxi uses in the spec, or can this be left for each implementer to define? Can be a useful tool with various purposes so perhaps better to leave it flexible for now.

To accommodate this, there is a new shift_id field as part of each journey's attributes. A unique identifier for an entire driver's work shift, tied across multiple journeys and therefore trips.

The SF telemetry spec contains a vehicle and driver state with each record. We have general questions about how state changes could be associated with telemetry records. Might be worth discussing again during Provider/Agency unification.

No changes, but we can discuss more.

Fields in Taxi API we didn't see mappings for in MDS

• License Plate: SFMTA requires both VIN and license plate to be reported for each vehicle. The VIN field seems like the appropriate place, but we need another field to capture the other.

Added to vehicle attributes

• Dropoff_Address: SFMTA requires pickup_address and dropoff_address. The dropoff_address is collected for the same investigation purposes as pickup_address.

Added to trip attributes

• Is_wheelchair_transported: In MDS, there is the accessibility_options value for vehicle properties, but that describes the capability of the vehicle, not necessarily if it was used for a trip. We think a flag describing wheelchair use could be added to the trip_attributes array.

Added to trip attributes

• Fare_time: Similar to wait_time, fare_time indicates in integer milliseconds the time the vehicle was moving > 12mph, which is subject to a different fare calculation than wait_time. However, upon further reflection fare_time may be a superfluous field. It can be derived from trip_duration – wait_time; and (unlike wait_time) it’s not explicitly used in the calculation of meter fare.

Added to trip attributes as trip_fare_time

• Upfront_pricing: This should only be populated for trips that charged an upfront price rather than using the meter – there is a separate meter_fare field that should report what the meter rate would have been in the case of upfront priced trips (so that we can compare the upfront prices to meter rates as part of the evaluation of the upfront fare pilot program).

Added to fare attributes as meter_fare_amount

• Taxi_company_id: We've already discussed this at a few meetings, but still wanted to flag here.

This is already in the base MDS trips endpoint fields as provider_id. I think that works, taxi companies can be added and get an id just like any other company operating in the PROW.

• Total_fare: Would this be actual_cost in the MDS Provider Trips endpoint?

Yes. This is already in the base MDS trips endpoint fields as actual_cost .

[alexdemisch]

Thank you @schnuerle . I agree with you that each taxi company can get a MDS provider_id. In the SFMTA spec, there are two fields like provider_id, but they refer to two separate entities:

• provider_id: UUID that is associated with the data provider.
• taxi_company_id: UUID that is associated with the taxi company.

It seems like there are similar situations in car share where the data processor is not the same as the service operator. I'm not sure if anyone has asked to collect it, but might be worth adding as part base MDS?

[schnuerle]

All these changes and discussions have been addressed and complete with #801. Thanks to you all!

[marie-x]

Gosh that's satisfying! WOOOOOOOO!