Adding a field in trip objects to cover cancelled trips easier

[pierre-bouffort]

When integrating the taxi and passenger services data, we realized it was complex today to send a trip object in cases where the trip was cancelled for whatever reason (no-show, app-cancellation, etc...). This is because the only way to determine the trip was cancelled is to go into the mode-specific trip attributes and infer the cancellation from the cancellation_reason field being not-empty (as of today, only an unnormalized string of text).

=> We suggest to add a trip_cancelled boolean as part of the root trip object so that the cancellation can be determined a lot easier. In this case, fields such as distance, duration, etc... could be made optional when trip has been cancelled for whatever reason.

This could be made mode-specific if some other mode do not need such a field.

PS: See issue #888 for our take on the mode-specific attributes and how we suggest to structure them.

[jiffyclub]

It is possible, though somewhat cumbersome, to determine if a trip was cancelled by cross-referencing with status changes. There is a trip_cancel event type and the events schema contains any related trip IDs.

[kevin-courbet-blue]

There might be race conditions where the trip is sent before the event (the standard does not enforce the sequence of events). I don't think we want to reject a trip event simply because it arrived earlier than the status change event.
Further, some providers may only implement a Trips endpoint feed for instance, and then there would be no status change event to reference.
Lastly, this request for change is also to improve data integrity by offering a means to validate different shapes of trips, such as "no show" trips which are a common use case, for which some fields may be unavailable (such as distance). Currently, the standard's definition is either too restrictive at times (duration required but does not exist for a cancelled trip), or too loose ("optionally required" mentions, but sometimes it is not clear when that field should be required or not). This change (along with Issue #888 ) would be a step towards tighter type definitions for events, to improve data quality across the board.

[schnuerle]

@pierre-bouffort is this still a need for you, or do you have more thoughts?

Does the trip_cancel Event cover this already for you?

If important still, we can try to get it into MDS 2.1 very soon.

[pierre-bouffort]

As explained above, I think it is possible, but cumbersome to go and cleanup the trips already received based on the event, but that can do the trick for the time being. Changing the trip objects and adding a 'trip_cancelled' boolean doesn't sound like a complicated change, but maybe that would be tough to fit into MDS 2.1.

Not a critical issue anyway.