Trip definitions

[jean-populus]

Is your feature request related to a problem? Please describe.

Trip counts are an important metric for cities but the data we receive through MDS doesn't reflect the reality on the ground. For example, short trips that are just a few meters, phantom trips, trips that leave the city boundary and disappear. We can't use the data as-is and have to make judgement call on which trips to count and which trips to filter.

Describe the solution you'd like

It would be helpful if there was a shared understanding and recommendation on what counts as a Trip. Currently each city/provider/3rd party is a separate conversation and unique implementation.

For example, we could only count trips with an actual_cost.

Is this a breaking change

• I'm not sure

Impacted Spec

• policy

Describe alternatives you've considered

n/a

Additional context

see 2022.02.17 working group discussion

[ezmckinn]

Agreed that this is an important thing to clarify from an operator perspective, as well. 

Some questions for us to consider on the next working group call:


• What are valid reasons for a trip to be omitted (e.g. distance, time), vs. included and flagged as a valid edge case?

• Do we omit linked trip_start and trip_end events, as well?


  • I’d suggest “yes”, because this will keep trip counts aligned between /status_changes and /trips, and also avoid having to re-tool the state machine. However, this could be incompatible with Agency implementations that require trip start/end events to be reported within seconds of the user attempt to start. 


• Does MDS Policy need to be updated in any way to accommodate this definition? Might that even be the best place to define what will be counted?


[schnuerle]

Discussion today about adding more clarifying information to the spec around trip definition and types of 'trips' in MDS.

Could go in Definitions and/or provider trips.

Currently says:

A trip represents a journey taken by a mobility as a service customer with a geo-tagged start and stop point.

This doesn't clearly say that the start/stop points must be different, or define the length of a journey. Wording could be more like:

A trip in MDS represents a free or paid trip transaction by a mobility service provider. Trips that do not involve moving a device any distance (due to cancelled reservation, equipment/app issue, communication loss, etc) are legitimately represented as 0 trip_distance and possibly 0 trip_duration in MDS. However these 0 distance trips that are sent via MDS should not count as a 'trip' when calculating provider fees as defined in Policy.

[mplsmitch]

Years ago there was an effort to develop a bikeshare equivalent to US DOTs National Transit Database. Defining what constituted a trip was one of the more difficult issues. At that time, the available data was filled with trip records that weren't actual trips. For example, maybe the user unlocked the bike only to find that it was in need of repair and immediately ended the rental.

Often times trip records had an origin point but no end point because of a loss of communication or other issue so that wasn't reliable. You couldn't count on billing records because in a membership based system often there is no billing for a trip, or you have subsidized users who don't pay or marketing promotions for free rides.

Systems that offer things like day passes will combine all the fees incurred for the duration of the pass and only bill once to save on credit transaction fees so billing isn't tied to individual trips. In a station based system, many users will begin and end trips in the same location so you may have no record of distance traveled.

In the end we decided that trip duration was the only reliable indicator of use and we used anything >=1minute as the threshold for what constituted a trip. Going through my data I could see that this didn't catch all non-trips but it got more than 95% and at >2 minutes we would have been excluding actual A to B trips.

[dirkdk]

I think a 60 second minimal duration for a trip sounds good as a cutoff.

I would suggest adding a field to MDS provider should_be_included with possible values true or false rather than completely exclude the trip. Because indeed it will be hard to wait for the 120 second mark to start sending MDS Agency events to see if the trip has qualified to be included.

[jiffyclub]

I've drafted a definition in #762 for discussion.

[schnuerle]

Resolved with PR #762