Qimera - Data Format Specific

This page contains frequently asked questions for Qimera.

On this page:

Is the Qinsy online Kalman positioning filtering used by Qimera when processing DB files?

If you have QPDs, they will import automatically into Qimera. If you re-process the QPDs in Qimera, you will get new position data using Qimera's computation engine, which is different from Qinsy's computation engine. There is no Kalman filtering in Qimera; the position stream straight from the observed values is used. If filtering was applied in the original QPD, it will be lost.

As of Qimera 1.6.0, the navigation source for multiple objects will be extracted from the QINSy QPD and saved. This allows for support for previously unsupported object navigation types. Full reprocessing can then be carried out without the loss of the Qinsy navigation solution.

When working with Qinsy data, are all parts of the Qinsy project necessary? Or, are only the .db files required? Are the .db files self contained? Is there any benefit to copying a whole Qinsy project locally before starting to work with it in Qimera?

Qimera will load the .db files and will import and convert the data from the ancillary sensors into the Qimera project. If there are pre-existing QPDs in the usual location, then Qimera will find these QPDs and you can begin examining the data and create gridded products immediately. The .db files are self contained and no other data is extracted from any other file. Qimera will never modify the .db file so you don't necessarily need to make a backup, you can work with Qimera directly in your Qinsy project folder.

As of Qimera 1.6.0, .db's containing multiple objects, and the navigation type for said objects which contain the multibeam system, are not currently supported in Qimera. Therefore, the QINSy QPD's will be needed.

When working with QINSy data, is there any way to query the data after it is loaded into Qimera in order to find the coordinate system of the imported data?

Yes, if you select the database in the Project Sources window you can then view the coordinate system and other properties of the data by selecting the Properties tab in the tab page list. It will also show you the co-ordinate system of the projected .qpd as well.

With QINSy data, does the project auto-reproject to UTM if that option is left on during project creation?

No, it does not. When you import .db data, Qimera inherits the projection system that was chosen in QINSy.

I would like to import my QINSy DB files that have an ROV with multibeam as well as my hull mounted multibeam system into Qimera, is this possible?

Previous to Qimera 1.6.0 this is not possible, Qimera is limited to supporting one object DB files, unless your ROV has its own associated navigation string, motion sensor etc. we do not support USBL positioning.

If you have a QINSy QPD for each DB, Qimera 1.6.0 and later will support the extraction of the QINSy nav solution and will allow for full reprocessing of that data.

When adding .hsx files, the Add Raw Sonar Files dialog requests a 'Time Reference/Acquisition Time Zone'. Is this information pulled from the .hsx file?

Hypack can be configured to record the data in the local time zone. When merging Hypack data with externally recorded data, such as POSMV or SBET files (which are both referenced to UTC), Qimera needs to be able to understand what time zone the .hsx data was recorded in, if it wasn't configured to work in UTC. Unfortunately, the time zone offset relative to UTC is not recorded in the .hsx file and the user must provide this information on import.

Hypack data may or may not have SVP information available during the SVP strip stage of import. What determines whether or not this info is available in the .hsx?

A user can choose to load a profile during acquisition in Hypack, in this case, the SVP that's loaded will be written out to the .hsx file. If no SVP is specified, then there won't be one in the .hsx file.

Why is Qimera not reading my Binary Navigation SBET (.out) files?

Qimera does not recognize the (.out) extension because POSPac's internal data formats all have the same (.out) extension regardless of what is actually in the file. In POSPac's internal data format, approximately 15 files share the same extension, which presents issues for Qimera. The main issue is there is nothing in the files that actually distinguish the contents of the file. Therein the user must manually rename the basename of the Binary Navigation SBET file. We realize asking the user to rename files is generally considered a bad practice, however in general this is a single file per day of acquisition. Renaming the file is the only way to ensure that the user doesn't accidentally select the wrong .(out) file. Regardless of the (.out) file selected, the file would be read by Qimera with no way to distinguish if the file is indeed the correct one for this particular task.

When importing POSPac SBET files, 'sbet' must be part of the base name of the file. The base name is the part of the file path after the directory and preceding the file extension. If you have an associated RMS file, it must have the same naming except that 'sbet' is replaced with 'smrmsg'. If this naming convention is not used, Qimera will not be able to auto-recognize the file type.