Web Conference 2021.06.01 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 - Michael Schnuerle, OMF
  2. Regulation spec discussion - Jacob Baskin, Coord
    • "Location" starting point - bounding box, existing specs

Organizers

Minutes

Notes

Michael Schnuerle (OMF) provided a brief intro to CDS and summary of curb survey initial results

  • Short term scope - CDS development for commercial loading curb areas
  • Today's call focused on CDS Regulations spec
  • Project timeline includes CDS design thru Sept 2021 with finalization occurring by end of the calendar year
  • Upcoming June Curb WG meetings to focus on Events and Metrics specs

Curb Survey - policy use cases - 12 responses across 9 agencies and 3 companies

  • Most respondents using tools to assist with curb asset management
  • 80% using in-house standard or no standard at all
  • 3 using CurbLR, though 2 not using it now as they'd like to support for future work
  • Remaining standards used - Coord, OpenStreetMap and other in-house formats
  • What use cases does curb data collection support - large majority 75% - asset inventory and cataloging regs and measuring utilization
  • 10-20% using it to optimize curb use for fairness/equity, monitor curb payments, dynamically give access to curb uses
  • Standard use cases around inventory and cataloging, not many advanced use cases yet, but a goal for CDS
  • Curb WGSC welcomes more responses to the survey right here

Regulations Spec Overview discussion led by Jacob Baskin (Coord & Curb WGSC member)

  • Way for cities to specify a loading area and applicable regulations to share with companies and public
  • Goal in the greater vision is to move beyond digital asset and dynamically manage the curb space
  • Reason for the kick-off survey was to look at existing spec use
  • Several ways of bridging data between specs
    • Take Curb LR and maintain compatibility with it. Write data in format that's valid by new spec and considered valid by CurbLR. Field compatibility across both specs. Could be constraining to a new spec but also beneficial if CurbLR continues to be used. Survey so far doesn't show a large Curb LR compatibility need yet
    • Location - how do we talk about a given place on a curb. CurbLR defines curb as one dimensional line. GIS practitioners may start with a polygon to account for how long curb may extend into the street. Do we want curbs in CDS to be a line or an area? Advantages of using a line - any area involves a certain amount of educating guesses - how long outward does it extend. GIS buffers help account for GPS inaccuracies? Is bounding box needed in the end given this GPS inaccuracy?
    • Compatibility - Value in producing a spec you can automatically translate from one spec to another format. Write a tool that works for many - definitions compatible, adding some optional elements unique to each spec.

Discussion Based on Guiding Questions

  1. Location - line or area?
  2. Value in maintaining compatibility with CurbLR moving forward?
  3. Value of being able to mechanically translate between specs?
  • Coord produced linear data for Boston in the past.
    • Matt Warfield, Boston - has used linear data in Google Earth, provided to Verizon for some data analysis
    • Jacob - if CDS developed, does Boston still need Curb LR?
    • Matt - No, we are in a place to adapt a spec that's out there and produced and supported
    • Jacob Malleau, CurbIQ - use CurbLR for all products. Started using because it was one of the only established formats at the time. Clients don't always specify a spec but feels it's relatively easy to switch between. Prefers to stick with CurbLR but is open to changing to an open source standard if that's what orgs are using.
  • Matt Davis, Populus - To what degree does OMF need a curb regulations spec at all? Could CurbLR be that spec?
  • WGSC talked about cities potentially bringing in their own linear referencing. If cities do have a basemap, it can be in SharedStreets format. But CurbLR requires the use of SharedStreets, which could be a hurdle for some. Could optionally support it.
  • Issue is there isn't a universal basemap everyone is using. For example, two neighboring cities using different linear referencing systems that cut off at municipal border
  • Take whichever linear referencing system you want to use and bake in compatibility. City will need to do the work of determining which basemap they want to use. If a city has zero basemap or a city has no desire to tie curb data to such a basemap, then SharedStreets does a great job.
  • Do we want to have a field called "Location" that's SharedStreets specific? SHST location field can be filled in to anyone can understand which street you're talking about. Regardless of reference system one is using, it can be tagged as internally developed or SharedStreets. Advise against using Way IDs from OSM as they can change.
  • Discovering membership by lines/LR is harder than polygon.
  • One field of a linear referencing system might have a numerated list so you can reference what you want in that area. SharedStreets has one ID for a street by direction of travel vs. other options that don't differentiate between directions. Can be sorted out via pull requests.
  • Michael - a goal of CDS is to create a spec easy for cities to use and does not have forced dependencies. This is what led us to looking at a geography options for expressing curb regs, letting cities use what they use already as a basemap and layering CDS on top of that.
  • Jean Kao - Looking at city needs down the line to share this data externally, how does using a city’s own basemap fit into sharing this info (e.g., Google Maps)?
    • Jacob - recall Google-GFTS use case. If Google requests curb data and it only contains geographies and they integrate into map products and they do it incorrectly (e.g., Chicago top v. bottom layers of a road).
    • Waze used a proprietary basemap to reference streets and it was up to Google to make sense of it and align with their basemap. No linear reference data in Waze spec - just polyline and street name
    • SharedStreets was trying to change this by offering an option for universal linear referencing
    • Michael - a chance that Mobility Data may be taking over CurbLR data spec though we don't know the outcome of those conversations yet. When that happens there will be a governance model (e.g., version numbers, releases, public/private groups managing the work in public). Directly referencing may be risky right now, but we can ensure compatibility for those who use it via ID reference.
  • Perspective from private companies?
    • Brian Ng, Lacuna - have started looking at curb use cases with cities. Using polygons given need to extend out beyond the curb to examine different zones (e.g., measuring double parking) and expanding beyond. Ability to apply regs will inevitably extend into the roads. 3-D box also allows for height restriction considerations.
    • Michael S - WGSC also identified need for curb "box" independently
    • Matt Warfield, Boston - Approaching the curb as a zone - curb lane, curb edge, space between a building and the curb edge, including the furniture zone, pedestrian space, etc.
  • Jacob Malleau, CurbIQ - Line or box matters not to identify where an asset is located.
  • Michael - cross-referencing possible - array of CurbLR IDs inside CDS that point to where an area is touching them, while also having CurbLR potentially add CDS IDs for road segments that connect to CDS areas.
  • Nick Meyers - For reference here is a Road Centerline Data Standard in MN that is being developed and tried to account for other business use cases: https://www.mngeo.state.mn.us/committee/standards/roadcenterline/MN_GAC_Road_Centerline_Data_Standard_Schema.xlsx
  • Stephen Hanrahan, DDOT - Do operators (Uber, Google Maps) use linear or polygons?
    • Companies doing routing tend to always use lines. But matching lines to polygons still possible.
    • Jacob - linear reference plus polygon may be an option
    • Jacob Malleau - how many people are used to seeing curb data as lines?
    • Michael - visual benefits to each at different viewing scales - bounding boxes as curb lines from far away zoom
  • Anil Merchant, Automotus - So far we’ve noticed and leveraged the use of boxes for some key insights into the type of park events (e.g., blocked bike lanes vs. pulling in flush with the curb vs. double parked events). Michael right about the boxes working as lines.
  • Polygons purpose is to offer structured access to the curb, bigger than asset management/inventory
  • Michael to Brian Ng - any polygon visualization challenges so far?
    • Not really. City reference maps may need to be manually adjusted
    • Double parking - airport dropoff areas on a loop - curb zone may be three lanes deep. Need to find a way for CDS to deal with this, but 2D works better than 1D. Larger polygon for the area may be needed here.
  • Translators between formats should be possible and will be considered.
  • Have consensus from this meeting to start with 2D polygon areas for location, and reference other specs and basemaps by and ID option.

Next steps for OMF and Curb WG