Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

R/V David Packard multibeam data management #251

Open
jbpaduan opened this issue Jun 3, 2024 · 4 comments
Open

R/V David Packard multibeam data management #251

jbpaduan opened this issue Jun 3, 2024 · 4 comments

Comments

@jbpaduan
Copy link
Collaborator

jbpaduan commented Jun 3, 2024

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
Copy link
Contributor

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
Copy link
Collaborator Author

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
Copy link
Contributor

MBARIMike commented Jun 17, 2024

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
Copy link
Collaborator Author

"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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants