RampNet 2.0: measurement, condition inference, and tagging — we already collect the supervision and discard it at ingest

The thesis

RampNet 2.0 is not "find more curb ramps." It is find + measure + rate + tag — moving from "is there a ramp here?" to "is this ramp usable, and what is wrong with it?"

Detection is the part that is close to done. RampNet holds F1 0.908 on un-anchored gold GT and beats all eight challengers on every benchmark split by 0.19–0.34 F1; the remaining levers are incremental (#54's threshold change bought +7.7 recall for free, #78's TTA bought nothing). The marginal value of a better detector is falling, and the north star — an AI labeler that finds, tags and rates at least as well as humans — is three-quarters unstarted.

And this is the part that street-level imagery uniquely owns. #85 established that aerial orthoimagery already detects curb ramps in production (34k ramps at 1-inch GSD). What aerial structurally cannot do is judge slope, surface condition, obstruction, tactile warning, or whether a ramp points into traffic — all of which need a pedestrian-height viewpoint. Condition inference is therefore the durable differentiator, not a nice-to-have.

The unique data we already have and currently discard

This is the concrete finding. Three separate streams of condition and measurement supervision already flow through this repository, and all three are truncated to geometry at read time:

1. Project Sidewalk severity, tags, and descriptions — dropped on ingest.
stage_one/crop_model/ps_model/data/download_data.py pulls /v2/rawLabels CSV exports from 12 Project Sidewalk city deployments (blackhawk-hills, chicago, cliffside-park, columbus, knox, mendota, newberg, oradell, pittsburgh, sea, st-louis, teaneck) and consumes exactly six columns: Label Type, Agree Count, Disagree Count, Panorama ID, Panorama X/Y, Panorama Width/Height (lines 237–262). Every label's severity rating (1–5), tags, and free-text description are read and thrown away.

That is the crown-jewel dataset for this problem — human accessibility judgments on curb ramps, at scale, with per-label validation counts — and the pipeline uses it purely as a source of pixel coordinates.

2. Government attributes — reduced to three fields.
stage_one/dataset_generation/combine_location_data.py writes all_locations.csv with exactly latitude, longitude, date (line 95). Whatever the source geojson/csv carried — condition, compliance status, slope, width, material, ADA/PROWAG status, remediation history — is discarded at parse time. Municipal ramp inventories frequently carry several of these.

3. Extent — present in the gold set, unused.
manual_labels/*.txt are YOLO-format boxes (class cx cy w h); we have only ever consumed the centers. Noted already in #83, repeated here because it is the same pattern.

What the supervision actually supports

capability	supervision	notes
Tagging	PS tags, multi-label	Vocabulary includes Narrow (<3 ft), Points into cross traffic, Surface problem, Missing tactile warning, and others. Validation counts give a quality filter — the same Agree − Disagree ≥ 2 gate already used for detection
Rating	PS severity 1–5 (ordinal)	5 = impassable barrier for a wheelchair user
Measurement	derived, not annotated	Metric width, slope, landing size — quantities PROWAG actually specifies

The three interlock in a useful way: "Narrow (<3 ft)" is a measurement threshold, not an opinion. So a metric width estimator both predicts that tag and produces a continuous quantity, and the tag becomes a free validation signal for the measurement head.

And the measurement method is already demonstrated on our exact imagery. UrbanVGGT (March 2026) estimates metric sidewalk width from Google Street View — semantic segmentation + feed-forward 3D reconstruction + adaptive ground-plane fitting + camera-height scale calibration — at MAE 0.252 m, 95.5% within 0.50 m. Its ablation finds scale calibration is the critical component, which is the same 2.5 m camera-height trick already in prepare_yolo_dataset.py's pitch strategy. Ground-plane fitting is better conditioned for curb ramps than for the sidewalks it was built for, because a ramp is a ground-plane object by definition. See the #48 prior-art comment for the fuller stack.

Four things that will be genuinely hard — worth stating before anyone designs a model

1. Absence of a tag is not a negative. Most curb ramp labels almost certainly carry no tags at all. Treating untagged labels as negatives makes this a positive-unlabeled problem wearing a multi-label costume, and naive training will learn tag prevalence rather than tag presence. This is the trap most likely to produce a confidently wrong result.
2. Severity is subjective and rater-dependent. #74 already showed rubric confounding on Budapest at low reviewer confidence — and that was a single expert rater on a binary-ish judgment. A 1–5 scale across many volunteers and 12 cities will carry substantial and structured noise. Inter-rater analysis has to come before treating severity as ground truth.
3. Temporal mismatch. PS labels and GSV panoramas both have dates, and condition changes. A 2019 severity rating against a 2023 panorama is measuring a different ramp. This confound does not exist for detection (ramps rarely move) but is central for condition.
4. Extent is a prerequisite for crop-based tagging. PS labels are points; a tagging model needs either a resolved ramp extent (#83) or a fixed crop convention, and the choice will materially affect results.

Proposed first step: a data audit, before any modelling

Cheap, CPU-only, no GPU, and decisive. Pull rawLabels for the 12 cities already in the pipeline and report:

• how many CurbRamp labels carry a severity rating, and the severity distribution per city;
• how many carry ≥1 tag, the tag frequency distribution, and the co-occurrence structure;
• the validation-count distribution (how many survive an Agree − Disagree ≥ 2 style gate with severity/tags attached);
• the distribution of the gap between label date and panorama capture date;
• inter-city variation in all of the above — a proxy for rater-population effects.

That answers "is this supervision dense and clean enough to train on?" before anyone commits GPU time or designs an architecture, and it is committable as a finding either way. If severity turns out to be sparse or wildly inconsistent across cities, that reshapes the whole plan — and is exactly the kind of negative result this repo exists to record.

A second, equally cheap audit: check what attributes the government files in location_data/ actually carry beyond lat/lng/date, since combine_location_data.py discards them sight-unseen.

Structure

Suggest treating this as the umbrella issue for the RampNet 2.0 condition/measurement scope, with the audit above as the first concrete task and separate sub-issues per track (measurement, tagging, severity) once the audit says which are viable.

Related

• #85 — aerial detects but structurally cannot rate; this is the capability that justifies street-level
• #83 — extent/polygons, a prerequisite for crop-based tagging and for measurement
• #48 — multi-view fusion; condition inference benefits from multiple views at least as much as detection does
• #84 — training recipe; any new head (severity, tags, size) is a Stage 2 retrain and inherits that budget question
• #74 — the rater-subjectivity problem, already observed on a much simpler judgment

Note on sourcing: the Project Sidewalk API and labeling-guide pages redirect-loop against automated fetching, so the tag vocabulary above is partial and drawn from secondary sources. The authoritative list should be pulled from the API during the audit.

🤖 Generated with Claude Code (claude-opus-5[1m])

Start by reading stage_one/crop_model/ps_model/data/download_data.py and stage_one/dataset_generation/combine_location_data.py, then inspect the rawLabels inputs and files under location_data/. Report severity, tag, validation-count, and label-to-panorama date distributions for the 12 cities, and record any government attributes beyond latitude, longitude, and date.