-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bring fork up-to-date with CityOfLosAngeles repo #1
Merged
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
Suggested API additions
This is a markup version of the LADOT draft Dockless rules that is in PDF form. Please make reference to this text version when making comments.
Adding .md file for draft rules to allow for formatting and pull requests. @Vladinthecity modify with Jose as desired.
* Added unique ID attribute for provider availability API * Added company name to availability api * updated point and multipolygon specifications
This reverts commit 963b1e9.
…-data-standard * 'master' of https://github.com/CityOfLosAngeles/mobility-data-standard: adding company name. Fixes #22 (#24)
Carry over from Swagger
Suggesting a change to the identifier for a vehicle away from a UUID and using the operators identifier instead. The thought here is that each bike manufacturer already has a unique identifier for their vehicle embedded in their code (QR code or otherwise). It's part of the inherent of the business. Let's use that number so they could be correlated to real bikes on the street if it ever became necessary.
Renamed Remove-Vehicle API to Deregister-Vehicle. Removed need for reason_code since these descriptions are used for service.
Change device_id to VIN
update Availability to Status Change in table of contents
* Update README.md * Updated Register vehicle Changed vehicle_id structure to be an input from operator. Also changed response from register-vehicle endpoint to message * Update DeRegister endpoint Updated to E.md * Updated Register vehicle Changed vehicle_id structure to be an input from operator. Also changed response from register-vehicle endpoint to message * Update DeRegister endpoint Updated to be compatible with new vehicle_id schema. Added an "API KEY" section ibe compatible with new vehicle_id schema. Added an "API KEY" section in header of endpoint * Updated Update-trip-data endpoint * Included Route definition from the Agency side as well. * Format changes * Needed a default event_type for newly registered vehicles. Added a operator provided Unique_ID (as a UUID) to reperesent the table key for vehicle registrations Removed parking related messages, added 2xx messages that makes the system failure tolerant * See Comment #36 Per @hunterowens request.
Added messages that supports the following Workflow: 1. Register Vehicle (register the vehicle with the agency) 2. Deploy Vehicle (put a vehicle on the street) 3. Start Trip - Tell the Agency that a trip has started 4. Update Telemetry - Update data within an opened trip 5. End Trip - Tell the Agency that a trip has ended
Co-Authored-By: hunterowens <[email protected]>
`provider` APIs must support versioning going forward. As implemented here, we will use a custom media-type to negotiate the API version a client and server will use. A couple reasons for taking this approach: * API versioning will become important as 0.3.0 and future releases are published with breaking changes that Providers, cities and third-parties will need to implement/adopt on differing timelines. * Because this is a specification for others (Providers) to implement their APIs against, mandating URI structure beyond endpoints could be burdensome or limiting. Conversely, leveraging standard HTTP Headers in a compliant manner places no limitations. * Further, in practice, many providers have already begun implementing their own versioning in their registered `mds_api_url`. Closes #114
Consistent naming/format and remove unneeded provider_id parameter.
Update README.md
Update README.md
Also replacer "UUIDv4" with "UUID4", as is convention
…ta-standard into dev * 'dev' of https://github.com/CityOfLosAngeles/mobility-data-standard: (33 commits) Update definition of timestamp to match provider Also replacer "UUIDv4" with "UUID4", as is convention Update README.md Update README.md Clarify that the time-based-filtering query parameters should be stackable. fix cloud line. add mds-agency-cli project Adding Cloud as Provider, mds, and gbfs language cleanup, link to GPS articles truncate -> round switch to round, fix typo. Update provider to allow precision based truncate. fixes #209 Cleaning up service_areas endpoint Add versioning requirement to Provider API Fixing two missing initial event states. Update provider/auth.md Authentication Requirements. Fixes #171 Update README.md Update README.md generate full schemas clean up and fix the schema ...
In conversations and from ingesting data, it's become clear there is ambiguity in how parties are reporting data in their MDS Provider API implementations with respect to the boundary of the municipality they are operating in. This commit adds some clarifications and definitions to capture the original intent of the spec and what most cities (Santa Monica and LA) have been expecting in this regard.
…ta-standard into dev * 'dev' of https://github.com/CityOfLosAngeles/mobility-data-standard: Service Areas Bugfix. (#239) clarify type of acceptable boundary geometry fix formatting [Provider] Clarify how endpoints relate to municipality boundaries.
Release notes 0.3.0
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.
No description provided.