Skip to content
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
merged 211 commits into from
Mar 12, 2019

Conversation

jfh01
Copy link
Owner

@jfh01 jfh01 commented Mar 12, 2019

No description provided.

Jascha Franklin-Hodge and others added 30 commits June 3, 2018 15:46
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.
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.
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
oderby and others added 28 commits February 4, 2019 16:36
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.
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.
@jfh01 jfh01 merged commit 6fa5674 into jfh01:master Mar 12, 2019
jfh01 pushed a commit that referenced this pull request Oct 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.