94 lines
4.6 KiB
Markdown
94 lines
4.6 KiB
Markdown
# 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.
|