Mapillary Vistas as a second supervision source: off-the-shelf baseline, and a path to non-ramp label types

RampNet is curb-ramp-only. Mapillary Vistas is a large, public, street-level
segmentation dataset whose label set overlaps ours, and it offers two independent
things. They are separable, and the first is much cheaper than the second.

1. The one baseline class the comparison roster is missing

docs/model_comparison.md already scores RampNet against eight external models —
gemini-3.1-pro-preview, gemini-3.6-flash, Qwen3-VL-32B/8B, molmo2-8B,
owlv2-large-patch14-ensemble, grounding-dino-base — across all nine city splits and
manual_gold, with a ninth gemini-3.7-flash leg run and published (#20). So the
external-comparison question is well covered. What is not covered is a class:

every challenger in the roster is zero-shot — a prompted general VLM or an
open-vocabulary detector. None is supervised on curb ramps from a different dataset.
The roster answers "can a general model be prompted to do this?"; #51 answers
"architecture vs data within our dataset". Neither answers "do somebody else's
supervised curb-cut labels transfer to deployment panoramas?"

The existing results make that question sharper rather than academic. OWLv2 and
Grounding DINO reach recall 0.85–0.97 at precision 0.03 on richmond: the concept is
findable, the discrimination is not. A supervised-transfer arm tests directly whether
real labels — just not our labels — fix the precision side.

Vistas' label set includes a curb-cut class (construction--flat--curb-cut) and a curb
class (construction--barrier--curb); exact names to be confirmed against the v2.0
label set, and the whole arm is only cheap if that class really exists. A Vistas-trained
segmenter (public Mask2Former / SegFormer checkpoints) is then a zero-training
supervised baseline we can run over the benchmark. It also produces masks rather than
points or boxes, which no roster member does.

Known caveat, and it comes from our own paper. The RampNet paper (arXiv 2508.09415)
already reviewed this exact class and rejected it as a data source: "their categorization
was overly broad and included driveways labeled as curb cuts." So the source labels are
known to be noisy in a specific, accessibility-relevant way — a driveway apron is not a
curb ramp. That does not sink the arm, because "does a model supervised on somebody else's
noisy curb-cut labels transfer?" is still an unanswered and cheap question, and the
driveway confusion is itself measurable against our benchmark (it should show up as a
characteristic FP mode, which fp_taxonomy.py can already name). But it means this must be
framed as a baseline, never as a supervision source for us, and the paper's prior
assessment should be cited rather than rediscovered.

Design constraints, not reasons to skip it:

• Score it through the existing harness. It is model-agnostic (--models), and an
  arm scored any other way is not comparable to the nine legs already run.
• Vistas is perspective imagery, ours is equirectangular. Needs a reprojection pass;
  scripts/box_gallery.py already cuts perspective views out of equirects at a chosen
  FOV, so the input path largely exists. Expect a perspective-biased checkpoint.
• Class semantics are not ours. A Vistas "curb cut" is not the apron + detectable-
  warning pad + flares of our BOX_RULE v2. This is a detector baseline scored by the
  benchmark's point protocol — not a labeling substitute, and not an extent-gold source
  (#114 established that only hand-drawn extent gold is trustworthy here).

2. A route to label types beyond curb ramps

This is the part with the larger payoff, and nothing in the roster touches it. Project
Sidewalk labels Crosswalk, Obstacle, SurfaceProblem, and NoSidewalk in addition to
CurbRamp, and we have no detector for any of them. Vistas carries plausibly-mappable
classes for several (crosswalk markings, sidewalk/road surface, street furniture that
reads as obstacles) — the cheapest path to a second label type that does not start with
a new annotation campaign.

What it does not solve, stated up front so the scope stays honest:

• PS label semantics beyond existence — severity, tags — have no Vistas analogue.
• The point-vs-region question. Crosswalks and surface problems are extended regions,
  not points; ProjectSidewalk/sidewalk-auto-labeler#47's impedance-region work is the
  same question from the other end, and the two should be reconciled before either ships.
• Nothing here is validated. Any new label type needs the GT protocol the curb-ramp arm
  went through (rampnet.validation + a gallery), and that cost is per-label-type.
• Class semantics need auditing per class, not once. The curb-cut class turned out to
  include driveways; assume nothing about the crosswalk or sidewalk classes until each is
  spot-checked the same way.

Verified while filing (2026-08-17): Vistas 2.0 is 124 classes and does carry both Curb
and Curb cut. For contrast, Cityscapes has no curb-related class at all — its full
30-class definition puts road, sidewalk, parking and rail track in the flat group and
stops there — so Vistas is the specific dataset worth the effort here, not scene-parsing
datasets in general.

3. Secondary, and deliberately not scope-driving

Street and sidewalk masks are also a candidate input to the crop-sizing work (#114): the
street/sidewalk boundary is the curb line, so its local tangent gives a ramp's
orientation directly — which matters because the azimuth analysis on #114 showed
orientation is not recoverable from where a ramp sits in the image. Street width in
pixels at the ramp's row is also a metres-per-pixel reference needing neither a
camera-height estimate nor a flat-ground assumption, the two things that break on hilly
cities. Noted so the connection is not lost; it belongs to #114/#83 and should not
expand this ticket.

Suggested first step

Run one Vistas-pretrained checkpoint over ~100 benchmark panos from two cities (one GSV,
one Mapillary), reprojected to perspective views, and eyeball per-class coverage before
committing to anything above. That is an afternoon, and it decides whether either arm is
worth real work.

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

Start with the suggested ~100-pano, two-city run using a Vistas-pretrained checkpoint and the existing --models harness; use scripts/box_gallery.py for perspective reprojection and inspect class coverage. Compare outputs through docs/model_comparison.md and fp_taxonomy.py, then use rampnet.validation and a gallery for any label-type arm; done means a reproducible baseline and audited class semantics.