mbari-org / SeafloorMappingDB

Make MBARI seafloor mapping datasets more accessible and useful
GNU General Public License v3.0
3 stars 6 forks source link

R/V David Packard multibeam data management #251

Open jbpaduan opened 5 months ago

jbpaduan commented 5 months ago

The new R/V David Packard's multibeam sonar surveys and data products need to become available through SMDB. The location for the logged (.kmall) and processed files is anticipated to be parallel to the year-directories for the MAUV and LASS data, not within them, e.g., /Volumes/SeafloorMapping/Packard/2024/20240215_EM304MkII_SAT/ Here, under year directories also, each expedition directory may contain several data directories. Other directories, such as Figures in this example, will contain data products. The various MAUV and LASS year-directories may also utilize R/V Packard data in their compilation directories.

MBARIMike commented 5 months ago

The current logic of load.py is agnostic on the form of the directory structure underneath /Volumes/SeafloorMapping/ so this directory structure should work fine.

jbpaduan commented 4 months ago

Please change the field "Vehicle" to "Platform" to accommodate R/V David Packard, MBARI LASS, various AUVs (ours and Sentry), and soon the Paragon (which will use a pole-mounted multibeam to survey the upper Monterey Canyon for Aaron Micallef).

MBARIMike commented 4 months ago

We should clarify what we mean by "Vehicle" and "Platform" and have it reflected by the modeling in models.py.

The models.py module currently has a Platform class (with a PlatformType class) that gets populated from the third line in the Notes: https://github.com/mbari-org/SeafloorMappingDB/blob/main/smdb/scripts/load.py#L462. (It doesn't look like the Platform information is shown anywhere in the web interface.)

The Mission class has a vehicle_name field field which is populated from the survey_tally spreadsheets: https://github.com/mbari-org/SeafloorMappingDB/blob/main/smdb/scripts/load.py#L1616

jbpaduan commented 4 months ago

"Platform" was intended to track ship names, which would be good to track, though that field would be empty once we achieve having data collected by a fully autonomous vehicle recharging itself on a mooring, ready to map in response to an event. It's messy to get ship name from the Notes file, but it can often be found in the first handful of lines and becomes part the Expedition name, which is fine (and may be adequate). Could be useful to track the ROV onto which the LASS package is mounted, though that might be assumed from the ship in the expedition name.

The field for "Vehicle" is what I've come to identify as the package of mapping sensors: LASS with sonar, lidar, cameras mounted to an ROV and someday an AUV; the MAUVs with several sonars and new sensors being strapped on; Sentry with its sonar (and issues); Packard with its sonars; and soon a pole-mounted multibeam for Aaron. If Platform is not the right word for that, what might be, since Vehicle is misleading?

At the moment, line 3 of the Notes files generates some garbage and not always the ship name (see screengrab from website's Admin view of the database: Screen Shot 2024-06-17 at 2 26 24 PM. It's anathema to the original plan of scouring our servers for everything, but would Platform be better to also be populated from the survey tally spreadsheet?