Five questions, answered in order. The last one turned up a real defect in the current quantity logic.
A span is the gap between two adjacent supports. A pylon is just a support that happens to be tall — it doesn't create or remove spans. no_of_span stays the single input, supports stay no_of_span + 1, and the location keys a_1, p_1 … p_8, a_2 are unchanged.
What is new: spans are no longer interchangeable. Each one derives a type from its two end supports — and that type decides how the deck and girders are built and counted.
| Span | Length | Start | End | Pylon ends | Derived type |
|---|
The rule is just: 2 pylon ends → main · 1 → back-stay · 0 → approach. Auto-derived in the form, editable if the client's construction plan differs.
A pylon rises continuously from its own pile cap. There is no separate pier wall underneath it, so counting both would double-count the same concrete. What the deck actually lands on at a pylon is the cross beam between the legs — that is the pier-cap equivalent.
| Structural role | At an abutment | At an ordinary pier | At a pylon |
|---|---|---|---|
| Foundation | Pile + Pile Cap | Pile + Pile Cap | Pile + Pile Cap (Ø1500, denser) |
| Vertical element | Abutment Wall | Pier Wall | Pylon (Lower) 158 |
| Deck support | Abutment Cap | Pier Cap | Pylon Cross Beam 160 |
| Above deck | — | — | Pylon (Upper / Mast) 159 |
| Cable system | — | — | Stay Cable 161 |
| Bearings | Yes | Yes | Yes (unchanged) |
Pier Wall and Pier Cap are currently no_of_span - 1 = 8 on this bridge. The correct answer is 4 — only P1, P6, P7, P8. The four pylon supports must be excluded or the same locations get counted twice under different names.
An ordinary pier has 2 components to update at p_1 (Pier Wall, Pier Cap). A pylon has 4 at p_2 — Lower, Cross Beam, Upper, Stay Cable. Same location key, more components. The schema already allows this.
This is the sharpest of the questions, and the current quantity logic gets it badly wrong. The two deck types use girders in opposite proportions.
Cross Girder quantity is hardcoded no_of_span — one per span. That is right for a conventional deck with end diaphragms. On a cable-supported span the cross girders are the primary load path: one at every cable anchor point, transferring deck load into the edge girders and up the cables. Mindhola's P2–P3 span needs 22, not 1.
Left unfixed, the bridge would show 9 cross girders instead of 86 — and physical progress would be wrong for the entire superstructure.
Deck Slab is currently 1 per span. That holds only where the deck is cast as one unit on a launched girder grid. A span built outward from the pylon isn't one deck — it's a run of segments, each cast and then held by the next stay cable.
| Span type | Erection method | Longitudinal | Cross girders | Deck unit |
|---|---|---|---|---|
| Approach | Precast, launched | Girder × n per span | 1 per span | Deck Slab × 1 |
| Back-stay | Cast in-situ on staging | Edge Girder × 2 | = anchors on span | Deck Slab × 1 |
| Main | Balanced cantilever | Edge Girder × 2 | = anchors on span | Deck Segment × n |
This is why erection_method is a per-span field rather than a bridge-wide setting — it's the switch that selects which deck and girder model applies to each span.
| ID | Component | Qty | Derivation |
|---|
This is what the progress-entry location dropdown must offer. Note P2–P5 carry four components each where P1/P6/P7/P8 carry two.
Location keys are unchanged — a_1, p_1 … p_8, a_2 for point components and a_1_p_1, p_1_p_2 … for span components. Only which components appear at each key changes.