Web Conference 2021.08.10 Curb - openmobilityfoundation/curb-data-specification GitHub Wiki

Web Conference - Curb Working Group

  • Every other week Tuesday call at 9am PT / 12pm ET / 6pm CET

Conference Call Info

Meeting ID: 898 5980 7668 - Passcode 320307
https://us02web.zoom.us/j/89859807668?pwd=ZzJrbEpTNVB4WkNqNiszcmFYVzBwZz09

One tap mobile: +13126266799,,89859807668#,,,,*320307# US (New York)

Dial by phone: +1 929 436 2866 (US) (Find your local number)

Agenda

Main Topics

  1. Welcome and process (5 min) - Brian Hamlin, SDOT
  2. Regulation/Event/Metrics spec recap (5 min) - Michael Schnuerle, OMF
  3. Curb policy use case (8 min) - Tomas Carranza, LADOT
  4. CDS Curb API Discussion (40 min) - Discuss larger open questions

Organizers

  • Hosts: Brian Hamlin (SDOT), Jacob Baskin (Coord), Michael Schnuerle (OMF)
  • Note Taker: Danielle Elkins
  • Facilitator: Angela Giacchetti (OMF)
  • Outreach: Brian Hamlin

Minutes

Notes

Action Items

For everyone:

  • Feedback on Regulations external to or within curb Zones
    • Second object in /zones, not in a /regulations endpoint. But could add parameter that sends IDs only and no regs to reduce filesize.
    • Maybe a 'current' parameter in /zones that only returns currently used regulations in active zones?
    • Could add an optional endpoint /regulations to return all as JSON, or filter by one regulation ID.
  • Feedback on GeoJSON vs JSON
    • GeoJSON for some files, JSON for others?
    • Or support both with .json and .geojson file names, swapping content? Maybe a 'format' parameter?
  • Feedback on data storage and processing – concerns over file sizes – is this an issue in MDS currently? 100 of MB file? Some MDS Geographies alone have over 20MB, so maybe not an issue
    • Should static files even be allowed, or is it only dynamic ones?
  • Feedback on potential metrics

Minutes

Curb policy use case presentation by LADOT

  • Developing a digital map of curbside access
  • Focus on 3 main goals:
    • Augment staff with external resources
    • Pursue outside grants
    • Test and pilot
  • Rogelio Pardo, Urban Movement Labs
    • Helping to refine business models and regulatory structures
      • Facilitated workshops
      • Working with Local agencies and schools on workforce challenges
      • Pilots
        • Pilot with IBI and CurbIQ
  • Jacob Malleau, Curbside specialist at IBI Group
    • CurbIQ developed in house at IBI
      • Set of tools and APIs to help cities collect, manage, and disseminate curbside data
    • Pilot Overview
      • Project Goals:
        • Demonstrate and compare 2 different curbside data collection processes for visualization and analysis in LA for UML
        • Generate curb data in open data std
        • Using CurbLR for now – hoping to migrate to CDS
        • Provide access to CurbIQ tools to visualize, collect, manage, and disseminate curbside data
      • Collection Methods
        • Vehicle based mobile mapping, surveying by foot
        • Addressing challenges with collection methods: Poor GPS accuracy
      • Progress – completing mapping
      • Next Steps – Compare data collection methods, share data/takeaways with UML partners, and provide template for best overall methodology to collect curbside data for the whole City

Discussion of CDS Curb API

Do regulations go inside each Curb Zone, or are they external and reference by ID?

  • Jacob Baskin (Coord): Don’t want consumer to have to make 2 API pulls to get useful data – zone and regulation data. Calling first and second endpoint unnecessarily complicated. Call zone endpoint and get back 2 lists: list of zones, list of regulations (map from IDs to regulations).
  • Michael (OMF): Policy in MDS similar. ID for geographies.
  • Jacob : Don’t want pulls that are useless on their own
  • James Graham (DC DOT): For internal/external regulation discussion: @jacob: would the external policy in option '2a' be stored at the zone level?
    • Jacob (Coord) no stored at the regulation object level within the zone endpoint
  • Eric Mai (Lacuna): these curb zone geographies very rarely change, so seems cumbersome for these to change
  • Jacob (Coord): does this design solve that? Zone ids change each time reg changes. Underlying geometry of the curb doesn’t change but the zone does.
  • Jacob Malleau (CurbIQ): Having that reg ID is still helpful, common regs exist across geographies, so ID would be easier to update all at once.
  • Jacob (Coord): To address concern, only produce content of each ID one time or not return geometry each time requested. Connection between dates and ID. Zone IDs have effective and end dates.
  • Michael (OMF): Will flush out for the final draft.
  • Jacon (Coord): What’s included in the reg ID? Each reg have its own ID?

GeoJSON or JSON? Pros/cons

  • Danielle (Mpls): Just wanted consistency with MDS, so JSON is okay, for that reason
  • Jacob (Coord): Just do geographic pieces as GeoJSON: would just be areas, zones and spaces
  • Michael (OMF): If not it will be JSON, will write that in for discussion.

Where is the end point processing mostly done? Host or consumer side?

  • Jacob (Coord): in this format you could easily get to 100s of MB of data – is data size an issue?
  • Michael (OMF): Decide what should be dynamic and get feedback from cities on size
  • Jack Reilly (Vianova): Our cities can get over 20mb geography data in policy API

From chat: