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.