Question: should reserved but canceled trips show up in trips endpoint?

[dirkdk]

Question

We at Spin are working on reservations. For internal reasons that means we create a trip object in our data store. A happy path is that a user first reserves a vehicle and then later starts a trip. However a user may cancel the reservation, without moving the vehicle one bit.

For now I am inclined not to want to have this trip show up in Provider Trips endpoint.
Provider Status Changes would show up yes as there is an event reserved with a matching available for canceling the ride. Same with Agency Push, we have an event reserve with a matching cancel_reservation, and a separate trip_start

Question: should reserved but canceled trips show up in Provider Trips endpoint?

Is this a breaking change

• No, not breaking

Provider or agency

• provider

[jfh01]

Is this addressed by #271 and #439?

[Retzoh]

Not directly. #271 adds the distinction between the reserved and trip status to provider.
We might want to explicit that the event_types transitioning between available and reserved, reservation_start and reservation_end, have no trip_id associated and thus do not appear in the trip endpoint.

[thekaveman]

I think this has been resolved with #506 and will be further described with #534.

The only status changes that require a reference to a Trip are those that cause the vehicle state to enter or leave on_trip, namely: trip_start, trip_end, trip_cancel, trip_enter_jurisdiction, trip_leave_jurisdiction. Since the reservation_cancel event takes a vehicle from reserved to available, there is never a trip involved.

So I think the answer is: no, a reservation that is canceled should not show up in the /trips endpoint. That information should be reflected in /status_changes and/or /events.

[schnuerle]

Scenario: Someone reserves a device via the app, and the clock starts ticking on the payment per minute. Then after 15 minutes they decide they don't want a ride. So no ride was taken, but they were charged.

This was not a trip made, but a charge for a trip was made. So the question is, in the eyes of the MDS endpoint, is this a trip that gets recorded? For counting trips made and distance travelled, no. For looking at fees collected and a device in the ROW, yes.

[dirkdk]

Scenario: Someone reserves a device via the app, and the clock starts ticking on the payment per minute. Then after 15 minutes they decide they don't want a ride. So no ride was taken, but they were charged.

This was not a trip made, but a charge for a trip was made. So the question is, in the eyes of the MDS endpoint, is this a trip that gets recorded? For counting trips made and distance travelled, no. For looking at fees collected and a device in the ROW, yes.

to examine fees, as standard_cost and actual_cost are optional is more of an edge case. Primary use case of Trips is where somebody traveled. I'd say leave these trips out of the Trips endpoint.

[schnuerle]

@dirkdk do you think that @thekaveman's answer that this is resolved now is good for you? Or do you think there needs to be some clarifying language somewhere about this specific use case, eg that trips only get logged if distance is travelled with device? We can also bring up on a WG call.

[schnuerle]

We will be talking about this on the Working Group call tomorrow: https://github.com/openmobilityfoundation/mobility-data-specification/wiki/Web-conference-notes,-2020.10.01-(Joint-Working-Group-City-Services)

[dirkdk]

@dirkdk do you think that @thekaveman's answer that this is resolved now is good for you? Or do you think there needs to be some clarifying language somewhere about this specific use case, eg that trips only get logged if distance is travelled with device? We can also bring up on a WG call.

@schnuerle yes. I would agree that indeed we should not include this trip in the Trips endpoint. I can't make the call tomorrow, but I think we are in agreement and have reached a conclusion

[schnuerle]

@dirkdk We discussed this on the call today.

Some use cases came up related to this, like knowing across a city the percent of fleet devices in use at a time (Blue Systems). Though this could be determined from /events or /status_changes though. Another use case is policies that charge a fee when a reservation is made. Thought this is contained within Policy and relies on /status_changes (and /events maybe in the future), so /trips data is not needed either.

There was a hypothetical use case about if the trip was charged, there may be some useful analysis in looking at the fees, but didn't get a city on the call to confirm this. So we need to get some city feedback.

Dirk can write up PR for review and feedback? Maybe just some wording clarification about the trips endpoint. Right now it says:

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

Suggest something like:

A trip represents a journey taken by a mobility as a service customer with a geo-tagged start and stop point, once a vehicle enters the on_trip state. A reserved state where no trip was taken is not included.

Note: in this case zero distance trips would still show up, as long as a device enters on_trip.

I made a new issue #583 that specifically calls out fees. I will link it to the new PR when ready.

[schnuerle]

I believe this request is taken care of in MDS 2.0, with this new language and the new state machines.