Skip to content

Web Conference 2021.06.01 Curb

Jump to bottom
Marisa Mangan edited this page Jun 2, 2021 · 14 revisions

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
  • Today's call focused on regulations
  • Reminder 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 but 2 not using it now as they'd like to support for future work
  • Remaining standards used - Coord, OpenStreetMap and other in-house formats
  • Use cases does curb data collection support - large majority 75% - asset inventory and cataloguiing regs and measuring utilization
  • 10-20% using it to optimize curb use for fairness/equity, monitor curb payments, dynamically give access to curb uses
  • Curb WGSC welcomes more responses

Regulations Spec Overview 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 have curbs 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, but the result

Discussion Based on Guiding Questions

  1. Location - line or rectangle?
  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
    • 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
  • 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
  • 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 as they can change
  • On 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 v. other options that don't differentiate between directions. Can be sorted out via pull requests.
  • Michael - reminder, goal is to create a spec easy for cities to use and does not have dependencies on. This is what led us to looking at a geography options for expressing curb regs
  • 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 system to reference streets and it was up to Google to make sense of it. No linear reference data in their spec - just polyline and 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 and we don't know the outcome. Until that happens there's no governance model (e.g., no version numbers, releases). Directly referencing may be risky, but we can ensure compatibility.
  • 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"
    • 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 that point to where an area is touching while also having CurbLR
  • 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 lines from far away
  • 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)
  • Polygons purpose is to offer structured access to the curb, not just asset management
  • Michael to Brian Ng - any polygon visualization challenges so far?
    • 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. Larger polygon for the area may be needed here.

Next steps for OMF and WGSC

  • Open an issue on Github on this topic
  • Preparing and presenting on the other 2 components of CDS
  • Please sign up for Curb WG mailing list announcements and other ways to get involved

CDS logo

CDS Links

1.0.0 Release

Clone this wiki locally