OGC Testbed-14: CityGML and AR Engineering Report

This ER provides findings and recommendations which may impact a number of OGC Working Groups that deal with standards for working with 3D geospatial data.

All questions regarding this document should be directed to the editor or the contributors:

Contacts

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

As the use of CityGML was an important objective of this initiative, attempts were made to identify useable data sets, as well as CityGML Application Domain Extensions (ADEs) which may provide information more particularly useful for Augmented Reality experiments. Existing CityGML ADEs identified included:

Also relevant are the open source BIM collective [4], Indoor Spatial Data Model Using CityGML ADE [5], application of large 3D CityGML models on smartphones [6] and Augmented Reality Games with CityGML [7].

However, as it was already difficult to find a basic usable CityGML data set in an area of interest, let alone one defining any of these ADEs, no such data sets were identified.

Being able to see "hidden" features is a very useful aspect of AR, displaying underground utilities such as pipelines, is a good use case scenario. A data set of a pipeline in Kaohsiung, Taiwan available in the COLLADA format was used for some experiments in the Testbed. The location of the content however, proved problematic as no testbed participant was normally located in Kaohsiung.

The Testbed sponsors originally specified requirements for supporting 3D Tiles and/or I3S. They also hoped for a continuity of the work performed in Testbed-13 on 3D client performance. As a result, the focus shifted on the presentation of 3D buildings in an AR application. One problem with the presentation of 3D buildings in AR is that the actual buildings are normally directly visible, without the need for augmentations. As such, a 3D model would simply obstruct a real, better view of the actual building. However, having the 3D model could potentially be useful in an emergency response scenario where thick fog or smoke could severely restrict visibility. Alternatively, presenting the buildings with a reduced opacity setting may be useful to verify the accuracy of a data set with the real world, and/or for mapping one’s surroundings. The vast majority of the experiments performed in this initiative dealt with this 3D buildings scenario.

Unfortunately, the data sets used had little attribute information available. However, the approach implemented for transforming and transmitting buildings data kept into consideration the capability for preserving attributes when better attributed data is available.

In order to experiment with the capacity to display actual annotations apart from 3D models, separate and combined experiments were done using OpenStreetMap data for presenting street maps, including buildings and streets names.

Although desktop experiments were done with terrain elevation and aerial imagery, the very limited nature of mobile hardware, as well as the desire to not hide the majority of the camera feed made it difficult to find a proper use case for these data in a mobile Augmented Reality scenario. In one case however, information from the elevation model data was incorporated within the buildings position information.

See Chapter 10 for a detailed description of the data sets used for all experiments, as well as how they were processed and integrated for use by the services and Augmented Reality clients.

In this initiative, generic geospatial datasets, with no special consideration for Augmented Reality, were used so that AR applications developers could readily make use of any geospatial datasets such as those defined or transmitted using OGC standards. Similarly, current GIS applications developers can leverage their existing tools, data and expertise to start deploying Augmented Reality solutions.

Many of the same concepts for styling geospatial features apply whether dealing with a cartographic or 3D view (whether doing Augmented Reality or not). As an example, any flat feature can be simply draped on the ground, and the same stroke or fill symbolizers can be applied to the feature(s). Labels and markers (annotations) typically still face the user as billboards, even if their 3D position serves as a basis for projecting to a screen position.

Some additional capabilities are possible however, such as defining styles specific to solid shapes / volumes, or using 3D models as markers. There is also the concept of depth of objects, which is sometimes useful to have objects sorted back to front with actual depth values.

With this in mind, rather than defining something entirely distinct, it makes sense to extend the classic GIS styling model with 3D capabilities.

A great advantage of unifying styling representations is to be able to easily integrate any styled GIS content within an AR application.

This is done through the same mechanism as specifying cartographic styling for vector features in a typical cartographic 2D view, with a symbolizer concept associated with a feature described in a generic manner which accommodates 3D views just as well as 2D views.

As part of the ongoing next iteration of defining a standard conceptual model for styling capabilities, these possibilities were also considered within the Testbed-14 portrayal thread activities.

This conceptual model for styling features, as well as an encoding for it, is detailed in Appendix C.

By configuring how the Augmented Reality content is displayed on either the camera feed, or the rendering of a virtual 3D view of the integrated urban model represented by the CityGML, entirely on the client, a great level of flexibility is gained. This linking can be established by specifying styling rules, and referencing available attributes associated with the geospatial data. In the approach used in this Testbed, the description of annotations elements was not hardcoded in either the source CityGML or the transmission format.

Capabilities very specific to Augmented Reality could be extensions to a conceptual model for styling geospatial data. This would provide a mechanism by which to re-integrate ARML capabilities within this conceptual model.

At a very close range, the GPS precision is not enough to accurately register the camera with the surroundings. Indoor, the GPS signal is blocked, and devices cannot communicate with satellites. Virtual sensors such as the Android fusion sensor providing 6 degrees of freedom integrating the gyroscope, accelerometer, magnetometer in addition to input from the camera may solve some of these challenges. However, potentially recognizing features from a pre-existing data set and/or leveraging more advanced computer vision techniques on the camera feed could help solve some of these challenges.

Access to detailed in-door data sets is key for looking at these challenges in the context of Augmented Reality. Perhaps insights from the Indoor mapping and Navigation pilot would prove useful. Additionally, hardware with stereoscopic cameras might offer better ways to more accurately register the view. It is also possible to apply pattern recognition, and place markers in the real world at specific locations where augmentations should appear.

Finally, augmentation of reality at a smaller scale is generally more interesting and useful, making it possible to display more relevant content which is part of the user’s immediate surroundings. The heavy reliance on the complex topic of computer vision however implies more involved processes, and for this reason this was reserved for a future initiative.

The (rear-facing) camera of the mobile device provides a live feed of the user’s surroundings. It supplies an application with the backdrop in which augmentations can be integrated so that the user feels as though these are part of their actual surroundings. In computer vision-based Augmented Reality, the camera feed is not merely a backdrop but is analyzed in real time to identify anchoring patterns or to precisely locate features. Through the use of virtual fusion sensors such as Android’s six degrees of freedom sensor (TYPE_POSE_6DOF), the camera can also play an integral part in maintaining accurate information about the position and orientation of the device.

The Ecere client directly accessed the Android camera using the Android Camera 2 API. The Ecere client is built using the native eC programming language rather than Android’s Java development language. Further the NDK API for the Camera 2 was only added in Android API Level 24 (corresponding to Android 7.0 — Nougat). As there was a desire to support devices with an earlier version of Android, the Java Native Interface (JNI) had to be used. This decision required writing extra code to make use of that Camera API, thus complicating the task of implementing camera support. By using the Camera 2 API through JNI, it was possible to support Android devices starting from API Level 21 (corresponding to Android 5.0 — Lollipop). This code will likely be published under an open-source license as part of the Ecere SDK, and may be re-usable in other projects (including in projects written in other native languages such as C or C++, with minor modifications).

That camera code uses a capture session set up with repeating requests to continuously capture images. Using a lower resolution than the camera is capable of capturing can provide smoother performance. The performance of the current setup is still being investigated as it is believed that performance can be further improved, potentially by taking a more direct path between the captures and displaying the image on the device.

Obtaining the GPS coordinates is the most accurate means for retrieving the device’s location. However, using the on-board GPS chip only works outdoors, and requires significant power. The network location mechanism can use the cell tower and Wi-Fi triangulation, but these computed locations are fairly inaccurate.^[1]

Ideally for a geospatial AR application, the GPS unit should be used to provide coordinates. This could prove a real challenge for indoor Augmented Reality applications (possibly the location could first be obtained as close as possible from outside the building). Using the GPS provides the absolute frame of reference for the device’s position in relation to the Earth.

Because the Android NDK does not provide an API for obtaining the GPS coordinates and location updates, the JNI also had to be used to set up location updates and access the GPS chip in the Ecere Android client, through the LocationManager class.

In addition to latitude and longitude, the on-board GPS chip can provide altitude information. The altitude returned by Location.getAltitude() will be the altitude above the WGS84 reference ellipsoid, not the mean sea level. The latter can be obtained by taking into account the difference between the EGM96 geoid and the WGS84 reference ellipsoid, which varies between a difference of -100 and 80 meters).

This altitude information from the GPS has not yet been used in the Ecere client.

A guide to the Android motion sensors can be found here.

The use of location updates, sensors and the camera capabilities is particularly costly in terms of power. Turning off such capabilities when not required is essential to minimize this impact. This is in addition to potentially heavy use of the Graphical Processing Unit (GPU) for rendering a large number of items and/or 3D geometry. This makes Augmented Reality applications rather power hungry, as they can quickly drain a device’s battery. Correspondingly, it also produces a lot of heat, and the size of a device can be related to both its ability to dissipate this heat and the capacity of its battery. As purely anecdotal information, the Testbed-14 participants saw two laptops and one tablet perish during this initiative!

These are things to consider for field operations where devices would be required to be used for long periods of time without the ability to charge the devices, especially if operations increasingly rely on such Augmented Reality applications. It was beyond the scope of this testbed initiative to perform an analysis of factors such as power usage, heat and battery duration of devices. The small team was kept busy for the entire duration of the testbed by the already significant workload of the primary objectives. These objectives included processing and serving relevant data sets, achieving interoperability between the different services and clients, as well as displaying augmentation properly registering with the real world. This could be investigated in future AR initiatives. However, this would require strictly determining many variables and evaluation criteria so as to produce useful results.

Ecere built a client targeting Android mobile devices, leveraging their cross-platform Ecere and GNOSIS SDKs and making use of OpenGL ES, the Android sensors, and the Android Camera 2 API directly. The client would automatically connect to both services and request 3D contents data in a tiled manner based on the current view position. It provided buttons to jump to fixed locations for the datasets (Washington, D.C. and New York City), as well as to the last known GPS position, or to constantly reposition the camera based on GPS location updates.

The client currently requires an Android 5.0+ device, as well as support for OpenGL ES 3.0. It will be possible to lower this requirement to OpenGL ES 2.0 after some fallbacks are properly implemented in the Ecere graphics engine. Application packages (APKs) were built for ARM CPUs, both 32-bit (armeabi v7a) and 64-bit (arm64-v8a), and tested on multiple devices.

There are four buttons in the application:

If Follow mode is not toggled on, the user can:

Whether Follow is on or not, the user can simply rotate the device around freely to update the camera view orientation (yaw/pitch/roll).

These experiments focused on rendering 3D buildings, as streamed by the services.

Other experiments were done with OpenStreetMap data, which featured more interesting attributes for use as annotations. Portrayal rules were established using the GNOSIS Cascading Map Style Sheets (described in Appendix C) to display labels for roads and buildings, as well as the roads themselves. These rules also included extrusion of buildings footprints (polygon layers) to render them as 3D buildings based on the OpenStreetMap Simple 3D Buildings attributes. [9]

OpenStreetMap data from Washington, D.C, was also combined with 3D buildings data from a GIS-FCU service to verify the correctness of the location.

Some experiments were also done in a desktop version of the client, rendering the vast majority of the New York City CDB data set content (buildings, trees, 3D terrain elevation, high-resolution imagery). Support for CDB geotypical models, such as the trees, was added during this initiative. Those were most notably missing from Central Park in Testbed-13 demonstration. Much effort was also spent optimizing the GNOSIS graphics engine, and work is still on-going to further improve performance.

A mobile client targeting iOS, using ARKit, was built by GIS-FCU.

The services implemented were mainly based upon and extended the Web Feature Service. Both GIS-FCU and Ecere provided a Key/Value Pair WFS service. The supported requests included:

Additionally, the Ecere service provided a WFS3/Next Generation-style API. It could be used to retrieve all elements of a CDB data set, including the terrain elevation models (a coverage) and imagery, either tiled or not, showing how Next Generation OGC services could be harmonized as a single service. A Unified Map Service interface (a service type developed during Testbed 13) was also made available, although support for 3D models and textures was not completed.

Using a direct socket connection (e.g. direct socket or WebSockets) was considered, but there was no time to include this in the experiments. Proper used of persistent HTTP connection and request queueing might also offer similar advantages.

See also Chapter 9 for a detailed description of both services and their requests.

The formats used to transmit data during this initiative included:

The participants opted for E3D for its simplicity, implementing both loaders and writers from the ground up, as well as for the slight compactness advantage and readiness to load 3D model data onto the GPU, without any required parsing. Although during these experiments E3D was used to describe 3D models by both services and both clients, glTF could also be used with the same types of requests as an alternative output format. OpenFlight or COLLADA, would also be valid candidates for 3D models output formats, although the latter would be much heavier due to its XML and textual nature.

Several factors affect the performance of displaying 3D contents, and some of these were highlighted in Testbed 13 3D Performance Client ER. [10] Those aspects were also considered in this initiative to facilitate achieving good performance in the clients. Ideally, 3D data sent to a mobile or web client is optimized through pre-processing so as to minimize the size of a transmitted payload, and it is batched by materials so as to reduce rendering overhead. However, only limited efforts could be spent implementing these optimizations and batching due to the short duration of the Testbed and the focus on Augmented Reality experiments.

Nevertheless, the interface described herein would still be appropriate for services delivering an optimized payload, and for clients to take full advantage of them. The E3D model format also has special considerations to facilitate the batching of materials.

A key goal of achieving good performance is to minimize the number of drawing calls and state changes, and batching geometry by materials makes this possible. The E3D specifications also introduce the concept of a Material Group, which conceptually can encompass multiple compatible materials for which geometry could be rendered within the same drawing call, using the same texture object. Ideally, all models within a single 3D data layer (e.g. 'Buildings' or 'Trees') use the same material group, and potentially multiple layers could use the same material group as well, allowing to render an entire scene with a single drawing call. This also implies using a single Vertex Buffer Object for storing all of this batched geometry.

For textured environments, this also requires the use of either or both texture atlases and array textures, which allow using a large quantity of texture data within a single texture object. While a texture atlas can be used to regroup smaller textures within a single larger texture, array textures allow to define multiple layers of large textures.

Since the batching of geometry follows visual properties, but not necessarily the logical structure of the entities represented by the models (e.g. buildings), it is essential to maintain this original organization so as to preserve selection and attribution capabilities. The E3D format allows this with the concept of parts, establishing a relationship between faces and a part ID, which in turn can be used with this service interface’s for querying parts attributes. This can be used, for example, to transport original properties from a CityGML dataset.

Another important aspect, especially relevant to geotypical models, is the use of geometry instancing. With instancing, an entire forest made of thousands of trees for example can be rendered by lighter drawing commands with minimal position information for each tree which can reference one of a few complex models e.g. for trees of different species.

More basic ways in which re-use helps gain performance include indexing the same vertices through the use of indices to describe faces, as well as having multiple models sharing the same textures.

Some experiments were done entirely offline based on a local data store. The GNOSIS Data Store was used to organize tiled layers (in GNOSIS Map Tiles pyramid format), with sub-folders for models (in E3D format) and textures (in JPEG, PNG or ETC2 format). This demonstrated the possibility to retrieve, store, publish, and directly visualize a partial or complete dataset of terrain elevation, imagery and 3D model data based on the same principles as the client/server interaction mechanism described herein. Furthermore, this embodiment of the dataset represented a significant reduction in terms of storage size (e.g. 3D model and terrain data layers easily fit within the OGC portal’s limited allowed file size) as well as count of files, as well as performance improvements, compared to the original CDB.

During this initiative, questions and thoughts regarding the potential relationship with the 3D Portrayal Service came up, but there was no time devoted specifically to consider what that relationship could be. Therefore investigating any overlap or complimentary aspects, and integrating any of the capabilities prototyped during this testbed activity within the 3D Portrayal Service framework would be reserved for future work. Some suggestions included considering the integration of the additional 3DPS capabilities within a general harmonized or unified next generation map service, which we tried to demonstrate as something feasible with this interface. Additionally, we feel one of the initial of the objective of the 3DPS which was to bridge the gap between different model formats, allowing a service to offer multiple supported formats, is within the grasp of this interface through a format parameter for the GetModel and/or GetTile request, e.g. allowing to return an E3D or glTF file; or a GNOSIS Map Tile or 3D Tile. The E3D specifications, as an alternative yet simple way of describing 3D models, may also inform the formulation of a conceptual model and/or simple profile to which both glTF (the foundation of 3D Tiles) and I3S could be related as well, and this may help achieve additional format interoperability.

The service provided by Ecere was based on the GNOSIS Map Server and implemented primarily a Web Feature Service, with extensions for retrieving 3D models and textures. Both a classic Key/Value pair WFS as well as a next generation REST-based (WFS3) interfaces were used in the experiments. Additionally, an interface for the Unified Map Service (UMS), as prototyped for Testbed-13 Vector Tiles work package was used in the experiments.

For all requests, an authKey parameter provides security authentication, giving access to specific features. This authorization key is not included in requests herein, but is required for data derived from the New York CDB, which was provided solely for the purpose of this Testbed-14 AR initiative. As a result, many of the requests listed will result in a 404 - Resource Not Found error. The usage of the data set is subject to a license agreement with FlightSafety. OGC can be contacted in case these working resources would be useful and provide information on how to agree to this license and obtain the necessary authorization key.

All E3D files are stored in a geospatial database (PostGIS) in the backend. The client can send a RESTful request with latitude and longitude of an on-site user via the GetFeature method. The service will retrieve the corresponding ID of the E3D and return a list of buildings to the client in GeoJSON format. The client can send separate GetModel requests with each of these model IDs in order to retrieve the E3D models.

The two main source data sets that were used for the experiments were:

Some experiments made use of OpenStreetMap data (extracts in Google Protocol Buffer encoding of OpenStreetMap data model retrieved from Geofabrik and extract.bbbike.org). As well, a COLLADA model of Kaohsiung pipelines was also used in early experiments, converting the model to E3D format (available here).

Other data sources were identified as potentially useful for conducting additional experiments, but were not experimented with due to time constraints:

An intermediate CityGML data model was produced from Washington, D.C. 3D buildings multipatch shapefiles by GIS-FCU, primarily using Safe Software’s FME data integration platform.

Because the original building IDs were not unique, which would cause problems with how these were used later on in the conversion process, ESRI’s ArcGIS software was first used to associate a unique ID to each building, prior to the conversion from multipatch shapefiles to CityGML.

Previous research [12] from Technische Universität München (TUM) was instrumental in making this possible, as they shared an FME configuration file specifically for the purpose of creating such a building data model, which was used for setting up the conversion process.

This FME configuration file can be downloaded from here.

The resulting CityGML data set is available here.

The final CityGML data set can be previewed and visualized using FME’s CityGML inspector.

In the resulting CityGML data set, all of the 3D geometry is described using the following GML tags (themselves within CityGML tags such as bldg:WallSurface):

gml:MultiSurface → gml:surfaceMember → gml:Polygon → gml:exterior/interior → gml:LinearRing → gml:posList

The entire preprocessing of the Washington, D.C. 3D buildings data set, from multipatch shapefiles to E3D models through CityGML, is summarized in the following figure:

To facilitate the conversion process from CityGML to E3D models, as well as the visualization of E3D models in the GIS-FCU client, Ecere provided GIS-FCU with source code for reading and writing E3D models. This source code, implementing the E3D 3D Model Specifications (Appendix A), will become part of the open-source Ecere cross-platform SDK. Additionally, support for E3D may be contributed to the Open Asset Import Library. GIS-FCU opted for making use of the Ecere E3D API in its native eC programming language to implement the transformation from CityGML to E3D (eC was designed by Ecere, who also maintain the open-source compiler and tools for the language).

After parsing the CityGML to resolve the structure of each building, GIS-FCU implemented batch processing for outputting separate E3D models for each building. These E3D models get stored in a PostGIS database, while establishing reference positions for the buildings. A tool called 'm2S' tool was developed to perform this processing (transforming one input CityGML file into several E3D model files).

Ecere also provided a 3D model viewer (e3dView) to visualize and validate the correctness of E3D models and it was used for checking the result of the conversion from CityGML to E3D.

The GNOSIS data store serves as input from which the Ecere service (based on the GNOSIS Map Server) can directly serve geospatial data in a number of OGC services (e.g. WMTS, WFS) as well as UMS. It can also be used directly for high performance visualization by applications built using Ecere’s GNOSIS SDK, such as the mobile Augmented Reality client built for this initiative, or Ecere’s GNOSIS Cartographer GIS tool.

The data store (described in detail in Testbed-13 Vector Tiles Engineering Report - Appendix D) [13] consists of a simple directory structure with layers of tiled geospatial data in the GNOSIS Map Tiles format (Appendix B) organized by tile pyramids so as to keep a small file count and reduce file system overhead, while providing fast access to geometry without the overhead of a database. Data attributes are stored separately in an SQLite database with spatial indexing. For referenced 3D models as used in this initiative, a models subfolder contains separate E3D files, with a textures subfolder within for textured models. A layerInfo.econ description file contains information such as geospatial data type, geospatial and temporal extent. The data store can store any types of geospatial data supported by GNOSIS Map Tiles, which currently include imagery, coverage, vector data, point clouds, as well as referenced or embedded 3D models.

In order to produce a GNOSIS Map Tiles / E3D data set out of CDB, GNOSIS Cartographer was used. The CDB data set is simply pointed to using the 'Add' button of the data sources library panel, and then with the top-level node of the CDB data set, clicking on the Optimize button starts the conversion process.

Within a CDB 1.1 data set, vector data is represented using shapefile tiles. This also applies to points referencing 3D models. The 3D models themselves are stored separately as OpenFlight models, while their textures are stored using SGI RGB format. Imagery is stored using JPEG-2000 encoding, while GeoTIFF is used for elevation data.

When processing the complete New York CDB data set (as seen in the screenshots on the clients page), the following source layers were used:

In addition to these layers, the original CDB data set also contains vector roads and railroads layers, but these were not used.

When converting the 3D models layers, the elevation information from the elevation layer was incorporated into the referencing points of the GNOSIS Map Tiles.

The resulting data set in GNOSIS Map Tiles / E3D format is quite compact, compared with the original source layers, and contains much fewer files:

The imagery tiles were produced, but not yet using JPEG-2000 encoding within GNOSIS Map Tiles, so they are considerably larger. For this reason, only the lower resolution imagery layer is currently available from the Ecere service.

Some experiments used OpenStreetMap data to compensate for two important problems of both the main CDB and shapefiles/CityGML data sets:

Luckily, OpenStreetMap provides continuously updated and readily available data with worldwide coverage and a vast amount of textual attributes.

Again, GNOSIS Cartographer was used to convert various OpenStreetMap data sets (retrieved as extracts from the OSM database in OSM PBF format) of where participants happened to be during the Testbed initiative to GNOSIS Map Tiles (as regular vector data layers):

In addition to displaying roads and information such as building and street names, some experiments used the OpenStreetMap building footprints together with their data attributes to extrude these into 3D buildings. The OpenStreetMap Simple 3D Buildings schema allows to describe 3D geometry (up to a certain amount of details) out of regular polygons. This however requires both mappers to invest considerable time, as well as a lot of efforts from the client to fully and properly support all of the possible attributes (e.g. special roof shapes).

In one experiment, the OpenStreetMap data was used together with 3D data from the GIS-FCU service to add streets and building names.

In other experiments, the data was used on mobile devices for displaying information relevant to the location, based on the device’s position and orientation.

The Washington, D.C. OpenStreetMap layers are being served from the Ecere service e.g. through its WFS 3 / Next Generation service.

The coordinate system for E3D models is left-handed:

Little-endian throughout (least significant bytes first)

This version adds normals to the interleaved attributes (with x,y,z packed using 10 bits each).

The floating-point normal values for the normals are (0 is implied for non-specified component values):

{ z = -1.0 }, { z = -1.0 }, { z = -1.0 }, { z = -1.0 },

{ z = 1.0 }, { z = 1.0 }, { z = 1.0 }, { z = 1.0 },

{ x = -1.0 }, { x = 1.0 }, { x = 1.0 }, { x = -1.0 },

{ x = -1.0 }, { x = 1.0 }, { x = 1.0 }, { x = -1.0 },

{ y = -1.0 }, { y = -1.0 }, { y = 1.0 }, { y = 1.0 },

{ y = -1.0 }, { y = -1.0 }, { y = 1.0 }, { y = 1.0 }

This version compresses the data using LZMA (any series of blocks, except the version header block, can be compressed inside an LZMA block). Here the top blocks are compressed in one LZMA block.

If the tile is not flagged as empty or full, the actual tile data follows, based on geospatial data type.

For more details of how the compact tiled vector data works, see also its ECON textual representation in the OGC Testbed-13: Vector Tiles Engineering Report - Appendix C [13].

The embedded3DModel (0xB0) data type can be used to describe geospecific features, such as 3D terrain as pre-triangulated alternative to compressed coverage heightmaps, or other models covering a large area (e.g. infrastructure) to be split in tiles.

For coverages, NODATA values are encoded as -32,767.

Imagery and coverages can be filtered using a Paeth filter before being compressed with LZMA. For 16 bit rasters such as the coverageQuantized16 format used for encoding terrain elevation data, this achieves significantly better compression than the Paeth filter within the PNG format because it treats the 16 bit integers as a whole rather than as individual bytes. It also seems to compress ARGB rasters better than PNG.

The following is an eC reference implementation for the Paeth filter encoding:

This annex presents the conceptual model used for portraying Augmented Reality content in this initiative, which is based on a classic approach to style GIS features, but also applies to portraying geospatial data in 3D views. The usage scenarios covered during the testbed focused on geospatial Augmented Reality rather than computer vision Augmented Reality, and thus did not require any extensions beyond those capabilities. It was suggested that ARML could inspire future extensions specific to AR to integrate to this portrayal conceptual model, covering other scenarios with requirements specific to AR.

A similar conceptual model and the the GNOSIS Cartographic Map Style Sheets (CMSS) description of styles was also used during Testbed-14 portrayal work package (See 18-029 OGC Testbed-14: Symbology Engineering Report), as well as for the Vector Tiles Pilot. Objectives of the GNOSIS CMSS encoding (which was improved upon during Testbed-13 and Testbed-14) include maximizing expressiveness. A key concept in Testbed-14 work package is that styles described by the model could be encoded in different ways (GNOSIS CMSS being just one example), and the conceptual model exists to facilitate interoperability between multiple encodings, applications and rendering engines.