Simplify /vehicles/status

[sven4all]

Is your feature request related to a problem? Please describe.

Right now /vehicles/status is quite complex to implement for operators in comparison with the GBFS 1.0 (https://github.com/openmobilityfoundation/governance/blob/main/technical/GBFS_and_MDS.md#real-time-status-differences) where it is a succesor of. The complexity is that this endpoint is not only about the current realtime situation anymore but also about events that happened in the past in addition to the need to add identifiers to those events.

For pragmatic reasons (for example making it also viable for small operators to deliver data to dashboard) we now allow operators to implement a subset of /vehicles/status (https://docs.dashboarddeelmobiliteit.nl/data_feeds/for_monitoring/#mds-vehicles). Ideally this subset will be globally the same.

Describe the solution you'd like

From a municipality point the most important data is the current location + vehicle_state, more or less the same data that was already in GBFS 1.0. I would like to propose a simplified version of /vehicles/status to simplify the exchange of data between operators and municipalities.

Is this a breaking change

It depends on if we introduce a new simplified endpoint besides the existing /vehicles/status or that we would like to change the existing one.

Impacted Spec

• provider

I really would like to hear your experiences and opinions about this endpoint.

[jordibeen]

We at Check (a micromobility operator in The Netherlands) agree with Sven's concerns regarding the current data requirements in the MDS project. While standardizing communication and data sharing between cities and mobility providers is essential, it's important to prevent situations that limit creativity or force significant adjustments to current setups in order to conform to the standard.

When looking at some of the "required attributes" of the /vehicle/status endpoint, it seems that it's assumed that each mobility provider saves their event/telemetry data in fine-tuned detail similar as what the spec envisions. However, providers have made their own technical decisions based on performance or features throughout their development process. Thus, full integration of the MDS standard might require significant changes to existing architectures.

Sven already mentioned the requirement of having to extensively provide past events, but I would also like to point out the required attributes telemetry_id and trip_ids in the Telemetry model. Adding whether the last telemetry update happened while the vehicle was on a trip or not would require us to make drastic technical changes, impacting the performance of our MDS endpoint in the process.

MDS' main goal, mentioned in the about section of the project, is stated as follows:

Standardizing the communication and data-sharing with cities and mobility providers should be the goal here.

We kindly request a discussion among the community about the potential impact of such strict requirements in the standard. Finding the right balance between standardization and flexibility is crucial to make sure that the MDS specifications remain adaptable to various mobility providers while still ensuring interoperability.

[schnuerle]

@sven4all can you explain how you'd like to see /vehicles/status modified so that it meets your needs? Is it just not to include vehicles that are on a trip? Maybe a new query string parameter could be added for this option.

@jordibeen Individual cities have the ability to modify what is required or not from MDS, for specific operators, programs, RFPs, tenders, permits etc, using the Requirements feature. So for now they can specify fields the do not need using this. In the future, we may look at making some of this more optional in the spec for MDS 3.0, but cities do typically want to know telemetry of vehicles while on trips (not usually in real time, but after some delay).