osmWorkflow/.trellis/tasks/archive/2026-08/08-17-native-road-marking-semantics/prd.md

Native road marking semantics

Goal

Finish the native road marking model so the Nantaizi Road Workbench can persist meaningful centre-line and road-edge-line styles, regenerate native geometry deterministically, and deliver the same result to Blender/Cesium.

Requirements

• Add an explicit double-yellow-solid centre-line semantic. It must not be a generic double-line switch that permits invalid colour/pattern combinations.
• Keep all marking edits area-local in native-road-overrides.json; generated GeoJSON remains derived output.
• Make road edge lines selectable and style-editable in the Chinese Road Workbench, alongside existing centre lines and lane separators.
• Preserve the default Nantaizi output unless a user supplies an override.
• Native geometry must remain independent of osm2streets render geometry.

Acceptance Criteria

• A center-line-style override with double: true, yellow, and solid emits two offset centre-line polygons with an explicit effective style, while invalid double combinations are rejected.
• An edge-line-style override targets one directional road side and supports white/yellow plus solid/dashed styles.
• The Workbench exposes Chinese selection feedback, stages the correct override payload, and only shows the double-yellow choice for centre lines.
• Nantaizi native compile/check, Workbench/native tests, Blender pure tests, and native Blender/Cesium/preview build pass.

Notes

• Keep prd.md focused on requirements, constraints, and acceptance criteria.
• Lightweight tasks can remain PRD-only.
• For complex tasks, add design.md for technical design and implement.md for execution planning before task.py start.