Release 2.0.1 #893
Merged
Release 2.0.1 #893
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add GBFS endpoint for Whoosh
I noticed a few places in the provider README where it was still referring to "status changes" instead of the new term "events". There was also an inconsistency in the depiction of the response format.
In older versions of MDS data was nested under a `data` key in provider API responses, so trips data would e.g. be response['data']['trips']. This ended up reflected in the docs where each section would have a label like "`data` Payload" describing what was under the `data` key in the payload. In MDS 2.0 this nesting was removed, `trips` is now a top level key in the response from provider trips endpoint. However, the docs were not updated to remove the word "data" from the payload descriptions, leading to potential confusion for readers of the documentation. This PR changes "`data` Payload" to "Payload" throughout the provider README to bring it in line with the spec.
The description of the Provider vehicles endpoints was never really updated in the MDS 1 -> 2 transition so this rearranges and clarifies some things now that there are two vehicle information endpoints, one for static information like vehicle/propulsion type and another for realtime status. These changes are mostly rearranging/clarifying, but there is one major addition to the description of the `/vehicles` endpoint describing that when called without a device ID it is expected to return every vehicle ever deployed in a jurisdiction.
Update "status changes" to "events" in provider
…-response-docs Remove word "data" from provider response payload descriptions
Update to pairing list of vehicle_state and event_type for car sharing
…e-reports Reworded comment for start_date in Reports
The example API response for the /vehicles/status endpoint had the data key as 'vehicles' when it is in fact 'vehicles_status'.
Fix JSON key in /vehicles/status example response
- Specify that /vehicles called without a device ID should return all vehicles deployed in a region in the last thirty days - Specify that vehicle information about all device IDs present in MDS data for a region must be accessible via /vehicles/device_id regardless of when the vehicle was deployed
…clude Clarify which vehicles to include in the `/vehicles` endpoint
Fixing broken links in data-types markdown document
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
The Release for MDS
2.0.1has been created: https://github.com/openmobilityfoundation/mobility-data-specification/releases/tag/2.0.1Action Item
This pull request will be merged by OMF staff following approval by the WGSC.