GSF file usage and limitations
GSF files from a number of 3rd party software vendors have been giving a number of clients some trouble when importing into Qimera. The GSF format is a suitable data container for the interchange of georeferenced soundings but transferring raw sonar measurements, as well as all necessary ancillary data and sensor configuration, can be more difficult with this file format. There are three processing paths for GSF in Qimera, these are examined below with some information to help you decide the best way forward. Please get in touch with us if you find oddities or discrepancies and we can start collecting the known limitations associated with various sources of GSF files. This will help us to help other clients as well as giving us good information to feedback to other software vendors that provide the GSF format as an export option.
Import as Processed Points
When importing as processed points, the georeferenced solutions are taken "as is" and can be used directly for production of grid products. Creation of a Dynamic Surface will convert the GSF files into a QPD file, allowing for geospatial visualization and editing of your point data. This is the equivalent capabilitty that FM Hydro users would have been used to with the Fledermaus based geospatial processing tools we have offered in the past. This particular import path will not allow any georeferencing or mathematical correction of sounding positions. The GSF format is well suited for this particular application and few problems are expected as this particular workflow has been offered with FM Hydro for a number of years. This particular approach will give you the best representation of what your GSF file contains. In other words, if you are having problems importing GSF data as a raw sonar data, this is the best fall back solution in that it should give you a faithful conversion of your soundings into QPD format as the mathematics that are used to do this do not rely on any information in the GSF other than the soundings themselves.
Import as Raw Sonar Data
The second option is to import the GSF as a raw sonar file. When you do this, the GSF is mined for raw sensor data such as motion, position, surface sound speed, etc. Also, Qimera extracts the vessel geometry such as the sensor locations on the vessel and their angular orientations. After this stage, Qimera is ready to do one of two things, these are examined below. In either of the two scenarios below, if your results are inconsistent with your expectations after import and conversion to QPD, we recommend instead importing your GSF files as Processed Points. This will allow you to generate grid products and to edit your data points, but you will not be able to re-process data. If you find yourself in this situation, please get in touch with us and we'll see if a fix is possible. It may very well be that there is no fix possible due to missing or incorrect information in the file.
Direct Conversion to QPD
You can allow for a direct conversion of the georeferenced soundings into a QPD. This is the default option in Qimera and can be disabled in the Preferences dialog under the General Tab by unticking the option to "Automatically convert Kongsberg/GSF sonar data on import" option. If you leave this option enabled, a little bit of math is done to undo the vertical correctors that were applied to the soundings in the GSF, such as tide and draft, and store them into the equivalent storage fields in the QPD. Qimera then uses the sensor lever arms that were encoded in the file along with the motion sensor measurements in the file to compute and remove the horizontal and vertical offsets between the vessel reference point and the sonar head. This creates a QPD file that is 100% consistent with how Qimera would have created had it done all of the mathematical processing itself. This is done to facilitate quick re-processing of horizontal and/or vertical positioning, including tide. Inconsistencies between the GSF soundings and the Qimera soundings can occur when vertical correctors are reported but not applied, or vice versa, or when sensor locations are incorrectly reported or not reported at all.
Full Recalculation from Raw Measurements
If you've opted out of the option to allow a direct conversion to QPD, or if you've changed a processing configuration option that necessitates full sounding recalculation, then Qimera will start from scratch with all of the raw sensor measurements and will ray trace and georeference the soundings according to your processing configuration. There are several ways that things can go wrong, leading to incorrect results.
Multibeam Measurements
Problems can occur when the raw sonar measurements do not conform to expectation. For example, the beam angles and/or travel-times are incorrectly encoded. In this situation, you may find that the reported depths are significantly incorrect. The sign convention for the beam angles may also vary from one software vendor to another as there is not a strict enforcement of this. In these situations, you'll notice that soundings are flipped around from port to starboard and vice versa. These can both be fixed to some extent in the Vessel Editor by setting the travel-time scale and the receiver and/or transmitter beam angle sign conventions.
Vessel Configuration
If the sensor locations and angular alignments are incorrect or missing in the GSF, you may need to track down what those values should be and then input them in Qimera's Vessel Editor. Furthermore, the GSF format does not strictly enforce how dual head systems are represented. There may be cases where Qimera cannot detect that data are from a dual-head system, leading to gross errors in application of sensor offsets, etc. These scenarios may be recoverable but you should get in touch with us for some help in identifying the correct steps to achieve what you need. In the event that there is no workaround, we may be able to provide a fix but our ability to do so depends on whether the necessary information is encoded in the file.
Motion Sensor Measurements
A GSF file may or may not have the full motion sensor data stream at its full output rate. Qimera will warn you about this, watch for warnings in the Job Activity widget during import.
Sound Speed Measurements
Several problems can occur with sound speed profiles as well, if they are provided at all. Notably, the position and/or time of observation may be missing. Check for warnings on import in the Job Activity widget for information, or have a look at any profiles that are extracted using the SVP Editor. The GSF format lacks a mechanism to represent sophisticated sound speed application strategies. For example, you may have chosen a sound speed application strategy such as "Nearest in Distance" in a particular 3rd party software package, but this decision cannot be encoded in the GSF format. Though Qimera may have all of the raw sensor data, there is no mechanism for it to be able to choose the same strategy that you may have applied in your processing elsewhere. Understandably, there will then be discrepancies between Qimera's re-processed solutions and the original georeferenced soundings. You can set the correct sound speed profile selection strategy in Qimera's Processing Settings dialog under the Sound Velocity tab.
Vertical Referencing
The GSF format allows for encoding of a traditional tide and a GPS tide vertical corrector. There is also the possibility to store the ellipsoidally referenced height and the geoid/ellipsoid separation value. These data fields may or may not be filled out, and the sign conventions may or may not be followed.