Problem Statements

Track 1: Website / UI

This track is about designing and building new features for the RideScore DC interface — everything a user actually touches and sees. Teams will work with a ready-to-go HTML/Docker environment built on the MapLibre frontend and PostGIS/Martin tile backend, so you can plug in and start building rather than setting up infrastructure from scratch. Open problems include: letting users submit or input their own street safety scores or observations, adding ways for riders to flag hazards or leave feedback on a segment, improving mobile responsiveness, and rethinking how the map communicates safety information at a glance.

Track 2: Bike Safety Models

RideScore DC currently scores streets using a modified Level of Traffic Stress (LTS) model and a Bicycle Network Analysis (BNA) model, with CycleRAP parameters also mapped out. This track is open-ended: participants can build any bicycle-safety-relevant model of their choosing — it doesn't need to fit within RideScore DC's existing methodologies. You'll have access to a completed data pipeline and dataset (OSM enriched with DC Open Data, conflated against the DC Roadway SubBlock spine) with setup instructions, so you can focus on the modeling problem itself. Ideas include: new or hybrid stress/safety scoring approaches, models that weight specific risk factors (intersections, bike lane type, traffic volume, lighting), predictive models for crash risk, or exploratory analyses that surface patterns the existing models miss.

Track 3: Community Research Track

Who is RideScore for? Cyclists, scooter riders, policy makers, advocacy groups, etc? In this community and user research track, we explore who we think RideScore DC is built for and what we need to ask of users to understand the map … can they trust it, can they use it to make decisions? You don’t need to code or be a bike-safety expert, it’s your fresh perspective and diversity of thought that’s the point. Teams will work from a kit of persona cards, testing guides, and shared templates to start researching. Open problems include testing the map with users to find what’s confusing, comparing street scores with rider (or pedestrian) experience, reviewing how accessible the map is and how well it serves riders across all of DC’s wards, writing accessible and plain-language explanations of how the score works and what it can’t tell you, and comparing RideScore DC with peer bike-safety tools.