# Geometry

This is a schematic representation of the possible geometrical representations for multibeam sonar data.

- Ping: one transmit-receive cycle
- Beam Index: reception beam number
- Acrosstrack distance : horizontal range to the ship's nadir
- Range: length of the acoustical path
- Time: travel time along the beam
- Samples: sample number from the beginning of transmission

We gave specific names to the various geometries met in with multibeam data:

- PingBeam : Information from individual beams / vs ping number
- PingRange ; PingTravelTime ; PingSample : Complete received signals in range, time, or samples ; vs ping number
- PingSwath : Projected onto the seafloor ; vs ping number
- LatLong Georeferenced in Latitude & Longitude
- GeoYX Georeferenced in projected Cartesian coordinates
- OrthoYX Non-referenced orthonormed Cartesian coordinates

## PingBeam Geometry

*PingBeam* geometry is characteristic of multibeam data, the X axis represents beam numbers, it is the roughest representation possible. If the beam angular distribution is linvear (constant angular step) target objects are deformed onto the X axis.

## LatLong Geometry

A mapping survey is done by sweeping more or less wide seafloor stripes depending on the sonar technology, its frequency, its water height, its propagation conditions, the noise level ... Each line is separately projected in LarLong form.

*LatLong* geometry is the input point for *SIG, GMT, Google Earth, NasaWorldWind*... The grid step is defined by the user in metric units, and is transformed by SonarScope into distinct values in longitude and latitude depending on the latitude. Within this geometry, the geometry of geological objects is respected..

If the image is imported from another software, the latitude and longitude steps are is often equal, which causes a geometric deformation.

The *Geo YX* geometry is an orthonormed data in metric units. It has less interest in *SonarScope* because cartographic representations by GMT are in *LatLong* geometry.

## PingSamples Geometry

This Geometry is the one used for side-scan sonars. The ship track is situated in the middle, the acquired data on starboard are situated on the right side with the time axis running to the right, the acquired data in port are represented on the left side with the time axis running to the left. Conventionally we will use one unique axis oriented in the direct sense (to the right) and we will give a negative sign to data on port side.

For multibeam sonars, *SonarScope* transforms reflectivity data in this geometry which is certainly less effective from a disk space point of view than the compact representation used by those sonars, but which offers the great advantage of being able to process those data by using standard functions.

## PingSwath Geometry

*PingSwath* geometry makes it possible to access and to display all the ping (Y-axis). X-axis represents the horizontal line transverse to the ship. The choice of a more or less fine resolution for this axis acts proportionally on the image size. The metric step corresponding in Y depends on the ship's speed.

This geometry gives a wrong idea of the geometry of geological objects which are most often deformed; on the other hand this geometry is well adapted to various processings (compensation, filtering ....)

## Geometric transformations

With SonarScope, one can switch from one geometry to another.