Concepts
Why ruumica behaves the way it does, explained without steps.
These pages explain the ideas behind ruumica: how a network is modelled, how heights and datums are handled, why exports never change, how OTDR traces are judged, and how offline work is merged. Read one when a result surprises you. The how-to guides tell you what to do.
| Page | Summary |
|---|---|
| Projects and the network | How ruumica models a network as nodes, spans and cables, and how measurements and evidence attach to it |
| Heights and datums | Why ruumica stores elevations in the national height system, converts GNSS heights itself, and holds a position rather than store it without height |
| Exports never change | Why exporting the same project twice gives identical files, what the freeze instant does, and when ruumica refuses an export |
| OTDR verdicts | How ruumica judges OTDR traces, why one direction is never enough for PASS, and how events are placed on the cable route |
| Offline sync | How work recorded without a network reaches the project, why every device ends up with the same result, and what each status means |
| Profiles and authorities | Why each authority gets its own export profile, what a provisional profile means for your delivery, and what the marking on its files says |
| Roles and access | Who can see and change what in ruumica today, from organisations and sign-in to roles, and who records and signs a delivery |