docs: correct the v0.8 semantic-field scope + flush the working tree - #5
Merged
Conversation
Describe what the pipeline does (archaeological feature extraction and vectorisation) rather than how it does it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…s ours The v0.8 entry described `orthophoto_semantic.tif` as a "material-class field" to be consumed from upstream. Effigies now actually ships that raster (2026-07-26), and it is not material classes: the codes are ground/vegetation/structure from OpenPointClass's stock vehicles-vegetation-buildings model, trained for aerial and urban scenes and near-meaningless on a trench. The fine material classes are Structura's own deliverable — a trained 2D image model fused back onto the mesh by the Effigies multi-view blend — which makes v0.8 a research milestone, not a plumbing one. Record that, the guaranteed properties of the field as delivered, and the field-vs- object contract including the one-way runtime flow. Also note the intake prerequisite: `orthophoto_semantic.tif` matches the "ortho" substring in `intake.discover_inputs` and is silently mis-tagged as an RGB orthophoto, so the open intake-layout decision now gates v0.8. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The intake-layout decision read as a tidy-up ("refine to the actual
WebODM layout"). It is now a correctness issue: `RasterKind` has only
ORTHO and DEM, and the substring test in `discover_inputs` matches
`orthophoto_semantic.tif` on "ortho", so an Effigies output tree feeds
the class raster to the 2D segmenter as if it were a photo, silently.
State the failure mode, the shape of the fix, and the fact that it
gates ROADMAP v0.8.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Documentation only — no code touched, no behaviour change.
Why
Effigies started shipping
odm_semantic/orthophoto_semantic.tifon 2026-07-26. Checking the delivered field against our own docs showed the v0.8 entry had been written against an assumption that no longer holds, and turned up a latent intake bug on the way.What changed
ROADMAP.md— v0.8.0 scope corrected. The entry said "consumeorthophoto_semantic.tif(material-class field)". The raster now exists, and it is not material classes: the codes areground/vegetation/structurefrom OpenPointClass's stockvehicles-vegetation-buildingsmodel, trained for aerial and urban scenes and near-meaningless on a trench. The mechanism is finished; the content is not.The fine material classes (stone / soil / ceramic / mortar) are our deliverable — a trained 2D image model, run per view and fused onto the mesh by the Effigies multi-view blend. That reverses the direction (3D→2D today, 2D→3D planned) and is the only route by which vertical section faces get classified at all. So v0.8 is a research milestone, not plumbing, and the entry now says so and flags that it may warrant its own milestone.
Also recorded: the guaranteed properties of the field as delivered (pixel-identical to ortho and DSM, occlusion-correct, class codes), and the field-vs-object contract including the one-way runtime flow and the paving case.
docs/architecture.md— the intake open decision now names a real failure. It read as a tidy-up. In factRasterKindknows onlyORTHOandDEM, and the substring test indiscover_inputsmatchesorthophoto_semantic.tifon"ortho"— point Structura at an Effigies output tree today and the class raster is handed to the 2D segmenter as if it were a photo, silently. That makes the intake decision a prerequisite for v0.8, and both documents now cross-reference each other.README.md— subtitle reworded, committed separately. This was sitting uncommitted in the working tree; it is unrelated to the above and is here only so it stops leaking into unrelated commits.Not in scope
The intake fix itself (a
SEMANTICkind plus layout-aware discovery) is described, not implemented. The v0.5-vs-v0.8 ordering question is left open — this PR makes the trade-off legible, it does not decide it.🤖 Generated with Claude Code