search

openmobilityfoundation / mobility-data-specification

A data standard to enable right-of-way regulation and two-way communication between mobility companies and local governments.
https://www.openmobilityfoundation.org/about-mds/
Other
676 stars 232 forks source link

Adding a field in trip objects to cover cancelled trips easier #889

Open pierre-bouffort opened 7 months ago

pierre-bouffort commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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.