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

Update to pairing list of vehicle_state and event_type for car sharing #881

Closed bergenklem closed 8 months ago

bergenklem commented 8 months ago

Explain pull request

The pairing list for _vehiclestate and _eventtypes for car sharing has several descriptions more aligned with a taxi service than a car sharing operation.

This draft PR is a follow-up of Issue 868 , and proposes minor updates to the descriptions so that they stay more in line with how car sharing works.

This draft PR also includes two discussion points:

1. Describing the event where a vehicle_state goes from reserved to stopped.

Original description is as follows:

_| reserved | stopped | reservation_stop | The vehicle has stopped to pick up the passenger |_

In a car-sharing operation, the car would already be parked - ready for the next customer to pick it up.

I've proposed to change the description to be "the customer has activated the vehicle". An activation is typically initiated through the providers app/RFID-chip/by provider (in cases where you've lost your key-card for example).

2. We should discuss the need for the "driver_cancellation" event.

Q: what is the difference between a driver and a customer for a car sharing-mode? As to my knowledge, in a car sharing operation, the driver = customer (the provider could let several customers/users be drivers in the same booking, but there's never a 3rd party driver involved). If the driver is not the same as the customer(s), then I would say we are talking about a taxi service/ride hailing.

Hence, I don't think it make sense to distinguish between customer and driver in car sharing.

_my proposal would be to remove driver_cancellation from the list of event_types.

If so, this change would also cause need for an update of the state machine diagram.

Is this a breaking change

Not breaking

Impacted Spec

Which spec(s) will this pull request impact?

Additional context

Add any other context or screenshots about the feature request here.

CLAassistant commented 8 months ago

CLA assistant check
All committers have signed the CLA.

schnuerle commented 8 months ago

I believe we left driver in there because there are scenarios where the company may deliver the car to the customer, e.g. have a driver employee/contractor drive the car to the customer's home. So we should leave this in for the 2.0.1 release.

If we want to discuss and remove it in a future release, it would have to be the 3.0 release as this would be a breaking change. If anyone would like to do this, please open a separate issue.