The following decision process is used for all incoming multibeam data that is supported by Qimera and it is based on the number of SVP observations found in the source file.ġ) If no SVP is found, the multibeam file's SVP selection algorithm is configured as " Fixed velocity from surface sensor". Nearest in distance, within user specified time: Same as "nearest in distance", however, a time constraint imposes a maximum allowable time difference between the ping time and the SVPs being considered.Īt the end of the data extraction from a multibeam source file, Qimera makes an attempt to configure the most reasonable SVP lookup strategy for the incoming source file.The selected SVP can vary on a ping-by-ping basis.
Nearest in distance: use the SVP position of observation to determine which is nearest in distance for any given ping location.Nearest in time: use the SVP times of observation to determine which is nearest in time for any given ping time.Real-time scheduling: match the application of sound speed profiles as they were applied during acquisition.Fixed velocity from user specification: same as "Fixed velocity from surface sensor", however, the user specifies the sound velocity to use.Fixed velocity from surface sensor: use the sound velocity from the surface sensor (this is usually reported in the multibeam ping packets) to create an SVP with constant velocity across the entire depth range.Specific sound velocity profile: associate a single SVP file to a multibeam file.This is done in Qimera by selecting a " Sound Velocity Strategy". Given a set of multibeam data files and a set of SVP casts, it is necessary to provide a mechanism in which any given multibeam data file can be associated with one or more SVP casts for the purpose of ray bending corrections. Many imported multibeam data files require ray bending corrections. This allows imports to occur with over-writing edits that a user might have made on a particular SVP cast. In the event that a user edits one of the SVP files, Qimera will compare incoming new SVP files against the original record in the SVP directory. This is necessary as many source items may share the same SVP observation, but the user will prefer to only have to deal with a single instance of the SVP observation. Existing files in this directory are first checked to see if they are duplicates and only new SVP observations are added. The user can provide this information at a later stage in the SVP Editor.Īfter the scan is complete, Qimera copies new instances of SVP observations to the project's SVP directory in the vessel folder associated with the incoming source file. Qimera will always warn the user about files that have one or more SVP casts with missing time of acquisition and/or position of acquisition. Qimera scans the incoming multibeam file for SVP data and if it finds any, these are written into the file's metadata directory. Qimera not only scans for and extracts SVP information from incoming multibeam files, it also sets the SVP processing configuration based on the SVPs found in the file and the metadata that is associated with them.
0 kommentar(er)
