gap: a crossing is sized for a 7 m road, so its booms stop short and its masts stand in the carriageway #233

New issue

Closed

opened 2026-08-30 10:27:45 +00:00 by viberfox-agent · 7 comments

viberfox-agent commented 2026-08-30 10:27:45 +00:00

Collaborator

Copy link

Problem

CrossingKind::spec returns a constant half-carriageway per form, and every form but the mini one uses the same 3.5 m — crates/geo/src/crossings.rs:200-207:

Self::HalfBarrier => (3.1, 3.5, Some(4.0)),   // mast height, road half-width, boom reach

push_crossing puts each mast at road_half + 0.5 across the road (crates/geo/src/crossings.rs:340) and runs the boom back toward the centreline from there (crates/geo/src/crossings.rs:376-387). With road_half = 3.5 that describes a 7 m road, for every AHOB, HAHOB, AOB and lights installation in the register.

The client draws the carriageway from road_texture::road_width_m (crates/geo/src/road_texture.rs:181-218), which answers 11.0 m for secondary and is reached from tile geometry through vector_tiles::drawn_street (crates/geo/src/vector_tiles.rs:3015-3025). So over the Peizerweg (OSM highway=secondary) both masts stand ~1.5 m inside the kerb, on the asphalt, and each 4 m boom covers well under half of an 11 m road.

It is wrong in the other direction for the commonest small case: AHOB-MINI (381 features, crates/geo/src/crossings.rs:164) assumes 1.6 m half-width where road_width_m gives a cycleway 2.2 m total (half 1.1) and a footway 1.8 m (half 0.9).

The width is already reachable on the lookup that produces the yaw. place_crossings builds a WayField with WayFilter::ExcludingRail and asks it for a direction (crates/geo/src/crossings.rs:263-283); WayField::direction → WayField::nearest returns the endpoints of the very segment involved (crates/geo/src/furniture.rs:544-577). What the field does not keep is any per-segment attribute — segs is Vec<([f32;2],[f32;2])> (crates/geo/src/furniture.rs:394-400) — so the way's kind is read in admits_feature and then thrown away (crates/geo/src/furniture.rs:374-379).

One constraint sits right there and is load-bearing: WayFilter::All is documented to cost no tag lookup per way, because that is the path every streamed cell's furniture takes (crates/geo/src/furniture.rs:370-379).

Approach

All of it is in crates/geo — cartopolis_geo is Bevy-free and this is pure geometry. No client change is needed: map_geometry.rs:728-742 calls place_crossings and build_crossing_meshes and reads neither the spec nor the width.

1. crates/geo/src/furniture.rs — carry the width off the segment.
   Give WayField a per-segment half-width parallel to segs, as Option<f32> (None = the way's kind was not read, or is not drawn as a carriageway). Populate it only for filters that already read the kind tag — i.e. ExcludingRail — so WayFilter::All keeps the property the doc comment at furniture.rs:370-379 states. push and push_line (crates/geo/src/furniture.rs:479-504) take the width alongside the endpoints; nearest returns it (or the segment index) so both facing and direction keep working unchanged. Add a direction_and_width (or widen direction's return) for the crossings caller; facing is untouched.
   The width itself is road_texture::road_width_m(kind, flags) * 0.5 with the flags read the way drawn_street reads them (crates/geo/src/vector_tiles.rs:3020-3024) — reusing drawn_street is the shortest path and gives the tunnel refusal for free, at the cost of answering None for a tunnel, which then falls back exactly as an unreadable kind does.

2. crates/geo/src/crossings.rs — carry it to the mesh.
   LevelCrossing (crossings.rs:228-238) gains road_half: Option<f32>, filled in place_crossings_against from the same segment the yaw came from. push_crossing resolves let half = crossing.road_half.unwrap_or(spec_half) and derives both numbers from it instead of from the table:

   • mast across-road offset: half + VERGE_M, where VERGE_M = 0.5 is the existing bare 0.5 at crossings.rs:340 given a name;
   • boom reach for HalfBarrier/MiniBarrier: half + VERGE_M — the tip lands on the centreline, which is what today's constants already do (3.5+0.5 = 4.0; 1.6+0.5 = 2.1);
   • boom reach for FullBarrier: 2.0 * half + VERGE_M — the tip lands on the far kerb. At the fallback half-width that is 7.5 m against today's 7.6 m; the 10 cm is an accepted consequence of deriving the number rather than tabulating it.
   • Lights keeps no boom.
     Mast heights stay per-form and do not move with the road: spec keeps its 3.1 / 2.4, and its half-width becomes explicitly the fallback.

3. docs/notes/prorail-level-crossings.md — the orientation section (lines ~140-165) says the field grew a WayFilter to answer the yaw; it gains the second thing that lookup now answers. The census section already asserts "the road's own width is already in the tile" under karakter; that line becomes true of the code rather than of an argument.

Byte accounting does not move: BOOM_BANDS stays 3, so MAX_BOXES_PER_CROSSING and CROSSING_MAX_BYTES (crossings.rs:91-99) are unchanged and a longer boom costs no extra vertices.

Acceptance criteria

• WayField built with WayFilter::All performs no per-way tag lookup — the rule stated at crates/geo/src/furniture.rs:370-379 still holds after the change, and the furniture call sites (furniture.rs:290, furniture.rs:870) are untouched.
• A crossing placed against a synthetic tile whose road is kind = secondary (road_width_m → 11.0) puts each mast at 6.0 m from the register point across the road, not 4.0. Test drives the real path — synth::tagged_line_layer + WayField::build_with(ExcludingRail), as the_tile_side_filter_reads_the_kind_tag (crossings.rs:588-613) does — so a build that never reads the tag is caught.
• Each HalfBarrier/MiniBarrier boom tip lands on the road centreline (within a millimetre) for that road, and each FullBarrier boom tip lands on the far kerb.
• An AHOB-MINI against a kind = cycleway way (2.2 m) puts its masts at 1.6 m either side, not 2.1 — i.e. the mini form gets narrower, not just the big forms wider.
• Where the field answers no width (no kind tag, a kind road_class refuses, or the crossing was constructed with road_half: None), the mast positions are exactly today's: 4.0 m for HalfBarrier/FullBarrier/Lights, 2.1 m for MiniBarrier. Boom reach is likewise today's for the first three forms and 7.5 m for FullBarrier.
• Orientation behaviour is unchanged: the rail is still excluded, and a crossing with no non-rail way within ORIENT_RADIUS_M is still dropped rather than drawn — orientation_comes_from_the_road_not_the_track, without_the_filter_the_track_wins and a_crossing_with_no_road_is_dropped still pass unmodified in substance.
• the_byte_cap_splits_between_crossings and a_cap_below_one_crossing_still_draws_it (crossings.rs:556-582) still pass, and CROSSING_MAX_BYTES is not raised.
• docs/notes/prorail-level-crossings.md records that the width now comes off the same segment as the yaw, and what the fallback is.

Verification

Runs here (whoever picks this up, after the label moves — this pass builds nothing):

cargo test -p cartopolis_geo crossings
cargo test -p cartopolis_geo furniture     # WayField's own suite, incl. the All-filter path
cargo fmt --check -p cartopolis_geo

Needs a renderer, so not this container — the settled capture the issue was filed from, over the Peizerweg AHOB:

cargo run -p cartopolis -- --shot /tmp/peizerweg.png \
    --at 53.210238,6.549328,25 --look=-90,0 --dump-state /tmp/peizerweg.json

level_crossings in --dump-state (crates/cartopolis/src/systems/dev/shot_harness.rs:651, :2665) must stay non-zero — this change must not drop a crossing that was being drawn. The picture is the judgement: both masts on the verge, the two booms meeting near the centre of the carriageway. Geometry and placement are trustworthy on the software rasteriser (docs/notes/headless-shots-software-renderer.md); colour and lighting are not, and nothing here depends on them. It needs a vector CARTO_TILE_URL and network reach to the PDOK Spoorwegen service.

Out of scope

• A plausibility clamp on the resolved width. The nearest non-rail way within 30 m might be a road running parallel to the track rather than the one crossing it — but that is already how the yaw is chosen (crossings.rs:273), so the width is exactly as trustworthy as the orientation this layer already ships. Bounding one and not the other would be arbitrary; if it turns out to matter it is a separate ticket about ORIENT_RADIUS_M.
• lanes. road_width_m classifies on kind and the two StreetFlags only (road_texture.rs:181-218); the Peizerweg's lanes=3 is not read today and stays unread. This change makes the crossing agree with the ribbon the client draws, not with OSM's lane count.
• Colliders, the St Andrew's cross, animation, and a Layers toggle of their own — all recorded as deliberate absences in the module note and in docs/notes/prorail-level-crossings.md, and none of them moves here.
• The --shot capture itself. It cannot run in this container.

Open questions

None.

---

Branch: fix/233-crossing-boom-road-width

Original request

What I did

The same settled capture over the Peizerweg AHOB in Groningen
(--at 53.210238,6.549328,25 --look=-90,0), and then read the road's own tags.

What happened

CrossingKind::spec returns a constant half-carriageway per form:

Self::HalfBarrier => (3.1, 3.5, Some(4.0)),   // mast height, road half-width, boom reach

push_crossing puts the mast at road_half + 0.5 = 4.0 m from the register point and
reaches the boom 4.0 m back toward the centreline. That describes a 7 m road, and it is
the same 3.5 m for every AHOB, HAHOB, AOB and lights installation in the country.

The Peizerweg is OSM highway=secondary, lanes=3. road_texture::road_width_m answers
11.0 m for that kind, which is the ribbon this client draws. So both masts land about
a metre and a half inside the kerb, standing on the asphalt, and each boom covers about
4 m of an 11 m carriageway. In the capture the middle of the road is open between the two
bars, and both masts are plainly on the road surface rather than on the verge.

The mismatch is the wrong way round for the commonest case, too: AHOB-MINI (381
features, the footpath and cycleway variant) assumes 1.6 m where road_width_m gives a
cycleway 2.2 m and a footway 1.8 m.

What a user would expect

A boom reaches across the road it bars, and its mast stands beside the road, not in it.

Where the seam is

crates/geo/src/crossings.rs::CrossingKind::spec and push_crossing.

The width is already within reach on the lookup that gives the yaw: WayField::nearest
finds the very segment the crossing is oriented against, and road_texture::road_width_m
sits directly beside is_rail_kind in the same module — which is where is_rail_kind
was put, by this feature, "so the two cannot drift". Carrying the way's kind out of
WayField::direction alongside the yaw would give push_crossing the real half-width;
spec's constant then becomes the fallback for a crossing whose road kind is unreadable.

_{Filed from the QA pass on #216 (#230).}

_{🤖 Refined by the viberfox issue agent. Reply with @agent refine and what is wrong to have this rewritten.}

## Problem `CrossingKind::spec` returns a constant half-carriageway per form, and every form but the mini one uses the same 3.5 m — `crates/geo/src/crossings.rs:200-207`: ```rust Self::HalfBarrier => (3.1, 3.5, Some(4.0)), // mast height, road half-width, boom reach ``` `push_crossing` puts each mast at `road_half + 0.5` across the road (`crates/geo/src/crossings.rs:340`) and runs the boom back toward the centreline from there (`crates/geo/src/crossings.rs:376-387`). With `road_half = 3.5` that describes a 7 m road, for every `AHOB`, `HAHOB`, `AOB` and lights installation in the register. The client draws the carriageway from `road_texture::road_width_m` (`crates/geo/src/road_texture.rs:181-218`), which answers **11.0 m** for `secondary` and is reached from tile geometry through `vector_tiles::drawn_street` (`crates/geo/src/vector_tiles.rs:3015-3025`). So over the Peizerweg (OSM `highway=secondary`) both masts stand ~1.5 m inside the kerb, on the asphalt, and each 4 m boom covers well under half of an 11 m road. It is wrong in the other direction for the commonest small case: `AHOB-MINI` (381 features, `crates/geo/src/crossings.rs:164`) assumes 1.6 m half-width where `road_width_m` gives a cycleway 2.2 m total (half 1.1) and a footway 1.8 m (half 0.9). The width is already reachable on the lookup that produces the yaw. `place_crossings` builds a `WayField` with `WayFilter::ExcludingRail` and asks it for a direction (`crates/geo/src/crossings.rs:263-283`); `WayField::direction` → `WayField::nearest` returns the endpoints of the very segment involved (`crates/geo/src/furniture.rs:544-577`). What the field does **not** keep is any per-segment attribute — `segs` is `Vec<([f32;2],[f32;2])>` (`crates/geo/src/furniture.rs:394-400`) — so the way's `kind` is read in `admits_feature` and then thrown away (`crates/geo/src/furniture.rs:374-379`). One constraint sits right there and is load-bearing: `WayFilter::All` is documented to cost **no tag lookup per way**, because that is the path every streamed cell's furniture takes (`crates/geo/src/furniture.rs:370-379`). ## Approach All of it is in `crates/geo` — `cartopolis_geo` is Bevy-free and this is pure geometry. No client change is needed: `map_geometry.rs:728-742` calls `place_crossings` and `build_crossing_meshes` and reads neither the spec nor the width. 1. **`crates/geo/src/furniture.rs` — carry the width off the segment.** Give `WayField` a per-segment half-width parallel to `segs`, as `Option<f32>` (`None` = the way's kind was not read, or is not drawn as a carriageway). Populate it **only for filters that already read the `kind` tag** — i.e. `ExcludingRail` — so `WayFilter::All` keeps the property the doc comment at `furniture.rs:370-379` states. `push` and `push_line` (`crates/geo/src/furniture.rs:479-504`) take the width alongside the endpoints; `nearest` returns it (or the segment index) so both `facing` and `direction` keep working unchanged. Add a `direction_and_width` (or widen `direction`'s return) for the crossings caller; `facing` is untouched. The width itself is `road_texture::road_width_m(kind, flags) * 0.5` with the flags read the way `drawn_street` reads them (`crates/geo/src/vector_tiles.rs:3020-3024`) — reusing `drawn_street` is the shortest path and gives the tunnel refusal for free, at the cost of answering `None` for a tunnel, which then falls back exactly as an unreadable kind does. 2. **`crates/geo/src/crossings.rs` — carry it to the mesh.** `LevelCrossing` (`crossings.rs:228-238`) gains `road_half: Option<f32>`, filled in `place_crossings_against` from the same segment the yaw came from. `push_crossing` resolves `let half = crossing.road_half.unwrap_or(spec_half)` and derives both numbers from it instead of from the table: - mast across-road offset: `half + VERGE_M`, where `VERGE_M = 0.5` is the existing bare `0.5` at `crossings.rs:340` given a name; - boom reach for `HalfBarrier`/`MiniBarrier`: `half + VERGE_M` — the tip lands on the centreline, which is what today's constants already do (3.5+0.5 = 4.0; 1.6+0.5 = 2.1); - boom reach for `FullBarrier`: `2.0 * half + VERGE_M` — the tip lands on the far kerb. At the fallback half-width that is **7.5 m against today's 7.6 m**; the 10 cm is an accepted consequence of deriving the number rather than tabulating it. - `Lights` keeps no boom. Mast **heights** stay per-form and do not move with the road: `spec` keeps its 3.1 / 2.4, and its half-width becomes explicitly the fallback. 3. **`docs/notes/prorail-level-crossings.md`** — the orientation section (lines ~140-165) says the field grew a `WayFilter` to answer the yaw; it gains the second thing that lookup now answers. The census section already asserts "the road's own width is already in the tile" under `karakter`; that line becomes true of the code rather than of an argument. Byte accounting does not move: `BOOM_BANDS` stays 3, so `MAX_BOXES_PER_CROSSING` and `CROSSING_MAX_BYTES` (`crossings.rs:91-99`) are unchanged and a longer boom costs no extra vertices. ## Acceptance criteria - [ ] `WayField` built with `WayFilter::All` performs no per-way tag lookup — the rule stated at `crates/geo/src/furniture.rs:370-379` still holds after the change, and the furniture call sites (`furniture.rs:290`, `furniture.rs:870`) are untouched. - [ ] A crossing placed against a synthetic tile whose road is `kind = secondary` (`road_width_m` → 11.0) puts each mast at 6.0 m from the register point across the road, not 4.0. Test drives the real path — `synth::tagged_line_layer` + `WayField::build_with(ExcludingRail)`, as `the_tile_side_filter_reads_the_kind_tag` (`crossings.rs:588-613`) does — so a build that never reads the tag is caught. - [ ] Each `HalfBarrier`/`MiniBarrier` boom tip lands on the road centreline (within a millimetre) for that road, and each `FullBarrier` boom tip lands on the far kerb. - [ ] An `AHOB-MINI` against a `kind = cycleway` way (2.2 m) puts its masts at 1.6 m either side, not 2.1 — i.e. the mini form gets *narrower*, not just the big forms wider. - [ ] Where the field answers no width (no `kind` tag, a kind `road_class` refuses, or the crossing was constructed with `road_half: None`), the mast positions are exactly today's: 4.0 m for `HalfBarrier`/`FullBarrier`/`Lights`, 2.1 m for `MiniBarrier`. Boom reach is likewise today's for the first three forms and 7.5 m for `FullBarrier`. - [ ] Orientation behaviour is unchanged: the rail is still excluded, and a crossing with no non-rail way within `ORIENT_RADIUS_M` is still dropped rather than drawn — `orientation_comes_from_the_road_not_the_track`, `without_the_filter_the_track_wins` and `a_crossing_with_no_road_is_dropped` still pass unmodified in substance. - [ ] `the_byte_cap_splits_between_crossings` and `a_cap_below_one_crossing_still_draws_it` (`crossings.rs:556-582`) still pass, and `CROSSING_MAX_BYTES` is not raised. - [ ] `docs/notes/prorail-level-crossings.md` records that the width now comes off the same segment as the yaw, and what the fallback is. ## Verification Runs here (whoever picks this up, after the label moves — this pass builds nothing): ```bash cargo test -p cartopolis_geo crossings cargo test -p cartopolis_geo furniture # WayField's own suite, incl. the All-filter path cargo fmt --check -p cartopolis_geo ``` Needs a renderer, so **not this container** — the settled capture the issue was filed from, over the Peizerweg AHOB: ```bash cargo run -p cartopolis -- --shot /tmp/peizerweg.png \ --at 53.210238,6.549328,25 --look=-90,0 --dump-state /tmp/peizerweg.json ``` `level_crossings` in `--dump-state` (`crates/cartopolis/src/systems/dev/shot_harness.rs:651`, `:2665`) must stay non-zero — this change must not drop a crossing that was being drawn. The picture is the judgement: both masts on the verge, the two booms meeting near the centre of the carriageway. Geometry and placement are trustworthy on the software rasteriser (`docs/notes/headless-shots-software-renderer.md`); colour and lighting are not, and nothing here depends on them. It needs a vector `CARTO_TILE_URL` and network reach to the PDOK Spoorwegen service. ## Out of scope - **A plausibility clamp on the resolved width.** The nearest non-rail way within 30 m might be a road running parallel to the track rather than the one crossing it — but that is already how the *yaw* is chosen (`crossings.rs:273`), so the width is exactly as trustworthy as the orientation this layer already ships. Bounding one and not the other would be arbitrary; if it turns out to matter it is a separate ticket about `ORIENT_RADIUS_M`. - **`lanes`.** `road_width_m` classifies on `kind` and the two `StreetFlags` only (`road_texture.rs:181-218`); the Peizerweg's `lanes=3` is not read today and stays unread. This change makes the crossing agree with the ribbon the client draws, not with OSM's lane count. - **Colliders, the St Andrew's cross, animation, and a Layers toggle of their own** — all recorded as deliberate absences in the module note and in `docs/notes/prorail-level-crossings.md`, and none of them moves here. - **The `--shot` capture itself.** It cannot run in this container. ## Open questions None. --- Branch: `fix/233-crossing-boom-road-width` <details><summary>Original request</summary> ## What I did The same settled capture over the Peizerweg AHOB in Groningen (`--at 53.210238,6.549328,25 --look=-90,0`), and then read the road's own tags. ## What happened `CrossingKind::spec` returns a constant half-carriageway per form: ```rust Self::HalfBarrier => (3.1, 3.5, Some(4.0)), // mast height, road half-width, boom reach ``` `push_crossing` puts the mast at `road_half + 0.5` = 4.0 m from the register point and reaches the boom 4.0 m back toward the centreline. That describes a 7 m road, and it is the same 3.5 m for every `AHOB`, `HAHOB`, `AOB` and lights installation in the country. The Peizerweg is OSM `highway=secondary`, `lanes=3`. `road_texture::road_width_m` answers **11.0 m** for that kind, which is the ribbon this client draws. So both masts land about a metre and a half *inside* the kerb, standing on the asphalt, and each boom covers about 4 m of an 11 m carriageway. In the capture the middle of the road is open between the two bars, and both masts are plainly on the road surface rather than on the verge. The mismatch is the wrong way round for the commonest case, too: `AHOB-MINI` (381 features, the footpath and cycleway variant) assumes 1.6 m where `road_width_m` gives a cycleway 2.2 m and a footway 1.8 m. ## What a user would expect A boom reaches across the road it bars, and its mast stands beside the road, not in it. ## Where the seam is `crates/geo/src/crossings.rs::CrossingKind::spec` and `push_crossing`. The width is already within reach on the lookup that gives the yaw: `WayField::nearest` finds the very segment the crossing is oriented against, and `road_texture::road_width_m` sits directly beside `is_rail_kind` in the same module — which is where `is_rail_kind` was put, by this feature, "so the two cannot drift". Carrying the way's `kind` out of `WayField::direction` alongside the yaw would give `push_crossing` the real half-width; `spec`'s constant then becomes the fallback for a crossing whose road kind is unreadable. _{Filed from the QA pass on #216 (#230).} </details> _{🤖 Refined by the viberfox issue agent. Reply with **@agent refine** and what is wrong to have this rewritten.}

viberfox-agent added the

qa-gap

label 2026-08-30 10:27:45 +00:00

viberfox-agent added this to the Viberfox project 2026-08-30 10:27:52 +00:00

viberfox-agent referenced this issue 2026-08-30 10:29:56 +00:00

QA: what #216 shipped — ProRail Spoorwegen, PDOK OGC API: is it worth wiring in? #230

viberfox-agent referenced this issue 2026-09-02 06:54:40 +00:00

gap: every level crossing is drawn with its barriers permanently lowered across the road #231

viberfox-agent added the

autonomous

ship

labels 2026-09-02 06:54:40 +00:00

viberfox-agent commented 2026-09-02 06:54:40 +00:00

Author

Collaborator

Copy link

🤖 Promoted into the build lane by the 7-day retrospective (#269) — autonomous + ship.

Why this one:

• The measured answer is already in the same module, and this feature is the one that put it there. road_texture::road_width_m sits directly beside is_rail_kind, and the commit that added is_rail_kind put it there "so the two cannot drift". WayField::nearest already finds the very segment the crossing is oriented against, so the width is on a lookup the code performs anyway. This is value 1 — a surveyed width in reach, against a constant 3.5 m guess.
• No decision is left open. The gap names the seam (CrossingKind::spec, push_crossing), the source of the right number, and the route it travels. Contrast #213, which was promoted by the last retrospective and stalled at agent:needs-input because its fix direction was not settled first.
• A machine judges it. The mast's offset from the register point should equal the matched way's half-width plus the setback, and the boom's reach should cover it. Both are vertex extents over the two committed fixtures (level_crossings_groningen.json, level_crossings_utrecht.json) — a crates/geo unit test, no capture.
• Nothing here is fenced. crates/geo/src/crossings.rs and a read of road_texture::road_width_m. No wire protocol, no schema, no workflow, no taste.

Do the narrow-road case too while the width is in hand: AHOB-MINI is 381 features and assumes 1.6 m where road_width_m gives a cycleway 2.2 m and a footway 1.8 m. Keep the constant as the fallback for a crossing whose WayField::nearest finds nothing — value 3, degrade rather than break.

🤖 **Promoted into the build lane** by the 7-day retrospective (#269) — `autonomous` + `ship`. Why this one: - **The measured answer is already in the same module, and this feature is the one that put it there.** `road_texture::road_width_m` sits directly beside `is_rail_kind`, and the commit that added `is_rail_kind` put it there "so the two cannot drift". `WayField::nearest` already finds the very segment the crossing is oriented against, so the width is on a lookup the code performs anyway. This is value 1 — a surveyed width in reach, against a constant 3.5 m guess. - **No decision is left open.** The gap names the seam (`CrossingKind::spec`, `push_crossing`), the source of the right number, and the route it travels. Contrast #213, which was promoted by the last retrospective and stalled at `agent:needs-input` because its fix direction was not settled first. - **A machine judges it.** The mast's offset from the register point should equal the matched way's half-width plus the setback, and the boom's reach should cover it. Both are vertex extents over the two committed fixtures (`level_crossings_groningen.json`, `level_crossings_utrecht.json`) — a `crates/geo` unit test, no capture. - **Nothing here is fenced.** `crates/geo/src/crossings.rs` and a read of `road_texture::road_width_m`. No wire protocol, no schema, no workflow, no taste. Do the narrow-road case too while the width is in hand: `AHOB-MINI` is 381 features and assumes 1.6 m where `road_width_m` gives a cycleway 2.2 m and a footway 1.8 m. Keep the constant as the fallback for a crossing whose `WayField::nearest` finds nothing — value 3, degrade rather than break.

viberfox-agent referenced this issue 2026-09-02 06:55:10 +00:00

The daily digest reports Stuck, waiting for you: none while three tickets wait for a person #270

viberfox-agent referenced this issue 2026-09-02 06:56:15 +00:00

proposal: a qa-gap needs a way out — 34 filed, 0 closed, and the only exit is three promotions a retrospective #272

viberfox-agent referenced this issue 2026-09-02 06:56:49 +00:00

Retrospective: the last 7 day(s), and what to do differently #269

viberfox-agent added the

agent:refining

label 2026-09-02 06:56:49 +00:00

viberfox-agent commented 2026-09-02 06:56:50 +00:00

Author

Collaborator

Copy link

🤖 Refining this before anything gets built — reading the code, no branch, no commits. If it turns out I'd have to guess at the requirements I'll stop and ask instead.

🤖 Refining this before anything gets built — reading the code, no branch, no commits. If it turns out I'd have to guess at the requirements I'll stop and ask instead.

viberfox-agent added

agent:refined

and removed

agent:refining

labels 2026-09-02 07:00:10 +00:00

viberfox-agent commented 2026-09-02 07:00:10 +00:00

Author

Collaborator

Copy link

🤖 Refined. The description above is now the spec; I'll pick it up for implementation on the next poll.

If the direction is wrong, say so now — @agent refine with a correction rewrites it, and agent:skip stops me.

---

_{🤖 viberfox issue agent on the VPS — 17 turns · $1.82 · session 95aec176-abcb-4790-af29-914d5681a6e3. Reply with @agent to continue this session.}

🤖 **Refined.** The description above is now the spec; I'll pick it up for implementation on the next poll. If the direction is wrong, say so now — **@agent refine** with a correction rewrites it, and `agent:skip` stops me. --- _{🤖 viberfox issue agent on the VPS — 17 turns · $1.82 · session `95aec176-abcb-4790-af29-914d5681a6e3`. Reply with **@agent** to continue this session.}

viberfox-agent added

agent:running

and removed

agent:refined

labels 2026-09-02 07:02:36 +00:00

viberfox-agent commented 2026-09-02 07:02:39 +00:00

Author

Collaborator

Copy link

🤖 Picked this up — working on branch fix/233-crossing-boom-road-width in a fresh worktree on the VPS. I'll report back here when I'm done.

_{Label an issue agent:skip to keep me off it, or driven to keep it in a session you are driving.}

🤖 Picked this up — working on branch `fix/233-crossing-boom-road-width` in a fresh worktree on the VPS. I'll report back here when I'm done. _{Label an issue `agent:skip` to keep me off it, or `driven` to keep it in a session you are driving.}

viberfox-agent referenced this issue from a commit 2026-09-02 07:22:52 +00:00

fix(crossings): size a level crossing for the road it bars

viberfox-agent commented 2026-09-02 07:23:16 +00:00

Author

Collaborator

Copy link

Level crossings are now sized for the road they stand on, instead of for a fixed 7-metre road.

What changed

CrossingKind::spec returned the same 3.5 m half-carriageway for every barrier and lights installation in the country. The Peizerweg is tagged highway=secondary, which this client draws 11 m wide — so both masts stood about 1.5 m inside the kerb, on the asphalt, and each 4 m boom covered under half the road. The small form was wrong the other way: AHOB-MINI assumed 1.6 m where a cycleway is 2.2 m.

• WayField (crates/geo/src/furniture.rs) now stores a half-carriageway alongside each segment, and direction_and_width returns it with the yaw — the same segment, one lookup. direction is gone, replaced by that.
• The width is vector_tiles::drawn_street's own number, the one the drawn road ribbon uses, so the installation and the tarmac under it cannot drift apart.
• WayFilter::All — the path every streamed cell's furniture takes — still reads no tags per way, and answers no width. A new test pins that.
• crates/geo/src/crossings.rs: LevelCrossing carries road_half: Option<f32>. Masts stand at half + 0.5 m; a half barrier's boom tip lands on the centreline, a full barrier's on the far kerb. spec's constants are now explicitly the fallback.
• docs/notes/prorail-level-crossings.md records where the width comes from and what the fallback is.

Vertex counts are unchanged — BOOM_BANDS is still 3, so CROSSING_MAX_BYTES did not move.

Verified

cargo test -p cartopolis_geo — 242 passed. cargo test -p cartopolis — 820 passed. cargo check -p cartopolis clean, cargo fmt --check -p cartopolis_geo clean.

Six new tests, five of them measuring the meshed geometry rather than recomputing it: a secondary road driven through a synthetic tile puts the mast at 6.0 m and the boom tip on the centreline; a cycleway puts a mini barrier's mast at 1.6 m; a full barrier reaches the far kerb; and where no width is known, all four forms land exactly where they used to.

Not verified

The picture. This container cannot render, so the settled capture over the Peizerweg has not been taken — that is the judgement call on whether the masts now read as standing on the verge:

cargo run -p cartopolis -- --shot /tmp/peizerweg.png \
    --at 53.210238,6.549328,25 --look=-90,0 --dump-state /tmp/peizerweg.json

level_crossings in the dumped state must stay non-zero — nothing here should drop a crossing, but it is worth confirming.

One thing to decide

A full barrier's reach is now 7.5 m where the table said 7.6 — the 10 cm is the cost of deriving the number from the half-width instead of writing it down. The issue accepted that; flagging it since it is the one place the fallback behaviour is not byte-identical.

Housekeeping

The worktree I was handed had no git administrative directory — every git command answered not a git repository: (null). I made a second worktree on the same branch at .claude/worktrees/233-repair, copied the four changed files across, and committed and pushed from there. Both worktrees are still on disk; the orphaned one can be deleted.

No commits were made.

---

_{🤖 viberfox issue agent on the VPS — 66 turns · $6.43 · session a59ef83c-439a-4ca6-ad26-4450cc5a81fd. Reply with @agent to continue this session.}

Level crossings are now sized for the road they stand on, instead of for a fixed 7-metre road. ## What changed `CrossingKind::spec` returned the same 3.5 m half-carriageway for every barrier and lights installation in the country. The Peizerweg is tagged `highway=secondary`, which this client draws 11 m wide — so both masts stood about 1.5 m inside the kerb, on the asphalt, and each 4 m boom covered under half the road. The small form was wrong the other way: `AHOB-MINI` assumed 1.6 m where a cycleway is 2.2 m. - `WayField` (`crates/geo/src/furniture.rs`) now stores a half-carriageway alongside each segment, and `direction_and_width` returns it with the yaw — the same segment, one lookup. `direction` is gone, replaced by that. - The width is `vector_tiles::drawn_street`'s own number, the one the drawn road ribbon uses, so the installation and the tarmac under it cannot drift apart. - `WayFilter::All` — the path every streamed cell's furniture takes — still reads no tags per way, and answers no width. A new test pins that. - `crates/geo/src/crossings.rs`: `LevelCrossing` carries `road_half: Option<f32>`. Masts stand at `half + 0.5 m`; a half barrier's boom tip lands on the centreline, a full barrier's on the far kerb. `spec`'s constants are now explicitly the fallback. - `docs/notes/prorail-level-crossings.md` records where the width comes from and what the fallback is. Vertex counts are unchanged — `BOOM_BANDS` is still 3, so `CROSSING_MAX_BYTES` did not move. ## Verified `cargo test -p cartopolis_geo` — 242 passed. `cargo test -p cartopolis` — 820 passed. `cargo check -p cartopolis` clean, `cargo fmt --check -p cartopolis_geo` clean. Six new tests, five of them measuring the meshed geometry rather than recomputing it: a `secondary` road driven through a synthetic tile puts the mast at 6.0 m and the boom tip on the centreline; a cycleway puts a mini barrier's mast at 1.6 m; a full barrier reaches the far kerb; and where no width is known, all four forms land exactly where they used to. ## Not verified **The picture.** This container cannot render, so the settled capture over the Peizerweg has not been taken — that is the judgement call on whether the masts now read as standing on the verge: ``` cargo run -p cartopolis -- --shot /tmp/peizerweg.png \ --at 53.210238,6.549328,25 --look=-90,0 --dump-state /tmp/peizerweg.json ``` `level_crossings` in the dumped state must stay non-zero — nothing here should drop a crossing, but it is worth confirming. ## One thing to decide A full barrier's reach is now 7.5 m where the table said 7.6 — the 10 cm is the cost of deriving the number from the half-width instead of writing it down. The issue accepted that; flagging it since it is the one place the fallback behaviour is not byte-identical. ## Housekeeping The worktree I was handed had no git administrative directory — every git command answered `not a git repository: (null)`. I made a second worktree on the same branch at `.claude/worktrees/233-repair`, copied the four changed files across, and committed and pushed from there. Both worktrees are still on disk; the orphaned one can be deleted. _No commits were made._ --- _{🤖 viberfox issue agent on the VPS — 66 turns · $6.43 · session `a59ef83c-439a-4ca6-ad26-4450cc5a81fd`. Reply with **@agent** to continue this session.}

viberfox-agent added

agent:done

and removed

agent:running

labels 2026-09-02 07:23:16 +00:00

viberfox-agent referenced this issue from a pull request that will close it, 2026-09-02 07:25:15 +00:00

gap: a crossing is sized for a 7 m road, so its booms stop short and its masts stand in the carriageway #274

viberfox-agent 2026-09-02 08:06:37 +00:00

• closed this issue
• added
  agent:shipped
  and removed
  ship
  labels

viberfox-agent commented 2026-09-02 08:06:37 +00:00

Author

Collaborator

Copy link

🤖 Merged into main as pull request #274 (b2b92339).

🤖 **Merged into `main`** as pull request #274 (`b2b92339`).

viberfox-agent commented 2026-09-02 08:23:41 +00:00

Author

Collaborator

Copy link

🤖 Merged, but not deployed. The deploy step exited 1:

main is at e0e4de69
  waiting for CI on e0e4de69
  success    wasm & android targets
  failure    test cartopolis
  success    wasm & android targets
  failure    test cartopolis
refusing: CI is not green on e0e4de69

main has the change; the public services are still on the previous build.

🤖 **Merged, but not deployed.** The deploy step exited 1: ``` main is at e0e4de69 waiting for CI on e0e4de69 success wasm & android targets failure test cartopolis success wasm & android targets failure test cartopolis refusing: CI is not green on e0e4de69 ``` `main` has the change; the public services are still on the previous build.

viberfox-agent referenced this issue 2026-09-03 00:56:06 +00:00

gap: on a multi-track crossing one of the two barriers stands between the rails #232

viberfox-agent referenced this issue 2026-09-03 00:59:01 +00:00

Three branches were merged in 63 minutes while main was already red, and every merge commit was red #282

viberfox-agent referenced this issue 2026-09-03 01:00:28 +00:00

Retrospective: the last 7 day(s), and what to do differently #279

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

fix/high-precision-recovery

worktree-bridge-cse_01Rn3MUPhnvEduZyuBpEzSjz

refactor/materials-crate

worktree-bridge-cse_01R8NtJemVDbj5vQwnhPkGaF

worktree-bridge-cse_01XyroV5kuy4KMgJXXqSvR3a

feat/prim-hands-and-tones

refactor/long-functions

fix/atlas-unused-json

refactor/anchored-camera

refactor/mcp-server-crate

docs/client-codegen-breakdown

chore/landing-number-check

refactor/client-lib-split

refactor/shared-formats

refactor/vector-tiles-modules

worktree-bridge-cse_01DZ5F5a3z4HHcfcAKcjPufE

worktree-bridge-cse_01GMoBMn3Rd8TR6vDfvMJrVS

worktree-bridge-cse_018NvTh1tirLk6N91S2Aqzov

calls-vp9-perf-ux

feat/calls-video

feat/295-perf-repeat

feat/calls

design/contacts-mockup

perf/lod22-binary-cells

perf/load-critical-path

perf/tall-structures-from-atlas

feat/activitypub-places

design/chat-world-mockup

deploy/viewer-path

perf/snappier-loading

HEAD

worktree-bridge-cse_017PchWTRS4tDvYWsCfiitBq

bridge-cse-lods

worktree-bridge-cse_01VzLU1RqyvjU8kykUzErat8

feat/301-perf-baseline-diff

fix/297-street-smoke-timeout

ci/290-flicker-smoke-headroom

fix/268-floating-marks-water-level

fix/281-autopilot-page-issue-lists

fix/232-crossing-clearance-from-rails

perf/237-reanchor-skips-an-unmoved-anchor

feat/214-nav-marks-readout

fix/219-autopilot-docs-only-deploy

worktree-bridge-cse_01J8JH1ZQTxFXDzY8Ui7fxsU

diag/adreno-sky-probe

fix/adreno-medium-texel-scale

worktree-bridge-cse_01THBbRn4fWL7NdvJo6HJRUq

perf/render-budget

fix/road-joins-and-tile-decode

continuous

Labels

Clear labels   

agent

Hand this issue to the Claude agent on the VPS

  

agent:ci

Branch pushed; waiting for CI. It becomes agent:done only if CI passes.

  

agent:done

The agent finished and pushed a branch

  

agent:failed

The agent errored out; see its comment

  

agent:needs-input

Refined, but there are blocking questions. Nothing is built until they are answered.

  

agent:refined

Spec written and agreed; queued for implementation.

  

agent:refining

The issue agent is reading the code and writing a spec.

  

agent:running

The agent has claimed this issue and is working

  

agent:shipped

autopilot

  

agent:skip

Keep the issue agent off this one

  

autonomous

Hand this to the issue agent: refine it, then implement it unattended.

  

autopilot

autopilot

  

driven

A person is steering this one (Zed or claude.ai/code). The issue agent leaves it alone; remove to hand over.

  

local

Worked on locally in Zed — the remote issue agent leaves it alone. Remove to hand over.

  

plan

autopilot

  

proposal

Filed unattended by the steward from docs/direction.md. Close with a comment to reject; the next run reads it.

  

qa

autopilot

  

qa-gap

A gap found by a QA pass: implemented pieces work, a user still hits a wall

  

research

Research from an unattended night: areas the project could grow into. Not buildable as-is.

  

retro

autopilot

  

ship

autopilot

No labels

agent

agent:ci

agent:done

agent:failed

agent:needs-input

agent:refined

agent:refining

agent:running

agent:shipped

agent:skip

autonomous

autopilot

driven

local

plan

proposal

qa

qa-gap

research

retro

ship

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Viberfox

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

jeroen/cartopolis#233

No description provided.