OGC CityGML 3.0 Part 2 GML Encoding Conformance Test Suite

Scope

This Standard documents the OGC GML Implementation Specification (IS) for the CityGML 3.0 Conceptual Model. The CityGML 3.0 conceptual model is a Platform Independent Model (PIM). It defines concepts in a manner which is independent of any implementing technology. As such, the CityGML Conceptual Model cannot be implemented directly. Rather, it serves as the base for Platform Specific Models (PSM). A PSM adds to the PIM the technology-specific details needed to fully define the CityGML model for use with a specific technology. The PSM can then be used to generate the schema and other artifacts needed to build CityGML 3.0 implementations.

This standard defines the PSMs and schemas for the CityGML 3.0 Implementation Specification (IS) for Geography Markup Language (GML) implementations. The GML schemas are explained in an overview and design decisions that have been made are documented as well.

Several conformance classes are defined in the principal specifications; the ones listed below are covered by this test suite:

  • Annex A: Conformance Class Abstract Test Suite

    • A.1. Conformance Class Global

    • A.2. Conformance Class Core

    • A.3. Conformance Class Appearance

    • A.4. Conformance Class Bridge

    • A.5. Conformance Class Building

    • A.6. Conformance Class CityFurniture

    • A.7. Conformance Class CityObjectGroup

    • A.8. Conformance Class Construction

    • A.9. Conformance Class Dynamizer

    • A.10. Conformance Class Generics

    • A.11. Conformance Class LandUse

    • A.12. Conformance Class PointCloud

    • A.13. Conformance Class Relief

    • A.14. Conformance Class Transportation

    • A.15. Conformance Class Tunnel

    • A.16. Conformance Class Vegetation

    • A.17. Conformance Class Versioning

    • A.18. Conformance Class WaterBody

The Conformance Class Global Module has 1 missing requirement (https://github.com/opengeospatial/ets-citygml30-part2/issues/21 [Issue 21]), which will be implemented in the next stage if possible.

Test requirements

The documents listed below stipulate requirements that must be satisfied by a conforming implementation.

The documents listed below stipulate requirements that must be satisfied by a conforming implementation.

  1. OGC City Geography Markup Language (CityGML) Part 2: GML Encoding Standard

Test suite structure

The test suite definition file (testng.xml) is located in the root package, org.opengis.cite.citygml30part2. A conformance class corresponds to a <test> element, each of which includes a set of test classes that contain the actual test methods. The general structure of the test suite is shown in Table 1.

Table 1. Test suite structure
Conformance class Test classes

GlobalValidation

org.opengis.cite.citygml30part2.global.GlobalValidation

CoreValidation

org.opengis.cite.citygml30part2.core.CoreValidation

AppearanceModuleValidation

org.opengis.cite.citygml30part2.module.AppearanceModuleValidation

Appearance Module

org.opengis.cite.citygml30part2.module.AppearanceModuleValidation

BuildingModuleValidation

org.opengis.cite.citygml30part2.module.BuildingModuleValidation

BridgeModuleValidation

org.opengis.cite.citygml30part2.module.BridgeModuleValidation

CityObjectGroupModuleValidation

org.opengis.cite.citygml30part2.module.CityObjectGroupModuleValidation

DynamizerModuleValidation

org.opengis.cite.citygml30part2.module.DynamizerModuleValidation

ConstructionModuleValidation

org.opengis.cite.citygml30part2.module.ConstructionModuleValidation

GenericsModuleValidation

org.opengis.cite.citygml30part2.module.GenericsModuleValidation

LandUseModuleValidation

org.opengis.cite.citygml30part2.module.LandUseModuleValidation

PointCloudModuleValidation

org.opengis.cite.citygml30part2.module.PointCloudModuleValidation

ReliefModuleValidation

org.opengis.cite.citygml30part2.module.ReliefModuleValidation

TransportationModuleValidation

org.opengis.cite.citygml30part2.module.TransportationModuleValidation

VegetationModuleValidation

org.opengis.cite.citygml30part2.module.VegetationModuleValidation

VersioningModuleValidation

org.opengis.cite.citygml30part2.module.VersioningModuleValidation

WaterBodyModuleValidation

org.opengis.cite.citygml30part2.module.WaterBodyModuleValidation

TunnelModuleValidation

org.opengis.cite.citygml30part2.module.TunnelModuleValidation

The Javadoc documentation provides more detailed information about the test methods that constitute the suite.

How to run the tests

The options for running the test suite are summarized below.

As entry point the Landing Page of the OGC CityGML 3.0 Part 2 GML Encoding is expected.

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.citygml30part2.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>Test run arguments</comment>
  <entry key="iut">https://host/capabilities</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.

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-citygml30-part2-0.1-SNAPSHOT-aio.jar [-o|--outputDir $TMPDIR] [test-run-props.xml]

3. Docker

This test suite comes with a Dockerfile which can be used to easily setup the OGC test harness with the test suite. Details can be found on Create Docker Image and create and start Docker Container.

4. OGC test harness

Use TEAM Engine, the official OGC test harness. The latest test suite release are usually available at the beta testing facility. You can also build and deploy the test harness yourself and use a local installation.

Using the REST API

Using the REST API of the TEAM Engine requires some run arguments. These ate summarized in Table 2. The Obligation descriptor can have the following values: M (mandatory), O (optional), or C (conditional).

Table 2. Test run arguments
Name Value domain Obligation Description

iut

URI

M

A URI that refers to the implementation under test or metadata about it. Ampersand ('&') characters must be percent-encoded as '%26'.