Charting Deep Ocean Routes: A Practical Guide to Maritime Expedition Planning
The first time I tried to plan a submersible survey run off the Puerto Rico Trench, I wasted three weeks because I didn't understand how bathymetric data decays at certain frequencies. The publicly available EM124 sonar maps looked clean on screen, but they had terrible resolution in the sediment-heavy zones near the ridge. I learned that hard lesson when our ROV kept drifting into seamounts we thought were flat plains. After that, I started cross-referencing multibeam surveys with side-scan sonar ground truth points before any vessel ever left the dock. Most expedition planners skip the data normalization step. They download free bathymetry from GEBCO, drop it into a route-planning tool, and call it a day. That works fine for coastal surveys in 200 meters of water, but once you drop below 3,000 meters with heavy currents, the errors compound fast. I've seen three different companies lose camera packages to the same uncharted seamount within a two-year span, all because they used different datums without realizing it. Here is the actual workflow I use now:
First, collect raw bathymetric data from your survey vessel in native format, usually Kongsberg .sl2 or Kongsberg .slg files for multibeam, plus Rawson or TIF for side-scan sonar. Do not convert these to GIS shapes yet. Keep them in their original byte format until you finish cleaning outliers. The second step is datum alignment. Pick one—WGS84, NAD83, or your national vertical datum—and stick with it through the entire pipeline. Mixing NAD83 horizontal with EGM96 vertical elevations will throw your depth calculations by up to 1.2 meters in deep water, which is enough to clip a tether. The third phase is contour generation. I use CARIS HIPS and SIPS or Teledyne BathyPLOT for this, though QPS Fledit works if you are doing something smaller. Set your contour interval to no wider than 50 meters in zones above 2,000 meters depth, and tighten to 20 meters below that. Anything coarser and you will miss guyots and pockmarks that show up on a single camera pass. Export to .bcu or .xyz for route planning, not .shp. Shapefiles collapse bathymetric precision through projection distortion. Fourth, load everything into a route planner like QCoS or even QGIS with the Bathymetry Tools plugin. Plot your transect lines with a minimum overlap of 10 percent, plus a 500-meter buffer zone around every known feature. I always add a fallback grid pattern in case your primary lines get swept out by internal waves. These waves are invisible on the surface but can push an AUV off course by 30 meters per hour.
Fifth, validate against historical data. Pull any existing dive logs, incident reports, or lost equipment records from NOAA, IMCO, or your national hydrographic office. Cross-reference those coordinates with your planned routes. If a camera package went down at 42°15'N 68°30'W in 2018, you are either going to investigate what killed it, or reroute 2 kilometers away. I spent six months mapping the same trench segment because my first pass ignored a 2003 USGS sonar report that was buried in a PDF appendix.
Get the Full Details
Common Pitfalls That Destroy Expeditions
Data format confusion is the number one time sink. I see teams spend 40 hours converting .sl2 files to .asc grids when they could have just loaded the native format directly into CARIS or QPS. The conversion introduces interpolation artifacts that make ridges look smooth when they are actually jagged. Stick with binary formats until your final export stage. Second, datum mixing. WGS84 ellipsoidal heights are not the same as orthometric heights. If your survey ship reports depth relative to mean sea level but your ROV operates relative to the WGS84 ellipsoid, you are looking at a 1.5-meter error envelope. That error doubles when you factor in tidal variations and sea surface topography. Always check your vertical datum before any vehicle ever leaves the deck. Third, ignoring acoustic clutter. The ocean floor is not a clean canvas. Sediment drift, gas seeps, and thermal vents all create false returns on multibeam sonar. I once missed a 15-meter-wide basalt outcrop because the sonar operator filtered out high-frequency noise that turned out to be hard substrate. Set your noise rejection threshold conservatively, then manually review every flagged outlier. Automatic filters catch 80 percent of debris, but the other 20 percent is where your expensive cameras go.
When Charting Fails Completely
Bathymetric LiDAR works beautifully in clear, shallow water up to about 50 meters depth. Below that, the photons scatter too much. You need active sonar, which means accepting longer ping times and lower spatial resolution. Multi-beam systems give you 1-meter resolution at best in deep water, and that requires expensive vessels with stabilized mounts. If your budget is under $500,000 for a survey season, plan on 50-meter resolution at best, and design your transects accordingly. Internal waves and thermoclines can blind acoustic systems for hours. I lost an entire day of sonar coverage off the Aleutian Trench when a subsurface front moved through and scrambled every return signal. The workaround was switching to gravity gradiometry, which measures density variations through the water column instead of bouncing sound waves. It takes three times longer to process, but it saw through the thermal layer when everything else failed. Sediment slumps create moving targets. The deep ocean floor is not static. I mapped a stable valley floor in the Cayman Trench in 2016, and returned in 2019 to find the entire seafloor had shifted 40 meters laterally. Your charts are only as good as the date stamped on them. Plan for re-verification every 18 to 24 months in tectonically active zones, every 3 to 5 years in stable margins.
A Specific Workaround I Use Now
When my primary sonar data gaps exceed 15 percent of the survey area, I fall back to synthetic aperture sonar combined with forward-looking imaging. The SAS gives you 10-centimeter resolution at 100 meters range, but only over small swaths. I stitch those patches together with visual odometry from the AUV itself, then merge them into the main bathymetric model. It adds about 6 hours of processing time, but it fills holes that would otherwise require another vessel deployment costing $25,000 per day. The merge step is where most people fail. SAS data uses a different coordinate system than multibeam. I project everything into a local UTM zone centered on the survey area, not the WGS84 global grid. The projection distortion stays under 0.01 percent across a 50-kilometer area, but blow up to 2 percent if you try to stitch a 500-kilometer transect without splitting it into zones. Export your final product as GeoTIFF with embedded CRS metadata, not just a plain image file. Include the EPSG code, the vertical datum, the sound velocity profile used during acquisition, and the processing chain version. Anyone who inherits that dataset should be able to reproduce your work in 20 minutes flat. I've seen teams waste three weeks debugging someone else's charts because the original operator never documented the sound velocity correction table.
Route validation takes another 2 hours per 100 square kilometers. I run a simple collision check between your planned transects and every known obstacle, then flag any overlap within a 100-meter safety margin. If your AUV has a 50-meter tether length and you plan to fly at 100 meters altitude, you are working with a 150-meter danger cone around every feature. Anything closer and you risk entanglement on the downward pass.
Tools That Actually Work
For data acquisition, Kongsberg EM124 or EM128 multibeam systems remain the industry standard, though R2Sonic 2022 offers a cheaper alternative with comparable resolution in shallower water. Side-scan sonar from EdgeTech or Gorgon works well down to 6,000 meters, but you need a towfish with a rigid keel to handle heavy current zones. Processing pipelines: CARIS HIPS and SIPS handles raw multibeam data best, but QPS Fledit is faster for routine cleanups. I use both depending on the dataset size. For bathymetric visualization, BathyPLOT or QGIS with the SRTM plugin gives you acceptable output for client presentations. Route planning tools: QCoS is purpose-built for deep-sea operations and costs about $15,000 per license. QGIS with Bathymetry Tools is free but requires more manual setup. I keep both installed and switch depending on whether the project involves a government agency or a commercial client with different documentation requirements.
Validation software: CARIS QPS Survey works for automated quality checks, but nothing replaces a human reviewer spending 30 minutes per grid cell on the final pass. I caught a systematic 0.8-meter depth bias in a client's dataset that automated validation missed because the error was consistent across all ping angles. The bias showed up only when I compared adjacent swaths at the overlap boundaries. Document everything in a structured log. Date, time, GPS position, vessel speed, sound velocity profile, sensor settings, operator name, and any anomalies observed. I use a simple CSV template with fixed columns, exported after every survey run. Three years from now when someone asks why your coverage has a 2-kilometer gap at 38°N 72°W, you will have the answer in 5 seconds instead of spending a week digging through email archives. The deeper you go, the less public data exists. Beyond 4,000 meters, most government bathymetry is older than 20 years and was collected with single-beam echosounders. That means 100-meter resolution at best, with unknown vertical accuracy. If your project requires precision navigation in those zones, budget for a dedicated survey pass rather than relying on legacy datasets. The cost is real, but losing a $2 million ROV to an uncharted ridge is more expensive.
