3.1.1.  Organization

The Executable Test Suite has four stages:

1) MPEG conformance testing

The GIMI Standard is built on a collection of existing industry Standards. These standards are maintained by the Moving Picture Expert Group (MPEG), Motion Imagery Standards Board (MISB), the Joint Photographic Experts Group (JPEG), and the International Organization for Standardization (ISO). Since the OGC does not have authority to define conformance for these standards, the GIMI test-suite addresses these requirements using a widely accepted conformance test tool. ComplianceWarden was selected to fill that role.

2) GIMI File Parser

The first step in processing a GIMI file is to convert it from its’ native box structure into an in-memory representation of that structure. This task is performed initially by the SIS GeoHEIF code from Apache. Since this code does not address all of the GIMI box types, it is augmented by ETS-specific parsing code. It is expected that this code will be incorporated, in some form, into SIS in the future.

3) Information Extraction

The GIMI format is built from boxes. A box can contain other boxes, or data, but not both. This results in a complex data model where it can be complicated to locate and extract a specific item of information. The GIMI ETS parser flattens that format into a Java class model. In addition, it pre-processes information elements, making them easily accessible by the conformance tests.

4) GIMI Tests

The GIMI test-suite uses TestNG as its testing language. TestNG is a Java based software testing framework. The GIMI test-suite consists of one package for each conformance class, and one test method for each requirement. Since the required information has been pre-processed by the GIMI parser, the test methods can focus on the requirements.

3.1.2.  Conformance Classes

The GIMI 1.0 Standard is organized into five Conformance Classes. These are:

The GIMI Standard is self describing. The file header contains a set of “brands”. Each Conformance Class corresponds to a brand (the opposite is not the case). If the content governed by a Conformance Class (brand) is present in any form, then conformance to that Conformance Class is required. As a result, this test suite does not allow the user to select Conformance classes. If the content and brand are present, then the Conformance Class will be tested.

3.2.1.  Integrated development environment (IDE)

Use a Java IDE such as Eclipse, NetBeans, or IntelliJ. Clone the repository and build the project. Set the main class to run: org.opengis.cite.gimi1.TestNGController

Arguments: The first argument must refer to an XML properties file containing the required test run arguments. If not specified, the default location at ${user.home}/test-run-props.xml will be used.

You can modify the sample file in src/main/config/test-run-props.xml

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
  <properties version="1.0">
      <comment>Sample test run arguments</comment>
      <entry key="iut">file:///path/sample-image.heif</entry>
  </properties>

The TestNG results file (testng-results.xml) will be written to a subdirectory in ${user.home}/testng/ having a UUID value as its name.

3.2.2.  Command shell (console)

One of the build artifacts is an “all-in-one” JAR file that includes the test suite and all of its dependencies; this makes it very easy to execute the test suite in a command shell:

  java -jar ets-gimi-1-0.2-SNAPSHOT-aio.jar  [-o|--outputDir $TMPDIR] [xml-file]

Where xml-file is the path to the properties XML file, e.g., src/main/config/test-run-props.xml.

The example below declares the TE_BASE environment variable, the output folder for the test report, and the input XML file that references the GIMI file to be tested.

  java -jar -DTE_BASE=/cli-testing/te_base  ets-gimi-1-0.2-SNAPSHOT-aio.jar  -o /cli-testing/output  /cli-testing/test-run-props.xml

3.2.3.  OGC test harness

Use TEAM Engine, the official OGC test harness. The latest Beta versions of executable test suites are usually available at the beta testing facility. However, by the end of Testbed-21 the GIMI ETS was still at Alpha stage, therefore the ETS was only available from OGC’s Gitlab Server. It is envisaged that after validation and approval by the Sponsor, the ETS can be moved to the Beta testing facility or a similar environment. This may occur in subsequent Testbeds. Nonetheless, a user can also [build and deploy](https://github.com/opengeospatial/teamengine) the test harness and use a local installation.

5.2.1.  Conformance Package

The Conformance package contains five sub-packages, one for each Conformance Class. Each sub-package contains one or more Lava classes, each containing test methods with similar information requirements. Each java class contains an initialize() method which runs before any of the test methods. This method extracts information from the object model and prepares it for use by the test methods. Each test method addresses one and only one requirement.

5.2.2.  Content Package

The Content package contains seven sub-packages. These sub-packages are organized based on central concepts from the GIMI standard.

5.3.1.  Apache SIS

Apache Spatial Information System (Apache SIS) is an open-source Java library designed to support the development of geospatial applications. It provides core data structures for representing geographic features, spatial metadata, and coordinate reference systems, and it implements the GeoAPI interfaces to ensure interoperability with industry standards.

A key strength of Apache SIS lies in its adherence to OGC and ISO geospatial standards. Its referencing module supports coordinate reference system definitions and transformations between them. The library also provides storage modules capable of reading and writing a variety of geospatial data formats, including GeoTIFF, ASCII grids, and GIMI/GeoHEIF files.

Within the GIMI ETS, the Apache SIS library is used to support the parsing and reading of ISOBMFF and HEIF boxes. This includes code specifically designed for reading GIMI specific content in those boxes. Much of the source code developed in this Testbed for GIMI conformance testing was also contributed back into Apache SIS to improve the box parsing.

GIMI files are input to the Executable Test Suite using the GeoHeif software developed for Apache SIS. This software parses the GIMI file and generates one Java class for each box. While currently included in the GIME ETS project, they are expected to become a part of the Apache SIS platform in the future.

5.3.2.  Apache Jena

Apache Jena is a free, open-source Java framework for building Semantic Web and Linked Data applications. It provides developers with tools and APIs to create, manipulate, and query RDF (Resource Description Framework) data, which forms the foundation of many knowledge graph systems. The support for RDF includes the ability to write or read many of the common RDF encoding formats, e.g. RDF/XML, RDF Turtle, and JSON-LD.

A central feature of Apache Jena is its support for querying and storage of RDF data. Through its ARQ engine, Jena provides a full implementation of the SPARQL 1.1 query language, allowing users to perform complex queries. The framework includes TDB, a high-performance native triple store for persistent storage, as well as Fuseki, a server component. Jena’s ontology API supports vocabularies such as RDFS, GeoSPARQL and OWL, thereby making it ideal for integration into the GIMI Conformance Testing Tool.

Within the GIMI ETS, the Apache Jena library is used for parsing and reading RDF-encoded metadata retrieved from a GIMI file. By using Jena for this purpose, the ETS benefits from the ability of Jena to both parse and query an RDF graph. It is envisaged that future extensions of the ETS will include the ability to run SPARQL queries and apply SHACL shapes during validation.

5.3.3.  Apache Xerces

Apache Xerces is an open-source software project from the Apache Software Foundation that provides a family of XML parsers and related tools. The project includes implementations in multiple programming languages, notably Java, C++, and Perl. The parsers are optimized to handle large and complex XML documents while maintaining efficiency and reliability. The modular architecture enables developers to extend and customize parsing behavior for advanced use cases.

A core strength of Apache Xerces is its comprehensive support for XML standards and APIs. Xerces parsers are designed to be fully compliant with specifications such as XML 1.0 and 1.1, namespaces, and XML Schema, ensuring accurate validation and interoperability. The project supports widely used programming interfaces including DOM, SAX, JAXP, and StAX, providing flexibility for different styles of XML processing.

Within the GIMI ETS, the Apache Xerces library is used for parsing XML-encoded content such as the Security labeling included in a GIMI file. Not only is the ETS able to parse the XML-encoded Security metadata, but it is also able to validate the metadata to confirm that it is structured according to the schema defined by the Intelligence Community Information Security Marking (IC ISM) standard.

5.3.4.  ComplianceWarden

ComplianceWarden is an open-source pluggable compliance checker developed within the GPAC ecosystem to validate media files against a variety of formal specifications, particularly those related to modern multimedia container and codec standards. It serves as conformance testing tool for key specifications such as MPEG MIAF, AOM AVIF, and AV1 HDR10+, and is designed to extend to other formats including ISOBMFF, HEIF, MP4, and CMAF. The project is written in modern C++ and distributed under a permissive BSD-3 license, making it suitable for both research and production environments where standards compliance is critical.

A defining architectural feature of ComplianceWarden is its separation of parsing and validation. The tool first parses an input file into a generic abstract syntax tree (AST), which represents the structure of the media content independent of any specific rule set. It then applies validation rules attached to particular specifications on this AST, enabling flexible and extensible compliance checking across multiple standards. This design allows new specifications and rules to be added incrementally, supporting evolving industry standards while maintaining a consistent processing pipeline.

Within the GIMI ETS, the ComplianceWarden tool is used for verifying that a file conforms to the ISOBMFF and HEIF standards. ComplianceWarden is called by the GIMI ETS through an external process. This is because ComplianceWarden is mainly implemented in C/C++ whereas the GIMI ETS is a Java-based application. Nonetheless, the results of the tests executed within ComplianceWarden are reported back through the GIMI ETS and TEAM Engine. Therefore, the user only ever needs to interact with the entire GIMI ETS through a TEAM Engine.

6.4.1.  Get the source code

The source code is available from GitHub. Use Git to clone the repository and checkout a branch or a tagged release as indicated below:

git clone https://github.com/opengeospatial/teamengine.git git checkout ${project.version} (git checkout 6.0.0)

Apache Maven 3.9 is required to build the TEAM Engine code base, which currently consists of the following modules:

6.4.2.  Build with Maven

Simply run mvn package in the root project directory to generate all build artifacts, or run mvn install to also install them into the local Maven repository. The main build artifacts are listed below.

The site documentation can be generated by simply executing the ‘mvn site’ phase against the top-level POM. An aggregate PDF document is also created and placed in the target/pdf directory.

6.4.3.  Set up an instance directory (TE_BASE)

The value of the TE_BASE system property or environment variable specifies the location of the instance directory that contains several essential sub-directories. Create the TE_BASE directory (e.g. at /srv/teamengine) and unpack the contents of the teamengine-console-${project.version}-base archive into this location; make sure that users (including the Tomcat user) have write access. The structure of the TE_BASE directory is shown below.

TE_BASE
  |-- config.xml    # main configuration file
  |-- resources/    # test suite resources
      |-- site      # site-specific HTML (welcome, title, etc.)
      |-- lib       # Java-based test suites and supporting libraries
  |-- scripts/      # CTL test scripts
  |-- work/         # teamengine work directory
  |-- users/
     |-- {user1}/   # user account information and test run results
     |-- {user2}/
     +-- ...

CTL test scripts must be placed in the TE_BASE/scripts directory. Java-based test suites along with their supporting libraries are placed in the TE_BASE/resources/lib directory.

6.4.4.  Create a dedicated Tomcat instance

Apache Tomcat 10.1 is a supported servlet container. It is strongly recommended that a dedicated Tomcat instance be created to host the teamengine application. That is, keep the location of the instance-specific data (referred to as CATALINA_BASE in the Tomcat documentation) separate from the Tomcat software installation (CATALINA_HOME). Create it as outlined below for your operating system.

To create a CATALINA_BASE directory in Windows:

  mkdir base-1 & cd base-1
  xcopy %CATALINA_HOME%\conf conf\
  mkdir lib logs temp webapps work

In a Unix-like environment:

  sudo mkdir -p /srv/tomcat/base-1; cd /srv/tomcat/base-1
  sudo cp -r $CATALINA_HOME/conf .
  sudo mkdir lib logs temp webapps work

The recommended JVM options for the Tomcat instance are shown below. Note that the maximum memory heap size (-Xmx) may need to be increased as the number of concurrent users increases.

  CATALINA_OPTS="-server -Xmx1024m -XX:MaxPermSize=128m -DTE_BASE=$TE_BASE -Dderby.system.home=$DERBY_DATA"

Unpack the contents of the teamengine-common-libs archive into the CATALINA_BASE/lib directory. Deploy the teamengine.war component by either copying it into the CATALINA_BASE/webapps directory or using the Tomcat Manager application. Start the Tomcat instance.

The URIs listed below provide starting points for discovering and executing test suites. Modify the path if the name of the WAR file (and hence the context path) has been changed from the default value: “teamengine”.