The Ping360 is “meant for” whatever it’s useful for. The raw data it outputs is mostly helpful for navigation with a visual display, but could be processed for additional functionalities (potentially use-cases like mapping, and object identification, avoidance, and analysis, depending on how and when the data is processed, and how the device is mounted).
The Ping Sonar provides sonar profiles, including an estimate of the distance to a sonar-reflective surface or object, if it can see one. Facing downwards on an ROV or boat, the distance estimate is a measure of the altitude from the vehicle to the water bottom (assuming the vehicle is upright), and can be combined with a depth estimate (from a pressure sensor, or ~0 for a boat) to determine the height of the water column at that point.
If you have estimates or measures of the vehicle position at the time of each altitude estimate then you can combine those to form a bathymetric map of the area where the measurements were taken. The “naive” approach which just outputs a single point per measurement should be reasonably straightforward (this comment shows an example result from a user with a kayak and an Arduino).
A more complex approach that considers...
…the overlap of the ping beam from closely spaced measurements may be able to get additional resolution and accuracy (especially for bumpy surfaces), but would require some software development and an understanding of beam shapes and sonar theory to implement, and likely a decent amount of validation/verification. That’s something I’ve been thinking about, but haven’t had time to work on yet. A plus side of that kind of approach is it would be reasonably device agnostic, as long as the appropriate beam characteristics, and the vehicle and device orientation, can be captured by the processing.
Note that if you don’t want/need to process the profile data to make your own distance estimates then you can turn on the BlueOS MAVLink integration for the ping sonar (available in recent BlueOS 1.1.0-beta versions), which then sends the sonar’s distance estimates directly into the autopilot telemetry logs (which also include the depth and position data), in which case you don’t need Ping Viewer or its sensor logs at all (although you may wish to look at Ping Viewer to see the profile data while operating, which is also fine, and doesn’t prevent the MAVLink integration from working).
The sensor requirements depend on your operating conditions and data requirements. As in the example I linked to, a minimal setup could involve just a small boat, a battery, a Ping Sonar, a GPS sensor, and an Arduino for capturing the data, and a thruster setup (or human) for propulsion and turning.
Regardless of your sensor setup, most likely the data compilation and processing you do will output a point cloud of water bottom position measurements. I’m unsure what you want to do with your data, or what your 3D models involve, so it may be that the model(s) are the data, or that the data can be imported and aligned with the model(s), or that both the model(s) and data are imported into and aligned in a separate application.