Getting Your Bathymetric Data Into a usable Format
Most people hit a wall the first time they try to merge raw sonar surveys with modern chart standards. I spent three weeks wrestling with a single multibeam dataset from a charter fishing boat in the Gulf, trying to get it to line up with NOAA test charts, before I figured out what was actually going wrong. The core problem is almost never the software. It's the datum mismatch. Your source data might be in WGS84, your target chart in NAD83, and your vertical reference could be LAT or MLLW. Throw in a local tidal correction and you have a recipe for horizontal drift of several meters across the same survey area.
Thalassa Charting The Unseen Rhythms Of Our Liquid Planet
That phrase came from a 2023 workshop at Scripps, and it stuck with me because it describes exactly what good ocean floor mapping does. You are not just drawing contours. You are tracking how water moves, how sediment shifts seasonally, how river plumes rework the shelf every spring. A static chart lies if you do not account for the rhythms underneath it. Here is how I approach it when I start a new coastal project. First, pull the raw depth points and convert everything to a single horizontal datum. I use PROJ command-line tools or the cs2proj function in QGIS. Never trust the default transformation options in commercial packages without verifying them against ground control points. The default "Bing" grid shift I used once produced a 4-meter skew on a 2-kilometer transect. Second, process the vertical offsets. Tidal correction is non-negotiable. I grab the harmonic constants from the nearest NOAA co-tidal station, run them through OTIS (the Open Tide Harmonic Inference Software), and apply the predicted tide back to each ping. If your survey is near a major river mouth, add a freshwater bulge correction. In the Mississippi delta I found a 12-centimeter unmodeled bulge that completely invalidated my initial draft chart.
Third, I interpolate the surface using topo-bathy fusion. Yes, it sounds trendy, but it is just ordinary gridding with a variable cell size. Use finer cells in the intertidal zone and coarser cells offshore. I typically settle on a 2-meter cell near shore transitioning to 10 meters by the 30-meter depth contour. Anything finer than that is usually noise from vessel motion anyway. I learned this the hard way during a project off the Outer Banks. The company client wanted 0.5-meter resolution everywhere. I produced it. Three months later they reported a navigation incident where their charts showed a 4-meter shoal that did not exist. I re-examined the raw data. The high-frequency spikes were not features. They were side-scan artifacts from a submerged debris field that the beam pattern was misinterpreting as a ridge. That cost me two weeks of reprocessing and an awkward phone call.
Get the Full Details

What beginners miss about tidal datums
Everyone focuses on the horizontal transform. Almost nobody checks whether their depth values are referenced to the same tidal datum as the chart base. If your depths are in meters below chart datum but your source bathymetry is still in raw water column measurements, your contours will be systematically too deep or too shallow depending on the tidal cycle during the survey. I see this error in maybe one out of every five submitted datasets. The fix is simple once you know it. During processing, tag every depth point with its exact UTC timestamp. Then cross-reference against the predicted tide at that timestamp and every subsequent hour. Apply the residual. This takes about twenty minutes for a typical 50,000-point survey using a Python script with the python-tides library. It is cheaper than redoing the whole project.
When the data just will not cooperate
Sometimes the survey area has no tidal gauge nearby. This happens more often on small island coasts and in developing nations. The usual workaround is to borrow harmonic constants from the nearest station within 100 kilometers, apply a phase lag correction based on the co-tidal line interpolation, and flag the resulting depths as estimated in the metadata. You lose accuracy, maybe half a meter in extreme cases, but it is better than publishing uncorrected raw soundings. I also recommend keeping your original unprocessed data somewhere safe. The industry standard is a NetCDF or XBT file format with the full metadata embedded. I store mine on a local NAS plus an offsite S3 bucket. It took me two hours to recover a lost survey last year because I had the backups. The version without backups would have required re-vessel, which runs about eight thousand dollars per day. The bottom line is that good charting is not about fancy visualization. It is about correct datums, proper tidal reduction, honest uncertainty notation, and knowing when your data is not good enough for the intended use. Everything else is decoration.