Web conference notes, 2020.05.28 (City Services wg)
Web conference notes, 2020.05.28 : City Services WG
- biweekly call at 9am PST / 12pm EST
- Join Zoom Meeting https://zoom.us/j/671331832
Meeting ID: 671 331 832
One tap mobile:
- +16699006833,,671331832# US (San Jose)
- +19294362866,,671331832# US (New York)
Dial by your location:
- +1 669 900 6833 US (San Jose)
- +1 929 436 2866 US (New York)
Find your local number: https://zoom.us/u/aeJWJsuC2b
add your name at beginning or end of call
- Jascha Franklin-Hodge, Open Mobility Foundation
- Henri Bourdeau, BlueSystems
- Michael Schnuerle, Open Mobility Foundation
- Eric Mai, Ellis & Associates
- Bill Dirks, Ride Report
- Dirk de Kok Spin
- Sean Holman, Ellis & Associates
- Michael Durling, Ellis & Associates
- Brooke McKim, Stae
- Brian Ng
- Jane Huang
- JR Heard
- Sanjiv Nanda
- William Henderson
- Zachary Levin
-
Provider / Agency reconciliation: follow-up after the 2020-05-27 webinar
- PR https://github.com/openmobilityfoundation/mobility-data-specification/pull/506
-
Unresolved discussions:
- unregistered vs non_operational naming
- on_trip vs in_trip vs trip naming
- Please add a comment to the PR on how you feel about those names
-
Jurisdiction API
- Issue https://github.com/openmobilityfoundation/mobility-data-specification/issues/491
- PR https://github.com/openmobilityfoundation/mobility-data-specification/pull/492
- Link to slides presented by Brian
-
Notes:
- Brian Ng and Jane Huang presented
- Jurisdiction contains reference to Geography ID 1:1
- Timestamp is there for legal reasons
-
Questions:
- Why is there a put and post in the spec, since the consumer of the API, providers, would not use them? Recommend pulling them out and just doing Get.
- Why create a separate API and not use the Geography API? Why not include jurisdiction as an endpoint into Policy? Recommend investigating what Policy integration would look like.
- Next steps: cover the use cases for the API to answer those questions @E&A & @Blue.
-
Audit API https://github.com/openmobilityfoundation/mobility-data-specification/pull/483
- Link to slides presented by Eric mai
-
Notes:
- Needed way to trust data in MDS and work out any issues collaboratively with cities and providers.
- Connected to an organization's deployment of a core (or a similar system and DB) to get MDS data.
- Use cases included status data, end trip validation, compliance spot checks.
- Minor issue when providers change tags on a vehicle but keep the same vehicile_id.
- Audit could be used by providers as well by their own field people to troubleshoot MDS issues.
-
Questions:
- Why add it to MDS? This moves away from the core MDS role about Provider-Agency communication.
- Should it live in a separate repo?
- Could it be separated from core?
- Adding fees in Policy -> Pushed to next meeting.
- Make routes optional in Provider/trips endpoint -> pushed to next meeting
- MDS repository organisation: the repository would benefit from a document providing a general view of the purpose of each part and API, and how they each interact with each other -> @mds-ops working group will discuss, start with Understanding MDS APIs.
