Publication Date: 2018-03-05
Approval Date: 2018-03-02
Posted Date: 2018-02-01
Reference number of this document: OGC 17-046
Reference URL for this document: http://www.opengis.net/doc/PER/t13-NG002
Category: Public Engineering Report
Editor: Volker Coors
Title: OGC Testbed-13: 3D Tiles and I3S Interoperability and Performance ER
COPYRIGHT
Copyright © 2018 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/
WARNING
This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.
LICENSE AGREEMENT
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.
This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.
None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.
- 1. Summary
- 2. References
- 3. Terms and definitions
- 4. Overview
- 5. Experiments
- 5.1. CityGML Source data
- 5.2. Experiment 1 - CityGML to 3D Tiles to Cesium
- 5.3. Experiment 2: CityGML on GeoRocket Database to Cesium via 3DPS Query
- 5.4. Experiment 3: CityGML to I3S to ArcGIS
- 5.5. Experiment 4: CityGML ADE on GeoRocket Database to virtualcityPUBLISHER to Cesium
- 5.6. Experiment 5: CDB Performance
- 5.7. Experiment 6: 3D Tiles Visualization in GNOSIS
- 5.8. Experiment 7: CDB to GNOSIS
- 5.9. Terrain and 3D Models Support in GNOSIS Map Tiles
- Appendix A: Revision History
- Appendix B: Bibliography
1. Summary
This OGC Testbed 13 Engineering Report (ER) documents the overall architecture developed in the "Interoperability of 3D Tiles and I3S using a 3D Portrayal Service and performance study of 3D tiling algorithms" activity. The report also summarizes a proof-of-concept of the use of 3D Tiles and I3S as data delivery formats for the OGC 3D Portrayal Service interface standard. The report captures the results from the interoperability tests performed as part of the 3D Tiles and I3S testbed work package. Specifically, this OGC Testbed activity focused on the following tasks:
-
CityGML files converted into Cesium 3D Tiles using Analytical Graphics (AGI’s) 3D Tiling Pipeline, and Cesium as the rendering client;
-
An OGC CDB data store converted into 3D Tiles using Compusult’s Streaming engine, Cesium and Ecere’s GNOSIS as rendering client;
-
CityGML data store GeoRocket, 3DPS with 3D Tiles as data delivery format, and Cesium as rendering client;
-
CityGML converted into I3S, 3DPS with I3S as data delivery format, and Cesium as rendering client;
-
CityGML converted into I3S using ArcGIS and FME, 3DPS with I3S as data delivery format, and rendering in ArcGIS client;
-
CityGML with application domain extension stored in GeoRocket, converted to 3D Tiles, and Cesium as the rendering client;
-
3D Tiles (generated by all streaming engines visualized) from Ecere’s GNOSIS rendering client;
-
CDB visualized directly from Ecere’s GNOSIS rendering client; and
-
I3S visualized from Ecere’s GNOSIS rendering client.
1.1. Requirements
An overview of the tests is provided in chapter 4.
Some experiments included the use of commercial software, specifically:
-
3D Tiling Pipeline developed by AGI to convert CityGML into 3D Tiles (available to the testbed for a six-month term for demonstration and evaluation).
-
GeoToolbox is a software product developed by Fraunhofer IGD consisting of a set of tools to handle, modify and transform Geodata. The tools are available as command-line tools but also include a Java API. One tool, which was used in the experiment, converts CityGML to the 3D-Tiles structure allowing the user to choose between several options. For example what kind of hierarchical data structure is used, if textures shall be included and how aggressive the textures are simplified inside the 3D-Tiles structure.
-
virtualcityPUBLISHER is a commercial software product developed by virtualcitySYSTEMS GmbH for publishing CityGML data sets online using state of the art 3D browser technologies. The software package is usually installed on a hosted or corporate server and provides a comprehensive backend user interface for managing projects, users, data sources, and for configuring 3D online maps. In this Testbed the embedded command line tool for extracting and processing CityGML data was used in order to generate visualization layers that can be streamed online.
-
FME to convert CityGML into I3S
1.2. Key Findings and Prior-After Comparison
There was little prior work to test the interoperability of streaming capabilities relating to the OGC I3S Community Standard ("I3S") and the 3D Tiles specification proposed as a new work item for an OGC Community Standard ("3D Tiles"). The interoperability & performance analysis conducted in the testbed’s 3DTiles and i3s: Interoperability & Performance work package provided a demonstration of 3D data streaming capabilities supporting CDB and CityGML data streamed according to the I3S and 3D Tiles specifications. The work also validated the 3DPS 1.0 interface specification using 3D Tiles and I3S as the content delivery formats. As a proof of interoperability, rendering of I3S in Cesium client has been achieved. Based in the results of the experiments, some change requests for the 3DPS version 1.1 have been identified.
1.3. What does this ER mean for the Working Group and OGC in general
From the 3DPS SWG’s perspective, the main interest is to validate the 3DPS 1.0 interface specification using 3D Tiles and I3S as the content delivery formats.
For OGC in general, this work examines the interoperability and performance characteristics of streaming capabilities relating to the 3D Tiles and I3S specifications. More specifically, it provided a prototype demonstration to test and validate the interoperability of the OGC 3D Portrayal Service standard using the 3D Tiles and I3S data delivery formats in an urban-centric scenario based on CityGML and CDB data stores.
In addition, open data test data sets in CityGML for testing streaming of 3D city models have been defined. It is recommended to use these data sets in future experiments as well to achieve comparable results.
1.4. Document contributor contact points
All questions regarding this document should be directed to the editor or the contributors:
Name | Organization |
---|---|
Volker Coors |
Fraunhofer IGD / HFT Stuttgart |
Ralf Gutbell |
Fraunhofer IGD |
Athanasios Koukofikis |
HFT Stuttgart |
Zakiuddin Shehzan Mohammed |
Analytical Graphics, Inc. |
Dave O’Mahony |
Compusult |
Jérôme Jacovella-St-Louis |
Ecere |
Arne Schilling |
virtualcitySYSTEMS GmbH |
Keith Ryden |
Esri Software Development |
1.5. Future Work
The version of GeoRocket that was employed here used the 3D Tiles spatial hierarchy in order to quickly rearrange the data and therefore deliver only the requested subset of the original hierarchy. On the higher levels of the 3D Tiles hierarchy, the delivered elements intersected the queried spatial bounds, so that more data/buildings were visible than was queried, and the 3D Tiles styling feature was used to avoid rendering those intersecting objects. But in the future, it is expected that the returned geometries will be modified to only deliver the requested content. Related to this issue are the extension of the region query in 3DPS towards a polygon with holes. Such region query would enable mixed 3D scenes from different data sources such as a 3D city model with some parts of the model replaced by BIM models served by a BIM server. This is a very interesting use case in urban planning to show future urban developments.
Currently, the tiling strategies are part of external tools developed by different participants. The data delivery formats act as general container of the tiles. A general flexible for the generation of tiles would be very helpful as this is one core elements of streaming 3D and maybe 4D data in future.
The CDB standard provides guidance on storing many other datasets beyond those used here. It is expected that future work will develop representations of the other datasets in suitable 3D Tiles formats. For example, CDB geotypical models could be represented in 3D Tiles "instanced 3D model" (I3DM) format. Also underground structures such as utility networks are of high interest.
Another important topic for future work is a mixed rendering of 3D scenes and image based rendering. With image based rendering, not only bandwidth can be saved, but it has an advantage on data security as well, as the vector data stays on the server side. The 3D Portrayal Service supports image based rendering as well with the conformance class view. However, a 3DPS that supports both scene graph delivery and image based rendering has not been implemented yet.
In general, the link between 3DPS and WFS should be explored in more detail to access attribute data from a 3D scene. Also the integration of sensor measurements and simulation results into a 3D scene is very relevant for the future cities.
1.6. Foreword
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.
2. References
The following normative documents are referenced in this document.
-
OGC 17-014r5, OGC Indexed 3d Scene Layer (I3S) and Scene Layer Package Format Specification
-
OGC 15-113, OGC® Volume 1 OGC CDB Core Standard Model and Physical Data Store Structure
-
OGC 12-019, OGC® City Geography Markup Language (CityGML) Encoding Standard
-
glTF (GL Transmission Format) - A Khronos Group open standard for runtime 3D asset delivery
3. Terms and definitions
For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.
3.2. Scene, 3D scene
geometry and texture data that is to be portrayed. The term "3D scene" refers to a digital representation of geographic data that is mainly composed from 3D graphics data (mainly geometry and texture data), which is also often referred to as 3D display elements.
3.3. Scene Graph
a scene graph is a collection of nodes in a tree like data structure. Each node can have many children and has only one parent. A node refers to a set of 3D display elements.
3.5. Tile
A tile is a collection of 3D display elements of a spatial bounding volume along with it’s metadata.
3.7. Abbreviated terms
-
3DPS 3D Portrayal Service
-
ADE Application Domain Extension
-
AGI Analytical Graphics Inc.
-
B3DM 3D Tiles Batched 3D Model
-
CMPT 3D Tiles Composite Tile
-
CPU Central processing unit
-
GPU Graphics processing unit
-
I3DM 3D Tiles Instanced 3D Model
-
I3S 3D Scene Layer
-
HDFS Hadoop Distributed File System
-
HLOD hierarchical Level of Detail
-
LOD Level of Detail
-
NYC DoITT New York City Department of Information Technology & Telecommunications
-
PNTS 3D Tiles Points
-
S3TC S3 Texture Compression
-
SLPK Scene Layer Package
4. Overview
The goal of the Testbed 13 activity documented in this report was to test and validate the interoperability of the OGC 3D Portrayal Service standard using the 3D Tiles and I3S data delivery formats. The focus was on using 3D Portrayal Service implementation instances to generate web-based visualizations with a workflow that used CityGML and CDB data sets as data sources and 3D Tiles and I3S as data delivery formats. The goal was to provide a prototype demonstration of 3D Tiles and I3S visualizations using an urban centric scenario based on CityGML and CDB data.
4.1. The Visualization pipeline
The visualization pipeline provides the key structure in any visualization system. In [REF_Moreland] Moreland gives a survey of visualization pipelines used in several applications. In this report, the concept of the visualization pipeline for the interactive portrayal of geospatial data was based on [REF_OGC_98-061]. It consists of three main components: Filter, Map, and Render. The Filtering step (sometimes called selecting) selects data from larger geospatial data set that should be displayed on the screen. The Mapping step maps features to display elements such as triangles and material definitions for an illumination model. This mapping can be done based on a style guide or based on individual appearance definitions per feature (see CityGML Appearance module as an example). During the Rendering step, the display elements are rendering into a screen buffer (or into an image) to be displayed on the screen.
User interaction is possible in each step, depending on the system architecture and the purpose of the system. A simple map visualization system may allow interaction in the rendering (zoom, pan, change position of the camera); a visual data analytics system needs to enable user interaction on Mapping and Filtering as well.
The experiments described by this report focused on the use of OGC standards in the Filtering and Mapping step to enable a distributed visualization pipeline. The Rendering is the core of Computer Graphics, libraries such as DirectX, OpenGL, and WebGL are used in this step. It has its own conceptual model, the so-called rendering pipeline. The rendering pipeline has changed tremendously during the last decade, from transformation and illumination models on CPUs to vertex and pixel shaders on GPUs.
The visualization pipeline can be distributed between client and server as follows [REF_OGC_09-104r1].
-
Filtering on the server, Mapping and Rendering on the client: This approach is very common in 2D, where a Web Feature Service (WFS) is used to select data. The selected features are transferred to the client - be it a desktop client or a web browser. The Mapping is done on the client side based on a style and the selected features will be displayed on the screen in a map. In 3D, this approach works fine for small models, but does not scale for larger models. One reason is that the Rendering pipeline is fast if the display elements are ordered by material rather than by features.
-
Filtering and Mapping on the server, Rendering on the client: The data is stored in a spatial database or file based on the server. The selected features will be mapped to display elements and will be stored in an intermediate file set (often called a scene graph) that is optimized for data streaming and visualization. It may use tiling strategies and binary data formats to reduce the amount of data transferred to the client. The client takes the intermediate data to render it on the screen. This approach is supported by the conformance class Scene of the 3D Portrayal Service (3DPS). In this report, this distribution of the visualization pipeline was analyzed using CityGML and CDB as file-based data storage, and GeoRocket as a spatial database. The results of the Mapping step are stored in both I3S and 3D Tiles.
-
Filtering, Mapping and Rendering on the server: The entire visualization pipeline is executed on the server. The Rendering step writes an image that is transferred to the client. This approach is usually called server side rendering. The 3DPS conformance class view supports this approach. However, it was out of the scope of this testbed.
In the work described in this report, the second case of the distribution of the visualization pipeline (filtering and mapping on the server, rendering on the client), was investigated in more detail. A special focus was placed on the use of CDB and CityGML for the geospatial data sources, the I3S and 3D Tiles specifications for data delivery from server to (web-based) client, and the OGC 3D Portrayal Service Standard as a query interface.
Note
|
3D Portrayal Service
The 3D Portrayal Service (3DPS) is an OGC service implementation standard targeting the delivery of 3D visualizations in an interoperable fashion. When client and service(s) involved share a common set of capabilities, it becomes possible to view and analyze 3D geo-information from diverse sources in a combined manner. Major use cases include navigation in the represented scene, retrieving feature information, and analyzing detailed information like simulation results or other 3D spatial information provided using the service instances. |
The conformance class scene of the 3DPS standard supports client side rendering and content delivery using a scene graph. A specific data delivery format is not defined by the standard, but is negotiated by the client and server using the 3DPS getCapability operator and defined mime types. For images, the data format itself was not examined; instead, suitable formats (such as jpeg, png, etc.) were selected. The same goal was pursued in 3D. I3S and 3D Tiles were suitable data delivery formats for the 3DPS conformance class scene.
A first example from an experiment done in advance of the Testbed 13 [REF_Koukofikis] illustrates the importance of a good mapping strategy. In the experiment, a CityGML data set was mapped to a X3D scene graph using FME. The X3D scene was displayed in a web browser using the JavaScript library X3DOM as a 3D viewer. Two different mapping strategies were compared:
-
order by feature (X3D-BF): mapping each building in the CityGML model to a node in the X3D scene graph
-
order by material (X3D-BM): mapping all geometry with the same material to one single node in the X3D scene graph
data set | No of Entities | No of Surfaces | Type | file size CityGML [MB] | No of Triangles in X3D | file size X3D-BF [MB] | file size X3D-BM [MB] |
---|---|---|---|---|---|---|---|
s1 |
1000 |
12413 |
Building |
16 |
33930 |
4 |
3.5 |
s2 |
10000 |
114939 |
Building |
146 |
280676 |
34 |
30 |
The average frames per second (FPS) was measured in a web application using CPU Intel Core i5-3210M Processor, Operating System Windows 8.1 Professional (64bit), GPU NVIDIA GeForce GT 620M, RAM 8 GB, Web X3D viewer X3DOM 1.7.1, Web Browser Chrome 48 (64bit), Web Server Apache 2.4.17.
This example clearly showed the impact on the mapping on the rendering performance on the client. In addition, the total time from the user query to the first image on the screen has to be taken into account for a distributed rendering pipeline. For larger scenes, tiling had a significant impact on load time.
4.2. Summary of Experiments
To implement the visualization pipeline, several experiments using CityGML and CDB data stores were conducted. AGI created the necessary processing algorithms to convert CityGML into 3D Tiles within its 3D Tiles Processing Tools; Esri created the necessary processing algorithms to convert CityGML into I3S within ArcGIS and by using FME; Fraunhofer and virtualcitySYSTEMS created the necessary processing algorithms to convert CityGML with and without application domain extension into 3D Tiles within GeoRocket. Further, Esri and HFT Stuttgart investigated the ability to convert CityGML into I3S and display it in Cesium to prove interoperability of I3S and Cesium using the 3DPS.
The processing algorithms took into consideration high- versus low-geometrically complex features, textured features, and the geographic distribution of features. 3D clients performed query operations using the 3DPS to return appropriate tiles. Data was streamed according to the 3D Tiles and I3S. In addition, runtime visualization strategies were developed and profiled.
The table below summarizes the experiments conducted.
Experiments 2 and 4 investigated source data management using GeoRocket. For these experiments, a 3DPS instance was implemented on top of GeoRocket. Experiments 1 and 3 investigated source data processing using AGI’s 3D Tiling Pipeline and Esri’s ArcGIS.
A similar workflow was developed by Compusult for data maintained in a CDB-structured data store (experiment 5), and Ecere implemented both 3D Tiles and I3S visualization (Experiments 6 and 8) as well as implementing direct visualization of CDB in their client (Experiment 7).
Input data included textured terrain and textured 3D buildings, and were provided as CityGML and CDB encodings.
Experiment | Data storage | Data Delivery | Query | Client | done by |
---|---|---|---|---|---|
CityGML |
3D Tiles |
URI |
Cesium |
Analytical Graphics Inc. (AGI) |
|
CityGML & GeoRocket database |
3DPS |
Cesium |
Fraunhofer IGD & AGI & Esri & HFT Stuttgart |
||
CityGML |
I3S |
ArcGIS client |
Esri & HFT Stuttgart |
||
CityGML & GeoRocket database |
3DTiles |
URI |
Cesium |
VCS & Fraunhofer IGD |
|
CDB |
3DTiles |
URI |
Cesium |
Compusult |
|
CDB |
3DTiles |
URI |
GNOSIS |
Ecere |
|
CDB |
— |
URI |
GNOSIS |
Ecere |
5. Experiments
To complete the above-defined experiments, the following data sets were used. Note that CityGML data can be made available within an instance of a GeoRocket server and queried online. In addition, the 3D Tiles and I3S data sets of the selected models that were converted in Experiments 1, 2, 3, and 4 are available (including the relevant metadata).
5.1. CityGML Source data
5.1.1. CityGML New York City DoITT Data set
The New York City Department of Information Technology & Telecommunications (DoITT) data set contains 1.1 million buildings modeled as CityGML in Levels of Detail 1 and 2 (LOD1 and 2), though this data does not include textures.
According to the DoITT web site, “Using the Open Geospatial Consortium’s CityGML specification as the basis, the NYC 3-D Building Massing Model was developed to a hybrid specification combining elements from Level of Detail (LOD) 1 and 2. Highlights of the model include the differentiation of building components including roof, facades and ground plane.”
For purposes of the specific work package tests, the focus was on Midtown and Lower Manhattan (south of Central Park).
If more feature types are needed in the future, the New York City road network data that is part of a CityGML data set created by TU Munich could be used.
5.1.2. CityGML model of Berlin
A CityGML-based Berlin 3D City Model was also utilized since the DOITT buildings did not have textures.
According to the Berlin 3D City Model web site, "Around 500,000 buildings in an urban area of 890 km² have been photographed from the sky and the roofs surveyed with lasers to create the 3D City Model of Berlin. The 3D City Model of Berlin is neither a commercial model nor is it based on commercially available 3D models. The 3D City Model of Berlin has been developed by Land Berlin’s Senate Administration for Urban Development (Senatsverwaltung für Stadtentwicklung), Senate Administration for Economics, Energy and Public Enterprises (Senatsverwaltung für Wirtschaft, Energie und Betriebe) and Berlin Partner für Wirtschaft und Technologie GMBH."
Batch downloads were available, and spatial subsets of arbitrary size of the model could be downloaded as ZIP archives containing CityGML and image textures. Each building was available as a CityGML LOD2 model (no LOD1, no LOD3) with semantic surfaces: RoofSurface, WallSurface, GroundSurface. A limited number of attributes such as roofType were included.