MB-System gives a seafloor survey a processing recipe

Imagine a seafloor survey in which neighboring passes disagree. A ledge appears twice, or the outer edges of a swath curl upward. Before drawing a smoother map, the survey team needs to decide what went wrong: a bad sounding, a position error, or the model used to turn a returning echo into a depth. MB-System, an open-source package for processing sonar data, gives these decisions separate places to live.[1][4][5][6]

Its file-based workflow leads to a useful architectural question: what must survive if someone wants to revise the survey later? The answer begins with the source data, the correction files beside it, and the program that brings them together.

Crew members in hard hats guide a yellow mapping vehicle beside a research ship in a gray sea. — MBARI crew launch a seafloor mapping autonomous underwater vehicle during a 2021 Pacific Northwest expedition. The vehicle carries the instruments; the processing workflow must preserve how their observations were interpreted. Photograph by Dave Caress, © 2021 MBARI; published in MBARI's account of its Cascadia research.[3]

Give each correction a place

At the bottom of MB-System is MBIO, an input/output library that lets processing programs work across supported sonar formats. The library absorbs differences in file representation so the tools above it can serve data from different instruments.[1] Above that common interface, the work splits into small, specific jobs.

Take a suspicious depth measurement. The interactive editor mbedit displays successive sonar profiles so an operator can inspect individual soundings. In its normal editing mode, it saves changes to their good-or-bad status in a separate file ending in .esf. It also creates or updates the corresponding .par parameter file so subsequent processing applies those edits.[4]

This separation has a practical history. The manual explains that older versions held the whole swath dataset in memory and wrote a new swath file directly. The later design retains bathymetry for editing and outputs flag changes, reducing what the editor must carry.[4] A narrower responsibility changes both memory demands and the form of the saved work.

That saved work needs care. When reopening a survey with existing edits, choosing to ignore the saved edits can replace them with a new edit file.[4] Keeping the original sonar file alone does not preserve the decisions made during a long cleaning session. For a team handing a survey from one analyst to another, the edit file deserves the same deliberate backup as the observations.

Position is a different question

mbnavedit handles the vehicle's navigation. It can save revised navigation in a companion file with the suffix .nve, which mbprocess later merges with the swath data.[5] This gives an operator a way to change where observations belong without expressing that change as a collection of rejected depth measurements.

There is a timing distinction underneath the interface. Some formats store navigation values alongside each sonar ping. Others contain separate navigation records with their own timestamps; MBIO must interpolate or extrapolate navigation when reading the survey records. Consequently, the navigation series presented for editing depends on the input format.[5]

For the imaginary doubled ledge, that distinction matters. I would want the review to establish whether the position problem concerns ping-associated values or a separately sampled navigation stream. Selecting plausible points on a screen is only part of the task. The analyst also needs to understand which recorded observations those points represent.

The water model needs its evidence

Depth recalculation needs a sound-speed profile: sound speed at successive depths. mbvelocitytool lets an analyst adjust one, inspect its effect, and save it with processing settings for a swath.[6]

Given travel times and beam angles, the software traces paths through that model to recalculate depths. An incorrect profile can curl a swath's edges. But the residual check also assumes a seabed smooth enough for its fitted line to make sense.[6] A tidy display still requires a physical interpretation.

Missing measurements change the problem. The tool can estimate absent travel times and angles using a simplified constant-speed model, but warns that the resulting modeling is not generally valid.[6] Reading a format successfully cannot supply observations it never retained.

The recipe becomes an output

The .par file connects these decisions. It contains processing modes, settings, and references to companion data. mbset creates or changes it, either for one swath file or for files selected through a datalist. Named controls such as NAVFILE, EDITSAVEFILE, and SVPFILE identify the relevant inputs.[7]

This is a useful distinction when reviewing a processing directory: a parameter file is an instruction sheet, while the referenced files supply its material. Copying the instruction sheet without its navigation corrections or sound-speed profile leaves an incomplete recipe. Conversely, changing a shared correction across many files calls for checking which files the datalist actually selects.

mbprocess reads that configuration and produces a processed swath file. Under its usual naming convention, survey.mb71 becomes surveyp.mb71. By default it processes missing or outdated outputs, comparing file modification times against the input and relevant dependencies. The -P option forces reprocessing; -S reports status and the modification times used in the decision.[2]

My engineering reading is that this resembles an incremental build. Its convenience should be judged within that scope: a freshness decision tells the operator whether work needs running again. It does not determine whether the chosen correction describes the sea correctly.

What the next reader receives

NOAA's National Centers for Environmental Information provides an independent view of the downstream stakes. Its submission guidance says the multibeam archive primarily maintains raw vendor-format data, also accepts supplemental information such as sound-speed profiles and vessel offsets, and relies heavily on MB-System in its management pipeline. It calls for documentation of both files and surveys.[8]

For a small research team with an experienced sonar analyst, I would treat a reproducible handoff as a bundle: the collected data, processing inputs, software version, and notes explaining why consequential corrections were chosen. A finished image cannot carry all of that reasoning. A parameter file records settings, but the judgment behind a rejected sounding may still need words.

Return to the ledge that appeared twice. A future reader should be able to distinguish a revised position from a discarded measurement and a changed water model. MB-System's architecture gives those explanations identifiable files. Preserving them lets the survey remain open to a better explanation.

cronfeed.work