Metadata and Reporting Requirements for IR Images and Video¶
1. Introduction¶
1.1 Purpose¶
This document outlines metadata requirements and technical specifications for IR images and video surveys. The goal is to ensure alignment with Equinor data delivery standards. These standards aim to facilitate robust environmental accounting and reporting, particularly concerning mapping and monitoring of biological resources utilising IR images and video.
A framework is provided to ensure that providers of technological services (also known as vendors) give a full overview of all relevant parameters needed for understanding, evaluating and analysing the data. Further, the procedures and requirements outlined below facilitate how the vendor shall deliver their data to Equinor.
1.2 Scope¶
IR data may be generated by stationary or moving systems (e.g. onboard moving vessels or fixed onto infrastructure). Deployments generally include multiple camera systems that are integrated to form a unified recording system, used to detect and identify visual cues. An IR camera sensor might therefore be a single IR camera or groups of cameras where video footage from individual IR cameras are merged in order to provide a wide azimuth video footage.
This document covers the technical, operational, and reporting requirements for infrared surveys, including:
- Metadata fields required for survey documentation.
- Sensor configurations and technical specifications for Infrared camera systems and auxiliary survey equipment.
- File formats and data delivery standards for images, videos, and geospatial data.
- Reporting requirements for integrating survey results into external databases like GBIF (Global Biodiversity Information Facility) and national databases.
Current drafted JNCC (Joint Nature Conservation Committee) guidelines outline the use of infrared camera systems during periods when visual mitigation is not possible (e.g., darkness, low visibility). The effectiveness of the infrared technology shall be documented. These requirements ensure alignment with JNCC while providing flexibility to accommodate project-specific needs.
Nomenclature for biology shall be reported in accordance with Catalogue of Life and, if relevant, other country specific requirements.
1.3 Target Audience¶
The intended audience for this document includes external:
Vendors: Such as survey providers tasked with data collection and delivery.
Marine Biologists and Ecologists: Professionals responsible for processing infrared data for e.g. detecting and classifying species.
Data technical teams: Data technical teams for implementing the data validation according to the standards defined.
2. Delivery of Data Procedure – Step by Step¶
To successfully deliver metadata, data, and reports to Equinor the following high-level sequence must be followed.
- The vendor shares contact and survey details as stated in the user guide provided by Equinor.
- Follow the user guide on how to deliver data according to the data formats section. Failures will result in retransmittal requests. Any contract specific requirements will be in addition to this.
- The vendor shall inform Equinor once the data is uploaded.
3. Requirements about Data Loader and Survey¶
- The vendor needs to supply the information described in the user guide (section 1 - Information Required Before Initiating Data Upload) prior to data delivery. The data loader’s email address and phone number will be used as their main identifier in Equinor’s systems. Equinor requires that email addresses are used solely by the data loader (i.e., it is not a shared email account).
- Once Equinor has received the information and approved it, the data loader may proceed with the subsequent upload. When loading data, the instructions in separate user guide shall be followed in conjunction with the requirements in sections 4 and 6 below.
4. Metadata Requirements and Delivery¶
Metadata plays a pivotal role in ensuring the consistency, traceability, and usability of data collected during surveys gathering imagery material for characterisation of field parameters and biological measurements. It serves as the backbone for data integration, regulatory compliance and effective environmental analysis.
This section outlines how metadata shall be delivered and the core metadata categories necessary to support these objectives, which include fields necessary for survey documentation, including survey-specific and geospatial metadata. Metadata shall, if no other requirements are given, be delivered to the following folder “DataAcquisitionInformation” (see section 6)
The metadata requirements are grouped into the following categories
I. Survey Metadata (see section 4.1): Captures details about the overall survey context and effort. Equinor requires that all data can be accurately located back to where it was acquired and can reconstruct the temporal context it was collected in.
II. Geospatial Metadata (see section 4.2): Ensures a detailed description of the survey’s spatial information. Survey metadata provides precise geographical coordinates and geodetic details for surveyed locations, enabling accurate mapping and analysis critical for environmental reporting and habitat classification
III. Sensor Metadata (see section 4.3): Documents the technical details of sensors and equipment used during the survey, such as sensor/camera type, calibration, operational parameters, and data resolution. This metadata is essential for understanding the conditions under which the data was captured and ensuring it meets technical and individual sensors’ quality standards.
Each of these metadata categories is designed to facilitate seamless integration with regulatory requirements and databases such as GBIF (Global Biodiversity Information Facility. They therefore ensure that survey outputs align with global environmental and scientific standards, supporting robust environmental management and decision-making processes.
In the subsequent sections, each metadata category is detailed with specific field descriptions, formats, and validation requirements to provide a comprehensive framework for documenting and delivering survey data.
4.1 Survey Metadata¶
Survey metadata refers to the type of survey conducted, defining the operational context of a survey, ensuring data traceability and enabling aggregation across related datasets.
Purpose:
- To link survey data to its broader campaign or project.
- To maintain a clear record of survey-specific attributes for reporting and compliance.
Key Fields:
-
Campaign number: Links the survey to a larger campaign.
-
Temporal details: Identifies the survey timeline (date and time).
-
Sensor setup details: Sensor information (number of sensors, sampling type) connected to a specific survey, project, or operational asset.
Table 1: Survey metadata:
| Field | Data Type | Description | Example |
|---|---|---|---|
| Parent Event ID | Text | Identifier for a campaign | Hywind |
| Location ID | Text | Identifier for survey location | LOC_001 |
| Event ID | Text | Unique ID for survey event | Hywind_LOC_001 |
| Survey Start Date and Time | Date (YYYY-MM-DD HH-mm-ss) | Start date of survey activity | 2024-01-15 12:00:00 |
| Project/Asset Name | Text | Name of project or asset | Hywind Tampen |
| Sensor carrier/platform | Text | Name of carrier/platform/Vessel used for deployment | Titanic |
| Sensor system | Text | IR system carrying the individual sensors/cameras | if relevant. E.g., Marine ObserverTM |
| Number of cameras | Number | Value indicating the number of cameras integrated in the IR system | 6 |
| Sampling type | Text | Describing the type of sampling | Stationary, Moving |
For naming conventions of files containing survey metadata see section 6.2.2.
Check-list essentials:
-
Ensure unique IDs for Parent Event, Location, and Event fields.
-
Cross-reference survey metadata with operational records.
-
Verify time zone consistency across all survey data
4.2 Geospatial Metadata¶
Geospatial metadata describes information related to the survey and the data, which allows for spatial contextualization of the sampling process. Therefore, geospatial metadata shall be shared, providing precise locational data critical for mapping and analysing surveyed areas.
Purpose:
-
To link survey data to its broader campaign or project.
-
To ensure spatial accuracy and facilitate geospatial analyses for habitat classification and environmental reporting.
Key Fields:
-
Geographical coordinates: Coordinates in decimal degrees, in WGS84.
-
Spatial features of the sampling setup: E.g., elevation, country
Table 2: Geospatial metadata
| Field | Data Type | Description | Example |
|---|---|---|---|
| Latitude * | Decimal (8 digits) | Latitude in decimal degrees for survey center point | 59.12345612 |
| Longitude * | Decimal (8 digits) | Longitude in decimal degrees for survey center point | 10.65432123 |
| Station name X** | Text | The station naming convention should be consistent with reports and other documentation supplied by the vendor | Hywind Tampen |
| Station_X_lat** | Decimal (8 digits) | Decimal degrees | 59.12345612 |
| Station_X_lon** | Decimal (8 digits) | Decimal degrees | 10.65432123 |
| Geodetic Datum | Text | Geodetic reference system | WGS84 |
| Country code | Text | Country code of location | NO |
| Survey elevation | Decimal (2 digits) | Average height of surveyed area in meters above sea level | 200.45 |
*For moving systems, e.g. onboard vessels, the vendor shall provide the coordinates for a center point of latitude and longitude in decimal degrees relative to the entire survey area. Details of the navigation information shall be given in accordance with section 6.2.2.
**For fixed or point-based surveys, fill accordingly.
All time stamp data should be supplied with UTC time zone and in ISO 8601 format, while all geospatial data is to be delivered in lat/long in WGS84 datum. Original coordinates (e.g., collected in other datums such as UTM), as measured or data source should be retained or archived. Any transformations applied to coordinate data should, when possible, be applied to the original coordinates, rather than coordinates that have been transformed at an earlier stage in the data lifecycle.
For naming conventions of files containing geospatial metadata see section 6.2.
Check-list essentials:
-
Ensure all coordinates fall within the operational survey area.
-
Verify datum consistency across all survey records.
4.3 Sensor Metadata¶
Sensor metadata describes the equipment used during the survey, ensuring transparency and reproducibility of data collection. The vendor shall document the type of system used and all relevant settings of the recording device. Note: If more than one type of sensor system is used then this information should be supplied for all the different types of systems deployed. For example, if multiple cameras are used with different settings, individual descriptions of all cameras are required.
Folder (where to store this type of data): “DataAcquisitionInformation”
Purpose:
-
To document the specifications and performance of sensors used for data capture.
-
To validate that data is collected under appropriate technical conditions.
Key Fields:
-
Sensor specifications: E.g. model and resolution
-
Operational Parameters: Pitch, roll, and heading of sensors relative to true North.
Table 3. Sensor metadata.
| Field | Data Type | Description |
|---|---|---|
| IR module model | Text | Brand of recorder |
| IR module type | Text | Camera core used |
| IR imaging detector | Text | Cooled or uncooled long-wave core |
| Single camera resolution | Number | Width and height in pixels |
| Angle resolution | Text | Combination of lens used and sensor resolution |
| Combined camera resolution | Number | Width and height in pixels |
| Frame rate | Number | Number in Hertz |
| Sensor bit depth | Text | Sensors come with different bit depth, but full bit depth is often not used in processing/storage |
| Wavelength range | Number | Range in micrometers |
| Spectral band | Text | Spectral classification |
| Thermal sensitivity | Text | NETD (Noise Equivalent Temperature Difference) 50 mK |
| Heading | Text | System heading in relation to true North |
| Field of view | Text | Field of view per camera |
| Azimuth | Text | Angle of view for each camera/sensor |
| Azimuth survey | Text | Total angle of view of several systems |
| Processing bit depth | Text | Processes for automated detection might work on raw sensor bit depth or on video bit depth |
| Recording bit depth | Text | Bit depth of recorded footage |
| Usage level | Text | Export designation |
| Sensor output | Text | Describes video output format |
| Stabilization system | Text | Type of camera stabilization |
| Elevation Above sea level | Decimal (1-2) | Operational elevation/altitude (meters) |
| System firmware | Text | Firmware version |
This table outlines the standard codes for identifying cameras used in videos and still images, ensuring consistency in file naming conventions.
Table 4. Suggested camera indexing and relevant descriptions *.
| CODE | Description |
|---|---|
| CAM1 | Port Camera |
| CAM2 | Centre Camera |
| CAM3 | Starboard Camera |
| CAM4 | Additional camera |
*Alternatively, a system designed with multiple cameras shall ensure similar codes assigned to each individual camera with a description of the labelling used.
Validation/check list:
-
Validate sensor data against operational requirements (e.g., location, altitude, and heading accuracy).
-
Ensure metadata overlays (e.g., elevation) are consistent across sampling and video and image files.
5. Minimum Technical Specifications¶
This section outlines the technical specifications required to conduct infrared surveys effectively. It includes the types and configurations of sensors used for data collection and the standards for data capture. Adherence to these specifications ensures high-quality data acquisition, operational consistency, and compliance with environmental standards.
The section is divided into the following subsections:
I. Sensor Types and Configurations: Describes the recommended sensors and their integration with carriers.
II. Data Capture Standards: Defines quality requirements for video and still imagery (e.g., camera resolution).
5.1 Sensor Types and Configurations¶
IR systems may be deployed onboard vessels and aircraft, or fixed-point platforms. In each scenario, digital video and still cameras may be used. Across all combinations, the relevant sensor type, configuration, and integration with carrier shall be documented. The use of auxiliary sensors (e.g., CTD, GNSS) shall also be reported. Independently of carrier, the integration and stabilization shall meet the requirements for minimum azimuth coverage and bearing/positioning of the target animal or species.
5.2 Data Capture Standards¶
The minimum data capture specifications are given in the table below. Additionally, survey-specific guidance may be given.
Table 5. Minimum requirements for file formats, length, and resolution.
| Data Type | Azimuth Coverage | Sample Rate/resolution | Recording bit Depth | Example file format | File length | Additional Requirements |
|---|---|---|---|---|---|---|
| Video | 360° (continuous coverage) | 5–10 Hz (minimum)* | 8-bit | MP4 H.264 (MPEG-4 AVC) | 30min | Continuous data recording (24/7). |
| Stills | 360° (minimum 10% overlap) | 720p* | 8-bit | PNG or JPEG | NA | Still images must have at least 10% overlap to ensure complete coverage.* |
| Track data | NA | NA | NA | ASCII comma-separated files (.VTF) | NA | Continuous data recording (24/7). |
*The final degree of overlap, sample rate or resolution, and bit depth shall be agreed upon and justified in the final metadata report (see section 7.1)
Quality Control Requirements:
-
Ensure videos are free from blurriness in both play and pause modes.
-
Validate the overlay of all required metadata fields during recording.
6. Data Formats and Delivery¶
This section summarizes data format and file naming requirements for deliveries of IR data. The objective is to give clear instructions to enable automated ingestion.
The nomenclature for biology shall be reported in accordance with Catalogue of Life, and, if relevant, in accordance with other country specific requirements. Uncertainty in survey results shall be given as a component of the project deliveries, thus ensuring comparability in the results across multiple surveys/projects.
If the vendor experiences issues related to data upload, use the following email: biodiversity-support@StatoilSRM.onmicrosoft.com.
6.1. File Formats¶
Survey information shall be delivered as an excel file. Raw, pre-processed, processed, and interpreted data shall be kept as separate entities, each with its own storage location. As described above, Equinor requires that sensor configuration and navigational data originating from moving deployment platforms (e.g., vessels) is provided to further contextualize the delivered datasets (section 6.2.2).
-
Raw data Defined as quality-controlled and cleaned photo and unmerged video data without erroneous, incorrect or data which does not comply with data protection regulations. Folder to store this type of data: “RawIRData”
-
Processed data Defined as quality-controlled photo and video data where signal processing has been applied (like resampling, filtering, merging, changes in brightness, etc). Folder to store this type of data: “ProcessedIRData”
-
Interpreted data Defined as data and results extracted from the imagery material. For example, automated signal detection logs, manual detection logs, transformed data, generated data (e.g., outputs of detection probability), and statistics.
Folder to store this type of data: “InterpretedIRData”
6.2. File Naming Conventions¶
The association between files and their parent data (if any) should be explained in the report. As explained in the data loading guide, systems with multiple cameras shall upload the data separately and in clearly designated/identified folders for each camera.
Required file naming structure for raw, and processed datasets:
I. Videos:
Example: EQ22900_CAM1_20240101T120000Z.mp4II. Still Images:
Example: EW1_ CAM1_20240101T120000Z.pngFolder structure: Files should be organized by survey date and time (e.g., 20240101_12).
Note that <Timestamp_of_start_of_data_in_file> is the UTC time and date at which the first data sample in the file was acquired written in this format: YYYYMMDDThhmmssZ (eg. 20250325T143200Z).
6.2.1 Requirements for Interpreted Data¶
The survey findings and interpreted biological and environmental data may be utilized and integrated into international and national databases, such as GBIF (Global Biodiversity Information Facility).
File format:
IR data detection (e.g., cetaceans, seabirds) shall include information in the form of detection events in a chronological order. If reporting only upon first sighting, use the same timestamp for both start and end of an event. A template for interpreted detection data is provided in section 7.2 DT½.
Datasets for detection probability and other analytical datasets (e.g., automated detector performance) shall be defined in the final report (see section 7).
Requirements regarding time extent:
Date and time period each file relates shall be reflected in the filename and in the report.
File naming convention:
The association between files and their associated parent data (if any) should be explained in the report. Required file naming structure
Where <Timestamp-Of-Start-Date-Survey> is the UTC time and date at which the first data sample in the file was acquired written in this format: YYYYMMDDThhmmssZ (e.g., 20250325T143200Z).
<Free-Text> describes the contents of the file (e.g., seabird detections). All filenames should be unique. Please quote full filenames when referring to them in reports.
Other requirements:
The report shall have a description of how the interpretations have been made (e.g., automated using a particular process, manual, combination of automated and manual).
6.2.2 Track Data and Operation Logs¶
All datasets originating from mobile systems (e.g., vessels, aircraft, moving across multiple stations) shall be provided as navigation logs for the platform. These logs must include a time stamp (in UTC) and geographic coordinates (latitude, longitude in WGS84) in decimal degrees at a one-minute resolution. Further, the track data must be synchronized in time with the time stamps provided for the IR video/photo files (and hence, the sensor metadata). Equinor must be instructed how to identify which track (i.e., navigation) data relates to which sensor and be able to combine the sensor data and the navigation data together to geospatially locate the sensor data. Configuration files from either system or individual cameras shall be delivered (i.e., operation logs), with appropriate labelling.
Folder (where to store this type of data): “DataAcquisitionInformation”
Mandatory file header requirements:
-
DateTime (YYYYMMDDThhmmssZ)
-
Latitude (decimal degrees)
-
Longitude (decimal degrees)
File naming convention:
A systematic overview of the sampling track shall also be provided. Required file naming structure
<Asset/Project>_<Contract-number>_<Station/transect>_<Timestamp-Of-Start-Date-Survey>_<Free-Text>_TrackData.csv
<Asset/Project>_<Contract-number>_<Station/transect>_<Timestamp-Of-Start-Date-Survey>_Operational log.csv
The vendor shall add in free text relevant descriptive labels to indicate whether the file represents track data or sensor configuration logs. In the event of multiple navigation logs sharing the same filename, please use the <Free-Text> field to uniquely identify which track data relates to which sensor.
6.2.3 Data Processing Details¶
In addition to supplying metadata, the vendor must also supply instructions about how Equinor can utilize the IR footage correctly. There are two categories of information required to do this:
I. Correlation Sensor Raw Data
In the absence of accepted industrial standards, the vendor must provide clear instructions explaining how their video footage can be connected/correlated to corresponding geospatial data thus enabling Equinor to know where image data was always acquired and the field of view interrogated by the camera at all times during the acquisition campaign. Processing and interpretation of data using vendor supplied IT tools. Equinor requires that there is sufficient metadata delivered with video footage to ultimately enable use of commercially available IT tools to interpret IR video/photo footage. For the time being however, Equinor accepts that usage of vendor specific proprietary IT tools might be required to view, process or interpret the IR footage. In these cases:
II. Equinor must have access to an IT tool which can process and interpret the IR footage correctly.
Equinor requires the vendor to supply information about how the IR data must be stored and handled in order to support usage of the vendor’s proprietary tools. An example of this would be if the vendor’s proprietary tool imposes a specific folder structure or other specific data management requirements in order to be useable.
6.3 Additional Data¶
The vendor shall supply additional data when they exist. For instance, files whose sole purpose is to relate to the environment the IR data was acquired in. Examples include: Metocean data, wind, tide, weather data, visibility data, operational data from facilities or construction, vessel data, oceanographic data from probes or sensors, biological, geoscientific data. Equinor requests that they add a list with relevant metadata associated with the additional instrumentation used in the survey.
Folder (where to store this type of data): “EnvironmentalRelatedInformation”
File naming structure shall allow the purpose of the files to be understood:
7. Integration and Reporting¶
Integration and reporting ensure that infrared survey data is properly aligned with regulatory requirements, environmental databases, and project deliverables.
This section outlines the protocols for preparing, integrating, and submitting survey reports.
Folder (where to store this type of data): “ReportsAndSupportingInformation”
7.1 Metadata Report¶
The metadata report describes an overview of the data acquisition, effort, and main findings, including additional and supporting details relevant to the data acquisition process.
The Metadata report should be provided in the following formats.
Reports: PDF.
Metadata Fields: The following fields must be included, please visit the section 4 for details.
The report shall provide an overview of the recordings, including:
-
Total number of files recorded and total file size.
-
Cumulative recording time.
-
Any known interruptions or gaps in data.
7.2 Imagery Data Report¶
An imagery data report shall provide a description of the interpreted datasets, analysis’s methods and annotations of relevant animal detections.
When automated detectors are used, the precision and recall of the detectors is explicitly disclosed in the final reporting documents, together with a reference to how these have been estimated (e.g., if only upon a certain sample of the data, the vendor shall specific the size of the sample used). If Artificial Intelligence (AI) detectors are used, the report shall also describe the AI system (e.g., supervised vs unsupervised machine learning), together with quantifiable metrics for its/their performance (e.g., number of samples used for training and validation). Traditional non-machine learning detectors shall also be described.
Animal detections shall be reported to the species level when possible, and at least the genus (e.g., Balaenoptera, Delphinus, Larus)
The report shall follow accepted scientific practices, where the vendor shall also expand on any known interruptions or gaps in the data (due to, for instance, operational malfunction and/or events beyond the control of the vendor).
Reports: PDF.
Data Fields: The following fields must be included, please visit the section 4 for details.
The report shall provide an overview of the recordings, including:
-
Sampling and detection timeseries.
-
Spatial features of detections and sampling effort.
The vendor shall also provide standardized documentation of marine animal (e.g., mammals and seabirds) detection events, using the following template sheets:
DT1: Sampling events
| Field | Description | Example |
|---|---|---|
| parentEventID | An identifier for the broader Event that groups this and potentially other Events. E.g., survey ID. | EQ02053 |
| locationID | An identifier for the set of location information. May be a global unique identifier or an identifier specific to the data set. | EmpireWind |
| eventID | An identifier for the set of information associated with an Event (something that occurs at a place and time). May be a global unique identifier or an identifier specific to the data set. | EQ02053_CAM1 |
| eventStartDateTime | The date-time when the start of the event was recorded. Recommended best practice is to use an encoding scheme, such as ISO 8601:2004(E). | 2018-10-05T13:00:00Z |
| eventEndDateTime | The date-time when the end of the event was recorded. Recommended best practice is to use an encoding scheme, such as ISO 8601:2004(E). | 2019-05-26T14:00:00Z |
| samplingProtocol | The name of, reference to, or description of the method or protocol used during an Event. | Infrared camera system |
| decimalLatitude | The geographic latitude (in decimal degrees, using the spatial reference system given in geodeticDatum) of the geographic center of a Location. | 72.46501 |
| decimalLongitude | The geographic longitude (in decimal degrees, using the spatial reference system given in geodetic Datum) of the geographic center of a Location. | 20.34738 |
| geodeticDatum | The ellipsoid, geodetic datum, or spatial reference system (SRS) upon which the geographic coordinates given in decimalLatitude and decimalLongitude are based. | EPSG:4326 |
| countryCode | An identifier for the country where the event occurred. Recommended best practice is to use ISO 3166-1-alpha-2 country codes. | NO |
| datasetName | The name identifying the dataset from which the record was derived. E.g., contract name. | Empire Wind 1 IR monitoring |
DT2: Associated Occurrences
| Field | Description | Example |
|---|---|---|
| eventID | An identifier for the set of information associated with an Event (something that occurs at a place and time). May be a global unique identifier or an identifier specific to the data set. | EQ02053_CAM1 |
| occurrenceID | An identifier for the Occurrence. | EQ02053_CAM1_FW_1 |
| basisOfRecord | The specific nature of the data record. Recommended best practice is to use this controlled vocabulary:Darwin Core Type Vocabulary | MachineObservation |
| eventStartDateTime | The date-time when the start of the event was recorded. Recommended best practice is to use an encoding scheme, such as ISO 8601:2004(E). | 2018-10-05T13:00:00Z |
| eventEndDateTime | The date-time when the end of the event was recorded. Recommended best practice is to use an encoding scheme, such as ISO 8601:2004(E). | 2019-05-26T14:00:00Z |
| scientificName | The full scientific name. Be as specific as possible. | Balaenoptera physalus |
| taxonRank | The taxonomic rank of the most specific name in the scientificName. | Species |
| type | The nature or genre of the resource. E.g., type of detector. | WhaleSpout |
| occurrenceStatus | A statement about the presence or absence of a Taxon at a Location. | Present |
| eventRemarks (optional) | Comments or notes about the event. | Presence of clutter. |
| organismQuantity (optional) | A number or enumeration value for the quantity of organisms | 63 |
| organismQuantityType (optional) | The type of quantification system used for the quantity of organisms. An organismQuantityType must have a corresponding organismQuantity. | % days with IR detections |
7.3 Visual Documentation¶
Provide photographic documentation of:
-
Deployment setup.
-
Equipment in site.
8. Glossary¶
The following terms and acronyms are used in this document and are defined here for clarity.
| Acronym | Explanation |
|---|---|
| ASCII | American Standard Code for Information Interchange |
| AVC | Advanced Video Coding |
| ID | Identification |
| MPEG-4 | Moving Pictures Expert Group 4 |
| Portable Document Format | |
| PNG | Portable Network Graphic |
| SSU | Safety, Security and Sustainability |
| VTF | Video Track Format |
| WGS84 | World Geodetic System 1984 |