Follow-up from review of #227. Not a regression — #227 improves these rows — but it inherits the defect _FORK_ORDER exists to fix, in a basin that doesn't yet have an entry.
Now
santiam|0little|008842|000053 Little North Santiam at Elkhorn
santiam|0little|009345|000112 Little North Santiam at Mehama
santiam|0middle|008960|000104 Middle Santiam at Cascadia
santiam|0middle|009295|999999 Middle Santiam at Green Peter Dam
santiam|0north|008410|000216 North Santiam at Boulder Creek
...
The Little North Santiam is a tributary of the North Santiam, but the label little sorts it above the Middle Santiam — separated from its parent by two gauges it has nothing to do with. By #227's own argument ("fork labels sort alphabetically, which carries no geography"), Santiam wants curating too.
Before #227 these rows sat in their own little north santiam basin over under L, nowhere near the Santiam at all — so this is strictly better, just not right.
Why it isn't a one-liner
Adding "santiam" to _FORK_ORDER cannot fix it. basin_and_fork keeps only the first modifier, so the row's label is little, not north — there is no ordering of (little, middle, north, south) that puts Little North Santiam next to North Santiam, because the key doesn't know it's a north anything. Ordering by elevation doesn't help either: it scatters the four North Santiam gauges and interleaves these two between them (measured while evaluating #227 — that's why _FORK_ORDER is curated rather than elevation-ranked).
The fix is the label-splitting already described in _FORK_ORDER's EF-Salmon caveat: let a fork carry its full modifier chain (north-little?) so it can sort adjacent to its parent, rather than collapsing to the first token. That changes basin_and_fork's contract and touches every compound-fork row (North Fork of Middle Fork Willamette, East Fork of South Fork Salmon), so it wants its own PR and its own look at the rendering.
Related
Same root cause as the EF Salmon (ag 02) / EF of SF Salmon (ag 04) collapse noted in _FORK_ORDER — both reduce to east and can't both be placed. Only the latter has a gauge today, so it's dormant; a future EF Salmon gauge makes it live. One label-splitting change would retire both.
— Claude · Opus-4.8(1M) · x-high
Follow-up from review of #227. Not a regression — #227 improves these rows — but it inherits the defect _FORK_ORDER exists to fix, in a basin that doesn't yet have an entry.
Now
The Little North Santiam is a tributary of the North Santiam, but the label little sorts it above the Middle Santiam — separated from its parent by two gauges it has nothing to do with. By #227's own argument ("fork labels sort alphabetically, which carries no geography"), Santiam wants curating too.
Before #227 these rows sat in their own little north santiam basin over under L, nowhere near the Santiam at all — so this is strictly better, just not right.
Why it isn't a one-liner
Adding "santiam" to _FORK_ORDER cannot fix it. basin_and_fork keeps only the first modifier, so the row's label is little, not north — there is no ordering of (little, middle, north, south) that puts Little North Santiam next to North Santiam, because the key doesn't know it's a north anything. Ordering by elevation doesn't help either: it scatters the four North Santiam gauges and interleaves these two between them (measured while evaluating #227 — that's why _FORK_ORDER is curated rather than elevation-ranked).
The fix is the label-splitting already described in _FORK_ORDER's EF-Salmon caveat: let a fork carry its full modifier chain (north-little?) so it can sort adjacent to its parent, rather than collapsing to the first token. That changes basin_and_fork's contract and touches every compound-fork row (North Fork of Middle Fork Willamette, East Fork of South Fork Salmon), so it wants its own PR and its own look at the rendering.
Related
Same root cause as the EF Salmon (ag 02) / EF of SF Salmon (ag 04) collapse noted in _FORK_ORDER — both reduce to east and can't both be placed. Only the latter has a gauge today, so it's dormant; a future EF Salmon gauge makes it live. One label-splitting change would retire both.
— Claude · Opus-4.8(1M) · x-high