• Every other week call at 11am PT / 2pm ET

https://zoom.us/j/627957166

Meeting ID: 627 957 166

One tap mobile:

• +16699006833,,627957166# US

Dial by phone:

• +1 929 436 2866 (US)

Find your local number

Add your own name, link, and organization during call

• Michael Schnuerle, OMF
• JR Heard, Ride Report
• Kegan Maher
• Mark Maxham, E&A / LADOT
• Jascha Franklin-Hodge, OMF
• Alex Demisch, SFMTA
• Steve Brining, Blue Systems
• Josh Johnson, Spin
• Matt Davis, Populus
• 20+ attendees
• ...

1.1.0 Release.

1. Geography API - new endpoint that defines geographic areas and has ID that can be referenced across MDS.
   • Current draft
   • Main Pull Request #499 (issue #500)
   • #498 author service (not submitted for 1.1)
   • Will discuss fields, endpoints, use cases.
   • Slide presentation from call
2. Future Meetings
   • Provider and City WG meetings align more. Weekly by topic instead of by WG. More alignment and overlap with 1.0.0.
   • Time. Change to early morning Pacific, mid day Eastern, late day Europe?
   • Start with City WG next week, Provider WG in two weeks.
   • Topics planned weeks in advance, added to calendar events.

Notes and or transcript of the call with presentation, document, GitHub links and calls to action.

See these notes in the #499 Pull Request and leave your thoughts there. Slides from today.

• /geographies use cases. Is it needed?

  • Caching - so providers and third parties can download it all at once.
  • Searching - so you can see all geographies at once and how they relate before asking for details on the one you need from another API.
  • Adding geoJSON fields would make it too unwieldy.
  • Agreed for now it's useful and keep as is.

• Previous Geographies

  • this is written now so these never become 'inactive', they just may not be referenced any more.
  • Warrants a new section that elaborates on the nuance and implementation here.
  • Need to check on city capacity to implement this and update
    • noted that Geography is already in Policy, so if a city is implementing Policy, they can handle the new Geography endpoint.
    • complexity comes from the prev_geographies - could be hard to keep things up to date
    • WGSC and OMF can do some outreach to cities and Policy Webinar attendees to ask about challenges
    • third parties can alleviate these concerns. Eg, in Louisville one employee just managed existing GIS files and one spreadsheet, and Stae took care of translating and publishing to Policy API.

• Type of Geography field

  • Currently is meant to just be the definition of an area to be used elsewhere
  • Use can always be found elsewhere in other APIs
  • Use cases could be to pass in a variable and return just those on /geographies, find specific geographies like city boundaries or parking spots, Metrics to get relevant areas
  • Discussion if it exists to make an enumerated list of value, or maybe some kind of tagging system, or freeform.
  • For now leave it out, but could be added later if other endpoints need it

• Public feed

  • Could be made public (non-authenticated) since there is no sensitive info here
  • Along with Policy, could be very useful for third party apps, new operators in a city
  • Needs to be accurate and stay up to date

• Discussed new more aligned WG Provider and WG City meetings with earlier start time for Provider and topic based discussions. No opposition to ideas. WGSC will work to move toward this model.