Repository navigation
User research Oct 2026: open requirements (Must/Should) #32
Description
These requirements come out of a user and market study (October 2026) of how comparable tools are used and where users get stuck. Priorities are a proposal based on that study; they have not yet been validated with users of this project. Items already present in the repo are left out.
Must
- Large files (100-500 million points) proven reliable, with known memory use and a clear error when limits are exceeded
- E57 read/write without loss (points, colour, intensity, stations, panoramas), validated against three independent readers
- LAS/LAZ keeps classes, extra bytes, CRS (WKT/GeoTIFF VLR) and scale/offset; no silent coordinate changes
- Test that deleted points stay deleted in every export
- Show coordinates and offset, warn on loss or change; RD (EPSG:28992) + NAP support
- Test and benchmark suite on real scans; no performance figure without hardware details
- Windows 11 and Linux without unusual driver requirements; clear install and error messages
Should
- Read COPC (HTTP range requests), possibly write with validation
- PTX with sensor transformation verified correct
- Light, classified IFC (IfcWall/IfcSlab/...) instead of proxies; point cloud as sidecar reference
- Deviation report (mean/95%/max) for every mesh and plane detection, also on real scans
- DXF output with a manageable number of layers
- First screen 'open, view, measure' without jargon; open sample scans included or linked
- Configurable index location and an index size estimate (network storage)
Activity
boazeggs commentedon Nov 5, 2026
Independent vendor validation now passes in #59 (draft until CI/lint finish). The report and repeatable scripts are in
native/validation/e57-photo-export/.The full-source BLK2GO section export measured 9m31.31s and peak RSS 66,572 KiB on this shared Linux machine. This is section-export evidence, not a full-source GUI colouring benchmark. The added panorama is synthetic; vendor station images and test additions are explicitly separated. #32 remains open for larger-scale, format and other Must/Should acceptance points.
boazeggs commentedon Nov 6, 2026
Aanvullende echte E57-validatie heeft twee interoperabiliteitsfouten gevonden en opgelost in #64, bovenop #63/#62/#53:
1,0werd32767. PDAL las de eerste genormaliseerde intensiteit daardoor als0in plaats van8190. Geschaalde en gemengde grenswaarden worden nu met hun juiste fysieke waarde gelezen en geschreven.De gecorrigeerde exports van de 471-punts BLK2GO-sectie met zes foto's en de volledige Riegl-scan met 1.095.702 punten, vijf stations en vijf foto's slagen met pye57/libE57, PDAL en een E57-geschikte CloudCompare. De volledige puntuitvoer van PDAL en CloudCompare is vóór/na export byte-identiek. De controle met libE57 bevestigt daarnaast de oorspronkelijke puntwaarden/prototypes, fysieke grenzen, rastergrenzen, stations, foto-bytes/calibratie en scanassociaties. De bronhashes zijn ongewijzigd.
Volledige regressie: 1.486 geslaagd, 0 fouten, 12 overgeslagen; Clippy voor alle targets en de minimale core, Rustfmt en Python-controles zijn groen. Alleen caches van bronnen met gecorrigeerde grenswaarden worden vernieuwd; de bestaande cache van het 199-miljoen-punts BLK2GO-bestand blijft geldig.
Herhaalbare controles, toolversies/pins en voor/na-bewijs vermelden ook de beperkingen: deze drie externe toepassingen delen de C++ libE57-familie. CloudCompare behandelt de vijf sferische foto's als gewone afbeeldingen; hun calibratie is via libE57 gecontroleerd. Er worden geen drie onafhankelijk geïmplementeerde externe decoders of alle leveranciersuitbreidingen geclaimd. Eerder getroffen exports moeten opnieuw uit de oorspronkelijke bron worden gemaakt; de verloren schaal kan niet veilig worden geraden.
Neem #64 mee voordat de E57-acceptatie als afgerond wordt beschouwd. #32 blijft open voor de overige brede Must/Should-punten en acceptatie; de bestaande review-heads zijn ongewijzigd.