Rise and fall or height of collimation: which to use, and the check that has to balance

Use rise and fall when the run has change points that matter and you want every one of them proved; use height of collimation when you are setting out many points from one instrument position and speed matters more. On the same booking they give the same levels, and the check is the same for both: the sum of the backsights less the sum of the foresights must equal the sum of the rises less the sum of the falls, and both must equal the last level less the first. When all three agree the backsights, the foresights and the arithmetic are proved. What neither method proves is an intermediate sight, and a run that starts and ends on a benchmark has a misclosure that is either inside the allowance you work to or is a reason to level it again.

The two methods on one booking

Height of collimation. Add the backsight to the level of the point it was taken on and you have the height of the instrument's line of sight. Every reading taken from that setup is subtracted from it: level = height of collimation minus the reading. At a change point the foresight closes the setup and the backsight opens the next, to the same staff position, and the height of collimation moves. It is one addition per setup and one subtraction per point, which is why it is quick and why it is the one used for setting out.

Rise and fall. Compare each reading with the one before it from the same setup. A smaller reading means the staff went up, so the ground rose by the difference; a larger one means it fell. Each level is the previous level plus the rise or minus the fall. It is an extra column of arithmetic per line, and in exchange every line carries its own check, because the rises and falls have to sum to the same thing the backsights and foresights do.

They are not two answers; they are two routes to one answer, and the point of doing both is that agreeing totals can hide two errors that cancel, while agreeing rows cannot. The example below is LEVEL's own: a drainage run from a benchmark on a gatepost, out through two inspection chambers and back to the benchmark, three setups.

The check that has to balance

Three subtractions, and they must give the same number:

• Sum of backsights less sum of foresights: 4.280 − 4.276 = 0.004
• Sum of rises less sum of falls: 4.469 − 4.465 = 0.004
• Last level less first level: 52.484 − 52.480 = 0.004

They agree, so the backsights, the foresights and the arithmetic that joins them are proved. The check is taught everywhere and skipped almost everywhere, because doing it by hand means adding four columns, and every one of them is another chance to make the error you are looking for. That is the case for doing it on the sheet, both ways, while the instrument is still set up and the staff is still on site, rather than in three weeks when a drain runs uphill.

What the check cannot see

An intermediate sight. Read IC 1 cover as 1.310 instead of 1.210 and the level of that one point comes out 100 mm low — and every total stays exactly as it was. The error moves the fall into that line and the rise out of the next by the same amount; the backsights and foresights are untouched; the last level is untouched; the sheet balances perfectly with one level on it wrong. Only a change point is guarded by the check, because a change point's reading is in the totals. An intermediate sight is guarded by reading it twice, or by coming back to it, and by nothing else, which is worth knowing before a cover level or an invert is set off one.

A foresight read wrong does the opposite: read the first change point's foresight as 2.865 and the three totals still agree with each other — the arithmetic is still consistent — but the run finishes 96 mm below the benchmark it started on. That is the closure's job, not the check's.

The misclosure, and what to do with it

A run that starts on a benchmark and returns to one, or to a second known level, finishes at a level that should equal the known one and does not, quite. The difference is the misclosure: here +4.0 mm. Whether that is acceptable depends on how far you went, not on how it feels, and the usual form of the allowance is a constant in millimetres times the square root of the number of setups, because the error accumulates one setup at a time. LEVEL takes the constant you work to; at 5 mm the allowance on three setups is 5√3 = 8.7 mm, and +4.0 is inside it. Some practices use a distance-based form instead, a constant times the square root of the kilometres run; the shape of the test is the same and the constant is whatever your specification says.

Inside the allowance, the error is distributed rather than ignored: shared out in proportion to the setups elapsed, which is where it accumulated, so the levels through the first setup carry none of it and the levels through the last carry all of it. The Corrected column above is that: −2 mm through the second setup, −4 mm through the third, and the benchmark back at 52.480. Those are the levels to write down. Outside the allowance, nothing is written down; the run is levelled again.

What LEVEL does and does not do

LEVEL takes the booking as you took it — station, backsight, intermediate, foresight — with the starting level, the level the run should close on and the allowance you work to. It reduces by height of collimation and by rise and fall independently, compares them row by row, works the three-way check, states the misclosure against the allowance, and distributes the error across the setups. It works with no signal, which is where levelling happens, and nothing is uploaded. It is checked on every build against the same reduction done outside it, including the intermediate-sight error that it says it cannot catch.

It does not know how you booked it in the field, and it cannot tell a misread from a mistyped one. What it can do is make the check cheap enough to run every time, which is the only way the check ever gets run.