A PROPOSAL FOR AN IMPROVED TRANSPORTATION MODEL IN CITYGML

: CityGML, an OGC standard, is an open data model for virtual 3D city models and includes buildings, roads, terrain, water bodies, etc. While many modules are well-developed (eg buildings, bridges, tunnels), the transportation model is, based on our consultations with various government agencies and municipalities, not sufﬁcient for most transportation applications. We propose in this paper several improvements to the CityGML v2.0 Transportation module, and to the previous efforts for improving it. Our additions are based on the consultations we had, and on the use-cases that were identiﬁed. We argue that the following changes are necessary: A) multi-LoD modelling of roads, B) carriageway representation, C) detailed intersection modelling and, D) introducing waterways as a new sub-class.


INTRODUCTION
CityGML is an open data model for the storage and exchange of virtual 3D city models.It is the international standard of the Open Geospatial Consortium (OGC, 2012).It defines the geometry, semantics and appearance of the most pertinent topographic objects in 3D (Gröger and Plümer, 2012).The Level of Detail (LoD) concept within CityGML is intended to discern multi-scale representations of semantic 3D city models from LoD0 -LoD4 (Biljecki et al., 2016).A model's LoD indicates its adherence to its realworld counterpart and this has consequences on its usability (Biljecki et al., 2016).CityGML is comprised of a core model and several thematic models including Building, Relief, Bridge, Transportation, Vegetation, and WaterBody.
The focus of this paper is the transportation module which we argue has several shortcomings in CityGML version 2.0.First, the network representation only supports one LoD (LoD0) and they are not related to the surface representation at different LoDs.Second, the LoD specification in CityGML does not differentiate between LoD1, LoD2, LoD3 and LoD4 and finally, it does not specify how to model intersections and roundabouts.This limits the usability of CityGML within certain transportation applications and doesn't align with LoDs present in other CityGML modules.
To meet some of these shortcomings, Beil and Kolbe (2017) propose an improved specification (Section 3).Based on a survey we conducted (Section 4), we found that their approach does not yet meet the LoD requirements of road maintenance authorities, i.e. as a hierarchy from complete roads, to carriageways to lanes.This paper builds on the work of Beil and Kolbe (2017) and proposes further improvements to the transportation model, namely A) a multi-LoD approach for road modelling, B) extending the definition to include road, carriageway and lane modelling, C) introducing a class for modelling intersections (including roundabouts) and D) introducing waterways into the transportation model.This work was carried out with consultations of various government agencies from which user needs were determined based on identified use cases.

The Many Applications of Transportation Models
There is a breadth of research and literature related to the applications of roads in 2D (Xie and Levinson, 2009).There are many common applications such as urban traffic modelling (Bazzan et al., 1999), cycle accident analysis (Greibe, 2003), and vehicle routing (Pillac et al., 2013).Waterway modelling is also an essential aspect of transport modelling, such as understanding the risk and the probability of an accident occurring (Roeleven et al., 1995) or vessels colliding (Montewka et al., 2010).Modelling roads and waterways together is also advantageous for applications such as cost analysis of utilising inland waterways vs. roadonly transport (Wiegmans and Konings, 2015).There is also a specific focus on government needs in road modelling due to their crucial role in road maintenance including de-icing, weed control, road markings and road lighting (Spielmann and Scholz, 2005), as well as canal maintenance with transport flows, drainage, freshwater supply and hydrology management (van Loenen et al., 2014).
Further applications are being developed within the 3D realm, one such application being the utilisation of 3D road networks for the optimisation of the routing network for waste collection and transportation (Tavares et al., 2009).The addition of 3D allowed the model to integrate the effects of road inclination and vehicle weight in order to optimise for minimum fuel consumption which resulted in lower costs than traditional shortest route approaches (Tavares et al., 2009).Law et al. (2011) describes the limitations of 2D noise mapping and explains the need for 3D roads and buildings for decision-making and stakeholder involvement, citing the complexity in the proximity of sky-scrapers and roads in Hong Kong.Kwan and Lee (2005) utilise ground transportation systems within a real-time 3D GIS quick emergency response system to facilitate easier navigation.
The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLII-4/W10, 2018 13th 3D GeoInfo Conference, 1-2 October 2018, Delft, The Netherlands There are many potential applications that require 3D road data to be included in a city model, these range from assisting in dayto-day municipal management, environmental modelling, urban planning and of course driving (Table 1).Biljecki et al. (2015) presents at least 29 use cases within more than 100 applications where 3D city models are utilised.Coupled with the knowledge that the number of national mapping agencies producing 3D data is increasing (Stoter et al., 2015) there is a need to ensure that government agencies can A) successfully integrate transportation elements within their 3D city models, B) continue to use the transportation elements in existing use cases and, C) explore new applications and opportunities by modelling transportation elements within 3D city models.

Transportation Modelling Standards
Transportation modelling is a large field of study and there exist several major standards.While the primary focus tends to be in the realm of network representation the standards nevertheless provide a crucial understanding in terminology, accepted practices and user and application needs.
Geographic Data Files (GDF) is an international standard under ISO 14825 designed to meet the requirements of roadtransport-related applications (ISO, 2011).GDF supports, within its framework, three levels referred to as Level-0, Level-1 and Level-2 (ISO, 2011).At the first and most basic level is the presence of the essential components of a road network: Node, Edge and Face; simple features (point, line, or area) are supported at Level-1, and complex features (aggregations of simple features) exists at Level-2 (ISO, 2011).While the majority of the standard and its applications exist in the realm of 2D, there is still support for various levels of 3D modelling such as elevation values representing the terrain height and the horizontal position of the minimum and maximum height above the terrain (ISO, 2011).It is mainly used by commercial mapping companies for navigation and is not designed to be integrated with larger city models.OpenDrive is an XML-based file format used by many driving simulation practitioners (VIRES, 2015a).The tiles are designed in order to describe entire road networks and include all data that belongs to a road environment (VIRES, 2015a).
There is no concept of LoD in OpenDrive because Open-Drive is designed specifically for traffic simulations, an application where the required information is clearly defined.
There is however the concept of beads which is a hierarchy of information at various levels with parent and children beads that guides which information can be included and under which section (VIRES, 2015b).OpenDrive follows cartesian x y z coordinates for the nodes of its graph and does have support for 3D elements; it accounts for situations such as curves where roads are elevated to one side, or elevation changes due to drainage (VIRES, 2015b).
LandInfra, Land and Infrastructure Conceptual Model (LandInfra) was designed for land and civil engineering infrastructure facilities (OGC, 2016).It is an OGC standard (conceptual data model) implemented with GML (in InfraGML) and supported by a UML conceptual model (OGC, 2016(OGC, , 2017)).
One of the features that it defines is the concept of the road Feature which is defined as a single segment of a road that is continuous, non-overlapping, and non-branching (OGC, 2016).A road Feature is a collection of zero or more elements such as pavement layer, sidewalk, etc. (OGC, 2016).
There is support for 3D road elements, 3D string lines to represent things such as profile views, longitudinal breaklines and long sections, and 3D surfaces and layers (OGC, 2016).There is no defined road LoDs within the standard.
OpenStreetMap (OSM) is a free, editable map of the world that is built by volunteers and provides free access to map images and underlying map data (Wiki, 2017a).Roads in OSM are covered by the feature Highways and includes any road, route, way or thoroughfare on land that connects locations to one another (Wiki, 2017b).The main focus of the Highway feature is to capture tags and therefore information about lanes, width, etc. are recorded within the attributes instead of with geometry (Wiki, 2017b).There is the concept of LoD in OSM but it is explained as a useful feature to rate how thoroughly a feature has been mapped and not as a comprehensive set of guidelines (Wiki, 2011).The concept is also guided mainly by attributes and not geometry and provides the possibility for n levels of detail (Wiki, 2011).
RoadXML is an XML file format that contains multiple layers of data that is designed in order to fulfil the needs of many driving simulation applications (Ducloux et al., 2004).The four main layers of information are topological (location and connection within a network), logical (significance in a road environment), physical (road surface of obstacles) and visual (geometry and 3D representation) (RoadXML, n.d.).Each layer is a Sub-Network which is a collection of Tracks The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLII-4/W10, 2018 13th 3D GeoInfo Conference, 1-2 October 2018, Delft, The Netherlands linked by Intersections, Tracks are enhanced with different types of data such as a road profile to define the pavement surface, road signs, traffic and 3D descriptions (Ducloux et al., 2004).It does not have an LoD concept.
A review of the current standards leads us to the following conclusions, A) there is no well established concept of LoDs for roads, B) there is an overwhelming focus on network representation and, C) integration of roads within a wider city model is not always a consideration.Furthermore, the standards are often tailored towards a specific application only, e.g.driving simulation, or the focus is on visualisation or data standardisation.These conclusions indicate that CityGML may be a good solution for addressing the shortcomings of the other standards and ensuring the usability of roads within 3D city models.

Outstanding Issues
While Beil and Kolbe (2017) provide a much-needed extension and clarity to the Transportation Model in CityGML 2.0 there is still room for improvement.Based on conversations with government practitioners who are eager to integrate their road data within 3D city models, there were several needs identified that would make the Transportation Model more suitable for different applications.The following summary highlights limitations within Beil and Kolbe (2017) while Section 4 describes further needs.
Edges and Nodes: While network representation has been extended to include representation at higher LoDs, the limitation is not limited to points and lines only and includes the entire gml::GeometricComplex which can lead to confusion.
Parking Lots: The inclusion of parking lots in the Square representation type along with plazas is not useful for most road modelling applications where the two have distinctly different transportation patterns and traffic flows.Petrol stations have a similar modelling need.
Holes: It is unclear why the class Holes, i.e. drain, roadway damage and manhole, is represented at LoD3, where for many practitioners holes can be an important aspect with LoD1 roads where polygon representation is already supported.

Sections:
The code list for the Section Attribute 'class' is named RoadSection but it contains attributes for railroad and track as well.
City Furniture: Can Sections also support road city furniture?
Tracks: The name of the sub-class 'Tracks' is confusing because the terminology is usually utilised for describing railways which are described as composed of 'tracks'.

NEEDS ANALYSIS
The number of national mapping agencies producing 3D data is increasing (Stoter et al., 2015) thus understanding the application needs of government agencies is an important aspect in ensuring the usability of CityGML.This work was carried out through the consultation of various government groups in the Netherlands that work with roads in practical applications.Consultations occurred over multiple meetings with representatives from: • the Provincie Noord-Brabant, provincial government for the province of Noord-Brabant • Rijkswaterstaat, Ministry of Infrastructure and Water Management in the Netherlands • CROW, a non-profit knowledge partner for (decentralized) governments, contractors and consultancy agencies • Sweco, a European engineering consultancy company The following needs have been identified.
An issue consistently raised during the consultation process is the need for explicit acknowledgement of road vs. carriageway vs. lane representation (Figure 2).A road indicates the entire portion of a road that allows for traffic flow, a carriageway indicates the directionality of the traffic flow and a lane demonstrates the individual driving lanes available.This is an important element that should be used to differentiate between the LoD2 and LoD3 The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLII-4/W10, 2018 13th 3D GeoInfo Conference, 1-2 October 2018, Delft, The Netherlands representation of a road.Carriageways are an important consideration when determining road closures for maintenance as well as for modelling over-all traffic flow.Carriageways also assist in understanding the relationship between different thematic uses, such as the ratio of traffic flow in a specific direction between cars and bicycles, this is especially pertinent for urban planning in relation to planning future cycle lanes or pedestrian walkways.This leads into the second need which is the need for a dual modelling approach that includes polygon and line representation of a road network, as is also proposed by Beil and Kolbe (2017).This is required because many applications require both representation types and a linkage between the two is necessary to reduce mismatch between datasets and to ease the linkage between the two representation types.Additionally the two representation types often have different requirements.For example, in the province of Noord Braabant, the polygon representation is stored at 100 meter intervals as is determined by road milestone needs, while the line representation is determined by intersection or lane divisions.This multi-representation type can easily implemented with the proposal of Beil and Kolbe (2017) with the introduction of the Section concept.Additionally the model should allow for not only dual representation types but the storage of these at different levels of detail, for example polygon representation at LoD2 and network representation at LoD3 for the same transportation network with a linkage between the two.
For network road representation there is a need to define not only lines (edges) but additionally nodes which often represent various important aspects of a road.Nodes represent where roads intersect other roads, where roads merge, split or change direction and where there are changes to road attributes such as speed or asphalt type (which has an impact on noise production for example).Nodes do not only act as connections for edges but are often significant features within traffic modelling themselves.They help in determining if turns at intersections intersect as well as in calculations determining if heavy good vehicles or large goods vehicles can complete a specific turn.The representation of nodes means that a road network can be ready for direct use in many simulations where their presence is obligatory.
Another required element that came up in discussions the most was the concept of intersections and their intense complexity.Intersections are defined differently by different users.What is the same for all users though, is the need for intersections to be defined as a separate class that can be modelled in addition to the roads.This is so that intersection specific attributes can be supported by the model.Some applications require only the physical intersection area or a buffer of the intersection area and therefore the intersection class needs to be flexible and open to definition by various users.Additionally there are vast differences between cross-intersections or T-junctions and roundabouts, and further differences in equal level versus different level cross sections.Intersection classes allow data practitioners to link several different city object types (e.g.lamp post) to specific intersections.This is crucial for city road maintenance which is often conducted by maintaining roads, green spaces and transportation objects (street-lights, sign post, milestones, etc.) in collective time blocks, i.e. replacing/repairing all city objects within an intersection at the same time.Intersections are also an important component of waterway modelling where intersections are often found to increase the risk of collision (Debnath et al., 2011).Intersections need a further element to increase their purpose and this is known as a stop line, the specific spatial point where traffic must stop for a traffic light or stop sign.Given the complexity of defining exactly what an intersection is, a stop line is one element that focuses specifically on providing clarity around traffic movement specifically, i.e.where exactly in the large physical space of an intersection is traffic regulated (Figure 3).The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLII-4/W10, 2018 13th 3D GeoInfo Conference, 1-2 October 2018, Delft, The Netherlands canals or other waterways is clearance space (i.e.under bridges), this concept is included as a proposal by Beil and Kolbe (2017) which can facilitate the smooth inclusion of waterways within the Transportation Model.
Lastly, parking lots and gas stations are unique transportation objects because they both facilitate transportation on their surface but the transportation flows have unique and different movements.Therefore there is a need for them to be defined in a unique class.They would be better represented as a separate subclass that account for their difference from roads and plazas.

GOVERNMENT USE CASES
The use cases were identified during the course of the needs analysis and a large portion are not supported by the current data structure of Transportation in CityGML.With the proposal of Beil and Kolbe ( 2017) and the addition of our work, the data structure would be fit for usage in all of the use cases identified.Table 2 summarises the use case, the issues associated with CityGML 2.0 and the additions that were required.

DATA MODEL
The following changes or inclusions are proposed to enhance the proposal of Beil and Kolbe (2017).The numbers correspond to the changes as visualised in Figure 6.Further additions not visualised in the UML are: • Add waterway segment to the codelist of RoadSection Attribute 'class' and rename the codelist to Section.• Add waterway segment to the codelist of the ClearanceSpace Attribute 'class'.• Add links to which city furniture is in a Section, supported via x-links.

PROPOSED REFINEMENTS OF SPECIFICATIONS OF ROAD LODS
In addition to the changes to the data model, the following refinements are proposed for the specification of the LoDs for roads.
• Make the presence of nodes explicit for LoD1 -LoD3 network representation.• Differentiate further between LoD2 and LoD3 by introducing carriageway representation for LoD2 and lane representation for LoD3.• Allow for the representation of Holes, and other "damage" attributes, from LoD1 -LoD3, because the main differentiation for road LoDs should be based on lane representation and thematic classes.Holes are a separate feature that is also represented as a gml::MultiSurface and can easily be integrated with LoD1.Future work can examine the potential need to define a separate set of LoDs for Holes.
These changes also facilitate the ability to describe roads as multi-LoD objects where the first value refers to its polygon representation (i.e.lane vs. carriageway, vs. road representation, see Figure 2) and the second to its network representation (Figure 4), e.g. a road model of LoD2.3 indicates that the polygon representation is at LoD2 while the network representation is at LoD3 (Figure 5).Many road maintenance applications can be conducted with LoD1 or LoD2 polygon representations (e.g.deicing) but require LoD3 network representation for the routing of maintenance vehicles.This approach also aids in linking data from different providers or where issues of data quality dictate that it's better to store certain error-free data at a lower LoD than at an erroneous higher LoD.This is not to be confused with the LoD approach of Biljecki et al. (2016) where the second value indicates increasing level of detail within a LoD family group.

CONCLUSION AND FUTURE WORK
CityGML as an OGC standard provides the opportunity to contribute to its further development and improvement, providing a collaborative approach.The authors hope that their work can add on to the work of Beil and Kolbe (2017) and together the implementation can be incorporated into CityGML 3.0.
Clarity around the various LoDs of roads assists in their integration and usage within 3D city models.Future work will focus on understanding the impact of different road LoDs within applications and how this can guide the decision-making process of data users.Furthermore, generating 3D city model data continues to be a tricky task, but generalisation can provide a potential solution thorough its approach of generating lower LoDs from higher LoDs (Labetski et al., 2017).A clear distinction between road LoDs facilitates the study of generalisation for roads in the context of 3D city models where the aim should be a harmonious generalisation that accounts for the presence of various city objects including buildings, roads and terrain, etc.
The modelling of waterways as transportation objects is an interesting component to examine further in future work.Future lines of inquiries can examine the possibility of modelling ports as an independent class, as well as the relationship between the WaterBody thematic model and the Transportation model, especially for elements such as ferry and shipping routes.Additional features like locks are important as well as understanding how to integrate waterways with the Bridge model in CityGML to include an understanding of opening and closing bridges.
Lastly, railroads were not seriously considered for this paper and it would be important to examine if there are specific needs that are required for modelling railroads efficiently within CityGML and whether some of the work by Beil and Kolbe (2017) and our work can be applied toward railroads.
The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLII-4/W10, 2018 13th 3D GeoInfo Conference, 1-2 October 2018, Delft, The Netherlands 3. CITYGML 2.0 LIMITATIONSThe current implementation of the transportation model in CityGML 2.0 includes four sub-classes: Road, Track, Railway and Square.For Roads the LoD specification is limited to a network representation at LoD0 and a multi surface representation for LoD1 -LoD4 and there is no distinction provided between LoD2 -LoD4.The focus of the transportation model is not volumetric but instead about the integration of the transportation system within a 3D city model.Beil and Kolbe (2017) provide a detailed and comprehensive list of the limitations of the transportation model as well as their suggestions of how to improve it (Figure1).Their proposal models Transport as linear representations for LoD0 to LoD3 (for the network) and as related space representations for LoD1 to LoD3.Starting from LoD0 (line) and LoD1 (space), the road represents the entire width of the road.LoD2 models a more detailed segmentation into TrafficSpaces and AuxiliaryTrafficSpaces, while LoD3 additionally allows the representation of subtle structures such as manholes or roadway damages.They remove LoD4 for roads, given that LoD4 is for the representation of interior structures in buildings and its application for roads is nonsensical.

Figure 1 .
Figure 1.The refinement of road LoDs as proposed by Beil and Kolbe (2017).

Figure 2 .
Figure 2. The difference between a road, a carriageway and a lane.Arrows indicate the flow of traffic.

Figure 3 .
Figure 3.The illustration of a stop line in an intersection.Stop lines shown coloured in red.

1.
Change the <Geometry> of Network representation from gml::GeometricComplex to be gml::Point and gml::LineString.This reduces the representation to edges and nodes only.2. Add <FeatureType> MotorSquare to account for parking lots, parking squares and gas stations.3. Add <Geometry> WaterWay to account for water transportation routes such as canals.4. Rename <Geometry> Track to Trail which better describes its representation.5. Add <Geometry> StopLines to record the location of stop lines within an intersection.6. Add <FeatureType> Intersection to be an abstract class for describing the geometry of an intersection as well as which TrafficSpace, AuxiliaryTrafficSpace, StopLines and city furniture it contains via x-links.7. Add a code list for the Intersection Attribute 'class', from S ¸erbu et al. (2014) 8. Change the <FeatureType> of Hole to lod1MultiSurface.9. Add multiplicity to the network representation type, and set it to 0 to many (0...*).

Figure 4 .
Figure 4. Our proposed refinement to the network representation of roads in CityGML.

Figure 5 .
Figure 5.An example of mixed-LoD modelling of a road section in the Province of Noord-Brabant, with the polygon representation at LoD2 and the network representation at LoD3.

Figure 6 .
Figure 6.The proposed additions to the data model for CityGML's Transportation model based on Beil and Kolbe (2017).