Web Conference notes 2019.10.03

• biweekly call at 11am PST / 2pm EST
• Join Hangouts Meet | meet.google.com/fxq-xate-ize | Phone Numbers ‎(‪US‬) ‪+1 413-893-3105‬ PIN: ‪322 693 255#‬

• Geoffrey Bir, Urban Radar
• Nathalie Nguyen, Urban Radar
• Thibault Castagne, Vianova
• Guillaume Attia, Vianova
• Thibaud Febvre, Vianova
• Kegan Maher City of Santa Monica
• Mark Maxham Ellis & Associates for LADOT
• Fletcher Foti Populus
• Shivam Vohra Scoot/Bird
• Taylor Boudreau Ride Report
• Michael Durling Ellis & Associates
• Sean Roberts CCSF
• Ash Roughani, City of Sacramento
• Morgan Herlocker SharedStreets
• Neil Goldader Ellis & Associates
• Andrew Scherkus, Roundtrip

before the call starts, posted here and on https://groups.google.com/forum/#!forum/mds-announce

1. Static File backed Query Parameters

2. Policy API Endpoint for cities to express policy. Related PR around service areas.

3. Removing Warehouses from status_changes

Notes and or transcript of the call

Host Kegan/Santa Monica

Static File backed Query Parameters](https://github.com/CityOfLosAngeles/mobility-data-specification/pull/357

Long been in discussion. Previous discussion of Brady’s initial proposal just remove some of the query parameters and defining how some of the query parameters can be used. Decision was made that maybe a different approach would be better, introducing some new query parameters explicitly for querying the static backed file base.

Andrew = happy for some of the provider implementations, I think it would be good if some of the providers would weigh in on some of the implementation and constraints experience on their systems. I was just analyzing based on reference architecture that I built and just general sort of ideas I had. More discussion I think is needed.

This does theoretical address the issue. John had initially brought this to our attention w/ issue 268 ‘making queries more predictable’, anyone from Lime or Lyft could speak to this? Would an implementation like this would it help? Too complicated? The implementation of query parameters.

Ben from Bird = generally we are on board with this, it’s definitely helpful and I think well likely once its implemented will push for this endpoint as the primary way to get or gather historical data because it would be significantly better for us from a systems perspective. The concerns weather or not the datasets are exactly the same makes sense to me, I’d be curious to hear consumers thoughts on a month dataset are not identical to the 30 day data set being different how big of problem is that.

Santa Monica = this is not a big difference. Something Andrew brought up page time ~ 2 minutes status pages or 5 minutes on trips. Would the pagination be the same, once a month, etc. Thoughts

Response: pagination is technical feat for some. Being able to respond an unpaginated single response would be our goal

Adam/Uber = question if we have this static end time parameter does that serve the same purpose as the min/max end times. Can we simplify the API by having just one time parameter here with expectation that query by the hour sufficient?

Limiting time to the hour or by the day would have been less desirable than a more explicit query parameter

Response that was definitely the conversations last time a bunch of us on provider’s side wanted to simplify things and consumers wanted granularity querying. There is no SLA in the spec its likely our response times for those queries will get long and folks therefore incentivize to use non granular queries.

Part of this comes from this tension of the original intent of provider APU as historical view to it being used as almost real time view of what’s happening, the introduction of an explicit query parameter definitely helps differentiate those two use cases. Another idea is a different end point and the current end point stay focused on the historic use case stay static and the new endpoint for the current real time endpoint.

Taylor/Ride Report = new endpoint would serve static files kinda HyperKnot mentioned. Historic purely static files and maintaining the status change trip endpoint as real-time endpoint, more GBFS type idea. Making things explicit moment/ historical requests. Real-time GBFS type

Question: what kinda of queries are you getting. Large historical back fill request or small time frame data sets Answers: Historical back fills varies paginated thru but majority are historical back fill Getting a sense of Fletcher/Populus = as a consumer there is some benefit of keeping it simpler on the providers side since not all providers have the same number of resources. Splitting into 3 endpoints one which is for real-time /GBFS type and one that is backed by static files keeping everything super clear, super short, super concise with minimum configuration parameters really makes sense to us.

Am I hear general consensus for different end point vs different queries parameters on the same end point? Separate end points best way to handle this? Vs new query parameter on the same endpoint?

As long as we don’t lose access to real time data

Clean up and codify endpoint uses without losing real time.

Keegan will work for being active on getting this into 040

Policy API Endpoint for cities to express policy. Related PR around service areas.

Max = anyone looked into policy PR any questions/critiques. Review of Policy API as posted on GitHub

Would each company be able to see each other’s static version for each company? An agency could host multiple static files

Assuming the geography is the same but the rules are different. One geography different rules? Yes, it can handle different rules same geography.

Conversation: Policy API. New w/varying issues. General Agreement that issues will be dealt with as it released into 040 but no general agreement needs further review. Might fall under experimental designation/review, enough cities actually actively consuming and using it. Still critical conversations to be had.

Issue 322

Removing Warehouses from status_changes](https://github.com/CityOfLosAngeles/mobility-data-specification/issues/373 Question: Providers have ware houses where they are onboarding and doing things with their devices and are sending back feedback to status changes and this is adding noise to the data that then needs to be filtered out. One issue is that language of the speck is not super clear, ‘available’ for customer use. It might useful to explicitly exclude vehicles and their status when within the ware house.

This is not a data or spec issue but an operations issue. MDS is about vehicles on the right of way, on the streets. Different public / private spaces e.g. UCLA. Continuum of issues. Is this a policy issue that each city would make regulations upon? Proposing language revision/clarification on Github.