Qimera Supported Import Data Formats

Supported Formats for Import

Source

Raw Sonar File Formats

The import and processing of raw data formats is dependent on licensing. In Qimera, go to the Help drop-down menu and choose View License Status to view your current license coverage.

File Format Specific Import Differences

Qimera can process raw sonar files to generate fully corrected and georeferenced sounding footprints for a number of formats.  Understandably, the import experience varies slightly from one format to the next based on the type of information that Qimera can automatically extract from the incoming data files.  Several file format specific nuances are explored below for each of the supported import file formats, along with images of the Add Raw Sonar File import dialog for clarity when necessary.

QPS .DB Format

The QPS .DB format as recorded in QINSy provides the cleanest import experience since Qimera is capable of determining all that it needs to know from the file itself.  This includes all sensor locations, offsets, data types, geodesy settings, vessel names, etc.

Kongsberg .ALL Format (MB56)

The Kongsberg .ALL format provides much of the information that Qimera requires with the exception of the coordinate reference system used by the raw positioning data stored in the file.  The lower portion of the import dialog provides a drop down list to specify the type of coordinate frame that the positioning data is referenced to.  The default is WGS-84.

The vessel name is sometimes stored in the .ALL file, in this event it is used directly.  Otherwise, the sonar model number and serial number are used to craft a unique vessel name.  The vessel name is used to help associate files from the same vessel together after multiple import sessions.  We encourage you to specify a vessel name in Kongsberg's SIS program during your survey setup to help you identify data files from different vessels in Qimera.  This is especially important If you find yourself using the same sonar head on vessels of opportunity.  Taking the time to name the vessel in SIS will make data management quite simple in Qimera.  If you have multiple Kongsberg sonar systems on the same vessel, we strongly encourage you to give different vessel names to the two systems to ease data management in Qimera.

The .ALL format does not encode the position of an SVP file and you will need to enter this information manually after importing your .ALL files in the SVP Editor.  The date/time of the SVP is encoded in the .ALL file but it is only as correct as the data that was provided to SIS, we encourage you to verify the date/time stamping of your SVP profiler and processing software that provides this to SIS in real-time to ensure that it is correct and reporting UTC time as well.

Qimera does not extract tide data from the .ALL format so you may need to provide that separately using the Tide Importer.

Full sonar processing is not currently supported for some of the older Kongsberg systems. The systems that fall into this category are the EM1002, EM3000, EM300, and EM120. Data from these systems can be imported in Qimera using the 'Add Raw Sonar Files' dialog but processing is limited to applying SBETs, Navigation, and Tides. Point cleaning, including use of the Swath Editor, and creation of surfaces is all possible.

Tools and processing steps that are not supported for these files are: Patch Test and Wobble Analysis tools, any edits to Vessel Configuration, Time Series, or SVP settings that trigger sound speed reprocessing.

Qimera supports Water Column Data stored in the separate .WCD file.

Reson .S7K Format

The Reson .S7K format provides much of the information that Qimera requires with the exception of the coordinate reference system used by the raw positioning data stored in the file and the vessel name.

Upon import of the first file into a project, you will be prompted to provide a vessel name.  This vessel name can be the same from one project to another.  Once a vessel name has been provided, the Vessel Assignment combo box in the import dialog will be updated with the vessel name.  The vessel name is used to help associate files from the same vessel together after multiple import sessions.  In a later import session of the same data type, you will find the Vessel Assignment combo box will be pre-populated with any vessel names that you've created on previous import sessions to the project.  In the event that you are importing data from another vessel into the same project, clicking the combo box will allow you to select "Use new vessel configuration...", at which point you will be prompted to provide a new vessel name.  Once that is done, be sure to select that vessel name from the Vessel Assignment combo box.

The lowest portion of the import dialog provides a drop down list to specify the type of coordinate frame that the positioning data is referenced to.  The default is WGS-84.

It is important to note that .S7K files can come from two different sources: PDS2000 or the Reson sonar controller.  When .S7K files are provided by PDS2000, they can be populated with vessel configuration information such as the sensor locations, angular alignments, draft, etc.  Qimera will extract these values and will use them during processing.  You can, of course, modify the values that are extracted in the Vessel Editor dialog.  If you record data using the Reson sonar controller software, the .S7K files do not contain vessel offsets and you will need to enter these manually in Qimera prior to processing if they are non-zero.

For users who record .S7K data using the Reson sonar controller software, it may be possible to have .S7K files that also do not contain any ancillary sensor data such as motion, position or SVP.  You will still be able to import these .S7K files, however, you will need to provide additional data separately after import of the .S7K files:

• Motion and/or position through ASCII import or Binary Import dialog
• SVP import

Qimera does not extract tide data from either or the two variants of .S7K format so you may need to provide that separately using the Add Tide File Tool.

Note that PDS2000 .S7K files may contain SVP but the date/time is not encoded in the datagram and you will need to enter this information manually in the SVP Editor if you want to take advantage of time-based SVP Selection Strategies in the Processing Settings dialog.  The same datagram format allows for encoding the position of the cast.  If this is present, Qimera will extract it.  If not, you will be warned about this on import and you will need to specify the position manually in the SVP Editor after import.  We encourage you to provide this information to PDS2000 such that the record that it records is as fully populated as possible.

Hypack .HSX Format

The Hypack .HSX format provides much of the information that Qimera requires with the exception of the geodesy settings and projection system used by the projected positioning data stored in the file and potentially a time-zone offset and potentially a vessel name.

Upon import of the first file into a project, you will be prompted to provide a vessel name if one is not found in the file.  This vessel name can be the same from one project to another.  Once a vessel name has been provided, the Vessel Assignment combo box in the import dialog will be updated with the vessel name.  The vessel name is used to help associate files from the same vessel together after multiple import sessions.  In a later import session of the same data type, you will find the Vessel Assignment combo box will be pre-populated with any vessel names that you've created on previous import sessions to the project.  In the event that you are importing data from another vessel into the same project, clicking the combo box will allow you to select "Use new vessel configuration...", at which point you will be prompted to provide a new vessel name.  Once that is done, be sure to select that vessel name from the Vessel Assignment combo box.  We encourage you to specify the vessel name in Hypack during your survey setup to help you identify data files from different vessels in Qimera.  If you provide HSX data with a vessel name, you will not be presented with the Vessel Assignment combo box.

The time reference is used to indicate the time offset, in hours, from UTC to the time zone that Hypack was configured to record data with.  It is possible to have Hypack record data with time stamps other than UTC and in these cases you will need to indicate the time offset relative to UTC.  If you don't know what this value is, you should consult with the individuals that recorded or provided the data.  It is possible to leave this field set to zero, however, you may have difficulties in aligning your raw sonar data with external data sources that are imported separately such as tide, SVP, binary navigation files, etc.  Unfortunately, there is no mechanism to record this time offset in the .HSX format so you must provide it during the import stage if it is non-zero.  Once data are imported, you cannot adjust this value so it is important to identify the correct value prior to import.  We encourage you to configure Hypack to record data in UTC for a seamless data import experience into Qimera.

The lowest portion of the import dialog provides a drop down list to specify the geodetic settings and projection that the positioning data is referenced to.  Hypack HSX files do not provide this information and the positioning data is stored in projected format without any reference to the projection or geodetic settings.  You will need to specify this by choosing a common projected coordinate frame from the combo box or by clicking the Select Coordinate System button labelled '...' to the right of the combo box.  This will launch the Coordinate System selection dialog and you will be provided with the full set of supported projection systems supported by Qimera.  In the event that Hypack has been configured with an unknown or poorly supported projection, it may be difficult to match this in Qimera.  We encourage you to keep projection configurations simple in Hypack and to perform complex geodetic configuration in Qimera.  Though you need to specify the projection of the incoming HSX data during the import stage, you can separately specify the desired projection of your Qimera project during project creation.

Qimera does not extract raw tide data from HSX format so you may need to provide that separately using the Tide Importer.  The TID record provided by the HSX record gives a total height corrector but it is not possible to determine if it is a true tidal corrector or a GNSS/GPS height corrector from the HSX file alone.

The following supplementary files that might be logged alongside the HSX are not used: .7k, .raw.

HSX format can provide SVP information but it has no mechanism to encode the date/time or position of the cast.  You will need to specify these manually after import using the SVP Editor if you want to take advantage of spatial and/or time based SVP Selection Strategies in the Processing Settings dialog. 

EdgeTech JSF Format

The EdgeTech JSF format provides much of the information that Qimera requires with the exception of the vessel configuration, sound velocity profile and the vessel name.

Upon import of the first file into a project, you will be prompted to provide a vessel name.  This vessel name can be the same from one project to another.  Once a vessel name has been provided, the Vessel Assignment combo box in the import dialog will be updated with the vessel name.  The vessel name is used to help associate files from the same vessel together after multiple import sessions.  In a later import session of the same data type, you will find the Vessel Assignment combo box will be pre-populated with any vessel names that you've created on previous import sessions to the project.  In the event that you are importing data from another vessel into the same project, clicking the combo box will allow you to select "Use new vessel configuration...", at which point you will be prompted to provide a new vessel name.  Once that is done, be sure to select that vessel name from the Vessel Assignment combo box.

There is no vessel sensor location or alignment information in a JSF file for Qimera to query and extract so user entry will be required.  Qimera treats the EdgeTech 6205 system as a dual head system, each with a unique transmitter and receiver.  According to the manufacturer, the receivers have nominal mount angles of +/-60 degrees relative to the vertical.  Beam angles reported by the sonar have this nominal mount angle included, these angles are removed to arrive back at the raw sonar relative angles.  This permits corrections for surface sound speed errors in Qimera.  Patch test alignment angles will be added with the correct sign convention to the nominal mount angles of +/-60 degrees.  It is important to note that the transmitter/receiver pairs are treated as two separate systems.  Data entry for the positions of each will be required for the most accurate results.

The JSF format does not support sound velocity profiles or tide measurements in the file.  Users will be required to provide this information separately if required.

NavO GSF Format

NavO's Generic Sensor Format (GSF) is an interchange format for echosounder data.  The format comes with a software I/O library that is freely available for use in applications such as Qimera.  It can be used to store the georeferenced and fully corrected results from hydrographic processing software such as Qimera, however, it can also contain the raw information that is found in all the other formats discussed on this page.  Though the GSF I/O software library is freely available, there are no built-in mechanisms or even standards to enforce users of the I/O library to ensure that all necessary ancillary information is stored in the file.  In other words, you can have very little of the required data to process data in a GSF file or you can have all of the required data.  Most providers of GSF files do provide the final sounding footprint solutions, that is largely how the GSF file format is used currently in the industry.  The provision of ancillary data and supporting information, such as sensor location offsets, will vary from one vendor to another.  Due to the flexible nature of the format, you can find yourself in a situation where a GSF file has sounding results that can be imported as Point Files and can be used to generate a bathymetric surface that is free of artifacts.  The same file, if imported as a raw sonar file and then re-processed, may very likely result in a bathymetric surface that suffers from one or more artifacts due to missing and/or incorrect ancillary information and data in the file.  For this reason, a warning dialog is provided to you as a reminder when you import GSF files, as shown in the image below.

When using a GSF file from an unfamiliar source for the first time, we strongly encourage you to review the data and information that is extracted from the file to gain an appreciation of the limitations of the GSF file that came from a particular source.  Once you have gained such an appreciation, please communicate it back to us and we can update our internal and/or external documentation to help our Support personnel and the Qimera community.

If you are working with GSF files, it is  very strongly  recommended to import them as Processed Point files first and to create a reference Static Surface to establish a baseline expected result.  After this is done, you should import and process the same file as a Raw Sonar file and then create another Static Surface from this to compare with your baseline expected result.  If discrepancies are found, you will need to evaluate the quality of the supporting ancillary information that is found in the file to determine the root cause.  We realize that Qimera is not perfect and that there are sometimes bugs, however, in the case of discrepancies between the two Static Surfaces, it is much more likely that the GSF file does not contain the necessary information to support full re-processing.  You should always verify processing capability prior to embarking on a processing project that will depend on GSF files when receiving GSF files from a source that is unfamiliar to you.  We cannot stress this enough: Verify your workflow long before starting your project.

All warnings aside, the GSF import experience is fairly straightforward.

Upon import of the first file into a project, you will be prompted to provide a vessel name.  This vessel name can be the same from one project to another.  Once a vessel name has been provided, the Vessel Assignment combo box in the import dialog will be updated with the vessel name.  The vessel name is used to help associate files from the same vessel together after multiple import sessions.  In a later import session of the same data type, you will find the Vessel Assignment combo box will be pre-populated with any vessel names that you've created on previous import sessions to the project.  In the event that you are importing data from another vessel into the same project, clicking the combo box will allow you to select "Use new vessel configuration...", at which point you will be prompted to provide a new vessel name.  Once that is done, be sure to select that vessel name from the Vessel Assignment combo box.

The lowest portion of the import dialog provides a drop down list to specify the type of coordinate frame that the positioning data is referenced to.  The default is WGS-84.

Some further discussion is warranted on the impacts of missing or incorrect information that can occur with particular variants of GSF files.

Depending on the source of the GSF file, the files can be populated with vessel configuration information such as the sensor locations, angular alignments, draft, etc.  Qimera will extract these values and will use them during processing.  You can, of course, modify the values that are extracted in the Vessel Editor dialog.  If your GSF files do not contain sensor offsets, you will need to enter these manually in Qimera prior to processing.  Qimera will warn you in the event of all sensor offsets being zero.

The GSF format allows for encoding the position and acquisition time of an SVP file, however, if either of these are not provided, you will need to enter this information manually after importing your .gsf files in the SVP Editor.  We encourage you to verify the date/time stamping of your SVP information.

Tide information can be encoded in the GSF file, when this is found in the file, it is extracted and the vertical referencing configuration is set up to use this information during processing.

As mentioned previously, GSF is often used to transmit corrected sounding footprint information from one software package to another.  When this type of information is found in the file, Qimera can generate a QPD directly from this.  The QPS standard for QPDs is to reference sounding footprint locations relative to the sonar head; the sonar head is referenced to the CoG using a separate set of 3D offsets that are stored internally with the ping data on a ping-by-ping basis along with the 3D georeferenced location of the CoG.  Since GSF files reference their sounding locations relative to the vessel reference point, the conversion process uses the sonar head linear offsets to re-reference the soundings to the sonar head.  In the event that the GSF file does not provide the sonar head offsets, or if the values are incorrect, this re-referencing exercise will generate QPDs that are inconsistent with the pre-processed soundings in the file.  Furthermore, if the waterline and/or sonar head Z offset is incorrect or missing, you may find that you have a static vertical offset in your results.  In this situation, you may have to manually enter the appropriate sensor location offsets in the Vessel Editor and then re-process the data to achieve acceptable results.

Motion sensor data can be encoded in the GSF for each ping and can also be encoded as a separate time-series data stream.  In the first case, there may be issues in re-processing data if the ping rate of the system is low such as when working in deeper water.  Qimera will warn you if the imported motion sensor measurements are at a low update rate.  In this case, it is advised that you import the motion sensor data separately from an alternate source to achieve the best results.

Positioning data in a GSF is reported for each ping and may have a low update rate when working in deeper water.  If re-positioning processing is required, it is advised that you import the position sensor data from an alternate source to achieve the best results.

Surface sound speed information in the GSF file is extracted from sensor specific subrecords which may or may not be present.

Multibeam raw measurements, i.e. beam travel-time and beam angle, are typically available in the GSF file.  The GSF format does not clearly specify the beam angle sign convention, nor does it provide a mechanism to indicate whether beam angles are referenced to the sonar face or to the vertical direction.  You may find that you'll need to use the Wobble Analysis Tool to adjust the sign convention of beam angles and/or the beam angle referencing.  In some rare cases, the travel-time is incorrectly scaled.  In this case, you can adjust the TWTT Scale for the sonar system in the Vessel Editor.  We have seen instances where the travel time is reported as a one-way travel time instead of the expected two-way travel time.  We have also seen cases where the travel-time is multiplied by an arbitrary scale such as 100.  In these cases, please inform QPS Support of this particular scenario so that we can inform other users and potentially get in touch with the software vendor that provided the GSF file to help them improve the quality of their GSF export files.

We'll say it one last time:  Verify your workflow long before starting your project.

GSF manual and filtered flags are respected. When a GSF is imported as either a Raw Sonar file or as a Processed Points file, the manual and filtered flags will be respected and carried through to the QPD.

ELAC SeaBeam XSE Format

The ELAC .XSE format provides much of the information that Qimera requires with the exception of the coordinate reference system used by the raw positioning data stored in the file and the vessel name.

Upon import of the first file into a project, you will be prompted to provide a vessel name. This vessel name can be the same from one project to another. Once a vessel name has been provided, the Vessel Assignment combo box in the import dialog will be updated with the vessel name. The vessel name is used to help associate files from the same vessel together after multiple import sessions. In a later import session of the same data type, you will find the Vessel Assignment combo box will be pre-populated with any vessel names that you've created on previous import sessions to the project. In the event that you are importing data from another vessel into the same project, clicking the combo box will allow you to select "Use new vessel configuration...", at which point you will be prompted to provide a new vessel name. Once that is done, be sure to select that vessel name from the Vessel Assignment combo box.

The lowest portion of the import dialog provides a drop down list to specify the type of coordinate frame that the positioning data is referenced to. The default is WGS-84.

The .XSE format does not encode the position of an SVP file and you will need to enter this information manually after importing your .XSE files in the SVP Editor.  The date/time of the SVP is encoded in the .XSE file but it is only as correct as the data that was provided to HydroStar, we encourage you to verify the date/time stamping of your SVP profiler and processing software that provides this to HydroStar in real-time to ensure that it is correct and reporting UTC time as well.

Qimera will extract tide if it is logged in the .XSE file. If it is not logged in the .XSE file, you will have to provide tide separately using the Add Tide File Tool.

R2Sonic .R2SC Binary Format

The R2Sonic R2SC format is a raw format that does not contain all of the information that Qimera requires.

Upon import of the first file into a project, you will be prompted to provide a vessel name.  This vessel name can be the same from one project to another.  Once a vessel name has been provided, the Vessel Assignment combo box in the import dialog will be updated with the vessel name.  The vessel name is used to help associate files from the same vessel together after multiple import sessions.  In a later import session of the same data type, you will find the Vessel Assignment combo box will be pre-populated with any vessel names that you've created on previous import sessions to the project.  In the event that you are importing data from another vessel into the same project, clicking the combo box will allow you to select "Use new vessel configuration...", at which point you will be prompted to provide a new vessel name.  Once that is done, be sure to select that vessel name from the Vessel Assignment combo box.

The lowest portion of the import dialog provides a drop down list to specify the type of coordinate frame that the positioning data is referenced to. The default is WGS-84.

There is no vessel sensor location or alignment information in a R2SC file for Qimera to query and extract so user entry will be required.  

The R2SC format only contains the raw multibeam range and angle information. Position, motion and heading information will need to be added separately via Add Binary Navigation Files or Import ASCII Navigation. After adding Navigation and Motion, the R2SC files will show that it needs to be processed and the "Auto Process" button will need to be pushed.

The R2SC format does not support sound velocity profiles or tide measurements in the file.  Users will be required to provide this information separately if required.

Kongsberg .KMALL Format

The Kongsberg .KMALL format provides much of the information that Qimera requires with the exception of the coordinate reference system used by the raw positioning data stored in the file.  The lower portion of the import dialog provides a drop down list to specify the type of coordinate frame that the positioning data is referenced to.  The default is WGS-84.

The vessel name is not currently stored in the .KMALL file as it was previously in the .ALL format.  The sonar model number and serial number are used to craft a unique vessel name.  The vessel name is used to help associate files from the same vessel together after multiple import sessions.  The vessel offsets for all sensors is stored in the .KMALL format, Qimera reads these and uses them appropriately during all processing such that no further vessel configuration is required.

The .KMALL format allows users to encode the position of an SVP file and we encourage operators to take advantage of this by correctly populating the position of an SVP cast during acquisition.  This allows direct use of SVP selection strategies such as "Nearest in distance", etc, without further data entry in Qimera.  The date/time of the SVP is encoded in the .ALL file but it is only as correct as the data that was provided to SIS, we encourage you to verify the date/time stamping of your SVP profiler and processing software that provides this to SIS in real-time to ensure that it is correct and reporting UTC time as well.

Qimera does not extract tide data from the .KMALL format so you may need to provide that separately using the Tide Importer.

Qimera supports Water Column data stored in the separate .KMWCD file.

Raw sonar file format capabilities and what Qimera is extracting from the raw sensor source files in import are explained in this supporting document - Qimera Sonar Source Data Import Capabilities .   

Processed Point Files

Format	Extension	Can Unload To	Links
9-Column ASCII Lidar	.all
ASCII XYZ	.asc, .cor, .csv, .txt, .xyz
CnC Binary	.bin
CnC Trace	.trace
Danish Geographic FAU	.fge
Danish FAU/FAU2	.fau, .fu2
Geoswath Kongsberg	.sff
Hydro 93 Binary	.b93
Hypack Hysweep	.hs2
IVS Binary	.ivs
LADS Mark II	.caf
LAS	.las
LASzip	.laz
MBSystem Fast Bathymetry File	.fbt
MPA/CARIS ASCII
MapInfo MIF	.mif
NAVO GSF	.gsf, .d0, .d1, .d2
NAVO/CARIS ASCII
Neptune PROC	.depth
OMG Merge	.merged
PFM	.pfm		Unloading not possible when importing as processed points
PDS2000	.pds
QPS QPD Versions 1 & 2	.qpd
RAN HTF	.htb, .htf
SHOALS 1K	.hof
SHOALS Hydro/Topo Airborne	.abh,
SHOALS OUT	.out
SHOALS TOF	.tof
SHOM Pivot	.piv
Swedish Binary DIS	.bdi
XSE Data Exchange	.xse
CARIS Processed Depths *License dependencies apply	.hdcs

Position and Motion Formats

 Other Source Data formats

Tide File Formats

Tide Data Files

Qimera supported Tide File formats specifications, metadata and sources are detailed in the supporting document Qimera Tide File Formats

Tide Definition Files

Supported Layer Data Formats