Semantic 3D City Model of Tokyo

Note that for the visualizations we do not use the 3DTiles standard, but tiled KML, COLLADA, and glTF/glb datasets instead. The reason is that there is no Open Source tool available yet, that can generate 3DTiles from large city models (neither given in CityGML nor in any other format). Our solution is the result of our own tiling mechanism that was implemented in our 3DCityDB webmap client on top of the CesiumJS web globe. This solution was made available even two years before 3DTiles were developed. The mechanism is explained in detail in the PhD thesis of Zhihang Yao (downloadable from http://mediatum.ub.tum.de/node?id=1574231). In the future, we intend to also produce 3DTiles directly from the 3DCityDB, but this will be subject to a proper funding of such developments. If you are interested, get in touch with us.

The demos are best viewed with Google Chrome or Apple Safari due to performance reasons.

Link: City of Tokyo including textured Buildings and Bridges in LoD2 (with original attributes in Japanese) 

Link: City of Tokyo including textured Buildings and Bridges in LoD2 (with attribute names translated to English) 

Link: Center of Tokyo - Results of a Solar Potential Simulation

The solar potential simulation was conducted for an area in central Tokyo. Each Building contains information on direct, diffuse and global irradiation values in [kwh/m²] on all building surfaces (including the walls), as well as the Sky View Factor (SVF). The irradiation values are aggregated per building and per month and can be inspected by clicking on a building. The simulation was performed using a tool developed at the TUM Cair of Geoinformatics. Some OuterCeilingSurfaces were disregarded on purpose.

Find below CityGML objects for the 23 wards of the city of Tokyo divided by thematic modules for download. Attention! The files generated for the entire city are in some cases very large. They can easily be imported into a CityGML compliant geodatabase system like our Open Source 3DCityDB. The files do not need to be uncompressed in order to be imported into the 3DCityDB. The original data was modified as described in the information section below. 

• Download CityGML Building objects. (1.7 million buildings; file size is 9.5 GB)
• Download CityGML Transportation Objects. (file size is 174 MB)
• Download CityGML Bridge Objects. (file size is 444 MB)
• Download CityGML LandUse Objects. (file size is 321 MB)
• Download the CityGML Relief. (file size is 433 MB)

The employed coordinate reference system of the datasets provided on the PLATEAU website is EPSG:6697, which is a 3D compound CRS, where the horizontal part is using geographic coordinates in degrees and the vertical part uses a metric reference system. Both the horizontal and the vertical coordinate reference systems refer to the JGD2011 datum. It seems that the first two coordinate axes are switched in all CityGML files, because when a dataset is being loaded into FME Data Inspector using EPSG:6697 the buildings are shown at the wrong location on Earth. When swapping the first and second coordinate values during reading, the 3D models are shown at the correct location instead. This behavior is also consistent with the 3DCityDB; only when the first two coordinate values are swapped during the CityGML import process, the bounding box of the entire dataset can be correctly computed. Interestingly, the FZK Viewer also recognizes (and supports) the EPSG:6697 CRS, and it displays the Tokyo CityGML datasets correctly without the need to swap the coordinate axes. Therefore, either the FZK viewer interprets the CRS wrongly or FME and the 3DCityDB (the latter uses PostGIS to transform coordinates). 

Working with the Tokyo dataset in the 3DCityDB with the EPSG:6697 CRS is not very convenient, because all kinds of tiled exports (in CityGML but also for visualization formats) can only determine the proper tiling automatically, if the model is stored in the spatial database in a projected CRS. Furthermore, if visualization exports in COLLADA and/or glTF format should be created, the data must be stored in the 3DCityDB using a projected CRS (and not using geographic coordinates). Hence, after loading of all datasets the 3DCityDB Importer/Exporter can be used to switch to a projected CRS like EPSG:6691, which is JGD2011 / UTM zone 54N using UTM projection. Note, that EPSG:6691 is a 2D CRS, but this does not cause any problem for the 3DCityDB (the 3rd dimension coordinates will then not be affected by coordinate transformations). There is another good reason to transform all 3D model data to the projected CRS, because then all three coordinate axes use the same unit of measure (meters) and surface areas in m² and building volumes in m³ can directly be computed. Also distances between buildings can be easily computed using the Euclidean distance (neglecting the small length distortions introduced by the UTM projection).

Buildings have representations in LOD0, LOD1, and LOD2. Some buildings have all three LODs, some only LOD1, and some only LOD2. Not all buildings in the dataset have also lower LODs in addition to their higher LOD.

The dataset makes use of the CityGML i-Urban Revitalization (i-UR) Application Domain Extension (in version 1.4). This means that, for example, building objects contain additional attributes as defined in the i-UR ADE besides the ones defined in the CityGML 2.0 schema. In order to keep these attributes when reading the dataset into the 3DCityDB, the ADE has to be registered with the (empty) 3DCityDB database before starting the import. The ADE package can be downloaded for free from https://github.com/3dcitydb/iur-ade-citydb

After correcting the coordinate axes problem and switching to CRS EPSG:6691, we have exported all datasets again from the 3DCityDB. In order to keep the GML file sizes reasonable, an automatic subdivision of the entire Tokyo dataset area into 5x5 tiles was chosen. We have created one export for each toplevel feature type; each packed into one ZIP file. The i-UR ADE attributes are still fully included. In order to import the files again into another instance of the 3DCityDB, simply the ZIP archive can be chosen as input dataset; the ZIP file doesn’t have to be decompressed in order to import the data.

We have created one tiled KML/COLLADA/glTF export for each toplevel feature type. These tiled visualization models can be viewed with the 3DCityDB Webmap client, which supports its own loading/unloading code for tiled KML/glTF datasets. Of course, 3DTiles are also supported by the 3DCityDB Webmap client, but to the best of our knowledge there is no free software available (yet), that could generate 3DTiles from large CityGML datasets. (Two commercial solutions would be the Cesium ion platform and a software from VirtualCitySystems.) All Relief features (TINs) were converted to a single Cesium Quantized Mesh file using the software package Cesium Terrain Builder, for which we also maintain a Docker container. The produced quantized mesh can be used as the Digital Elevation Model in CesiumJS.

We translated the attribute names from all generic attributes of all buildings from Japanese to English using Google Translate and updated the attribute names in the 3DCityDB database accordingly. The result can be viewed above. Clicking on a building queries our 3DCityDB and shows the attributes and their values. Note, that we only translated the attribute names yet, but not their values. But this could also be done.

The following commands show how the 3D city model of Tokyo (but also other city models represented in CityGML) can be easily imported into an instance of the 3D City Database (3DCityDB) running in a Docker container. As a prerequisite Docker for Desktop must be installed and running on your system. Make sure, that you have assigned enough hard disk capacity to the Docker engine as well as enough CPU and RAM resources. On my desktop PC running Windows 10 I have assigned 6 CPU cores, 12 GB RAM, 1 GB Swap memory, and 300 GB of harddisk capacity to the Docker engine (my workstation has 12 real CPU cores, 32 GB of RAM, and 2 TB of SSD harddisk). In this small demo we are going to use PostgreSQL/PostGIS. In order to browse and query the tables of the 3DCityDB after loading the datasets, it is also useful to have the software pgAdmin installed.

The following steps have to be performed to setup a 3DCityDB instance and to load datasets from Tokyo:

1. Download the CityGML files to import from above (e.g. the Tokyo buildings) and store the ZIP file(s) on your local drive. Let's assume you are using Windows and have created a folder C:\3DCityDB into which the downloaded files are copied.
   
   

2. Open a command shell (in Windows e.g. Powershell, in MacOS using the Terminal application) and type the following command to download and start the 3DCityDB:

   docker run -d -p 5432:5432 --name citydb-tokyo -e POSTGRES_PASSWORD=changeMe! -e SRID=6691 -e POSTGIS_SFCGAL=true 3dcitydb/3dcitydb-pg

   Docker will automatically download the container image from DockerHub. The Docker container 3dcitydb/3dcitydb-pg includes the PostgreSQL and PostGIS installation as well as the 3DCityDB database scripts. If no further container image tags are specified, the latest version of the container (at the time of writing this means PostgreSQL version 13 and PostGIS version 3.1 including the PostGIS SFCGAL extension) will be used. See the 3DCityDB documentation on Docker images for further options. If another instance of the 3DCityDB will be started on the same Computer, the previously loaded image will be reused and the startup will be very fast. You can open the Docker application and click on the citydb-tokyo container to see, if the container is already running and ready to accept connections (the last line of the shown log file should say: <timestamp> LOG: database system is ready to accept connections.
   
   

3. Type into the command shell the following command:

   docker ps

   It should produce this kind of result, showing that the 3DCityDB container has been downloaded and started successfully:

   CONTAINER ID   IMAGE                  COMMAND                  CREATED          STATUS         PORTS                    NAMES
   456a446f2053   3dcitydb/3dcitydb-pg   "docker-entrypoint.s…"   10 seconds ago   Up 4 seconds   0.0.0.0:5432->5432/tcp   citydb-tokyo

4. Download and start another Docker container, which has the 3DCityDB importer/exporter and Java included:

   docker run -i -t --name impexp --rm 3dcitydb/impexp help

   The command help at the end of the line shows the functionalities and command line options of the 3DCityDB Importer/Exporter. Since we want to import CityGML files, we can also ask for help regarding the command line options for the import command:

   docker run -i -t --name impexp --rm 3dcitydb/impexp help import

5. We can now import the previously downloaded CityGML dataset into our 3DCityDB instance citydb-tokyo. For this command, we will have to establish the link between the directory on our local host machine containing the CityGML file(s) (we chose C:\3DCityDB as stated above) and the Docker container of the importer/exporter tool using the -v option. We also have to link the two running Docker containers, because the container with the importer/exporter tool needs to know the IP address of the other Docker container running the 3DCityDB. This is established via the --link citydb-tokyo option and its usage in the host option -H citydb-tokyo of the impexp tool. To start the import type or copy the following command into the command shell:

   docker run -i -t --rm --link citydb-tokyo --name impexp -v C:/3DCityDB:/data 3dcitydb/impexp import -H citydb-tokyo -d postgres -u postgres -p changeMe! /data/CityGML_Buildings.zip

   When the command is entered typically a pop-up window appears asking for permission of the importer/exporter Docker container to access the host filesystem (here: the Windows filesystem). You need to give this permission. 

The following commands show how to connect to a 3DCityDB instance running within the Docker container named citydb-tokyo that was created and filled with data using the steps shown above. In order to run SQL commands (for queries and data modifications) type into the command shell window (in Windows e.g. Powershell, in MacOS using the Terminal application) the following command:

docker exec -it citydb-tokyo psql -U postgres -d postgres

This command runs the command line application psql in the 3DCityDB container, which can be used to administer and work with a PostgreSQL/PostGIS database. A prompt like postgres=# is shown and you can now enter SQL statements. In order to exit the psql application and to close the connection to the 3DCityDB simply type in exit and press the return key.

The following command lists all database tables for the database and user postgres:

\dt

Note that only the database tables from the schema citydb belong to the 3DCityDB.

In order to find out how many buildings were imported you can use the following query (note that SQL commands and queries always need to be terminated with a semicolon):

select count(*) from building;

If you want to learn about the attributes, indexes, and other information for a specific database table, for example the building table, try the following command:

\d building

We can see, that there is an attribute called measured_height, so let's query the database for the height of the tallest building:

select max(measured_height) from building;

If we also want to get the numeric ID (internal identifier used in the 3DCItyDB) of the tallest building, we change the query to:

select id,measured_height from building where measured_height=(select max(measured_height) from building);

With these information we can also query for the gml:id - that is the unique identifier of the building in the CityGML dataset - of the tallest building. For that purpose we must make a join to the database table cityobject, which contains the gml:id's and other information for all city objects in the city model (type the command \d cityobject to learn about the attributes of the cityobject table):

select b.id,c.gmlid,b.measured_height from building b,cityobject c where b.id=c.id and b.measured_height=(select max(measured_height) from building);

If we are looking for the ten tallest buildings we can use the following query:

select id,measured_height from building where measured_height is not null order by measured_height desc limit 10;

In the 3DCityDB, the geometries are represented in a separate table from the building table. In order to find out, if the 5th tallest building is represented by closed volumetric shapes in either LOD1, 2, 3, or 4 we can run this query. Replace <numeric id> by the identifier that was listed as a result of the previous query shown for the 5th tallest building (the one with 251m height):

select lod1_solid_id, lod2_solid_id, lod3_solid_id, lod4_solid_id from building where id=<numeric id>;

We can see for the 3D city model of Tokyo that the geometry of the 5th tallest building is represented by a Solid in LOD1 and LOD2. Here is the result shown in my example session:

postgres=# select lod1_solid_id,lod2_solid_id,lod3_solid_id,lod4_solid_id from building where id=1842891;
 lod1_solid_id | lod2_solid_id | lod3_solid_id | lod4_solid_id
---------------+---------------+---------------+---------------
      28064963 |      28065172 |               |
(1 row)

The shown lodX_solid_id values are foreign keys to the database table surface_geometry (use the command \d surface_geometry to learn about the attributes of this database table). This table has an attribute called solid_geometry, which contains the 3D solid geometry. Let's show the geometry of the LOD1 solid in well-known-text format:

select ST_AsText(solid_geometry) from surface_geometry where id=28064963;

We can check, if the geometry is considered a closed shell and if it is understood as a solid by PostGIS:

select ST_IsClosed(solid_geometry),ST_IsSolid(solid_geometry) from surface_geometry where id=28064963;

From the result we can see, that while the surface forms a closed shell, it is not considered a solid yet (for whatever reason). But we can make it a solid using the PostGIS function ST_Solid(), and afterwards we can compute the building volume (of the LOD1 geometry) in m³:

select ST_Volume(ST_MakeSolid(solid_geometry)) from surface_geometry where id=28064963;

The query runs for a couple of seconds and then gives the answer: the volume of the 5th tallest building in Tokyo (251m height) is 1,286,173.9 m³.

Note that the relational database schema with all tables, views, indexes, attributes etc. are well documented in the 3DCityDB online documentation. The documentation also shows how the object-oriented datamodel of CityGML was mapped onto the relational database schema, which is helpful to know, when writing SQL queries for the 3DCityDB.