-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trip definitions #748
Comments
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:
|
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:
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:
|
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. |
I think a 60 second minimal duration for a trip sounds good as a cutoff. I would suggest adding a field to MDS provider |
This addresses openmobilityfoundation#748 by adding a definition of a "trip" to the general-information.md file. The definition is meant for the purposes of analysis in particular, and not for filtering which data points are exchanged as part of MDS endpoints. I wasn't sure on the exact right spot for this since I hadn't seen anything like this done before in MDS, but I'm open to suggestions on that and the wording of the definition itself.
I've drafted a definition in #762 for discussion. |
This addresses openmobilityfoundation#748 by adding a definition of a "trip" to the general-information.md file. The definition is meant for the purposes of analysis in particular, and not for filtering which data points are exchanged as part of MDS endpoints. I wasn't sure on the exact right spot for this since I hadn't seen anything like this done before in MDS, but I'm open to suggestions on that and the wording of the definition itself.
This addresses openmobilityfoundation#748 by adding a definition of a "trip" to the general-information.md file. The definition is meant for the purposes of analysis in particular, and not for filtering which data points are exchanged as part of MDS endpoints. I wasn't sure on the exact right spot for this since I hadn't seen anything like this done before in MDS, but I'm open to suggestions on that and the wording of the definition itself.
Resolved with PR #762 |
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
Impacted Spec
policy
Describe alternatives you've considered
n/a
Additional context
see 2022.02.17 working group discussion
The text was updated successfully, but these errors were encountered: