Architecture
DE / PLATFORM SYSTEMBuilt to scale from one line to the whole survey.
Dolphin Explorer is organized into five strict layers. The result is a platform where readers, geodesy, rendering, and processing can evolve independently without turning the application into a fragile monolith.
Dependencies point down. Product policy stays out of the rendering and data layers.
Indexed data and processing outputs are preserved with the project across sessions.
The application becomes useful before every byte of a source file is decoded.
System map
Five layers. Clear responsibilities.
Read from the interface down to the shared data model. Higher layers use lower layers; lower layers stay independent of the application above them.
- 01
ui
src/uiSelf-contained Qt features and the application composition root.
- 02
app
src/appProject state, sources, layers, contacts, import classification, processing services, and workers.
- 03
pipeline
src/pipelineNode registry, graph structure, serialization, dirty tracking, and the topological runner.
- 04
util · io · geo · render
src/io, src/geo, src/renderFormat probing, readers, indexing, decoding, parsed artifacts, GDAL raster I/O, CRS handling, and display logic.
- 05
core
src/coreHeader-only survey and spatial data model: pings, traces, navigation, contacts, artifact indexes, raster grids.
SHARED FOUNDATION Business policy belongs in services and coordinators.
User interface
Self-contained features.
Application-wide state and events are coordinated through AppState, ProjectEventBus, and WindowRegistry. src/ui/mainwindow/ is the composition root.
map- 2D/3D spatial display, survey geometry, raster surfaces, and overlays
waterfall- Sidescan waterfall rendering, tools, and contact interaction
subbottom- Sub-bottom profile viewing and interpretation
nodegraph- Visual processing-graph editing
processing- Processing setup, progress, and execution
import- Project entry points and survey import setup
metadata- Source and layer metadata presentation
geodesy- Coordinate-system and geospatial workflows
contacts- Contact browsing, reporting, snapshots, and measurements
datalibrary- Project data and layer organization
export- Image, raster, and related export workflows
Repository
Repository layout.
CMake subdirectories are ordered util → core → io → geo → pipeline → render → app → ui.
Dolphin-Explorer/
|-- cmake/ CMake support and safety checks
|-- resources/ Icons and Qt resources
|-- src/
| |-- core/ Shared data model
| |-- util/ General utilities
| |-- io/ Survey readers, raster I/O, parsed artifacts
| |-- geo/ CRS and sonar geospatial algorithms
| |-- render/ Rendering support
| |-- pipeline/ Processing engine and nodes
| |-- app/ Projects, layers, services, and workers
| `-- ui/ Qt UI features and composition
|-- tests/ Unit, integration, smoke, perf tests
|-- CMakeLists.txt Root CMake configuration
|-- build_mingw.bat Primary configure/build script
|-- build_quick.bat Incremental build helper
|-- build.bat Alternative MSBuild workflow
`-- launch.bat Runtime deployment and launcherConventions
Development conventions.
Dataset identity is based on the normalized absolute path plus a file size and modification-time fingerprint, not a content hash.
- Use C++20 and the existing Qt and CMake patterns.
- Preserve the strict dependency direction: io and pipeline never depend on app, and app never depends on ui.
- Keep business policy out of MainWindow; prefer coordinators or application services.
- Preserve index-first, visible-first loading. Never require full-file decoding just to activate a layer.
- Treat .dlpd files as durable artifacts, not temporary caches.
- Keep unfinished UI actions hidden or disabled instead of shipping clickable placeholders.
- Keep the default concurrency cap of two for heavy import and decode jobs.
- Add or update focused tests when changing readers, persistence, processing nodes, geospatial behavior, or UI policy.
From structure to source
Build it. Explore it.
Set up the toolchain and see how the layers work together.
