Filed by #244 (p7-s4). Named in osm_mapping.md §2 and §4.
What p7-s4 does today, and the half that already works
OSM tags bridge=yes, tunnel=yes and layer=<n> are read, kept on the import plan, and reported — every such way emits a Warning saying it was imported at grade. They are not authored vertically: OSM carries no elevation, so there is no height to author from.
The correctness half is already done and must not be regressed. layer partitions the shared-node graph before road-end degree is counted, so two ways meeting at a node with different layer values are not joined — no link, no junction — and a Warning names both ways and both layers. Without that rule the import silently welds an overpass to the road beneath it: invisible in plan view, wrong in every 3D consumer. core/tests/test_osm_import.cpp pins it.
So this issue is the feature half: giving the separation a real vertical value.
Scope
- Derive an elevation offset per
layer step and apply it to the road's elevation profile — a default deck clearance is a defaults-registry question (realism_defaults.md), not a literal in the importer.
- Drive
edit::author_bridge for bridge=yes ways so the span is a real <bridge> record rather than only a raised road.
tunnel=yes is the mirror case and probably wants the opposite sign plus no bridge span.- The elevation has to ease rather than step, which is
edit::kGradeEaseLength and the connection contract's grade continuity guarantees — see connection_contract.md.
The trap worth writing down now
A layer value is relative and unitless — layer=1 means "above layer=0 here", not "5 metres up". Two unrelated crossings in the same district both tagged layer=1 are not at the same height. Any implementation that treats layer as a global elevation index will produce a district that is subtly, consistently wrong. The offset must be computed per crossing, from the pair of ways that actually meet.
Filed by #244 (p7-s4). Named in osm_mapping.md §2 and §4.
What p7-s4 does today, and the half that already works
OSM tags
bridge=yes,tunnel=yesandlayer=<n>are read, kept on the import plan, and reported — every such way emits a Warning saying it was imported at grade. They are not authored vertically: OSM carries no elevation, so there is no height to author from.The correctness half is already done and must not be regressed.
layerpartitions the shared-node graph before road-end degree is counted, so two ways meeting at a node with differentlayervalues are not joined — no link, no junction — and a Warning names both ways and both layers. Without that rule the import silently welds an overpass to the road beneath it: invisible in plan view, wrong in every 3D consumer.core/tests/test_osm_import.cpppins it.So this issue is the feature half: giving the separation a real vertical value.
Scope
layerstep and apply it to the road's elevation profile — a default deck clearance is a defaults-registry question (realism_defaults.md), not a literal in the importer.edit::author_bridgeforbridge=yesways so the span is a real<bridge>record rather than only a raised road.tunnel=yesis the mirror case and probably wants the opposite sign plus no bridge span.edit::kGradeEaseLengthand the connection contract's grade continuity guarantees — see connection_contract.md.The trap worth writing down now
A
layervalue is relative and unitless —layer=1means "abovelayer=0here", not "5 metres up". Two unrelated crossings in the same district both taggedlayer=1are not at the same height. Any implementation that treatslayeras a global elevation index will produce a district that is subtly, consistently wrong. The offset must be computed per crossing, from the pair of ways that actually meet.