Files
osmWorkflow/.trellis/tasks/archive/2026-08/08-13-native-road-compiler/prd.md

4.6 KiB

Native road compiler workbench

Goal

Build an incremental native road compiler for Chinese urban and campus OSM data that can progressively exceed osm2streets in geometry quality, explainability, and repeatable correction. The existing osm2streets pipeline must remain usable while the native compiler is developed and compared.

The first deliverable is a browser-based Road Workbench. It must expose the native compiler's source data, generated geometry, and diagnostics, allow users to make small semantic/topology corrections, persist those corrections as versionable overrides, and reload them automatically in later runs.

Confirmed Facts

  • Nantaizi currently works relatively well because its OSM data received deliberate supplemental tagging; it still has missing boundaries and polygons that cannot be closed.
  • Other tested OSM inputs expose osm2streets sensitivity to input structure and leave too much opaque, final-polygon repair work in QGIS.
  • Existing Blender consumes the nine GeoJSON render layers from osm2streets_web_out/; QGIS GeoPackage edits can currently be reimported only as a whole batch.
  • The repository has no existing interactive browser editing service. Existing Cesium preview is a static, generated verification page.

Requirements

  • R1: Add a native-road-compiler path without replacing or regressing the existing osm2streets path.
  • R2: Parse OSM into a canonical, source-traceable road model with stable references to OSM ways and nodes, explicit values versus inferred values, and diagnostics.
  • R3: Compile at least ordinary road segments and the initial supported junction subset into the existing render-layer contract, allowing existing Blender/Cesium consumers to be reused.
  • R4: Provide a browser Road Workbench that overlays raw OSM topology, generated geometry, osm2streets comparison geometry when available, and compiler diagnostics.
  • R5: The workbench must permit scoped user adjustments and save them to an area-local, human-reviewable override file. Future compile and workbench runs must load that file automatically.
  • R6: Each generated object and diagnostic must be traceable to OSM source IDs, compiler rule/inference evidence, and relevant override IDs.
  • R7: Validate topology and geometry before publishing generated layers; report unresolved semantic errors instead of silently disguising them as geometric repair.
  • R8: Develop against nantaizi plus problem inputs and report native versus osm2streets comparison metrics.

Scope Boundaries

  • First implementation targets Chinese urban/campus roads, ordinary road segments, T/cross junctions, directed/multi-lane roads, and data already tagged in nantaizi where possible.
  • Existing Blender, Cesium export, package format, building, vegetation, and water generators are out of scope unless a compatibility adapter requires a narrowly scoped change.
  • Directly editing final render polygons is not the intended correction model; generated layers remain derived output.
  • Complex interchanges, arbitrary multilayer junctions, and full worldwide OSM coverage are deferred until driven by concrete samples.

Acceptance Criteria

  • A native compile command produces a canonical road model, generated layers, diagnostics, and comparison artifacts for a configured area without changing the osm2streets output path.
  • A browser command serves a Road Workbench for an area and clearly shows source topology, generated output, diagnostics, provenance, and saved overrides.
  • A user can make the agreed first-scope override edits in the browser, save them explicitly, and receive a durable area-local override artifact.
  • Re-running compile or reopening the workbench applies saved overrides automatically and exposes their provenance.
  • The compiler reports invalid/unclosed geometry, dangling road ends, and unresolved junction/lane ambiguity with source IDs.
  • Nantaizi and at least one known problematic area can run through the native analysis/preview path, with comparison metrics captured rather than a claim based only on visual inspection.

Key Decisions

  • The first browser editing surface supports road parameters (width, directed lane counts, left/right sidewalk state) plus junction endpoint connect/disconnect decisions.
  • Turn restrictions, stop lines, and crosswalk placement are deferred until the compiler has a validated road/junction editing loop.
  • Overrides are a versioned, human-reviewable JSON artifact owned by the area, not edits to generated polygon layers.
  • Native output and osm2streets output remain parallel during development; neither silently overwrites the other.