One comma

A pattern in our sheet reader accepted digits and a minus sign, and nothing else. It met an elevation printed 6,550 — comma and all — and threw the label away before anything downstream could use it. On one plan set, correcting that took the count of readable cross-sections from zero to 26.

Then that same set refused to ship anyway. That is the more useful half of this note.

What the missing comma was sitting on

The pattern is probe_geometry.RE_INT, and it reads ^-?\d{1,4}$ — an optional minus sign, one to four digits, nothing else. It is applied in exactly two places in the code, and both of them are reading the elevation numbers printed up the side of a cross-section sheet: the vertical scale.

Those numbers are what the sheet uses to say how high anything is. Miss them and you do not get a wrong elevation, you get no elevation at all, and everything that depends on one stops before it starts.

The ceiling itself was not the problem here: 6550 is four digits and would have passed. The comma is what killed it. We left the four-digit ceiling in place on purpose — widening it would pull five-digit station numbers in among the vertical-scale labels — so a label printed 10,250 is still rejected, and elevations at or above 10,000 ft stay unread by this route. A test pins that rejection so the boundary is visible rather than accidental. On a Rocky Mountain project it will bite.

Here is what changed on the Colorado set — a corpus set we test against, not one of the five sets we build outputs from — with both label readers taught to strip the separator through one shared helper, and nothing else in the engine changed:

The part that makes it believable is what did not move

Oregon — our shorthand for an FHWA Federal Lands Highway set on the Historic Columbia River Highway, the location rather than the owner — is one of the sets that was already working, and it did not move. A fix that reaches only the sheets that were failing, and leaves the four existing deliveries byte-identical and Oregon's 88 sections unmoved, is one you can check rather than take on faith.

One caveat that has to travel with every count on this page. Across the five sets we build from, we have exported 332 stationed cross-sections — 124 on test1, 104 on FL-003, 88 on Oregon, 15 on FL-011, and 1 on FL-002. That is sections we got out, not coverage and not recall. There is no denominator anywhere in this project for "sections that exist on these sheets", so nobody, us included, can turn 332 into a percentage — the set-by-set breakdown of what 434 pages of plan sets actually yielded states the denominator problem in full. FL-002 makes the point on its own: 28 lines out of 1 of its 116 pages. And none of the outputs currently on disk was produced by the engine at HEAD, so their numbers are history, not a current claim.

Then it refuses to ship

Every delivery we have on disk refuses. All 26 of them — a different 26 from Colorado's 26 cross-sections — carry exportable=false, surface=null, refused=true: zero points, zero faces. No triangles, no dirt model, nothing a machine could be loaded with.

Each one names the same three reasons it stopped: frame_handedness_unconfirmed, alignment_absent, alignment_curvature_unknown. Colorado is refused earlier and for a different reason: station_uniqueness. The engine merged that project's corridors into a single unresolved roadway, so the same station number names two different places on the ground, and anyone asking for that station would get two contradictory sections with no way to choose between them.

In an estimator's words, the first three say: we cannot prove which side of the centreline the sheet is calling left and which it is calling right; we have no alignment to hang the stations on; and we do not know how that alignment curves between them. Any one of those can put a surface in the wrong place on the ground while every number on it still looks reasonable, and a preview would not show it.

Mathyra has never shipped a surface. We would rather hand back a named refusal than a model that looks finished. That reasoning is set out at more length in why the engine refuses instead of guessing.

Reading the numbers was never the hard part

Even with the vertical scale recovered, a cross-section sheet does not tell you which line is finished grade.

Group the lines on a sheet by what the drafter's pen was set to — width, colour, dash pattern — and count how many distinct settings appear per section. On Oregon, between 1 and 7, and only 19 of 86 sections have a single one, meaning only 19 are unambiguous on style alone. On FL-003, between 8 and 15 distinct settings on every one of the 111 sections in this pass — the style pass and the export census count sections differently, which is why this is not the 104 above, and we have not reconciled the two — with 10 settings on 31 sections, 11 on 27, 12 on 28. Zero of 111 are unambiguous.

The legend does not rescue it. On this corpus, legends do not map line styles to surfaces, and the layer names that would settle it live in the PDF's layer metadata rather than printed on the sheet. That is not a criticism of anyone's drafting. A sheet is drawn for a person who also has the typical sections, the profile and the notes in front of them, and it does that job. It was never drawn to be a machine-readable model, and agencies say so themselves — Caltrans ranks "supplemental project information" last of six contract parts in Standard Specifications 5-1.02 (2025 Edition) and describes electronic design files in the subsection of that name — though whether a given project’s model carries that status is set by its special provisions, not by the Standard Specifications, and TxDOT’s PS&E Preparation Manual posts cross sections and 3D models under a section headed "For Information only," with a mandated disclaimer that the data "is for non-construction purposes, only".

One of these problems is ours, not the drawing's

Our chain() joins stroke fragments by endpoint proximity and never asks whether the result is still a single elevation per offset. In the style group where we measured it, 37% of the lines come out multi-valued — two different elevations claimed at the same offset, inside one line.

The worst case we have measured is Oregon page 21, station 40575. A ground line traces out and back across the same offsets, then drops 64.04 ft straight down at offset 39.83, where it runs into the plot frame, one piece of the frame, grid and title-block furniture an extractor mistakes for ground — all inside one exported line. The engine catches these: 305 refusals for the same stated reason, conflicting elevations at a repeated offset. What it does not yet do is fix them. We tried splitting every line at its reversals and the count went from 305 to 305 — the collisions are between the pieces, not inside them. That one is open.

What one comma was actually worth

Not accuracy. External accuracy is unmeasured on this project and v1 says so plainly. Nothing here is a claim about how close our elevations are to the ground.

What it bought is the right to see the next problem on that set. A set producing zero output tells you nothing about what is wrong with it; a set producing 26 readable cross-sections and a named reason for stopping tells you where to look next. That is the whole trade, and it is the same trade behind the half-foot that was not there — which we could only look at because the pipeline ran far enough to be set beside a person reading elevations by hand off the sheet, in a check that sits deliberately outside the v1 gate roster and currently reads FAIL.

The longer version is on how a plan set becomes machine-readable data.