The bridge inventory form is a single page of 9 collapsible accordion sections (not a wizard). Here is every one of them, and whether it changes.
| # | Accordion section | Verdict | What happens |
|---|---|---|---|
| 1 | Administrative Details | Unchanged | — |
| 2 | Bridge and Location Details | Leave alone | Do not add "Cable Stayed" to Type of Bridge — see below |
| 3 | Construction and Agency Details | Unchanged | — |
| 4 | Carriage Way Details | Changes | One new value in bridge_pier_type + cascade branch |
| 5 | Foundation Details | Main work | New Support Type field + conditional Pylon Details fieldset |
| 6 | Super Structure | Changes | Per-span span type, erection method and deck system + cable anchorage |
| 7 | Approach Details | Unchanged | — |
| 8 | Miscellaneous Details | Unchanged | — |
| 9 | Drawings and Comments | Unchanged | — |
On Mindhola, P2–P5 have pylons; P1, P6, P7, P8 don't. BMS cannot express that today. bridge_component_plans is keyed (bridge_id, component_id) with no location column — a component is either present for the whole bridge or absent from it.
pile_details JSON.Foundation Details already generates one block per support and stores pile_details[2][pier_height]. We add pile_details[2][support_type]. The component plan then just says "Pylon, qty 4"; which four is read from pile_details — exactly as the 2D diagram already reads pier_height per support.
No migration. No change to the plan / progress / roll-up chain. Nothing that touches the other live girder bridges.
In config/constant/dropdowns.php, the bridge_pier_type array (currently 4 items) gains a 5th.
'bridge_pier_type' => [
'title' => 'Bridge Pier Type',
'items' => [
['key' => 'single_pier', 'value' => 'Single Pier'],
['key' => 'portal_pier', 'value' => 'Portal Pier'],
['key' => 'double_pier', 'value' => 'Double Pier'],
['key' => 'double_portal_pier', 'value' => 'Double Portal Pier'],
['key' => 'cable_stayed', 'value' => 'Cable Stayed'], // NEW
]
],
The cascade in carriage-way.blade.php that force-sets the other 7 Common/Separate selects needs a matching branch:
Mindhola is one deck with a median, not twin carriageways — same shape as single_pier.
pointer-events:none once a value exists). An existing bridge cannot be converted to cable-stayed. New bridges only.
One new field drives everything. Toggle it below to see the fields swap.
bridge_pier_type == 'cable_stayed'. Otherwise this field does not exist and nothing changes for existing bridges.Replaces Type of Pier / Height of Pier / Pier Dimensions / Pier Cap fields. Pile and Bearing fields stay — a pylon still sits on piles and still carries bearings.
bridge_inventory.pile_detailsgetSupportMeta() currently labels every interior support "Pn (Pier)". When support_type == 'pylon' it should read "P2 (Pylon)".
pylon_shapeAdded to config/constant/dropdowns.php.
'pylon_shape' => [
'title' => 'Pylon Shape',
'items' => [
['key' => 'h_frame', 'value' => 'H-Frame'],
['key' => 'a_frame', 'value' => 'A-Frame'],
['key' => 'inverted_y', 'value' => 'Inverted Y'],
['key' => 'single_mast', 'value' => 'Single Mast (I)'],
['key' => 'diamond', 'value' => 'Diamond'],
['key' => 'vase', 'value' => 'Vase'],
]
],
export/bridgeform.blade.php resolves labels via dropdownLabel() against the display-only config arrays. If pylon_shape isn't registered there too, the export prints raw keys like h_frame.
Not every span on this bridge is built the same way. That's the whole reason this section changes.
The current form captures one girder configuration per span — a count, a depth, a strand count. That works when every span is a row of precast girders dropped onto pier caps. It breaks here for two reasons:
Only rendered when bridge_pier_type == 'cable_stayed'.
Shown when Cable Supported = Yes.
Shown when Erection Method is a cantilever or segment method — there are no discrete "girders" to count on such a span.
Cable counts are entered per pylon in Foundation Details; anchor spacing is entered per span here. They describe the same cables from two directions, so the form should validate them against each other — this catches a whole class of data-entry error before it reaches progress tracking.
bridge_inventory.super_structure_detailstype_of_bridgeThat dropdown is administrative classification — Major / Minor / ROB / Flyover / River Bridge. Mindhola is a River Bridge. Structure type belongs in Carriage Way Details, not here.
cable_stayed option to super_structure_details[type]That dropdown describes the deck material and form — RCC / PSC / Composite, then solid slab / voided slab / girder slab / box girder. "Cable stayed" isn't a member of that set; it describes how the deck is supported, which is a different axis entirely. Adding it there would break the existing sub-type cascade for no gain.
The cable-stayed information belongs in the new per-span fields added in change 4 above — span_type, cable_supported, erection_method and deck_system. Keep the two axes separate.