How locations divide for progress entry

Three questions — where the deck lives, what happens where the cable section meets the approach, and how this stays compatible with every other bridge in the system.

First, the rule that already exists — and doesn't change

POINT LOCATIONS

a_1 · p_1 … p_8 · a_2

Things that stand at a support: piles, pile caps, walls, caps — and now pylons and stay cables.

SPAN LOCATIONS

a_1_p_1 · p_1_p_2 … p_8_a_2

Things that stretch between supports: girders, cross girders, deck, barriers.

So: you never select P3 and then pick a deck. Deck is a span component. To update deck you select a span — P2–P3 or P3–P4. That is already how BMS works today and nothing about cable-stayed changes it.

But your instinct is right about something else, and it matters ↓

A pylon really does hold deck on both sides — but they're two different spans

On a cantilevered main span the deck isn't built span by span. It grows outward from each pylon in both directions at once, segment by segment, each new segment held by the next stay cable. Two arms from adjacent pylons meet in the middle and are joined by a closure pour. So one span is built by two crews working from opposite ends.

The resolution: keep the span as the location, put the arm in the item number

Location stays p_2_p_3 — consistent with every other span component. The item number records which pylon cast it:

p2_seg_1 … p2_seg_11 ← cast from P2, working toward P3

closure ← the mid-span stitch

p3_seg_1 … p3_seg_11 ← cast from P3, working toward P2

This is the same shape as things BMS already does: pile_1…pile_n at a pier, g_1…g_n in a span. Location identifies where, item number identifies which one. No new concept.

And it answers your question directly: P3's deck work is the p3_seg_* items — which appear in both adjacent spans, P2–P3 and P3–P4. One pylon, two arms, two span locations.

Live — what the progress form offers at each location

Walk through P6 and then P5–P6 vs P6–P7 — that's the transition support case below.

The transition support — where the cable section ends

You asked what happens at the last pier, where one side is cable-supported and the other isn't. On Mindhola that's P6. Its two adjacent spans use completely different deck and girder systems.

SPAN P5 – P6 · back-stay

Deck systemEdge girder

LongitudinalEdge Girder × 2

Cross girders8

Deck unitDeck Slab × 1

Girder (3-step)not offered

Ordinary pier.
Pier Wall + Pier Cap.
No pylon, no cables.

SPAN P6 – P7 · approach

Deck systemGirder grid

LongitudinalGirder × 6

Cross girders1

Deck unitDeck Slab × 1

Edge Girdernot offered

Nothing special is needed for the transition itself. Because deck and girder components are per-span, and each span carries its own erection_method and deck_system from the form, the changeover happens automatically. P6 is just an ordinary pier that happens to have different neighbours.

The real implementation change this forces

Today BridgeComponentPlanRepository::getComponentsLocation() generates the same location list for every component, purely from no_of_span. Every component is offered at every location.

That breaks here. Selecting span P6–P7 must not offer Edge Girder — it doesn't exist there. Selecting P5–P6 must not offer the precast Girder 3-step. Selecting P1 must not offer Stay Cable.

// today — same list for every component
getComponentsLocation($bridge_id)            → ['a_1','p_1',…,'a_2', 'a_1_p_1',…]

// needed — component-aware, derived from the inventory JSON
getComponentsLocation($bridge_id, $componentId)
    Pylon / Stay Cable  → supports where pile_details[i].support_type = 'pylon'
    Pier Wall / Cap     → supports where support_type = 'pier'
    Edge Girder         → spans where super_structure_details[i].cable_supported = 'yes'
    Girder (3-step)     → spans where erection_method = 'precast_launched'
    Deck Segment        → spans where erection_method is cantilever/segment
    Deck Slab           → spans where erection_method is NOT segmental

Still no schema change. Availability is derived from the same two JSON columns the form already writes — pile_details for supports and super_structure_details for spans. Exactly the approach already agreed for pylon placement.

Zero regression for existing bridges. On a plain girder bridge every span is precast-launched and every support is a pier, so every filter passes and the list is identical to today's. The filter only narrows things when the config says so — additive, not a rewrite.

How girders stay consistent across all bridge types

You asked how this is managed alongside every other bridge in the system. The answer is that all four girder-family components share one pattern — span location + item number + optional step — and differ only in how many items and how many steps.

Component	Location	Item numbers	Steps	Appears on
Girder 18	p_6_p_7	g_1 … g_6	3 — cast / stress / launch	precast-launched spans
Edge Girder 163	p_2_p_3	eg_us, eg_ds	2 — cast / stress	cable-supported spans
Cross Girder 10	p_2_p_3	cg_1 … cg_22	none — binary	every span (count varies)
Deck Segment 162	p_2_p_3	p2_seg_n · closure · p3_seg_n	2 — cast / stress	cantilevered spans

Why this matters for the rest of the system: every one of these already fits the existing bridge_component_progress row shape — location + item_number + girder_step. No new table, no new column, and the roll-up services keep treating them as ordinary step-based components. A plain girder bridge is just the case where only the first row applies.

Page 6 of 6 · ← Back to the brief