3.1.1. OSM Data Visualization
OpenStreetMap (OSM) was founded in 2004 and has become a collaborative project that created a free and editable map of the world. OSM is one of the most prominent VGI projects. VGI, coined by [42
], is a specific case of the more general phenomenon, user-generated content (UGC) from Web 2.0. VGI is geospatial UGC, i.e., geospatial data collected by individuals voluntarily [43
]. OSM database contains crowdsourced geospatial data that are open, licensed under Open Database License (ODbL) [44
Since 2008, people more and more often have collected data that can be used for creating 3D objects, such as height and roof geometry data [45
]. Being able to constitute 3D objects from VGI sources is important, not only because we live in a 3D world, but also because 3D data allow the development and provision of many applications. The applications include providing a virtual 3D model of a city for demonstrating future city development plans to the public [46
], visibility analysis [47
], decision support for emergency [48
], visualizing topological relations [51
] and determining the environmental quality of public spaces [52
]. Various applications use OSM data for building 3D objects. A comprehensive list is available in the wiki of OSM (https://wiki.openstreetmap.org/wiki/3D
). Moreover, extensive research has been carried out related to this topic [45
The 3D OSM Plugin API was developed for NASA Web WorldWind in the Google Summer of Code (GSoC) program in 2017. The source code of the API is available on GitHub (https://github.com/kilsedar/3dosm
) with MIT License. The API provides a way to visualize OSM data in 2D and 3D on a virtual globe created using NASA Web WorldWind. Only buildings are visualized in 3D; the rest of the features are visualized in 2D. The spatial quality of OSM buildings was checked by comparing the OSM data of the Lombardy region of Italy whose capital is Milan with the region’s authoritative dataset. As a result, it was found that the positional accuracy of the OSM buildings is comparable with the quality of the authoritative dataset at scale 1:5000, as a result, they are suitable to use for the visualization developed in this work [57
The 3D OSM Plugin API fetches the OSM data based on a tag and the bounding box of the area for which the user wants to retrieve elements. Overpass API was used for fetching the data. Overpass API is a read-only API that serves a selected part of the OSM database. A client sends a query to the API and gets the data that correspond to the query. It has two query languages: Overpass XML and Overpass Query Language (Overpass QL). The Overpass QL was used to construct the queries. Overpass API returns the data in JSON format. The data in JSON format were converted to GeoJSON format using the osmtogeojson API (https://github.com/tyrasd/osmtogeojson
The height of the buildings that are visualized in 3D can be set using the OSM database, more specifically, the tags of features. First, the height key (https://wiki.openstreetmap.org/wiki/Key:height
) that describes the height of a feature is used to set the height of a building, if a value is assigned to it for an element with the building key (https://wiki.openstreetmap.org/wiki/Key:building
). If a value for such a height key is not defined, the building:levels key (https://wiki.openstreetmap.org/wiki/Key:building:levels
) that describes the number of above-ground levels of a building or part of a building is used to set the height of a building, if a value is assigned to it. Each level is assumed to be 3 m. If a value is not assigned to either key, the building is assumed to have five levels, i.e., be 15 m long. A comprehensive list of OSM keys that can be used to render 3D buildings is available in the wiki of OSM (https://wiki.openstreetmap.org/wiki/Simple_3D_buildings
). As these tags are not present most of the time, the API lets the user use a file in GeoJSON format obtained in the way described above, with an additional attribute that denotes the building heights. According to the publication [45
], less than 1.5% of the elements with building key in the OSM database had the height key in November 2011. Moreover, it is possible to set an arbitrary value for all the buildings. It is also possible to visualize the buildings in 2D.
The style of the OSM elements can be set using the API that employs two classes of NASA Web WorldWind: PlacemarkAttributes and ShapeAttributes. PlacemarkAttributes class is used for Point and MultiPoint Geometry types of GeoJSON. ShapeAttributes class is used for the rest of the Geometry types of GeoJSON and triangle meshes. Using the PlacemarkAttributes class, it is possible to set the image and label of placemarks, among others. Using the ShapeAttributes class, it is possible to set the interior and outline colour, outline width, whether to draw an outline, among others. The user can choose to set varying colours for the 3D visualization of buildings. The colours depend on the height of the buildings in the dataset and the colour and thresholds defined by the user. As the height of the buildings increases, the red component in the colour in RGB gets a higher value. Moreover, the thresholds that are ordered hold the values for building heights, and single colour is assigned to all the buildings with a height between two consecutive thresholds. In this way, a 3D heatmap that represents building heights is generated.
The authors participated in NASA Europa Challenge 2017 with an application that uses the 3D OSM Plugin API. Figure 3
displays screenshots from the application and exemplifies the capabilities of the API. The elements that are in the bounding box drawn on the virtual globe by the user can be retrieved from the OSM database. Moreover, the tag and colour of the elements can be defined by the user using the graphical user interface (GUI) of the application. Figure 3
a shows the amenities in Istanbul displayed using placemarks. The nodes were retrieved from the OSM database using the amenity=yes tag (https://wiki.openstreetmap.org/wiki/Key:amenity
). Figure 3
b shows the pathways that are used exclusively or mainly by pedestrians in Milan displayed using lines and polygons. The ways were retrieved from the OSM database using the highway=footway tag (https://wiki.openstreetmap.org/wiki/Tag:highway=footway
). Figure 3
c shows the forests and woodlands in Helsinki displayed using polygons and multipolygons. The ways and relations were retrieved from the OSM database using the landuse=forest tag (https://wiki.openstreetmap.org/wiki/Tag:landuse=forest
d shows the buildings in New York displayed using triangle meshes based on polygons and multipolygons. The ways and relations were retrieved from the OSM database using the building=yes tag. This visualization uses the values of the keys height and building: levels associated with the elements that represent a building to set the height of the triangle meshes. This visualization clearly shows the varying height of the buildings, which is because for most of the elements that represent a building in New York the height or building:levels keys with an assigned value exist.
However, as most of the elements that have the building key do not have the height or building:levels key, when possible, an alternative way was used to set the building heights. First, LIDAR data that represent digital terrain model (DTM) and digital surface model (DSM) were used to extract the height of the buildings in Milan. LIDAR data were received from the Ministry for Environment, Land and Sea Protection of Italy using the contact information available at the national geoportal (http://www.pcn.minambiente.it/mattm/en/data-distribution-service-pst/
). Then, they were converted to virtual datasets (VRTs) using the gdalbuildvrt program of Geospatial Data Abstraction Library (GDAL). Then, the VRTs of DTM and DSM were imported into GRASS GIS. The procedure involves subtracting DTM from DSM to get the height of the objects on the terrain using the r.mapcalc module of GRASS GIS. The OSM data that contain the building footprints in Milan were downloaded in GeoJSON format using Mapzen Metro Extracts and imported into GRASS GIS. Using the v.rast.stats module of GRASS GIS, some statistics were calculated for the footprints of the buildings. The calculated statistics were the minimum, maximum, average and median of the values of pixels inside each footprint. Among these statistics, the median was used to discard the outliers that may stem from the misalignment between the footprints in the OSM data and LIDAR measurements. Second, Urban Atlas Building Height 2012 dataset in GeoTIFF format provided by the Copernicus Programme (https://land.copernicus.eu/local/urban-atlas/building-height-2012
) was used to extract the height of the buildings in Rome. The only difference between this procedure and the previous one is the removal of subtraction between DTM and DSM, as the raster data already represent the building heights. For the other three cities the URBAN GEO BIG DATA project focuses on (i.e., Padua, Turin and Naples), the height and building:levels keys associated with the elements that represent a building were used to set the building heights.
3.1.2. CityGML Data Visualization
Besides VGI (i.e., OSM data in GeoJSON format), 3D vector data visualization was achieved using the OGC standard for representing 3D vector data that pertain to urban areas, CityGML. The visualization of the data in CityGML format would ideally be achieved using the 3D Tiles standard, as it is designed for streaming and rendering massive 3D geospatial data and using an OGC standard is consistent with the goal of achieving interoperability. Moreover, CesiumJS supports the 3D Tiles format. It is important to note that there are other OGC standards for 3D geospatial data delivery, such as 3D Portrayal Service (3DPS) and Indexed 3D Scene Layers (I3S), yet they are not supported by CesiumJS. However, there is not FOSS for converting data in CityGML format to 3D Tiles format. As a result, 3DCityDB was used for the visualization of the data in CityGML format in the URBAN GEO BIG DATA project.
Virtual 3D city models in CityGML format have been created for many cities in the world, yet they are not available for the five cities that the URBAN GEO BIG DATA project focuses on. For this reason, the team from the University of Padua developed software called shp2city that converts data in Esri shapefile format to CityGML format [58
]. In the URBAN GEO BIG DATA project, CityGML datasets that represent the buildings of Milan, Padua, Turin and Naples were generated using the shp2city software. Using 3DCityDB Importer/Exporter, the datasets were imported into a PostgreSQL database extended with PostGIS. Then, using the same software they were exported in KML, COLLADA, glTF formats tiled. The exported datasets were visualized using the 3DCityDB-Web-Map-Client. Since the buildings in the CityGML datasets have altitude values, it is possible to place them on the terrain. On the geoportal, it is also possible to simulate the sun, which enables to visualize shadows of the terrain and buildings at different times of the day and year. Moreover, six base maps were provided in the geoportal when CesiumJS was used to create the virtual globe, which are Bing Maps Aerial, Mapbox Satellite Streets, OSM, CARTO Dark, Stamen Terrain and Stamen Watercolor. The geoportal enables to switch between these six base maps.
Virtual 3D city models in CityGML format have been used for various applications, such as noise propagation simulation and mapping, energy-related assessments of buildings, indoor navigation, disaster management and homeland security [59
]. Disaster management applications include flood simulations for assessing the flood risk and potential damage at a micro-scale [61
]. In this work, virtual 3D city models in CityGML format were used for flood simulation. A semi-transparent polygon was placed on the ellipsoid surface of the virtual globe that users can extrude in meters using a slider in the GUI of the geoportal. It is possible to use the VRTheWorldTerrainProvider class of CesiumJS to generate the terrain geometry by tessellating the digital elevation model (DEM) that includes both land topography and bathymetry with a 90-m resolution for the entire globe provided by the VR-TheWorld Server (https://www.mak.com/products/terrain/vr-theworld-server
). Instead of using the DEM provided by the VR-TheWorld Server, a 5-m DTM of Milan in GeoTIFF format was used to construct the terrain of the virtual globe to increase the accuracy of the flood simulation. This dataset is published by the Lombardy region (http://www.geoportale.regione.lombardia.it/en/home
) as open data. The first step for using the DTM of Milan to construct the terrain of the virtual globe was creating terrain tiles in quantized-mesh-1.0 format (https://github.com/AnalyticalGraphicsInc/quantized-mesh
). The tiles were created using the Cesium Terrain Builder (https://github.com/ahuarte47/cesium-terrain-builder
). Then, the Cesium Terrain Server (https://github.com/geo-data/cesium-terrain-server
) was used to host the tiles. The geoportal refers to this server to retrieve the tiles. Following this approach, it is not possible to simulate floods anywhere else in the world as the DTM is only for Milan unless additional local DEM or DTM is used to construct the terrain of the virtual globe. Finally, the flood risk map of Milan published by the Lombardy region as open data was stored on GeoServer and tiled using GWC. The ImageryLayer and WebMapTileServiceImageryProvider classes of CesiumJS were used by the client to make requests to the WMTS implementation of GeoServer and place the retrieved tiled imagery on the virtual globe. More information was given by [66
]. Figure 4
summarizes the software used and their interactions to clarify the content given above. Figure 5
displays a flood simulation in Milan with the flood risk map and the visualization of the CityGML data that represent buildings.