Modes Feedback and Final Changes

[schnuerle]

Explain pull request

To collect feedback and incorporate final changes into the Modes work for the MDS 2.0 release candidate.

Is this a breaking change

• Yes, breaking

Impacted Spec

Which spec(s) will this pull request impact?

• ALL

Additional context

Please review and leave general feedback here as comments, or inline feedback by looking at the PR changes. You can browse the modes work in the feature-modes-2 feature branch.

Note there are some areas that specifically need feedback or aren't complete like:

• Any attributes for Journeys that don't work for Trips
• Other needed attributes for trips, fares, vehicles, accessibility for each mode
• State machine diagrams will be created later

[mguida22]

The MDS Modes work looks good and Ride Report will be using MDS 2.0 for micromobility and car share modes. Thanks for putting this together!

[alexdemisch]

The MDS modes work looks fantastic! SFMTA will use the MDS 2.0 passenger services mode for our Taxi reporting.

Two small comments/questions:

1. As noted in Consider incorporating TNCs/Ride-hail services #95 , SFMTA collects a separate UUID for the taxi company operating the service and for the data provider. The association between the two doesn't change often, but having the data provider id helps us know who to contact when there are data issues. If we don't want to add something like data_provider_id to base MDS, perhaps we can add a data_provider_id to trip_attributes?
2. The fare_attributes array for car share looks very similar to the passenger services one. I could see many of these being applicable, but others like driver_trip_pay and payment_type = 'paratransit' don't. I don't recall if anyone specifically asked for those.

[schnuerle]

1. As noted in Consider incorporating TNCs/Ride-hail services #95 , SFMTA collects a separate UUID for the taxi company operating the service and for the data provider. The association between the two doesn't change often, but having the data provider id helps us know who to contact when there are data issues. If we don't want to add something like data_provider_id to base MDS, perhaps we can add a data_provider_id to trip_attributes?

I think we could add data_provider_id to the base. This is happening in micromoblity too with newer companies, where a third party is doing the MDS data feeds on behalf of an operator. Either way, I wonder if they should go in the same providers.csv file, or be a new file (like we did with agencies.csv) called data_operators.csv or something? Could be that third party software companies could be on this list too. If not separate then data-only software companies will be added to companies operating in the PROW with no differentiation (unless we add a flag or something, but then maybe it should be a separate file if that's required).

UPDATE: see this Issue for the changes I made to add this to the MDS base #805 @alexdemisch

2. The fare_attributes array for car share looks very similar to the passenger services one. I could see many of these being applicable, but others like driver_trip_pay and payment_type = 'paratransit' don't. I don't recall if anyone specifically asked for those.

Agree paratransit should be be removed. Are there other values or fields here that people don't think will apply to car share and should be removed?

UPDATE: made these updates and a few other minor ones.

[nmad-sandag]

This looks good! - Nivedya Madankara Kottayi, SANDAG.

[ezmckinn]

Looks good to me. Thanks for all the hard work on this. - Emmett, Superpedestrian.

[marie-x]

Looks great!

[alexdemisch]

In the passenger services mode, is there currently a way to measure trip requests not fulfilled? What about wheelchair accessible vehicle trip requests not fulfilled? I recall talking about this early on in the modes work, but can't recall anything recent.

[AndrineG]

It looks great! - Andrine, City of Oslo

[schnuerle]

In the passenger services mode, is there currently a way to measure trip requests not fulfilled? What about wheelchair accessible vehicle trip requests not fulfilled? I recall talking about this early on in the modes work, but can't recall anything recent.

@alexdemisch I think this is possible with MDS currently. Eg, you can make a reservation, but then it can be cancelled by someone before the trip starts, usually at no cost.

There are some additional options specifically in the Passenger Services Mode that allow for different kinds of event cancellation tracking, which I think cover all the bases:

• driver_cancellation
• passenger_cancellation
• provider_cancellation
• reservation_cancel
• trip_cancel

[Aileen1Zhong]

For the Delivery Robots Mode:

1. Trip route - I think this should be changed to a radius instead of exact end and start points to protect extremely sensitive information. Information regarding start and end points of a route can be used to deduce who is ordering what (or at least from where). Aggregated over time this information can be used to deduce individual, group, or company habits. This may lead to caution towards using services as customers understand that municipalities are also privy to this information. This concern is exacerbated with vendors of sensitive goods (such as a planned parenthood or hospitals, etc.) in certain states or jurisdictions with restrictive laws. This could be potentially very damaging to customers (individuals or companies) if exposed.

2. Trip duration and distance - I think this should be changed to rough approximations until more delivery robots are allowed for usage. Since Delivery Robots are not ubiquitous and new, Information (absolutes, fluctuations) can be used to deduce operations details, hardware, and software limitations and performance. These are trade secrets, and could be damaging, if exposed.

3. Vehicle battery_pct and current_location - I think this should be removed. Information could be used to deduce overall efficiency of fleet operations, and similar operational performance metrics. These are trade secrets when aggregated over time, and be damaging to companies if exposed.

[schnuerle]

Hi @Aileen1Zhong those are good questions thanks for sharing! Trade secrets and privacy are similar to what's been brought up around MDS for micromobility over the years.

I've summarized your comment and some relevant MDS resources in discussion #808 where we can all dig in more deeply together with the Working Group and Privacy Committee. Please head here for the discussion, and we can bring back decisions here.

[avatarneil]

This LGTM!!! 🚀

[schnuerle]

Since the only open discussion point now after the month review is the discussion about delivery robots, I'm going to merge this request in the development branch so we can focus at new pull request on that issue, and also work to incorporate other changes like the Agency/Provider unification work. Will comment again here when it's ready.

Thank you all for your reviews and feedback!

[schnuerle]

I've created pull request #812 that adds precision to Policy Requirements to address most of the location concerns listed here. Please review, leave comments in general or inline, and you can see the object defined here and an example here.

[pierre-bouffort]

Looks good to Blue Systems, looking forward to using with the Delivery robots first, and other services in the future.

[schnuerle]

To close the loop here on the comment from @Aileen1Zhong, based on the robust discussion in #808, the consensus is that MDS already has good guidance and existing tools to limit data fields when needed for any reason. Those built-in MDS tool are:

1. Policy Requirements - using this, any or all fields mentioned in the comment can be left out of MDS data feeds if the city and provider agree, e.g. Provider /trips trip_duration, trip_distance, start_location, end_location, route and/or Provider /vehicles battery_pct, current_location. MDS 2.0 will include the ability to tie any data requests to defined use cases.
2. Geography Driven Events - Instead of returning GPS location of each trip's start and end location and route, it is possible for locations to be rolled up into larger geographic areas, e.g. census blocks, neighborhoods, a grid across a city, or any defined areas.