Detailed Streetspace Modelling for Multiple Applications: Discussions on the Proposed CityGML 3.0 Transportation Model

Abstract

In the context of smart cities and digital twins, three-dimensional semantic city models are increasingly used for the analyses of large urban areas. While the representation of buildings, terrain, and vegetation has become standard for most city models, detailed spatio-semantic representations of streetspace have played a minor role so far. This is now changing (1) because of data availability, and (2) because recent and emerging applications require having detailed data about the streetspace. The upcoming version 3.0 of the international standard CityGML provides a substantially updated data model regarding the transportation infrastructure, including the representation of the streetspace. However, there already exist a number of other standards and data formats dealing with the representation and exchange of streetspace data. Thus, based on an extensive literature review of potential applications as well as discussions and collaborations with relevant stakeholders, seven key modelling aspects of detailed streetspace models are identified. This allows a structured discussion of representational capabilities of the proposed CityGML3.0 Transportation Model with respect to these aspects and in comparison to the other standards. Subsequently, it is shown that CityGML3.0 meets most of these aspects and that streetspace models can be derived from various data sources and for different cities. Models generated compliant to the CityGML standard are immediately usable for a number of applications. This is demonstrated for some applications, such as land use management, solar potential analyses, and traffic and pedestrian simulations.

1. Introduction

Semantic 3-D city models often serve as the foundation for a wide range of analyses and simulations [1,2]. The vast majority of city models available today focus on building and terrain models. New technologies, such as autonomous driving, in combination with data registration methods, including mobile mapping systems, have begun to shift this focus on detailed streetspace models. These are recent developments; therefore, there are very few guidelines on detailed representations of roads and streetspaces within city models, let alone actual implementations. This paper presents substantially extended research on initial results published in Beil and Kolbe [3] with revised concepts, detailed workflow descriptions, and new results. Continuing a study project conducted at the Chair of Geoinformatics of the Technical University of Munich [4], this work explores different approaches for a detailed generation of streetspace objects within semantic 3-D city models mainly based on open data and compliant to the extension of the CityGML standard. While Kutzner et al. [5] presented many aspects of the next version 3.0 of the international OGC standard CityGML, in this paper, the revised Transportation Module is discussed.

The following research methodology is applied. First, we examined potential applications for detailed streetspace models and evaluated relevant standards. These standards are categorized and compared in order to identify different modelling approaches and to provide background information for evaluating potential shortcomings. Then, based on an extensive literature review as well as on experience from a number of projects and collaborations with stakeholders coming from mapping, environmental and planning agencies, simulation companies, municipalities, and companies in the automobile industry, modelling aspects for detailed streetspace models are identified. The authors then discuss concepts of the new CityGML3.0 Transportation Model with regard to its ability to meet the categories presented. Furthermore, the practicability of these concepts is demonstrated by generating several streetspace models and tested for several applications.

The paper is laid out as follows: After specifying the term ‘streetspace modelling’ in Section 2, Section 3 contains a categorization, introduction and evaluation of several standards relevant in the context of streetspace modelling. Most existing standards focus on a linear or parametric representation of roads. This leads to problems, when detailed and highly accurate areal models of streetspaces are required. An extensive literature review describing applications and their requirements for detailed streetspace models is presented in Section 4. Based on application-specific requirement categories and with regard to concepts provided within other standards, the CityGML3.0 Transportation Model is discussed in Section 5. Section 6 contains examples for detailed streetspace models. It is demonstrated that based on different data sources from various cities around the world, detailed streetspace models can be generated compliant to the concepts of the CityGML3.0 standard. Since these models are generated according to this standard, they are directly usable for a number of applications. In Section 7, applications, such as solar potential analysis, infrastructure management, and visualizations of traffic simulations, are demonstrated for some of the generated streetspace models.

2. Streetspace Modelling

Transportation systems, especially within big cities, not only include streets but also contain other transportation infrastructure, such as railways, trams, or waterways and canals. These multimodal transportation types often interact with each other and in many cases even share identical spaces in the city [6]. Level crossings of streets and railways or tramways within a road, for example, are part of the streetspace. Therefore, generating consistent non-redundant spatio-semantic representations of urban transportation space is challenging. This requires concepts as well as corresponding data models to divide real-world streetspace into individual objects. Streetspace models can also be categorized depending on application-specific requirements. While for some applications, a purely geometrical representation may be sufficient, others also rely on detailed semantic information in order to be able to distinguish individual streetspace objects. The significance of modelling topological relations or visual appearance also vary. These aspects can all be modelled in different levels of accuracy and detail. Applications, such as autonomous driving or pedestrian and vehicle simulations, for example, rely on semantically and geometrically very accurate models of streetspace [7,8], while driver training simulators may focus mostly on highly detailed visualizations [9]. Additionally, streetspace could be interpreted (quite literally) as ‘space above a street’ where movement of cars, pedestrians, and other traffic members takes place [10].

While there are concepts available for detailed streetspace modelling in the context of 3-D city models (CityGML2.0 for example does include a transportation model), these concepts are not expressive enough to fulfil modelling requirements of new applications, such as virtually testing autonomous driving systems. There are also standards from other domains available with different approaches to modelling streetspace, depending on the desired application [3,11,12,13,14]. The examination of these standards is relevant for several reasons. First, there are existing software products and datasets available for commonly used formats, such as GDF and OpenDRIVE. Second, established standards also concentrate know-how on how to meet requirements of applications within their intended domain.

3. Relevant Standards and Data Formats

This section reviews and compares standards, data formats, and guidelines dealing with possibilities to represent streetspace within different kinds of models. These standards are categorized by their main application purpose as this generally influenced their modelling approach. Standards and data formats relevant for urban and infrastructure planning and design include LandInfra and Industry Foundation Classes (IFC) and are mainly used by planners and civil engineers. OpenDRIVE, GDF, RoadXML, and Vissim on the other hand are tailored towards the needs of automotive applications, such as navigation or traffic simulations. INSPIRE, OSM, and CityGML are standards used for digital landscape modelling and mapping, while OKSTRA is a German exchange format used for facility and asset management in the context of streets. Employed frameworks and key aspects of each standard are summarized and then compared according to their classification and with regard to respective modelling approaches. An evaluation of all standards is conducted in Section 3.5 and summarized in

Table 1. Comparison of standards dealing with streetspace modelling ([22] revised and extended). * Additionally available in CityGML3.0 (see Section 5).

	LandInfra	INSPIRE	OSM	GDF5.0	OKSTRA	OpenDRIVE	RoadXML	Vissim	CityGML2.0
Geometry
Coordinate Space	3D	2.5D	2D	3D	3D	3D	3D	3D	3D
Straight line segments	🗸	🗸	🗸	🗸	🗸	🗸	🗸	🗸	🗸
Splines	🗸	-	-	-	🗸	🗸	🗸	-	- *
Clothoids	🗸	-	-	-	🗸	🗸	🗸	-	- *
Areal Rep.	🗸	🗸	-	a	🗸	-	b	🗸	🗸
Parametric Rep.	🗸	🗸	-	🗸	🗸	🗸	🗸	🗸	-
Semantics
Surface Material	🗸	🗸	🗸	🗸	🗸	🗸	🗸	🗸	🗸
Function	🗸	🗸	🗸	🗸	🗸	🗸	🗸	🗸	🗸
Driving Ways	🗸	🗸	🗸	🗸	🗸	-	-	🗸	c *
Driving Lanes	🗸	-	-	-	🗸	🗸	🗸	🗸	🗸
Driving Direction	-	🗸	🗸	🗸	🗸	🗸	🗸	🗸	d *
Traffic Logic	-	🗸	e	🗸	🗸	🗸	🗸	🗸	- *
Bridge Model	🗸	f	g	h	🗸	i	-	-	🗸
Tunnel Model	🗸	f	g	h	🗸	i	-	-	🗸
Road Marking	🗸	-	-	🗸	j	🗸	🗸	🗸	🗸
Street Furniture	-	-	-	🗸	🗸	🗸	🗸	🗸	🗸
Vegetation Objects	🗸	🗸	🗸	🗸	🗸	k	-	-	🗸
Multiple Traffic Types	🗸	🗸	🗸	🗸	🗸	k	-	🗸	🗸
Level of Detail	-	-	-	🗸	-	-	-	-	🗸
Topology
Linear Referencing	🗸	🗸	-	🗸	🗸	🗸	🗸	🗸	-
Road/Lane Linkage	-	-	-	🗸	🗸	🗸	🗸	🗸	- *
Appearance
Texture	-	-	-	l	-	-	🗸	🗸	🗸
Other aspects
Main Application/Purpose	Land and civil enginee-ring	EU harmon. data integration	Gen. of open maps	Navigation	Road doc. and asset mngmt	Driving simulation	Driving simulation	Traffic simulation	City models and their applications
Encoding	GML/ XML	GML/ XML	XML	XML binary	GML/ XML	XML	XML	XML	GML/ XML
Developer/Issuer	OGC	EU Com.	OSM	ISO/TC204	BMVI	ASAM	OKTAL	PTV	OGC
Legend	Fully available			Limited availability			Not available

(a) Attributes such as Road Surface Type or Road Surface Condition exist. Enclosed TrafficAreas are used for parking areas; (b) RoadXML3.0.0 contains new elements for area generation; (c) Driving ways are not represented explicitly (but could be modelled using TrafficAreas); (d) Driving directions could be indicated with generic attributes; (e) OSM tags such as access or tags for routing purposes (one way, etc.) are available; (f) Modelled as “AbstractOtherConstruction”; (g) Attribute for road/railway lines; (h) Modelled in a generic way as “Structures”; (i) Indicated if Roads are part of Tunnels/Bridges; (j) Marking available as attributes of different features; (k) Vegetation can be represented using “objects”/Railroad objects can be represented but only in context with Roads; (l) The attribute “texturedSurfaceAvailable” can be used to indicate if textured surfaces are available.

.

3.1. Standards and Data Formats Used for Urban and Infrastructure Planning and Design

The OGC standard ‘Land and Infrastructure Conceptual Model Standard’ (LandInfra) defines concepts for providing and understanding information about land and civil engineering infra-structure [15]. The standard relies on the ISO 19100 series of geographic information standards. It covers various subject areas defined by so-called requirement classes. The most relevant in terms of street modelling are Alignment and Road. However, LandInfra is a new standard and has not been widely used yet.

The Building Information Modeling (BIM) data format Industry Foundation Classes (IFC) [16] is a digital description of constructed, i.e., man-made, objects. The most recent release is candidate standard IFC4.3. Since IFC4.3 is not officially released yet, the standard is not included in Table 1.

Both standards make use of an alignment concept for describing streets with a linear representation using parametric descriptions for representing their spatial extent. An Alignment in LandInfra is defined as a positioning element, which provides a linear referencing system for locating physical elements. It can be defined in several ways, such as horizontal, vertical, or 3-D alignment. For roads, there is typically an Alignment for the centerline. For dual carriageway roads, separate alignments should be realized; however, they may also share a reference horizontal alignment at the approximate center of the entire road. Based on a linear referencing method (LRM), locations along the Alignment can be defined as linearly referenced locations. DistanceAlong and offsetLateral-Distance values shall be measured in the horizontal plane and ignore any vertical displacement, if Alignment is used as a linear element. OffsetVerticalDistance values can be considered. IFC on the other hand contains a so-called IFCAlignment concept to define a reference system for linear construction structures, such as roads or rails. This may consist of a horizontal alignment defined in the x/y plane accompanied with a vertical alignment defined along the horizontal reference line. This is very similar to concepts presented in LandInfra. In fact, the alignment concept has been jointly developed for LandInfra and IFC. While projects, such as IFCRail, IFCTunnel, and IFCRoad, are planned to extend the data model of the next version of IFC towards different infrastructure, LandInfra already contains concepts for modelling Roads. The class Road in LandInfra offers multiple alternatives for representing a road design, such as Road Elements, 3D StringLines (~profile views), 2D Cross Sections, and 3D Surfaces and Layers. Road elements can include many different types, such as pavement, sidewalk, or curb, defined by an attribute called RoadElementType. Multiple road elements can be grouped together as RoadElementSet. RoadElements can be physically located optionally by a spatial representation or a linearly referenced location. A triangulated irregular network (TIN) can represent the surface of a road. Jaud et al. [17] address issues of IFC concerning geo-referencing. This is also relevant for large infrastructure projects (such as roads or tunnels, which need to take into account the Earth’s curvature) that are often represented in custom coordinate reference systems. LandInfra, on the other hand, brings in concepts from other OGC and ISO TC211 standards, including coordinate reference systems.

3.2. Standards and Data Formats Used for Automotive Applications

Geographic Data Files (GDF) is an ISO standard mainly used in vehicle navigation for the exchange of digital maps between map manufacturers and navigation system integrators. Additionally, GDF provides numerous rules for data capture and representation in regard to many streetspace objects. The current specification GDF5.0 was published in 2011 by ISO and is divided into several sections [18].

OpenDRIVE is an open data format originally developed by VIRES Simulationstechnologie GmbH to describe street networks and is commonly used for driving simulations by automobile manufacturers, including BMW, AUDI, and Daimler [7]. Management of the standard was transferred to the Association for Standardization of Automation and Measuring Systems (ASAM) in 2018. The current format specification, Version. 1.6, was published in 2020 [19].

Similar to OpenDRIVE, RoadXML is a format originally conceived for driving simulators. The traffic space is organized into several layers of data, including traffic data, surface data, topologic data, sound data, and user data. In contrast to OpenDRIVE, the circle of active users of RoadXML is fairly limited. Version 3.0.0 of RoadXML was published in 2020 [20].

Vissim is a software tool and data format to perform microscopic behavior-based multi-purpose traffic simulations to analyze and optimize traffic flows [21]. Vissim is one of the most used multimodal traffic simulation software and can be applied for planning of different traffic scenarios or with regard to traffic light control. Potential traffic members include cars, buses, trucks, bikes, pedestrians, or trams. Ruhdorfer [22] described the Vissim traffic model in detail.

All standards are based on linear representations of streets. While GDF and Vissim only allow the use of straight line segments, OpenDRIVE and RoadXML use a reference line described as a sequence of geometric primitives, such as straight line segments, spiral curves, cubic polynoms, and parametric cubic curves. Along this reference line, a variety of road properties, such as an elevation profile, traffic signs, or lanes, can be defined. All standards also contain linking mechanisms for describing topological relations in order to allow navigation through a road network. The standards use a parametric description of lanes relative to a reference line. While GDF uses linear representations of road networks in different levels of complexity, areal geometries can be used to describe areas with unstructured traffic movements, such as car parks. OpenDRIVE contains parameters per lane for ‘surface material code’, ‘roughness’, and ‘friction’. Road networks may be georeferenced using a projection definition formatted as ‘proj4’-string. For surface descriptions, the standard explicitly refers to another document called OpenCRG. Here, road surfaces are represented using a curved regular grid (CRG) visualizing road elevation data in proximity to a reference line [23,24]. Vissim allows the derivation of areal geometries from information on street widths. Additionally, 3-D graphic models, such as SketchUp or Autodesk DWG data, can be integrated in order to achieve detailed visualizations of the simulation results. All standards contain concepts for modelling traffic logic and a linear referencing system. GDF and Vissim allow the representation of multiple transportation types, whereas OpenDRIVE and RoadXML focus on representations of roads used by cars. Railroads can be represented in OpenDRIVE but only in context to a nearby street. For the description of dynamic interactions of traffic members, such as overtaking maneuvers, OpenDRIVE refers to the related standard OpenScenario [25].

3.3. Standards and Data Formats Used for Digital Landscape Modelling and Mapping

The INSPIRE Data Specification on Transport Networks aims for interoperability of spatial data and services from different sources across the European community [26]. Regarding transportation, INSPIRE intends to establish a framework for an integrated transport network and related features that are seamless across international borders. The INSPIRE Generic Network Model (GNM) relies on the ISO 19100 series of geographic information standards. This includes a network connection mechanism to establish cross border connectivity and intermodal connections, object referencing to support reuse of information and avoid redundant representations, and a linear referencing system. Spatial object types are defined within a feature catalogue and attributes are enumerated in code lists. The data specification covers all major transport network types, including road, rail, water, air transport, and cableways. Elements in the network are handled as nodes, links, aggregated links, areas, and points and can have temporal validity. Nodes are only represented if an intersection between links exists in the real world. Topology is not handled explicitly within the data specification. However, it is stated that the data provided must be suitable for the reconstruction of the topologic relationships.

OpenStreetMap (OSM) is a community project that provides user-generated maps available for web viewing and downloads [27]. Map features defined on the project homepage (https://wiki.openstreetmap.org/wiki/Main_Page) are identified by so-called keys. These include ‘highway = *’ used for any kind of road, street, or path. An assigned attribute value further indicates the importance of each highway within the road network. Potential highway attributes include primary, secondary, or tertiary roads as well as motorway and other road types. OSM data is mostly used for map making and sometimes for navigation applications. While an OpenStreetMap Linear Referencing (OSMLR) concept was developed for providing linear referencing to OSM road data, this concept is not used by default. OpenStreetMap data is user-generated open data, thus accuracy and availability can vary heavily depending on the location [28].

City Geography Markup Language (CityGML) is an open data model and XML-based format to represent, store, and exchange semantic 3-D city and landscape models. The Open Geospatial Consortium (OGC) issued the current standard CityGML 2.0 in 2012 [29]. It defines numerous classes and relations for many thematic city objects with respect to their spatial, semantic, and appearance properties. All city objects can be represented in five consecutive levels of detail (LoD). The most relevant thematic model in the context of representing streetspace is the ‘transportation model’. It consists of the main class TransportationComplex and can be thematically specialized into four subclasses called Road, Square, Track, and Railway. Transportation features can be represented as linear networks in LoD0. Starting from LoD1, transportation objects are spatially represented by MultiSurfaces. LoD2-LoD4 representations allow a further semantic decomposition into TrafficAreas (e.g., driving lanes or sidewalks) and objects not directly used for vehicle or pedestrian movement called AuxiliaryTrafficAreas (e.g., middle lanes, kerbstones, or green space). Attribute values for properties like class, function, or usage are defined using code lists enumerating the specific possible entries. CityGML is used worldwide for representing and exchanging 3-D city models. Until now, CityGML has been mostly employed to represent models of buildings, the terrain, or sometimes bridges and tunnels. Recently, the first CityGML streetspace models have been created [3].

While INSPIRE and CityGML contain concepts for linear as well as areal representations of streetspace, OSM only allows linear geometries. There are proposals for areal modelling of streets (https://wiki.openstreetmap.org/wiki/Proposed_features/Street_area) in OSM. In contrast to standards used for automotive applications, linear geometries can only be represented using straight lines for each of the standards. All standards include multiple transportation types, such as railways, waterways, footpaths, or cycle lanes, which is mainly indicated using respective attributes. However, in the case of OSM, this information often is not available. While INSPIRE offers a linking mechanism for multimodal transportation networks, OSM and CityGML2.0 do not have concepts for expressing such relations.

3.4. Standard Used for Facility and Asset Management

‘Anweisung Straßeninformationsbank’ (ASB) and ‘Objekt¬katalog für das Straßen-und Verkehrswesen’ (OKSTRA), released by the Federal Ministry of Transport and Digital Infrastructure of Germany, are standardized catalogues for the uniform recording, manipulation, and provision of street object characteristics [30]. ASB describes object structures from a technical perspective, whereas OKSTRA focuses on formal descriptions using data schemas and UML representations of streetspace objects [31]. The model is based on several ISO standards, including ISO 19107 [32] and ISO 19109 [33]. ASB and OKSTRA are used by German administrations to collect and store uniform information on public streets and traffic infrastructure. The concept is described using definitions given in ASB. First, types of streets that should be included are designated. A linear representation is used to illustrate the described modelling concept. Every street is divided into several sections, with each section being bounded by two uniquely identified nodes. Every section inherits a stationing system, starting at the first node and ending at the second. A node can be made up of multiple smaller branches like ramps or driveways connecting different sections. The standard proceeds by giving numerous detailed examples, again illustrated via line and node representations, on how to represent various streetspace scenarios. These include inter alia intersections in different levels of complexity, roundabouts, bridges, and overpasses. While it is possible to model objects with areal representations, streets are commonly represented with linear structures.

3.5. Evaluation

While standards have so far been compared within their category, all standards are now evaluated concerning different modelling approaches, including available geometries, semantic information, topological concepts, and possibilities for visualization. This is summarized in Table 1. Furthermore, concepts additionally available in CityGML3.0 are also indicated. The colors in each cell indicate if a category is covered by a certain standard. Green cells indicate that the feature is fully available for the specific standard. Features symbolized with red cells are not available and yellow cells imply limited availability of the specific feature. Each yellow cell is labelled with a letter and further explained. More detailed explanations on each cell can be found on a corresponding Wiki page (https://wiki.tum.de/display/gisstreetspacemodelling/Relevant+Standards). GDF, OKSTRA, and ASB offer extensive regulations on dividing streetspace objects into different categories. OpenDRIVE, ASB, and LandInfra deliver solutions for problems not addressed in the current CityGML standard like linear referencing and stationing systems. Similar to OpenDRIVE, RoadXML and Vissim focus on semantic and topological aspects. Gilbert et al. [34] present a detailed comparison of LandInfra, IFC, and CityGML with regard to differences in conceptualization, semantics, coordinate reference systems, geometries, and other aspects, and discuss challenges concerning software interoperability and data integration. Most of the presented standards focus on linear and parametric representations of streets only. This can lead to problems if a detailed representation of streets and streetspace objects is required as illustrated in Figure 1.

While a linear representation typically is sufficient for applications like navigation, traffic simulations, or noise mapping, an areal street model is often needed in order to represent geometric details like bus stops, irregularly changing street widths, or road markings. Additionally, large sealed surfaces like plazas or parking lots should be modelled as surface geometries. This could be beneficial for visualization or spatial analyses.

Park et al. [35] show how detailed areal information on the length, width, or slope of roads is necessary for calculating optimal snow removal routes. Strassenburg-Kleciak [36] discussed possible benefits of areal street representations in OSM. Some applications benefit from accurate visualization of streetspace using textures and detailed 3-D models. Most standards dealing with streetspace modelling do not allow for an easy derivation of 3-D visualizations. An areal 3-D representation of streetspace objects is not supported by all standards. Semantic aspects are covered by most of the standards presented. Unsurprisingly, standards designed for traffic/driving simulations or navigation purposes focus on topological properties. Additional thematic features, such as tunnels, bridges, road markings, city furniture, and multiple traffic types (road, railway, pedestrian, etc.), can be important in the context of multimodal traffic relations. This is an advantage of CityGML since all these thematic modules can be integrated within a consistent city model.

4. Applications for Detailed Streetspace Models

The following section contains a detailed literature review on possible applications for detailed 3-D streetspace models (with no claim to completeness). These applications impose a number of different modelling requirements upon models of detailed streetspace in order to be usable. These requirements may be very specific for each application (e.g., “positional accuracy of objects must be better than 0.03m”). Listing these requirements in detail would be out of scope of this paper. However, streetspace datasets are not just limited by available data but also by the underlying modelling frameworks and potential conceptual shortcomings of the standard or format the data is provided in. Thus, modelling aspects are categorized more generally in Section 4.2. This allows a discussion and comparison of CityGML3.0 with other standards and concepts with regard to how far they fulfil these aspects.

4.1. Literature Review on Potential Fields of Application

4.1.1. Infrastructure Planning and Management

Digital 3-D city models can be the basis for land use management [37,38]. Besides settled areas, the cityscape is mainly shaped by public traffic areas. Visual simulations of constructed areas as well as free space can be used in order to plan different scenarios and conduct effort and cost analyses. In this context, large construction projects, such as new highway sections or bridges, can be planned digitally. This can also be used to visualize the future 3-D view of these constructions and thus prevent potential resistance of citizens against planned constructions. In this context, it is relevant how much effort it takes to create accurate visualizations from data provided in different standards. Döllner and Kleinschmit [39] as well as Bock et al. [40] show that virtual 3-D city models can build an innovative foundation for making complex spatio-semantic information accessible in terms of sustainable land use management. Many communities have a duty to fulfill their municipal obligations, such as clearing streets of snow or leaves. Planning these often-expensive tasks in order to find the most effective and economical implementation could be supported by detailed streetspace models [35]. This involves routing tools, which require topological information within street networks. Areal street models combined with knowledge of pavement conditions can be used for assessments of expected repair costs. This also involves maintenance of streets and damage mapping. Results of structural health monitoring and damage detection of road pavements can also be linked to individual streetspace objects within a city model. Zhao et al. [41] show the advantages of spatial models in the context of estimating road degradation parameters. Kolbe et al. [42] showed how CityGML and semantic city models can be used for emergency planning. In combination with knowledge about buried utility infrastructure, detailed areal streetspace models can be used to determine which parts of a road would be affected by street excavations [43]. The term ‘digital twin’ originally was used for the physical and functional description of components, products, or systems of industrial machines, including information for all lifecycle phases [44]. This concept can be transferred to the context of urban planning and smart cities [45]. Methods for consistent version management and historization of streetspace models are necessary for these applications. The digital twin of a city can be described as a digital representation in terms of its physical assets, including buildings, streetspace, vegetation, and other objects [46]. Models of real-world objects, such as streets, enriched with dynamic real-time information on traffic volume for nowcasting or simulation results, can be integrated into planning or management processes of transportation infrastructure.

4.1.2. Automotive Applications

Knowledge on the exact shape of streetspace objects is key for autonomous driving applications. Schwab and Kolbe [7] discuss application-specific requirements of road space models in the context of automated driving development. On the one hand, virtual tests of automated driving systems, including sensor simulations, can be conducted using digital streetspace models. On the other hand, information contained within detailed streetspace models can be used as “ground truth” for automated driving systems trying to understand their environment. This also requires information on traffic areas used by other road users, such as pedestrians, cyclists, or trams. Schwab et al. [8] present a concept for road space modelling to couple the sub-microscopic driving simulator “Virtual Test Drive” with a pedestrian behavior simulator for testing automated driving systems. In the course of this process, OpenDRIVE datasets are transformed to CityGML datasets and used for generating a pedestrian simulation scenario. Richter et al. [47] analyze the requirements to the development and test of automated driving systems using virtual city and traffic models and propose a concept for an integrated urban development framework. Strassenburg-Kleciak [36] stated that information on street edges can be used in order to increase driving safety. Connected vehicles in combination with data on the length and width of certain street sections can be used to assist drivers with overtaking maneuvers. Randt et al. [48] described how virtual 3-D landscapes can be used for driving simulators and emergency driver training. Piga et al. [9] show that the same scenario represented in different levels of detail affects the validity of the driving experience and thus driving behavior. Keler et al. [49] created a bicycle simulator, including 3-D visualizations of real-world streets and intersections. Other automotive-related simulations, such as traffic simulations or driving dynamic simulations, can also be supported by information derived from detailed streetspace models [14,50,51]. Wilkie et al. [52] show methods on how to create a geometrically and topologically consistent 3-D model from GIS data usable for traffic simulations. Boersma [13] discussed several use cases for digital road models, including traffic models, maintenance, and navigation by examining specific data needs with respect to these three applications. Topologic relations of street and lane objects are especially important for navigational applications and traffic simulations. Chao et al. [53] also present road modelling techniques in the context of traffic simulations. Roads normally forbidden for automobiles but wide enough to be used by ambulances in emergencies could be integrated into navigation systems. In this context, knowledge on steps, curbs, etc. could be considered for barrier-free route planning in order to assist persons with reduced mobility [54].

4.1.3. Environmental Simulations and Analyses

Detailed 3-D streetspace models can be the foundation for a variety of environmental simulation and analysis methods. Local heat islands in largely sealed areas, such as street intersections or plazas, can be analyzed using information derived from areal street representations in combination with knowledge of solar irradiation. The optimal placement of street signs and traffic lights can be planned within city models and supported by visibility analyses [1]. Bassani et al. [55] evaluated GIS data to estimate the available sight distance in a typical urban road. Ghassoun et al. [56] show how city models can be useful for air quality analyses. Willenborg et al. [2] demonstrate how to convert a city model to be usable for computational fluid dynamics (CFD) simulations in the context of detonation simulations. A similar approach could be implemented for linking particulate matter simulation results with spaces above traffic areas. In this context, dynamic information (e.g., changing pollution levels during a day) needs to be linked to streetspace objects. The combination of air-quality simulation results (particulate matter) with information on areas and spaces frequented by pedestrians can be used for identifying particularly affected places. Easy visualizations of such results can be important for quick and intuitive evaluations. Parameters, such as the number of intersecting streets, their respective width, and angles between street arms, can be derived from accurate streetspace models [57]. In combination with other parts of a city model like buildings and vegetation, highly accurate simulations can be conducted. Based on areal information of streets and footpaths, clearance spaces can be easily modelled. These can be used to simulate heavy-load transportation and identify problematic areas. While linear representations of streets are often sufficient for noise simulations, areal models can be used to visualize the results [58]. Detailed street models with information on elevation can also be the foundation for water run-off and flood simulations with high levels of detail [59]. Amirebrahimi [60] demonstrate flood damage assessment for building models. Similar evaluations could be made using areal streetspace models.

4.1.4. Land Administration and Topographic Mapping

Models of streetspace can also be used for a more detailed description of the Earth’s surface in the context of digital landscape models (DLMs) and topographic mapping. Fiutak et al. [61] present methods for generating a 3-D-DLM from different data sources, including areal roads for an area of 254 km² near Lake Constance. The Land Administration Domain Model (LADM, ISO 19152 [62]) is designed to cover basic information-related components of land administration, including legal/administrative information (land use rights, ownership, taxation, etc.), mapping, and surveying [63]. This also concerns surfaces that are part of roads and other infrastructure. Detailed streetspace models can be beneficial for integrating this information with spatial representations. This is also relevant for road infrastructure asset management and closely linked to maintenance applications mentioned before. Switching from 2-D mapping to 3-D topography has been adapted by some regional or national agencies [64]. This includes 3-D modelling of terrains including roads or other transportation infrastructure. Gristina et al. [65] present concepts for a GIS-based implementation of a road cadastre system usable for road inventory while addressing advantages of 3-D streetspace modelling.

4.2. Categorization of Key Modelling Aspects

Based on the literature review presented in Section 4.1, as well as discussions and collaborations with colleagues and stakeholders in the field of streetspace and city modelling, key modelling aspects for detailed streetspace models are identified. In addition to geometric, semantic, topologic, and visual characteristics, this includes time-dependent aspects, such as representing dynamic information and managing different versions of models. This categorization facilitates an evaluation of representational capabilities of the CityGML3.0 Transportation model with regard to each one of these modelling aspects in comparison to the standards presented in Section 3. Furthermore, this allows a comparison of different modelling aspects with respect to their importance to individual applications discussed in Section 4.1. Some of the authors have many years of experience in the field of city modelling and standardization and are active members of the OGC. The authors were also involved in a number of projects with relevant stakeholders from mapping, environmental, and planning agencies; municipalities; simulation companies; and companies in the automobile industry. This work has led to the identification of the following seven key modelling aspects:

• Thematic resolution: Possibility to distinguish between different thematic objects as well as the degree of semantic segmentation, available object attributes, and object relationships.
• Geometric resolution: The degree to which geometric details of individual objects are represented as well as the degree of geometric segmentation and available geometries.
• 3-D positional accuracy: Relative or absolute accuracy of object coordinates.
• Network and areal topology: Topological relations between linear and areal representations of road networks or streetspace objects.
• Topicality and evolution: Up-to-dateness of the model; keeping track of the changes of the streetspace model over time and managing different but consistent versions (or stages within the lifecycle) of objects.
• Dynamic and real-time information: Consideration of (highly) time-dependent information; linking objects with (highly) dynamic and real-time information.
• Visualization: Importance of realistic visualization, which may include textures or coloring.

The relevance of these categories is now discussed with respect to some of the applications presented in Section 4.1. For many use cases, a high positional accuracy of the represented streetspace objects is of great importance. Applications, such as autonomous driving, emergency planning, or land use management, obviously rely on highly accurate information on the position and location of road edges on the one hand. Driving dynamics simulations or driver training simulators on the other hand do not depend on exact real-world coordinates (absolute positional accuracy) but rather rely on a high geometric resolution and high-quality visualization. While the need for high positional accuracy correlates with a dependency on a high geometric resolution for applications, such as autonomous driving or clearance space analyses, driving dynamics simulations mostly rely on a high geometric resolution in order to simulate uneven or bumpy road surfaces [50]. Ross [37] lists the data requirements of virtual 3-D city models in the context of land use management. Thematic resolution is especially important for applications that need to distinguish between thematically different streetspace objects. Real-world models with semantic information on roadbeds, edges, and sidewalks can be useful as a priori information for autonomous driving software [66]. In order to be able to generate clearance spaces for traffic surfaces used by cars as well as traffic surfaces used by other transportation types (such as pedestrians, trains, or ships), thematic distinctions between different thematic surfaces must be possible. With the exception of driving simulators and driving dynamics simulations, the topicality of the data represented in streetspace models is important to all other applications presented. Consistently managing different versions of streetspace models (e.g., within their lifecycle) is relevant for applications, such as infrastructure planning. Big construction projects, for example, need to be described in different stages of planning. Topological relations can be modelled using detailed street models and can also be linked to other thematic objects contained within a city model, such as buildings or vegetation. Ruhdorfer et al. [51] show the importance of predecessor/successor relations between individual roads or lanes in the context of traffic simulations. Tamminga et al. [67] and Tamminga [14] analyzed modelling requirements focusing on traffic and transportation models and also discussed possibilities to match these requirements to the CityGML data structure via a Transportation Application Domain Extension (ADE). This includes, inter alia, the ability to distinguish various vehicle types, representations of mixed use of infrastructure (e.g., road and rail), representing the geometrical design of a road or modelling parking areas as intermediate destinations for multimodal trips. The importance of modelling transportation infrastructure in consistent levels of detail is also explained. Topological relations between utility network elements are of great importance [43]. The CityGML UtilityNetworkADE provides concepts for representing topology and connectivity within utility networks [68]. These concepts could be transferred to streetspace models. A dynamical component to streetspace modelling is especially important to time-dependent applications. Traffic simulations should be able to simulate traffic flows for different times during the day, and spatial analyses, such as particulate matter or local heat island analyses, also need to take into account changes of objects and attribute values during various times of the day or year. While a realistic visualization of streetspaces can be beneficial for most applications, it is essential to driver training simulators to ensure a realistic experience. Non-overlapping geometries are necessary to avoid visualization problems, such as z-fighting. The efforts required to create visualizations differ strongly over different modelling approaches provided by the standards discussed earlier. While parametric representations first need to be transformed to areal representations, explicit areal geometries can be visualized immediately.

5. Discussion of the Proposed CityGML 3.0 Transportation Model

Figure 2 shows the UML diagram of the revised and extended CityGML Transportation Model. New classes compared to CityGML2.0 are highlighted with orange borders.

Several studies, including Beil and Kolbe [3], Beil [11], Labetski et al. [12], Boersma [13], and Tamminga [14], have examined the CityGML 2.0 Transportation Model, identified deficits, and contributed several proposals for improvement. Based on discussions with relevant stakeholders and comparisons with concepts included in other standards (see Section 3), this advanced CityGML 3.0 Transportation Model was developed in the context of the OGC CityGML Standards Working Group (SWG) [69,70]. Note that the CityGML 3.0 Transportation Model is still subject to the final voting of OGC members. This proposal, including revised concepts on spaces, linear, areal, and volumetric representations, a revised LoD concept, and new classes, is discussed in this chapter with regard to its capability to meet the modelling aspect categories identified in Section 4.2.

Table 2. Meeting modelling aspects with CityGML3.0.

Modelling Aspects	Support in CityGML3.0
(1) Thematic resolution	Section/Intersection concept, 3 levels of thematic granularity down to lane-level accuracy
(2) Geometric resolution	Representations of streetspace objects with linear, areal, volumetric or point cloud geometries available, LoD concept, highly accurate (explicit) real-world geometries (in contrast to parametric representations), spaces concept, (3 levels of granularity)
(3) 3D positional accuracy	Arbitrary coordinate systems, Accuracy also depending on underlying modelling framework
(4) Network and areal topology	Predecessor/Successor concept, graph- or areal networks possible
(5) Topicality and evolution	Depending on available data, Versioning Module available
(6) Dynamic and real-time information	Dynamizer Module for representing time-dependent properties
(7) Visualization	Appearance Module (colors, texture), Open Source Software, non-redundant geometric and topologic representations (e.g., important to avoid z-fighting)

summarizes how concepts of the revised and extended transportation module in CityGML3.0 meet the requirements within the respective categories. The following discussion examines and evaluates these concepts with regard to each category and compares them to the standards evaluated in Section 3.

5.1. Thematic Resolution

Street and transportation networks can be very large and complex, thus standards dealing with streetspace modelling often contain concepts for thematically partitioning these networks into smaller objects. CityGML3.0 thematically divides large street networks into Roads, which consist of Sections and Intersections as illustrated in Figure 3a. Additionally, each Section or Intersection can be divided into TrafficSpaces and AuxiliaryTrafficSpaces, which in turn are further specified using class, usage, and function attributes. This is coherent to the semantic decomposition of transportation objects as defined in the CityGML 2.0 standard and thus ensures compatibility between both versions. Sections (colored in light orange) represent segments that can clearly be assigned to one individual Road. Sections are connected by Intersections (colored in light blue), which can belong to multiple Roads at the same time. Types of Sections as well as Intersections are defined by respective class attributes. Similar to Labetski et al. [12], Intersections are modelled as individual objects categorized by different types [71]. In order to avoid a redundant representation of Intersections shared by multiple roads, a linking concept is used to reference the shared Intersection. Usage of XLinks to implement object linking to avoid redundant representations is explained in more detail in the CityGML specification document [29]. Beil and Kolbe [6] demonstrate this concept for multiple transportation types, including a level crossing shared by a Road and a Railway object simultaneously. In the example in Figure 3a, Intersections are reduced to the smallest area used by different Roads. In some cases, it might be useful to expand Intersections as shown in Figure 3b. This, however, makes it difficult to calculate the actual street surface area for each individual Road. Both interpretations of an Intersection are possible and can be modelled depending on specific application requirements. The defining attribute for Sections/Intersections belonging to the same Road is (in most cases) a common street name attribute. Roads could also be segmented depending on changing attributes, such as surface material or speed limit. In this case, it does not make sense to represent each part of a Road with an individual Section for each surface material or speed limit. The introduction of a linear referencing system in combination with the definition of logical sections could be the solution to this problem. However, this needs further work.

The new version 3.0 of CityGML will come with a revised LoD concept as proposed by Löwner et al. [72] and will only contain four levels of detail. Furthermore, in contrast to CityGML2.0, the LoD concept only refers to the geometric but not the thematic resolution of objects. Since the thematic decomposition is not directly linked to LoDs anymore, a new attribute ‘granularity’ is introduced, in order to express different levels of thematic decomposition within the transportation module. Figure 4 shows a Section with multiple thematic parts. It is indicated that an areal representation with granularity = area should cover the entire width of the street, including sidewalks or kerbstones. A more detailed segmentation into TrafficSpaces and AuxiliaryTrafficSpaces representing individual traffic ways should be realized with thematic granularity = way. Thematic granularity = lane additionally allows the representation of individual driving lanes [3,12,14]. As long as roadways are not topologically separated, streets are represented by a single centerline in thematic granularity = area (red line in Figure 4). In addition to the driveway centerline, linear representations for footpaths and bikeways (blue lines in Figure 4) become possible with thematic granularity = way, thus enabling a more detailed thematic decomposition of streetspace. While individual driveways (sometimes referred to as carriageways) are represented with individual linear/areal TrafficSpace objects in granularity = way, granularity = lane representations finally contain one linear/areal TrafficSpace object for each individual driving lane. This is consistent with proposals made by Boersma [13] and Tamminga [14] based on Beil and Kolbe [3] for linear representations of roads and junctions in different levels of detail.

CityGML3.0 contains new classes in order to allow the representation of further thematic objects. Markings are modelled by an individual class representing additional surfaces independent of the level of granularity. This new class should not be limited to road markings but could also be used to model markings related to railway or waterway traffic. Markings can span over multiple (Auxiliary)TrafficSpaces and thus lie in the same plane as road objects but should be rendered on top. As already mentioned, holes in street surfaces, such as road damages, manholes, or drains, should be represented by MultiSurface geometries. In contrast to Markings, HoleSurfaces should be modelled as cut out ClosureSurfaces in an (Auxiliary)TrafficArea.

Principles and concepts explained for Road objects also apply for Waterways, Railways, and Tracks. Similarly, linear as well as areal representations in multiple levels of granularity are possible. All of these different transportation types are modelled using the same data structure. Thus, combinations of these infrastructure types are simple [6]. This is beneficial to applications, such as multimodal transportation or barrier-free navigation. Labetski et al. [12] describe why waterways should be part of the transportation model. While water bodies are already represented in CityGML 2.0, a new class Waterway is used to model water-related transportation scenarios.

The thematic segmentation of street networks into Roads that are further divided into Sections and Intersections, which again are split into (Auxiliary)TrafficSpaces used in CityGML3.0, is similar to concepts of OpenDRIVE, where roads and junctions can be distinguished and contain individual lanes and lane sections. OpenDRIVE Junctions are defined as areas where three or more roads meet. GDF also allows the distinction between roads and intersections. While GDF, OSM, and INSPIRE do not allow a thematic partitioning of roads into individual lanes, this is possible in LandInfra, RoadXML, and Vissim.

5.2. Geometric Resolution

The revised LoD concept as well as the introduction of different levels of thematic granularity also affect the way transportation objects are represented geometrically. As mentioned before, LoDs in CityGML3.0 refer to the geometric representation of objects only. In LoD 0, object geometries are modelled using a highly generalized geometric representation, while no generalization is applied in LoD 3. Thus, the highest detailed geometric and semantic representation of transportation objects is achieved using LoD 3 geometries with thematic granularity = lane. CityGML 3.0 introduces the concept of modelling TrafficSpaces, which can be spatially represented with linear, areal, volumetric, or point cloud geometries. Geometries are represented using absolute world coordinates. These models can be used immediately for a number of spatial simulation applications, whereas parametric representations often need to be transformed to an explicit representation before (cf. Section 5.7.). In contrast to CityGML2.0, the use of MultiCurve geometries allows the representation of clothoids or splines. Volumetric representations are realized using a newly introduced space concept. A detailed explanation of the space concept is given in [5]. This also affects the way Transportation objects are represented. Figure 5 illustrates this concept for a simple example of a Road corridor. The displayed example shows a Section of a Road. The Section is semantically and geometrically decomposed into two sidewalks and one carriageway each represented by its own TrafficSpace (illustrated with blue boxes in Figure 5). The volumetric geometry of a space, however, can be omitted.

TrafficAreas (depicted in green) represent the ground surface of each TrafficSpace. The same concept would apply to AuxiliaryTrafficAreas and AuxiliaryTrafficSpaces. The newly introduced class ClearanceSpace (in red) makes it possible to represent space that has to be kept clear in order to ensure safe traffic. These clearance spaces can easily be generated by extruding TrafficAreas by a certain amount. In combination with other city objects, such as CityFurniture or Vegetation, potential conflicts can easily be detected. ClearanceSpaces can also be represented with point clouds (as produced by a mobile mapping system). The given example can be transferred similarly to other Transportation objects, such as Railway, Track, Waterway, or Square. Transportation objects are not just represented by their surface but also consider the space above used for transportation. This concept distinguishes the CityGML 3.0 Transportation Model from all related standards presented in Section 3.

Boersma [13] identified missing affiliations between areal and linear representations of the same scenario. Potential matching problems of identical scenarios represented in different ways are displayed in Figure 6. The left part of the image shows a possible representation of two intersecting streets in granularity = area. This scenario could be modelled using four lines representing each street segment and meeting in one point. An areal model on the other hand could include four sections and one intersection. In order to generate a consistent model for linear as well as areal models, each line should be split at additional connection points (represented with yellow dots in Figure 6).

Nodes can be derived from the linear network if needed for connectivity or shortest path graph algorithms. The advantage of this representation (in contrast to GeometricComplex geometries used in CityGML 2.0) is that intersecting lines representing different transportation types do not need to have nodes. This way, different transportation types are not connected if it is not possible to switch between them at a certain point (e.g., road and railway networks intersecting at a level-crossing). Non-redundant geometric integration of multiple transportation infrastructure is discussed in [6].

Available geometric representations of streetspace within other standards are evaluated in Section 3.

5.3. 3-D Positional Accuracy

The positional accuracy of individual objects within 3D city models, including transportation infrastructure, is not only dependent on the data gathering method and the accuracy of the produced data. The underlying modelling principle of a data standard also has an impact on the representational capability with regard to potential accuracy. CityGML allows the use of arbitrary coordinate systems and is especially suitable to represent geographically large extended structures (such as roads or railways) where the Earth’s curvature needs to be taken into account. Explicit representations of all geometries using absolute world coordinates allow the modelling of objects and object boundaries according to their actual extent, while parametric representations typically provide information on street and lane borders using width attributes relative to a reference line. However, real-world objects, such as borders of individual lanes, are complex and often irregularly shaped. Thus, either complex parametric descriptions of these objects (using polynoms, etc.) are necessary, or simplifications (e.g., a constant lane width) need to be done, which affects the positional accuracy of objects. Standards using explicit representations of all geometries with absolute world coordinates, such as CityGML, avoid such problems.

5.4. Network and Areal Topology

Figure 7a shows a direct comparison of linear network representations in different levels of granularity. While linear representations in granularity = area are modelled with one axis per driveway and section, linear representations in granularity = lane contain separate lines for each individual driving lane, following every possible way a car could take. This automatically implies a predecessor/successor concept useful for applications, such as navigation or traffic simulations. Figure 7b shows that these predecessor/successor relations can become complex depending on the desired level of detail.

An explicit representation of predecessor/successor relations (e.g., regarding turning restrictions) can be modelled as shown in Figure 8. Segment B is predecessor of segment A and C, segment A is predecessor of segment B. At the same time, segment A and C are successors of segment B and segment B is successor of segment A. This way, all possible routes are defined. This concept can also be applied to areal or volumetric objects. While this concept increases the appeal of CityGML for navigational applications, other standards (e.g., OpenDRIVE, RoadXML, GDF) feature more complex linking mechanisms for representing traffic logic, including relations of individual lanes to traffic signs or traffic lights. This information could be added to CityGML3.0 in an Application Domain Extension (ADE), though.

5.5. Topicality and Evolution

Data topicality is solely dependent on available data or data update cycles. Another aspect to this, however, is the storage and management of different versions, historization, and consistent version management of alternative planning scenarios. CityGML3.0 contains a versioning concept for representing multiple versions of city objects and storing information on changes over an entire lifespan of individual objects [73]. GDF provides ‘Update Information Records’ to register changes in a particular dataset. INSPIRE and OKSTRA are the only other standards of those presented in Section 3 to provide similar concepts.

5.6. Dynamic and Real-Time Information

The new Dynamizer concept introduced with CityGML3.0 allows the modelling of highly dynamic and time-varying attributes within semantic 3-D city models [74]. Using Dynamizers, static attribute values of streetspace objects can be overridden with time series data. Time series data can be provided in external files or by linked sensor observation services. This is relevant for transportation infrastructure in order to represent information on changing traffic volume for nowcasting or changing speed limits for different times of the day. GDF supports the definition of temporal aspects of features, attributes, and relationships using starting and ending times. OpenDRIVE refers to the related standard OpenScenario for describing dynamic interactions of traffic members, such as overtaking maneuvers, but does not include concepts for representing dynamic information. The other standards presented in Section 3 do not contain similar concepts.

5.7. Visualization

The concepts to spatially and semantically partition transportation networks in combination with the linking mechanisms discussed earlier allow a non-redundant representation of objects sharing identical surfaces. Among other benefits, this ensures accurate visualizations by avoiding problems, such as z-fighting. Integrated and semantically and geometrically non-redundant representations using explicit areal geometries can be visualized directly, while data provided according to standards using parametric representations (e.g., to represent lane borders relative to a reference line) first needs to be transformed. Depending on the used base geometries of the reference line and parametric description of object borders (splines, clothoids), this can be difficult. Streetspace objects (especially lane areas within junctions) are often represented relative to multiple reference lines at the same time. This results in overlapping geometries when transformed to explicit areal representations. In consequence, there are few commercial software products available for resolving these issues in order to derive an integrated and non-redundant areal visualization from parametric data. In contrast, data provided in formats already using explicit areal geometries, such as CityGML, can be visualized directly with open source software, such as the 3DCityDB and a corresponding Web-Map-Client [75,76]. Furthermore, the appearance module of CityGML provides concepts for the representation of observable properties for surface geometry objects using colors or textures, which is (with the exception of RoadXML and Vissim) not included within other standards and data formats presented in Section 3.

6. CityGML Streetspace Models for Different Cities

While there are some CityGML2.0 Transportation models available (e.g., Singapore [77]), the majority of city models has been focusing on models of buildings and the terrain so far. In the following, we show that CityGML3.0 streetspace models can be derived from various data sources and for different cities around the world. The advantage of models available in the CityGML format is that they can immediately be used for several applications (see Section 7). Thus, this chapter shows how to create detailed CityGML streetspace models for different cities, including New York City, Melbourne, or Grafing near Munich, and based on different data sources. All of these examples can be explored interactively at https://wiki.tum.de/display/gisproject/Online+Demo+Collection. Most of these datasets are also provided as open data.

6.1. New York City

The detailed representation of the streetspace has been first tested using the example of New York City [3]. The NYC Open Data Portal provides an extensive number of datasets, including geometric as well as semantic information on streetspace objects for the entire city suitable for detailed streetspace modelling. This data is transformed, manipulated, and integrated using the software ‘Feature Manipulation Engine’ (FME) to generate CityGML compliant datasets.

The detailed street space model of New York City is generated using three main data sources. A semantic 3-D city model of New York City was generated within a study project conducted at the Chair of Geoinformatics of the Technical University of Munich [4]. The produced CityGML datasets are available for download on the project website (https://www.gis.bgu.tum.de/projekte/new-york-city-3d). The provided road dataset includes a LoD0 line-network representation and is the basis for the street model generated in this work. The second major data source is the so-called ‘NYC Planimetric Database’ provided in the NYC Open Data Portal. This contains representations of a variety of features, such as roadbeds, sidewalks, or parking lots, in the form of areal Shapefile data. Additional data is gathered searching websites of the NYC Department of Transportation (DOT), the Department of Information, Technology & Telecommunications (DoITT), and the NYC Department of City Planning (DCP). This includes information, such as speed limits, and pavement ratings, as well as guidelines with respect to the physical dimensions and used materials of streetspace objects. All data transformations and manipulations were performed using the Software ‘Feature Manipulation Engine’ (FME 2016.1). For storage, management, and integration of the large amounts of data generated, the open source geodatabase 3DCityDB Version 3.3 was employed. The actual implementation had to be based on the currently valid CityGML 2.0 Transportation Model but already considered suggestions made in the previous chapter of this article. The datasets contained in the Planimetric Database are delivered via an ESRI geodatabase in New York State Plane Coordinates, Long Island East Zone, NAD83, US foot. First, this data had to be transformed into the coordinate reference system (EPSG:32118) used by the mentioned project. Second, suitable test areas were selected in order to try out different implementation approaches with a manageable amount of data. The input data consisted of street centerlines with a large number of attributes, additional datasets containing further attributes for each centerline segment, and accurate areal data on multiple thematic features, such as roadbeds, sidewalks, or traffic islands (Planimetric Database). The main tasks are to integrate these data collections into one CityGML compliant dataset. Additional attributes like speed limits, pavement ratings, or number of lanes from mentioned datasets were matched to the already CityGML compliant centerline data via corresponding attributes, such as ‘street name’ or ‘segment ID’. The information contained in this ‘new’ centerlines dataset then was transferred to corresponding areal roadbed geometries using a spatial matching method. All available streetspace objects like sidewalks, parking lots etc. then were manipulated semantically and geometrically in order to achieve a detailed semantic 3-D streetspace model of the entire city. Due to the huge amount of data, multiple thematically divided CityGML files were generated for each streetspace object class respectively. These include 11 thematic object classes, such as roadbeds, sidewalks, or parking lots, with a total of 508,660 streetspace objects, each one assigned to the most appropriate of the 3 possible subclasses Road, Square, or Track. In addition, LoD2 Building models provided by the NYC DoITT are enriched with semantic information by assigning attributes from other datasets to building objects via corresponding ‘building identification numbers’. All generated CityGML objects as well as their respective data sizes are listed in

Table 3. Summary of all CityGML objects generated.

CityGML Class	No. of Objects	Data Size (Compressed. zip)
Curb	126,626	2.02 GB
Parking Lot Entrance	24,185	5.5 MB
Intersection	22,854	7.9 MB
Grass	258	0.3 MB
Road Marking	7826	3.9 MB
Dividing Strips	8841	74.8 MB
Roadbed	72,580	134.9 MB
Sidewalk	169,056	1.3 GB
Parking Lot	19,951	32.2 MB
Plaza	1360	5.5 MB
Interior Sidewalk	6205	15.8 MB
Building	>1,000,000	2.4 GB

.

The CityGML datasets generated were further processed. Using the 3DCityDB, KML-/COLLADA-files and corresponding spreadsheets were generated for each thematic class individually in order to integrate semantic and geometric information in terms of a tiled KML visualization model. This was achieved using the 3D-Web-Map-Client and visualized with the open source ‘WebGL Virtual Globe Cesium’.

In order to implement a more accurate semantic decomposition of individual streetspace objects, a smaller area was selected, and the data structure of this excerpt was adjusted by introducing TrafficAreas and AuxiliaryTrafficAreas, thus further specifying individual streetspace objects and generating a LoD2 streetspace model. In order to express affiliations to top-level features, each object is linked to superordinated Road, Square, or Track objects. Additionally, all objects are enhanced with suitable textures to accomplish a more realistic visualization. Being based on CityGML 2.0, the section/intersection concept introduced earlier could not be implemented explicitly yet but was already taken into account by creating individual Road objects for each section/intersection based on the suggestions made in Section 5, thus proving the practicability of the concept. Figure 9 visualizes the data structuring of this excerpt CityGML file.

Sub-level features, such as individual TrafficAreas or AuxiliaryTrafficAreas, belong to certain top-level features like Road or Square. While object classes like ‘Plaza’ (yellow Nr. 1, 2, and 3) or ‘Parking Lot’ (yellow Nr. 4) belong to Squares, Roads are composed of streetspace objects such as ‘Roadbeds’, ‘Sidewalks’, or ‘Dividing Strips’. There are two different types of Road objects represented, namely road sections (red Nr. 1, 2, 4, 5, 6, 8, and 9) and intersections (red Nr. 3 and 7), each identified by a respective citygml_function attribute. This dataset was recently used to generate data according to the CityGML 3.0 Transportation model structure presented in Section 5. This was achieved by applying the general GML Writer adding the GML Application schema of CityGML 3.0 as .xsd file using the software FME. The resulting data can be found on the respective GitHub page (https://github.com/tum-gis/cityGML 3.0-transportation-examples).

Until now, all streetspace objects have a base height of zero meter. Using height information provided by a digital elevation model (DEM), objects within the smaller area described earlier are adapted to the terrain. The 1-foot resolution digital elevation model used for this example is also provided as ‘GeoTIFF’ image by the New York City Open Data Portal. In order to generate geometries valid according to ISO 19107 [32], a triangulation method is implemented in FME. The procedure to adapt streetspace objects according to the terrain is visualized in Figure 10.

First, the height information contained within every pixel of the image is transformed from feet to meter. Then a 3-D surface model is generated from the image. The boundary lines of all individual streetspace objects are then generated and draped over the created surface (Figure 10a). Next, a new digital elevation model is generated by incorporating the created object boundaries as hard break lines into the surface model (Figure 10b). In the last step, thematic attributes are assigned to each individual triangle generated. This leads to the result shown in Figure 10c. Ideally, one TriangulatedSurface geometry per semantic object should be generated. This way, the digital elevation model could be substituted by individual triangulated surfaces each assigned to specific thematic objects. The result is visualized using the 3DCityDB Web-Map-Client. Changes in the height of individual street objects are visible. Robles-Ortega et al. [78] present a related approach to generate sloping streets using polygonal surfaces and TINs. Figure 11 shows an area in front of the Flatiron building in more detail. Individual streetspace objects, such as roadbed or sidewalk, are presented. In this example, a roadbed object is selected and thus highlighted in yellow. Object-specific attributes, such as street name or function, are immediately displayed. Raised objects, such as sidewalks or curbs, are represented with a vertical offset of 6 inches, and traffic islands and separating strips between two driving lanes are raised by 12 inches. This generates a realistic 3-D streetspace model. Among other improvements, intersections are represented as separate non-overlapping features containing information on all intersecting street names. The presented XLink concept was not yet implemented. Please note that this road space model is not the result of a procedural generation but reflects the exact layout of the real streetspace of New York City. Hence, it can be used for quantity take-off (e.g., paved surface area of Broadway) or measurement tasks. An extensive description of the project, including a detailed explanation of the implementation method, can be accessed on the project’s Wiki (https://wiki.tum.de/display/gisproject/3D+City+Model+of+New+York+City). All FME Workspaces created in the course of the project can be downloaded on the corresponding GitHub (https://github.com/tum-gis/3d-model-new-york-city). As mentioned earlier, all CityGML compliant data for the entire city as well as the semantically more detailed excerpt can be downloaded from the project’s website.

6.2. Melbourne

Concepts for streetspace models demonstrated in Section 6.1 can be transferred to other cities, given they provide similar data sources. The city of Melbourne also provides open data on streetspace objects for the city center (https://data.melbourne.vic.gov.au/Assets-Infrastructure/Road-segments-with-surface-type/su97-b2at). Similar to the process described in Section 6.1, FME can be used to generate CityGML compliant data. The original dataset contains polygonal 2-D shapefiles representing different types of surface information, such as carriageways, footpaths, intersections, parking bays, road curbs, or tramways. The data also contains many attributes, including condition (pavement rating), average width, length, or surface material. In combination with datasets, such as ‘road corridor’, ‘street furniture’, or ‘street names’, a detailed streetspace model can be created. The ‘road corridor’ dataset represents entire road segments and is therefore suitable to be transformed into CityGML sections as described in Section 5. It also contains an attribute on adjacent streets for each segment. This information can be used to determine dead ends. Figure 12 shows the first results of the generated streetspace model. Even though the procedures to derive CityGML streetspace objects from open data shapefiles are very similar for both New York City and Melbourne, entirely new FME Workspaces had to be created due to differences in data structure or available attributes. However, it is worth the effort, since models in the CityGML-format can directly be used for several applications (see Section 7). Guidelines on how areal information on streetspace should be recorded (segmentation, attributes etc.) will lead to standardized source data, which then could be more easily used for applications presented in Section 4. While the models of New York City and Melbourne were both created with source data derived from areal images, Section 6.3 describes how mobile mapping data can be used to generate highly detailed streetspace representations.

6.3. Grafing Near Munich

The work of Coduro [79] shows a third example for the consistent integration of street data in the CityGML format. For the experiments, datasets were provided by the company 3D Mapping Solutions GmbH, which utilizes mobile mapping systems to acquire high-resolution data of streetspaces and derive highly accurate maps (HD Maps) from it (for example, in the OpenDRIVE format). Data from the city of Grafing near Munich served as an example data set. The area around the city’s market place was surveyed kinematically by the company 3D Mapping Solutions GmbH in summer 2017. The total length of the axes is 1.8 km. The area contains 4 crossing areas, 12 street elements, and numerous streetspace objects. In connection with a project of the company CADFEM and its subsidiary virtualcitySYSTEMS GmbH and the city of Grafing, a semantic, CityGML-based 3-D city model was created. While the building model was provided by the Bavarian Agency for Digitisation, High-Speed Internet, and Surveying (LDBV), the textures on the building surfaces were applied by virtualcitySYSTEMS using oblique aerial images. First, methods were developed to convert road space data into a semantic 3-D streetspace model. These methods were then examined using a conversion of mobile mapping data prepared for the OpenDRIVE format into the CityGML format as an example and implemented in practice using the Grafing test area. This workflow was integrated to a production process for generating CityGML and OpenDRIVE data simultaneously from a common data source. The result of the practical implementation is a CityGML-compliant virtual semantic streetspace model, which is based on lane and object data captured by mobile mapping. The detailed streetspace model is textured and consists among others of lanes, green areas, parking areas, traffic signs, and trees. The combination of this streetspace model with existing LoD2 building models resulted in an integrated virtual city model. The final visualization in the Cesium-based 3DCityDB Web-Map-Client enables the linking of detailed highly accurate street data and the virtual 3-D building models. In addition to the visualization, the web client can be used for queries and streetspace analyses, such as the selection of roads with a certain speed limit. The streetspace data gain additional clarity due to the realistic area-based presentation in CityGML, as can be seen in Figure 13. Additionally, traffic flow data provided by the company OBERMEYER Planen + Beraten was visualized using car models. An animation of the simulation results can be viewed interactively (https://wiki.tum.de/display/gisproject/Online+Demo+Collection).

6.4. Complex Intersection in Ingolstadt Derived from OpenDRIVE Data

Schwab et al. [8] showed how to transform parametric OpenDRIVE data into areal CityGML compliant data using the Open Source transformation software r:trån (https://github.com/tum-gis/rtron). The result is visualized using the 3DCityDB Web-Map-Client and is shown in Figure 14. This is demonstrated using OpenDRIVE data (provided by 3D Mapping Solutions) of a complex intersection in Ingolstadt. Using FME, the generated CityGML data is further transformed into non-overlapping geometries and adapted according to semantic concepts described in Section 5. Each TrafficArea is part of a corresponding Section or Intersection object. Additionally, information on (multiple) function(s) as well as information on corresponding OpenDRIVE reference lines is stored within each TrafficArea. Markings are modelled as independent class and visualized within a separate layer on top of other streetspace objects.

6.5. CityGML 3.0 Concept Demo for an Area Around TU Munich

Figure 15 illustrates a demo visualizing some concepts of the proposed CityGML 3.0 transportation model presented in Section 5. The demo was created by digitizing streets around TU Munich from a TrueDOP20 with lane-level accuracy. The digitized data was then transformed to CityGML-compliant data using FME and visualized using the 3DCityDB Web-Map-Client. The demo includes TrafficSpaces as volumetric and TrafficAreas as linear and areal representations in granularity = lane.

7. Application Examples

As already explained in Section 4, digital city models and especially detailed areal representations of the streetspace can be useful for a variety of different applications. Some of these use cases, such as solar irradiation analyses, traffic simulations, or land use management, have already been tested using the generated streetspace models presented in Section 6. The first results of these tests are presented in this section. While most applications are demonstrated using the streetspace model of NYC, the models of other cities presented earlier are also suitable for those applications. Using the Web-Map-Client Pro (developed by the Chair of Geoinformatics at TUM), extended analyses, land use management, or city planning can be performed. The streetspace model of New York contains a huge variety of semantic information, such as street names, number of driving lanes, street area in m², or information on road surface conditions. These attributes can be queried in different combinations and thus be used for gaining additional information. First, all traffic areas (roadbeds and intersections) belonging to 5th Avenue are selected. By summing up all corresponding ‘area_sqm’ values, the total traffic area in m² of 5th Avenue is calculated. Then, making use of information on street pavement conditions (rated with 1–3 = BAD, 4–7 = FAIR, 8–10 = GOOD), all roadbed objects (of 5th Avenue) with a street pavement rating of 6 (lowest existing value) are selected. By calculating the total area in m² of the selected roadbed objects, assumptions on potential future repair costs can be made. Note that not all roadbed and intersection objects contain information on pavement ratings. The results of this calculation for 5th Avenue are:

• Total roadbed area: 273,198 m².
• Total intersection area: 156,085 m².
• Pavement rating = 6: 43,395 m².
• Pavement rating = 8–10: 136,322 m².

Detailed information on the areal extents of street and sidewalk surfaces in combination with vegetation and street furniture objects can be used for clearance space analyses. In Germany, for example, the space up to 4.5 meters above road surfaces should be clear of any potential obstacles. For sidewalks, this value is set at 2.5 meters. These spaces can easily be created once the exact surface geometry is available by extruding the ground surfaces of respective streetspace objects (cf. Figure 15). The NYC 3-D street model was also used to derive input datasets for the micro traffic simulation software Vissim. This software is used for microscopic behavior-based traffic simulations in order to analyze and optimize traffic flows [21]. Ruhdorfer [22] showed how to transform geometric, semantic, and topological information contained in the CityGML datasets into the Vissim-specific format. This data is then used to perform traffic simulations. Finally, the produced simulation data was transformed to time variable KML/COLLADA/glTF data that can be visualized in GoogleEarth or the 3DCityDB Web-Map-Client. Figure 16 illustrates the results of this process. The left part of the image shows a zoomed-out visualization of moving red dots, symbolizing moving cars. A higher resolution visualization on the right section of the graphic illustrates detailed car models used to represent traffic movement within the city model. The same visualization of dynamic traffic movement was realized for the model of Grafing near Munich shown in Figure 13.

Schwab et al. [8] used the model of a complex intersection in Ingolstadt shown in Figure 14 for generating a simulation scenery layout used by the pedestrian behavior simulation framework momenTUM [80]. Information on surfaces preferably used by pedestrians, such as sidewalks or crosswalks, in combination with obstacles, such as buildings, vegetation, or city furniture, is used for generating a navigation graph for route finding, whereas the edges follow a risk-based weighting. An edge located on a roadbed surface will have a higher risk-weighting than an edge located on a sidewalk. This information is derived from the CityGML function or usage attributes contained within individual TrafficAreas of the presented model. After simulating these scenarios, the simulations results are visualized using the detailed streetspace model.

Until now, solar irradiation analyses are mainly performed for buildings in order to estimate solar energy production potentials. However, this could also be used to simulate urban or local heat island effects caused by solar irradiation. Bornstein [81] discussed the urban heat island effect in New York City showing significant differences in temperature in and around the urban area of the city. Willenborg et al. [2] presented a method for large-scale solar potential estimation based on semantic 3-D city models given in CityGML. This tool is now tested using LoD2 Buildings in combination with areal streetspace objects, estimating global, diffuse, and direct irradiation. Figure 17 shows the result of this solar irradiation simulation. The city model is textured according to global irradiation values (kWh/a), ranging from blue (low irradiation values) over green to red (high irradiation values). This type of visualization is useful for quick and intuitive analyses of suitable areas to install photovoltaic systems or, in the case of streets, to locate local heat islands or shady places [82]. In order to allow more profound analyses, all calculated irradiation values as well as attributes, such as a ‘Sky View Factor’ (SVF), are also stored as attributes for each individual city object. As an example, the maximum SVF for three selected locations (open plaza (1), roof of Flatiron Building (2), backyard parking lot (3)) is shown. Bui and White [83] conducted related research by calculating the length and shape of shadows cast by buildings in New York City for different times during the year. The streetspace models of New York City (including solar potential analyses), Melbourne, Grafing (including traffic simulation), Ingolstadt, and the CityGML 3.0 concept demo around an area of TU Munich can be explored interactively via the following link (https://wiki.tum.de/display/gisproject/Online+Demo+Collection). Data of the streetspace models of NYC and Melbourne can be downloaded on the project’s Wiki page (https://wiki.tum.de/display/gisproject/Download+Section).

8. Summary and Outlook

This paper discussed a range of applications that require detailed 3-D representations of the streetspace. In order to cover the requirements imposed by a multitude of use cases, extensions and improvements to the CityGML Transportation Model for the detailed spatio-semantic representation of the streetspace were made. Transportation objects like roads, railways, tracks, and waterways can now be represented in three thematic granularities, and each in up to four different levels of geometric detail (LoD 0–3). In the new model, each level of granularity can have a linear, areal, volumetric, and point cloud representation. While granularity = area consists of a thematically undifferentiated representation of the streetspace, in granularity = way, the street surfaces are partitioned into roadbed, pedestrian walkway, etc. to represent individual carriageways. In granularity = lane, individual driving lanes are semantically and spatially separated, making these datasets usable for vehicle navigation and detailed traffic simulations. Holes in an objects surface, e.g., to model gully openings, road damages, or manholes, are introduced. Similar to Holes, Markings can span over multiple (Auxiliary)TrafficSpaces and thus are modelled as an individual class. Sections and Intersections are represented explicitly, allowing modelling of a street as one Road object consisting of Sections and Intersections, which are sub-classified into different types. Furthermore, 3-D volumetric geometries can represent traffic and clearance spaces above traffic surfaces. Newly introduced Waterways allow the representation of maritime traffic. The introduction of a predecessor/successor concept provides the possibility to represent traffic logics. Some of the described concepts are demonstrated by the detailed representation of the streetspace for New York City. This 3-D model was generated using multiple datasets from the NYC Open Data store and is provided in CityGML on the project homepage. Additionally, a number of different applications for detailed streetspace models were tested and analyzed. Furthermore, streetspace model demos for Melbourne, Grafing near Munich, a complex intersection in Ingolstadt, and an area around TU Munich were generated.

In the future, very high-resolution information on streetspace, derived from mobile mapping/laser scanning data, could be used for detailed representations of streetspace. Additionally, laser scanning point clouds could be transferred to semantically enriched CityGML data for analyses or visualization purposes. Large 3-D point clouds already can be visualized by transforming the data into 3DTiles (https://www.ogc.org/standards/3DTiles). This enables the immediate comparison of point cloud data with individual buildings or entire city models. One of the reasons why New York City was chosen to generate a detailed city and streetspace model is the availability of extensive open (geospatial) data. An increasing amount of data and information is also available for cities in Germany. How this data can be used to generated detailed (streetspace) models of German cities will be subject of future research projects. Standardized ways of gathering streetspace data for both linear and areal representations would make it easier to create usable models. Missing linear referencing concepts for CityGML are also part of future research.