que01/osmWorkflow
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: consume manifest-driven native roads

Browse Source
This commit is contained in:
que01
2026-08-26 10:55:47 +08:00
parent 5704b51315
commit 620127031e
16 changed files with 349 additions and 97 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/native-road-package-v1.md
View File

@@ -1,6 +1,6 @@
# Native Road Package v1
# Native Road Package v1.1
`native-road-package/v1` defines the boundary between the host area pipeline
`native-road-package/v1.1` defines the boundary between the host area pipeline
and the native road compiler. The compiler accepts only the input below; it
does not read `config/areas/*.json` or derive host paths.
@@ -60,6 +60,14 @@ shape and owns all path derivation.
11. `lane_centerlines.geojson` (semantic, not rendered)
12. `connectors.geojson` (semantic, not rendered)
`manifest.json` is required. It declares the same twelve sources in published
order using `{ source, role, materialLayer?, splitBy? }`. `surface` and
`marking` layers declare a host material slot; `semantic` layers are published
but Blender must not read or render them. A `splitBy` entry has one exact-match
case or more plus exactly one default case, so the legacy white center-line and
yellow lane-separator material routing remains declarative. Consumers reject a
missing/invalid manifest, a source/file mismatch, and unknown material slots.
The editable signal source at `trafficSignalsFile` is a sibling of `outDir`.
It is included in the parity baseline because regeneration must be stable.