Breakout Room Notes

Purpose: The purpose of NC-BPAID is to advance comprehensive, public domain, interoperable data on bike, pedestrian, and accessibility infrastructure that informs decision-making on the part of individual travelers, as well as the government, private, nonprofit, and academic sectors.

Scope: The scope of the NC-BPAID is limited to promoting the findability, accessibility, interoperability, and reusability (1) of bicycle, pedestrian, and accessibility infrastructure data through the development or endorsement, adoption, and widespread implementation of open standards and practices that support the efficient collection, exchange, and portability of these types of data (2).

Ultimately, the NC-BPAID should foster an independent and sustainable bicycle, pedestrian, and accessibility infrastructure data governance organization that will eventually lead the work of maintaining the specifications, soliciting representative involvement from the broad spectrum of stakeholders.

1. FAIR Data Principles: https://www.go-fair.org/fair-principles/
2. Mobility Data Interoperability Principles: https://www.interoperablemobility.org/

Below are the raw responses from the Google document given out during the meeting. Names and personal identifying information have been removed, but the notes are otherwise in their original form, as to preserve their intent and integrity.

Questions for participants:

1. What do you think about the proposed purpose and scope? What do you like? What needs improvement?

• solid scope
• likes the scope; we may find we need a few specs depending on use cases, and they should work well together.
• looks good. Make sure we distinguish the accessibility of the data and accessibility infrastructure. We’re producing standards, schemas and data interoperability, but not creating data. We also need to think about QA, especially when thinking about data at different scales and how the merging of that data will be used.
• feels like there are too many open standards out there; first step may be a field analysis to understand what’s out there and if it meets the need s. There are all different uses for the data, and we need to get a list of needs collected. We have a broad group and there will be a number of different needs, we need to compile them and analyze them.
• support for understanding the needs for the data and what the purpose is of the data. One of our goals is to develop a standard for this data, but there is already some of this data out there, how are we going to handle this issue? Will we force it into this new standard? Who will the data be available for? How do we capture the physical condition of the infrastructure? Maintenance and frequency of updates.
• the beauty of open source is that folks can come grab the schema and standard and adapt it for their use cases; this is an opportunity to collaborate on data interoperability, not just on bike ped data, but other data in general, especially with a safety focus in mind.
• are there other working groups on transit accessibility? There’s an overlap between the efforts on the transit side. Mentioned CDC’s work.
• GTFS Pathways: https://gtfs.org/schedule/examples/pathways/
• in support of the effort; has experience with communities that have recorded their bike data in five different ways, so it would be nice to be working with a spec.
• The purpose draft is broad and includes a lot of uses.
• That could be okay. The federal trails effort did something similar to keep it open to anyone.
• Is the purpose to advance interoperable data or to advance standards? Draft seems to veer away from standards.
• You need a standard if you’re going to collect data.
• Are we creating a final dataset?
• Vignettes and use cases are helpful for showing what the vision is.
• • For example, illustrate potential end goal, such as City A collects city crosswalk data using real world audit, while City B uses Google imagery / virtual audit. How do you make the data comparable?
• Maybe the scope should stay broad, but vignettes and other guidance help answer what we do first.
• Are we working with AASHTO? AASHTO has specific data management / principles working groups. We should ensure we’re not duplicating work but building on what exists. AASHTO is not focusing on security and data provenance – if state actors are corrupting data, there is nothing to prevent it. On provenance, unless there’s data lineage anyone could make up and distribute data. We need mechanisms to protect the data.
• The GTFS standards process learned that data quality is adhering to specification, and making sure the data reflects the real world. These are challenges the community has to solve. Accountability helps, and so do good incentives to prioritize quality.
• Box off the work into well defined sandboxes, and avoid being way too broad. For example, say we’re talking about crashes or highway deaths, but when you look at patterns over the last few decades, there are different factors related to deaths in urban versus rural environments. If the right information isn’t built into the data for easy access, it’s hard to surface. The formal structure needs to be there. Another example is EV infrastructure, and fitting local or rural EV infrastructure into the national infrastructure – how do we categorize, and what fields do we keep at the top level of the schema.
• We need to add a data quality piece.
• Standards are one component, and if they are not there, everything else downstream will be in chaos. They are the starting point, and they should be upgraded continually. Look at EV chargers as an example. We have L2, L3, etc. chargers. We don’t yet have L5 or L6 chargers, but we will someday. Standards need to be upward and backward compatible.
• No single entity – and especially no single for-profit entity – should own the standards.
• • Current language on this is a good starting point (“public domain,” shared organization for maintenance).
• Standard needs to be changing and dynamic, and it should shift as users and applications change. “Maintaining” means not just maintaining as is, but adapting over time.
• We need to add something after “data” in the purpose statement. Standards is the most important. “Advances data” is vague.
• We want the word “standard” in the purpose. It’s the whole reason we came together.
• Have it say something like “Arrive at interoperable data… by creating standards” or by doing X. Make the purpose less vague.
• “Through the development or endorsement of interoperable standards”
• Are we creating one thing, or are we creating separate bike, ped, accessibility standards and tools?
• We also need an open source, vendor neutral tool that can validate datasets – by reviewing metadata, checking and validating ledgers, check for potentially fake data, and verifying authenticity.
• Like interoperability, but want to explicitly call out who is it interoperable between?
• Need to define:
• • Open source vs public domain vs proprietary/licensed
• Licensing issues
• • Interoperable has many connotations in it -
• Definitions will change and infrastructure of interest also changes
• • Scope should address the expected changes, with an understanding that any specs/standards will need to evolve
• • mostly good and sufficient
• • Flip the scope: dev of data standards come first - emphasize and clarify shared data standards
• • Refer to standard(s) not standard - Polly +1 - family of standards
• • connectivity has to be mentioned in the scope as we want routability to be built in
• • Build in the ability to update and comment by the public - refutability of the data and update it by people on the ground - especially important in a low resource setting such as bike/ped/accessibility data
• • Helpful framing: defining the level of detail for different applications
• • • High level of detail for routing
• • • Low level of detail for reporting
• • Storm diagram communicates fidelity of model systems
• • Tool
• • • Share data to a platform that allows for adding data, but protects against bad actors
• Physical activity research
• • Use these kinds of data
• • Purpose and scope sounds right but pieces need to be defined better

2. Does it adequately represent what you want to get out of participating in this collaboration?

• The purpose draft is broad and includes a lot of uses.
• • That could be okay. The federal trails effort did something similar to keep it open to anyone.
• Is the purpose to advance interoperable data or to advance standards? Draft seems to veer away from standards.
• You need a standard if you’re going to collect data.
• Are we creating a final dataset?
• Vignettes and use cases are helpful for showing what the vision is.
• • For example, illustrate potential end goal, such as City A collects city crosswalk data using real world audit, while City B uses Google imagery / virtual audit. How do you make the data comparable?
• Maybe the scope should stay broad, but vignettes and other guidance help answer what we do first.
• Are we working with AASHTO? AASHTO has specific data management / principles working groups. We should ensure we’re not duplicating work but building on what exists. AASHTO is not focusing on security and data provenance – if state actors are corrupting data, there is nothing to prevent it. On provenance, unless there’s data lineage anyone could make up and distribute data. We need mechanisms to protect the data.
• The GTFS standards process learned that data quality is adhering to specification, and making sure the data reflects the real world. These are challenges the community has to solve. Accountability helps, and so do good incentives to prioritize quality.
• Box off the work into well defined sandboxes, and avoid being way too broad. For example, say we’re talking about crashes or highway deaths, but when you look at patterns over the last few decades, there are different factors related to deaths in urban versus rural environments. If the right information isn’t built into the data for easy access, it’s hard to surface. The formal structure needs to be there. Another example is EV infrastructure, and fitting local or rural EV infrastructure into the national infrastructure – how do we categorize, and what fields do we keep at the top level of the schema.
• We need to add a data quality piece.
• Standards are one component, and if they are not there, everything else downstream will be in chaos. They are the starting point, and they should be upgraded continually. Look at EV chargers as an example. We have L2, L3, etc. chargers. We don’t yet have L5 or L6 chargers, but we will someday. Standards need to be upward and backward compatible.
• No single entity – and especially no single for-profit entity – should own the standards.
• • Current language on this is a good starting point (“public domain,” shared organization for maintenance).
• Standard needs to be changing and dynamic, and it should shift as users and applications change. “Maintaining” means not just maintaining as is, but adapting over time.
• We need to add something after “data” in the purpose statement. Standards is the most important. “Advances data” is vague.
• We want the word “standard” in the purpose. It’s the whole reason we came together.
• Have it say something like “Arrive at interoperable data… by creating standards” or by doing X. Make the purpose less vague.
• “Through the development or endorsement of interoperable standards”
• Are we creating one thing, or are we creating separate bike, ped, accessibility standards and tools?
• We also need an open source, vendor neutral tool that can validate datasets – by reviewing metadata, checking and validating ledgers, check for potentially fake data, and verifying authenticity.
• some level of uniformity; OSM has a very similar WG starting in March; what differences are there from a USDOT perspective vs open source; can we bridge those gaps with this work? Gaps between fed, state, local; state to state; internationally; no spec to rule them all
• Define a minimum standard due to big differences in use cases
• people use these data for different downstream applications; how these data are defined and represented needs to be consistent, especially for routing/wayfinding
• • Truth in data - you say a curb is accessible but don’t justify how it is accessible (this is not a meaningful term); eg., subjective observations
• • Fit for purpose - lots of breaks in a sidewalk for driveways, is that fit for a routing algorithm? Maybe keep that level of detail in another associated system
• • Gap analysis for ITS JPO and USDOT around standards for these kinds of data (network, linear referencing, etc.) - benefit in interoperability but don’t require that everyone support everything
• • Profiles of attributes, data models that you can customize for different downstream applications
• • Truth in data: requiring objectivity in what’s in base data; no “accessible/not accessible” or “passable/not passable” because that is interpreted differently
• • If data is objective (aka measurable?), that allows for neutral downstream interpretation
• • Muddled in pedestrian ways because of different building standards; need to be clear about how those terms are defined
• • Disconnect: level of resources allowable for this kind of data collect and what we need it for
• • Suggestion: base graph be very simple for connectivity, but offer the way for those data to be extensible with different geometries (e.g., points, zones)
• • If we don’t agree on the connectivity, that will be difficult to work together downstream
• • Ability to relate back to linear referencing systems is important
• • Fusion with other datasets for safety, equity, etc. analyses - data integration
• • Acknowledge the big data collections already happening
• • • UW - OpenSidewalks + extensions
• • • WashDOT
• • • Oregon
• • • International efforts - Polly
• • • Georgia ITS4US project