Technological Forecasting & Social Change

Urban areas are currently facing new and enormous challenges: urbanization, connected and automated land and air transport with new demand for transport and logistic services, maintenance of more complex tra ﬃ c and supply infrastructure as well as mandatory digitalization of cadastral information under the constraints of limited space and resources. Di ﬀ erent stakeholders are interested in using detailed, precise and up-to-date data about the urban environment. These stakeholders are not only governmental bodies, road operators and (public) ﬂ eet managers but also companies that are interested in testing and operating new intelligent transportation systems and connected and automated vehicles in realistic and complex urban simulation environments. This article proposes a concept of how to tackle this complex task based on approaches already conducted in the domain of the development and test of automated driving and city modeling. Core elements of this thesis are an all-embracing geo-database, a toolchain to import, validate, process and fuse the necessary data as well as interfaces and data formats for automated data exchange. The feasibility and challenges as well as the potential and synergies of implementing of this concept are discussed by analyzing similar solutions in the key domains. The article concludes with a proposal to realize such a concept.


Introduction
Today, 54% of the world's population lives in cities with further 2.5 billion people by 2050 according to the United Nations (United Nations, 2014). Therefore, modern society is facing many new challenges (EYGM Limited, 2015). This applies in particular for the housing situation and its required improvements as well as for transportation and mobility needs directly interconnected to it. These two seem to cause conflicting interests since they occupy overlapping space. Moreover, because on the one hand, extremely high population density demands for individual transportation besides public transport, traffic, on the other hand, is a thread to inhabitants by air and noise pollution (Matsuda and Ma, 2018). Therefore, the traffic area appears to be the sticking point when organizing further urbanization. This, in turn calls for an effective and almost failure free planning strategy covering all stakeholders and their respective data needs.
Limited urban space is not only used for private transport, but also for delivery and pickup as well as for parking, for loading and unloading, and for waiting (Aiura, 2005). Another important factor is the need for additional space for cycle tracks. Hence, it becomes apparent that the current infrastructure, mostly planned and built in the 19th and 20th century, is not able to meet all these new requirements.
Next to infrastructure, also traffic itself needs to change in order to keep up with increasing traffic demand and with the aging society's changing transport needs. Traffic will be automated by further developments of current assistant systems to automated driving systems. Before that, transport will become connected where participants are interconnected in a so-called Vehicle-to-Vehicle (V2V) environment and also connected to the traffic infrastructure (a so-called Vehicle-to-Infrastructure (V2I) environment) to enhance traffic efficiency and safety (Kerner, et. al., 2010), (Weiß, 2011). It is expected that connected and automated vehicles (CV/AV) will mitigate the aforementioned problems (i.e. higher traffic demand, lack of space, and increase of emissions and pollution): firstly, the number of shared cars and rental services will grow, and new vehicle-sharing schemes will spread (Yang, 2013), (Ross, 2014). Automated cars could be called on-demand and leave when the driver is done with it, thus parking problems will vanish (Ross, 2014). Secondly, road capacity will increase (Pau, 2013), and therefore streets will narrow and cities will bulk up (Ross, 2014). Finally, CV/AV will help to reduce emissions. E.g. this could be achieved via a closed loop control system driven by bidirectional navigators using a vehicular cloud service (Pau, 2013). Moreover, CV/AV will improve safety and traffic flow because there will be less interruptions in traffic flow and less accidents (Pau, 2013), (Soubra, 2013), (Yang, 2013), (Ross, 2014).
Additionally, other communication participants such as connected fellow vehicles, in-vehicle so-called Internet-of-Things (IoT) devices (Guerrero-ibanez, et al., 2015), smart infrastructure elements like road side units (RSU), or the backend of a traffic management center could approach as well, which one may call Vehicle-to-X (V2X). The European Commission published a detailed and worldwide overview about automated and connected traffic and ITS in general in the final report of the study on "Public Support Measures for Connected and Automated Driving" (Medina et al., 2017).
Before automated driving functions will hit the market, they have to be tested in various situations and scenarios (Schöner, 2018) derived from the real world. For example, this technology is tested in real world environments such as the testbed in the city of Kassel, Germany where different traffic participants are connected to the road infrastructure (City of Kassel, 2019a). Car manufacturers such as Ford take the opportunity to test in different real world conditions, too (City of Kassel, 2019b). Most companies working on automated driving are building their map database on their own such as Waymo (Waymo, 2016). They currently drove the highest number of kilometers but still have to map each city on its own (Forbes, 2019).
Digitalization is integrated in more and more parts of our life applying trackers, nomadic sensors and smart meters summarized as Internet-of-Things (IoT) (Guerrero-ibanez, et al., 2015). Such a connected environment gives rise to advanced transport management strategies, e.g., the possibility to collect the amount of multi-source traffic data required to make accurate traffic predictions. This can be done by fast traffic simulations (e.g. using neural networks and machine learning) to evaluate traffic conditions for different traffic control strategies (e.g. different traffic signal settings, different route assignments) (Gora, 2017).
The Florida Department of Transport (FDOT) is already preparing for the expected rise of advanced traffic management strategies (Hadi et al., 2017) summarized as Intelligent Transportation Systems (ITS). Moreover, governmental bodies are already preparing the legislative and juridical basis and public support measures for CV/AV: After lobbying from Google's driverless car project (which is continued by Waymo (Waymo, 2016)), Nevada has passed first laws regarding autonomous vehicles already in 2011 (Luettel et al., 2012), and is continuously working on related Assembly Bill amendments (DMV Nevada, 2017). A good overview of autonomous vehicle legislation and the resp. legal foundation in the United States is given in (Swanson, 2014). Similar work has also been done in the European Union (Medina et al., 2017).
On the technical side, this all is stimulating further new approaches to efficiently improve travel quality (e.g. by aiming at optimum speed to ensure passage through the signals on green) while reducing the risk of collisions at the same time (Gora and Rüb, 2016). Additionally, they research for flexible control and management of transportation systems in real time to improve overall system performance (Sumalee and Ho, 2018). Moreover, connected transport will enable an intensified penetration of mobility as a service to request bigger and faster transport entities only on-demand. Thus, communication infrastructure needs to be deployed, either cable-based or wireless.
However, not only classical road traffic will be automated, but also light rail systems and robot fleets for commercial ground-based as well as airborne last mile transport will make this transition (Matsuda and Ma, 2018).
Next to the aforementioned space problems, energy supply and data communication infrastructure is facing important challenges due to the A. Richter, et al. Technological Forecasting & Social Change 155 (2020) 119970 need for distributed power supply or unforeseeable consequence of robot vehicles or intelligent infrastructure. It can be assumed that electrification of traffic will be increased not only for classic passenger cars and last mile commercial transport but for pedelecs, scooters and other electric personal assistive mobility devices (Brustein and Lanxon, 2018). Current energy infrastructure apparently is not ready for this change.
In contrast to a conventional urban mobility concept, a rising number of stakeholders will register interest in using the traffic area (e.g. smart mobility and parking, car and e-bike sharing) (RolandBerger, 2019) as well as the energy and data infrastructure (e.g. charging infrastructure, smart streetlights, waste and recycling management) (ScottMadden, 2017). These interests do not only include transportation issues. New stakeholders appear which aim at distributing and selling information about, e.g. events, locations and the traffic itself, and who even apply gamification methods (Zica et al., 2018). In the meantime, different stakeholders are monitoring, operating and managing the traffic area whereas others already plan its further developments (Homeier et al., 2017). Fig. 1 illustrates some of these new stakeholders in a potential futuristic scenario.
Until now, every traffic area stakeholder has driven its activities on its own or in small resp. limited activities such as research projects or testbeds (in Section 2 a more detailed look is taken on the key stakeholders). That leads to the situation that each participant collects or generates their required data on their own: public authorities doing it to manage their infrastructure, car manufacturers doing it to get ground truth (Waymo, 2016), and fleet operators may buy traffic and map data from map makers. Then these participants have to take care to update and extend their data pool on their own. Multiple efforts have to be spent for gathering the same data again and again. Additionally, the stakeholders storing it in different formats with different granularity and meta-information, which makes it very complicated to interchange the data. Also it is often very difficult to compare simulation results because of everyone taking a different dataset as initial scenario.
The overarching challenge for the integration of the aforementioned needs is to amalgamate all these interests and their underlying requirements. However, planners and public authorities do not always know prospective user's requirements and, therefore, have to response in a respectively short time. Moreover, during the process of planning, different data is used than for operations. This happens because infrastructure and its management evolved over centuries, indeed taking corresponding requirements into account. But often management and planning has not been fully harmonized to date. Merely using different ways of data storing causes inefficiencies in data transfer and usage and is, therefore, not capable of supporting the gaining speed of planning and operating in a sector with increasing complexity. The heterogeneous data availability, quality and usage are the starting point where a solution for complex planning and subsequent management processes has to be found.
In the domain of database management, avoidance of redundancies, which could lead to data anomalies is desirable. The normal forms (Kent, 1982) were developed to normalize the modeled data proposing for example atomic values, using primary and foreign keys and no transitive dependencies etc. (Date, 1999). This can be applied on spatial data, too (van Roessel, 2007). Database views are used to provide the data in a customer specific way without rearranging the underlying data. Thus, every user is still working with the same data but the data is presented in a structure meeting its needs. No data redundancies are necessary and therefore no anomalies such as heterogeneous granularity or meta-information can occur. Due to the fact that all stakeholders are working with the very same urban transportation space, it is valid to imply that also the digital representation of the traffic area should be managed once, and not redundantly.
This article is addressing the challenge of tackling the tasks of understanding the different use cases of different stakeholders focusing on the very same traffic area as one single task. Therefore some standard methodologies of database management and collaboration should be applied in the domain of integrated urban development considering novel Intelligent Transportation Systems. These methodologies raise following research questions: Is it possible to work on one dataset? If most of the stakeholders are interested on road and road infrastructure representation, is it be possible to describe it in a way that meets all requirements? Can it be done also for describing other domains such as city models or energy infrastructure? If not, how could it be incorporated and how can one ensure reusability?
How can the operating (i.e. accessing, processing, fusing, transferring, visualizing, storing) of such a dataset be achieved? What kinds of processing steps are necessary to guarantee a constant quality of the incoming data?
And, finally, are there any pioneer projects available that show the feasibility of such kind of approach?
This article addresses these research questions by introducing the thesis that the complex planning, development, testing, validating, presenting and operating activities of different stakeholders should base on the same data representation to gain synergies and avoid challenges. Therefore it presents a toolchain and database-driven concept, incorporating heterogeneous requirements based on different stakeholders' needs and currently available data formats to set up an integrative data storage, data processing and data provisioning. After an analysis of the involved stakeholders and of promising data formats, the three core components of the concept will be described regarding their design in more detail. The components will be based on a solution already successfully dealing with an aspect of the overall challenge. This strongly supports the technical feasibility, and distinguishes the concept presented in this article from many merely theoretical approaches.

Participating stakeholders and their current approaches
In order to understand the complexity of the task of developing an integrated urban development process, different stakeholders will be screened. Thereby, the focus is on revealing their roles and interests, their currently used data and their information requirements. The essential stakeholders are road and rail operators, governmental bodies, vehicle manufacturers, fleet operators, and of course the citizens.

Road and rail operators
Road and rail operators are managing the current traffic area for road, rail and light rail traffic. Usually they are commissioned by public authorities, but sometimes also public-private partnerships or complete private enterprises are performing this task. In general, road and rail operators have to maintain and partly build the infrastructure and therefore have strong interest in the planning of further development.
Road operators are heavily involved in urban development (at least in Germany), and thus usually have a solid data basis to store all of the road infrastructure data: In general, it's the layout of the road and the surrounding itself including road markings, traffic islands, road furniture, road signs and signals as well as a growing number of road sensors such as traffic (infrared) cameras, parking lot sensors, and V2X communication devices. They often use specialized geo-databases, e.g. CAOS' VIA TRAFFIC (CAOS GmbH, 2018) that supports the possibility to model the traffic area in a topological way as well as in a topographical way including georeferencing. Due to historical circumstances, data sometimes is only available in generalized data formats such as OKSTRA (BASt, 2018), which does not support a precise geometrical description. Additionally, road surface descriptions are stored in formats which are technically restricted to low resolution respectively data density. Additionally, logical road networks linked with the road infrastructure (such as traffic signs regarding the traffic rules) are used to calculate and simulate traffic flows. Road operators need to A. Richter, et al. Technological Forecasting & Social Change 155 (2020) 119970 keep their data base up to date but do not need a very high accuracy of the data. The data acquisition is often done by geodetics measurements for point objects or spatial limited areas. Broader areas are often derived by digitalization from blueprints. Light rail operators face even stricter regulations for the operation and planning of their infrastructure. Planning and building of new infrastructure often takes years while the data basis is in many cases rudimentary (e.g. consisting only of CAD drawings) or analogue because coordination with other stakeholders is already finished after the plan approval procedure. As a consequence, this data stays often the same for a long period because new changes need also long planning iterations, which means that these updates are also made with only a rudimentary data management. Nevertheless there are rising interactions with road operator data regarding signaling as well as V2X communication devices (City of Kassel, 2019b).
Rail operators are almost always operating an infrastructure with a limited amount of interfaces to other parts of the traffic area, such as railroad crossings and transitions from light rail systems to the long distance rail systems (like in Karlsruhe, Germany). Small rail operators often host only analogue data about their rail network. In contrast, large operators have the need and also the funding for economic operations and are therefore investing into digitalization of their existing rail network using specialized measuring trains (Makino and Satoh, 1998). In this case CAD and ALKIS (AdV, 2018) data is utilized as well as open data formats such as railML (railML e.V., 2018). These data formats can also be used for both, planning and simulation purposes, but often only include the rail superstructure. Infrastructure such as bridges, tunnels or station platforms nowadays are modeled using Building Information Modeling (BIM) (Ehrbar, 2016).
In general, the data about the rail network is needed to operate and maintain the infrastructure (Prescott and Andrews, 2013). While small rail networks are often measured only once a year (or even less with geodetics measurements), standard lines are often measured once a month. Railway lines with very strict requirements such as high-speed and maglev lines are measured even more often to monitor the condition (Shi, et al., 2014). Newly built lines are often surveyed before start of operation to update the position of all infrastructure elements because not everything is built exactly at the planned location.

Governmental bodies
Public authorities play diverse roles and have many tasks to fulfill and, of course, not all of them are directly related to the traffic or respective infrastructure. Besides those topics which are sometimes outsourced to road and rail operators, they have to keep an eye on the bigger picture of developing urban structure including urban parks, housing and commercial space, energy supply and disposal. This demands for further procedures, e.g. monitoring and calculating noise emissions and air pollution (and their possible dispersion) as well as planning alternatives and its visualization for decision makers and third parties. Accordingly, various data formats are used in the corresponding departments.
Such data is often gathered on demand only every few years by employing a specific service contractor if a broader area is of interest. Areal images and laser scans are used to derive data for creating or updating cadastral data (e.g. city models or green cadaster) by the service contractor itself or manually digitalized by the public authority departments. Spatial limited areas are again measured geodetically and manually incorporated in the data.
In general, classical geodata such as cadastre data are based on the proprietary Shapefile format, or stored in file geodatabases in a managed and provisioned way in ArcGIS (ESRI Inc., 2018) ecosystems. This may be supplemented by aerial images as GeoTIFF (OSGeo, 2018), digital elevation models as irregular mesh or even laser scan raw data in LAS format etc. If 3D data is available, sometimes CityGML (3D Geoinformation group, 2018) is used in the area of city-wide development especially in the context of the INSPIRE policy (EC, 2018). However, individual construction processes focus more on building information modeling (BIM) data formats.
As a result of data format diversity, single departments are often maintaining their own data pool instead of sharing it with others. Next to entrenched structures, external and in-house data provisioning costs in combination with a lack of money can be identified as a main reason. Moreover, commissioned companies such as road and rail operators are often using their own and enriched data pools. However, these are not synchronized with public authorities' databases due to missing respective contractual agreements.

Vehicle manufacturers
At first glance it may appear that vehicle manufacturers are not interested in being involved in urban planning and management (Musk, 2017). On closer inspection, nearly every vehicle already holds navigation data that is based on generalized graph models with points of interest added on top. Examples are the GDF-/RDF-based maps (ISO, 2018), (W3C, 2018) from map providers such as TomTom (TomTom, 2018a, 2018b), HERE (HERE, 2018), NavInfo (NavInfo, 2018) or even OpenStreetMap (OSM, 2018). As a consequence of increasing automation of vehicles, even more information about the urban environment is needed. The first demonstrations of fully automated driving in real world conditions showed that a detailed map about the environment is needed. For example for the Bertha Benz drive, a totally new map database was generated because no current source was able to provide all necessary information (Ziegler et al., 2014). To transfer first prototypes into more reliable products, highly precise data is needed in a broader range. Thus, navigation data becomes more and more detailed, including precise topographical elements describing, e.g., the course of the lanes. This is currently already modeled in High Definition (HD) Maps or in the Navigation Data Standard (NDS Association, 2018). Additionally, depth information such as in RoadDNA (TomTom, 2018a, 2018b) is integrated to support and enhance ego-localization. This (real-world) data is already needed for the development of automated driving functions for verification and validation in simulations and real-world scenarios as ground truth. For this, specialized data formats such as OpenDRIVE (VIRES, 2018), (Dupuis, 2015), RoadXML (RoadXML, 2018) or Road5 (IPG, 2016) are utilized. For example, OpenDRIVE is already used as a basis for Baidu's automated driving development framework Apollo (Gran, 2019). On the other hand, companies often use their own proprietary format (Waymo, 2016). The precise road descriptions are often combined with road surface descriptions with millimeter precision.
Often the companies gather the data on their own to meet the requirements of their proprietary data formats (Forbes, 2019). In testbed activities shared map databases are used to provide spatial data in different formats for the stakeholders using geoserver infrastructure (KoMoD, 2019).

Fleet operators
Operators of rental vehicles such as trucks, passenger cars and bicycles or scooters as well as cab companies need information about the road network and its current condition. This requirement includes, e.g., traffic congestion information and forecast  as well as customer numbers and traveling forecast (Ranjit et al., 2018), optimized routes (Wu et al., 2017), and available parking space or road condition. They apply respective data and use and process it not only for administrating the active vehicle fleet, but also for business management. Further, fleet operators need to communicate locations and statuses of vehicles that may be spread over the city to their customers. Data-driven innovation is further stimulated by a new group of competitors of fleet operators. However, vehicle manufacturers seek to evolve into mobility providers by using their own vehicle fleet to A. Richter, et al. Technological Forecasting & Social Change 155 (2020) 119970 collect, store and process data within their own backend system (ABI Research, 2018). For doing so, usually both groups use self-developed and proprietary data formats.

Citizens
Citizens are important stakeholders of the process of urban development. They are triggering and driving changes by claiming for adjustments in the fields of traffic, living, working and leisure. Additionally, growing interest arises in public open data to set up map communities such as OpenStreetMap, respectively OpenRailwayMap, or fruit tree and healing plant maps (mundraub, 2019) as well as private and free navigation services for bicycles and handicapped people. Currently, basic graph models and 3D information are used and interchanged using KML containers. Further, citizens want to be included in urban development (Beckwith and Sherry, 2018). Therefore, planning and the underlying data have to be processed and made available accordingly.

Summary of current stakeholder approaches
Urban transportation space is of interest for many stakeholders, which pursue very different and sometimes conflicting objectives. Diversity in stakeholders' rules and goals is directly reflected in data requirements and, therefore, data formats, quality demands and application software. However, the overall integrating concepts are a common space and transportation. Sharing data about shared space and topic areas is impossible due to missing interoperability between formats, application and due to heterogeneous spatial and temporal quality. Additionally, often data of built environment still is digitalized from blueprints and updated at irregular intervals. In doing so, semantic data is not collected or not appropriate for conversion into more specialized data formats. The latter also refers to budget for gathering the data and, more important, for keeping the data up to date. The spending of multiple efforts applies also for the further development of database schemas as well as data formats to represent new features and attributes that might be needed for upcoming use cases. Therefore data can hardly be interchanged and reused. Simulations and calculations done on different representations (regarding spatial, temporal and accuracy differences) of the same location are hard to compare, too.
The situation is tending to deteriorate due to stakeholder role changes and, therefore, different data acquisition possibilities and data representation requirements. For example, ad hoc traffic data is provided by new mobility providers who will partly consist of vehicle manufacturers or large carriers and logistic companies utilizing their vehicle fleet sensors. Furthermore, the third dimension mobility and respective data will play a more important role in the near future: Next to unmanned aerial vehicles used as flying sensors and transport units, aerial cabs and high-altitude platforms for monitoring, management and maintenance of traffic and its infrastructure are foreseen and not unrealistic any more. This is also envisaged in the Urban Air Mobility initiative of the City of Ingolstadt, Germany (City of Ingolstadt, 2018).
Therefore a new approach of cooperative urban development is necessary, which incorporates the heterogeneous objectives of current stakeholders but is also extendable for future challenges.

Current data formats for virtual city and traffic modeling
Intricacy of data availability and needs as well as of conceivable urban and mobility change is calling for solutions that support data integration. Since the concept development is not starting from scratch, the two most promising data formats that could help the stakeholders to model, store and exchange their data of the urban environment and traffic activities are described. However, it could be shown that easy weaving of data models for virtual 3D city models (CityGML) and concepts for road description (OpenDRIVE) is quite a challenge (Richter et al., 2016).

Unified city model development with CityGML
An important component for an integrated urban development is a city-wide representation of buildings and their related infrastructure that goes beyond visualization. In contrast to Google's Keyhole Markup Language (KML), Collada or X3D, CityGML (Gröger et al., 2012) may be used. Issued by the Open Geospatial Consortium it is an interoperable information model and encoding standard for the representation, storage, and exchange of virtual 3D city and landscape models. In addition to 3D geometric representations, it provides concepts to represent their semantics and their relations distinguishing real world features by providing 98 classes with 372 well-defined attributes in the current version 2.0. CityGML is commonly accepted in the field of 3D city modelings. Applications range from noise mapping (Czerwinski et al., 2007) to energy efficiency calculations (Dalla Costa et al., 2011) all the way to urban fine dust modeling (Ghassoun and Löwner, 2017), (Löwner and Ghassoun, 2018). A recent overview of applications can be found in (Biljecki et al., 2015).
A great advantage is CityGML's scalability to the user's requirements and data availability. Almost every thematic class may be represented in different Levels of Detail (LoD) from planar representation in LoD0 to a very detailed outdoor and indoor representation in LoD4. The LoD concept enables first, a gradual refinement of the geometrical characteristic, and, second, the adjunction of semantic properties. Therefore it supports gradual data collection with respect to different application requirements and efficient data visualization and analysis. Next to the definition of generic classes, CityGML may be extended by applying the Application Domain Extension (ADE) mechanism. This mechanism allows for the extension of CityGML classes by additional attributes and relations. Most relevant extensions available in the context of an integrated urban development are the EnergyADE (Aguguiaro et al., 2018) and the UtilityNetworkADE (Becker et al., 2011) in the current version of 0.2. The first supports the representation of building physics for the thermal behavior of a building, the energy system of a building and time series. The latter models features and networks of the electricity network, the freshwater network and the wastewater network. An extension for traffic-sign objects with focus on data acquisition by mobile laser scanners was developed (Varela-González et al., 2014) and accompanied by an approach to further model street spaces and topology using CityGML (Beil and Kolbe, 2017), (Labetski et al., 2018).
However, CityGML in its current version 2.0 as well as the mentioned Application Domain Extensions are currently under development. Next to an advanced LoD concept (Löwner et al., 2016) and others, CityGML3.0 will be extended by a new CityGML Dynamizer module to improve its usability for different kinds of simulations and to facilitate the integration of sensors with 3D city models (Kutzner and Kolbe, 2018).
Nowadays, data acquisition of 3D city models is done highly automated by photogrammetric and LiDAR (Light Detection And Ranging) methods for lower LoDs. LoD3 models can be captured applying mobile laser scanning methods, i.e. mobile mapping of detailed facades (Kersten et al., 2009), (Elseberg et al., 2013). Because of the open data initiative of Germany's federal states of North Rhine-Westphalia, Berlin and Hamburg approx. 400 LoD2 models are already available.
For storage and the further processing, the open source 3DCityDB with the 3D City Database Importer/Exporter may be used. Supported database backbones are Oracle Spatial/Locator and PostgreSQL/ PostGIS. Views of the data may be produced by SQL and imported to any further process chain. Unfortunately, no generic solution for the implementation of CityGML ADEs is supported by the 3DCityDB software but under development (Yao and Kolbe, 2017).
To this day, CityGML has been applied to some range in city administration. Singapore Land Authority (SLA) may serve as an example, which is leading a whole-of-government (WOG) initiative to create a A. Richter, et al. Technological Forecasting & Social Change 155 (2020) 119970 high resolution survey-accurate 3D national map to support the government and agencies in operation, planning and risk management (Soon and Khoo, 2017). It has also been applied for detailed street space modeling to support infrastructure planning and management in the city of New York, USA (Beil and Kolbe, 2017). To support activities in planning and maintaining urban areas, the federal state North Rhine-Westphalia has published a statewide 3D model in the format of Ci-tyGML (OpenGeodata, 2020). However, CityGML as it is and as it appears to be in version 3.0 does not solve the different needs of stakeholders described in previous Section 2.

Comprehensive road description with OpenDRIVE
For traffic management and operation the road description is the most crucial component. In contrast to graph-based data such as the OpenStreetMap database (OSM, 2018) or object catalogues such as OKSTRA (BASt, 2018), OpenDRIVE (Dupuis, 2015) may be used. Developed by a consortium of industry and research companies it is an open and royalty-free XML-based data format to describe a road network topologically as well as its 3D course and appearance topographically. In addition the surrounding, such as road furniture, vegetation and traffic signs respectively signals can be added as road objects. OpenDRIVE uses layers to divide the traffic area hierarchically into reference lines, lanes and features. These layers are described with 136 classes and various attributes in the current version 1.5 with improved support for complex real-world scenarios and data quality description (Dupuis et al., 2019). Applications range from driving and traffic simulation (Krajzewicz et al., 2013) to visualization (Nåbo et al., 2015).
A great advantage of OpenDRIVE is its flexibility of describing the topography of the road to meet the users' requirements. The layout is modeled using different mathematical descriptions, which supports modeling the road network both manually or by deriving it from realworld data. Additionally, it helps to select the best interpolation by each application without modifying the source data. Traffic rules are implicitly modeled by traffic signs and road markings. For simulation purposes the effect can be overridden using corresponding attributes.
Originally, OpenDRIVE was developed for driving simulation purposes. Thus, in general, road networks including their traffic infrastructure and furniture are modeled by hand using editor applications. The complex modeling of the surrounding or, e.g., energy systems was not required. More recently, OpenDRIVE has also been used for traffic simulation purposes as well as in frameworks for the development and test of automated driving functions. For example Baidu is using OpenDRIVE as basis for their Apollo framework (Lijun, 2018) with some modification to store lane boundaries with absolute coordinates as well (Gran, 2019). More and more real-world applications are appearing and the manual modeling is getting too complex. In earlier approaches GPS traces (Castro et al., 2006) and graph-or GIS-based data (Wilkie et al., 2012) were used to model the road networks. Nowadays, even highly precise data of road layout is needed and road surface is derived by applying mobile laser scanning methods, i.e. mobile mapping (Mitsubishi Electric, 2017). Despite of that more and more complex datasets are available covering highway scenarios as well as downtown situations (Gräfe, 2018). It has also been shown that the complex modeling of OpenDRIVE can be a growing issue for storing and handling of huge road networks with additional data about terrain and city models (Richter and Scholz, 2017). It appears that it does not solve the different needs of stakeholders described in previous Section 2.
Despite the fact that OpenDRIVE is free to use and utilized since 2006 and now is transferred to the automotive standardization organization ASAM (ASAM, 2018), a lot of OEM and Tier-1 still use their own propriety road description format. Thus a lot of stakeholders think on their own about upcoming challenges such as storage and maintenance of huge databases, gathering data for them, modeling new road scenarios and incorporating this in the description format. The interchange of data is still complicated due to the different data formats and modeling methodologies. That leads to the situation that often data cannot be reused in different simulation tools and also not by other project partners. This is a multiple duplication of effort and a waste of time and money.

Integrated urban development framework concept
Since none of the discussed and already advanced data models meet the needs of stakeholders described in Section 2, still bridging diverse data and processing requirements of parties involved seems to be the main challenge for the development of an integrated urban development framework to support novel Intelligent Transportation Systems. Currently there is no leading company or organization aiming at an overall and integrated concept because none of them either cover all the described domains or are declaring them as their economic goals. However, the German Aerospace Center (German: Deutsches Zentrum für Luft-und Raumfahrt e.V., DLR) is working in the domain of transportation systems with focus on automation of road and rail traffic, management of ground-based, air-and waterborne traffic as well as long-term transport planning and energy management. Therefore it has gained much knowledge in these domains. Thus, DLR together with the Federal Ministry for Economic Affairs and Energy of Germany (BMWi) prominently placed this topic as a research project called "Digital Atlas" in its strategy 2030, to make a first attempt towards a integrated urban development (DLR e.V., 2017).
This article presents the idea of the project "Digital Atlas" to develop a concept for enabling integrated urban development considering novel transportation systems. It is a thesis based on experiences gained by successful projects dealing with a similar but narrower focus.
The success of these projects demonstrates that the outlined challenges can indeed be tackled by the stakeholders, and may motivate them to aim for the expected synergies. The concept can serve as a blueprint for a multi-stakeholder approach, and as a proposed roadmap for the involved stakeholders.
In order to provide such a blueprint, firstly the concept focuses on the most essential technological problems, and provides a solution for each of them. Secondly, in some places, the descriptive level of detail necessarily has to stay generic. The rationale is that, based on previous experiences, it can be considered feasible to adapt these solutions to the specific requirements of each stakeholder.
The concept for an integrated urban development for diverse participation needs three core components: An all-embracing geo-database that relates temporal and spatial data to each other; a geodata processing toolchain, which assesses, processes and fuses input data and, finally, interfaces and data formats for an open interchange and to support different business concepts. The concept of these three core components will be presented in the following sections.

All-embracing geo-database
The development of one comprehensive database meeting requirements of all stakeholders involved is not reasonable. Respective data is too diverse, thus specific strategies for storing and processing are necessary. For example, aerial images and elevation models in raster data format are stored different than cadastral information, which is modeled as vector data. Further, information about the road environment may be stored mathematically as done by certain road description formats. Additionally, accuracy differs from centimeters for road description to meters for elevation models. As a consequence, the term 'all-embracing geo-database' just describes a bundle of distributed databases composed in a federal hierarchy. Depending on the use case of each particular set of geodata, it may either merely list and link to them in a catalogue service, (e.g. a Catalogue Service for the Web (CSW) (OGC, 2018)), or it is implemented as a federated database management system (FDBMS), i.e. a collection of cooperating database systems A. Richter, et al. Technological Forecasting & Social Change 155 (2020) 119970 that are autonomous and possibly heterogeneous (Sheth and Larson, 1990). Of course, it also can be a combination of both, a catalogue service and an FDBMS. The crucial point is to link the data. Relating as much information as possible directly across different database components is highly desirable. Thus, no specific data formats can be used because they would be optimized for their specific use, only including the problem of implicit representation of certain features. Straightforward and open description formats should be preferred, which can be mapped to common geometrical elements with context information stored as attributes.
One working example is the Road2Simulation format (Richter and Scholz, 2018), which utilizes 3D simple features (point, linestring and polygon) to comprehensively model the road environment, but ends up at the property line by design. The format uses a simplified data model for objects allowing for a detailed modeling of roads and their setting by relations. The utilization of simple features enables the processing of data in GIS and related applications. With the help of automated conversion, different and very specialized formats can be provided while simplified elements are translated into complex representations with their required spatial precision (Richter and Scholz, 2017).
Using this kind of methodology, a lot of information about a city can be represented. However, the way of addressing road objects in the Road2Simulation guidelines already reveals that the approach of simple features has its limitations. In particular this applies for the description of the object's appearance. Further, describing buildings with all their construction elements, power supply, electrical lines and plumbing with a simple feature approach would be inappropriate as well as would be a precise surface description. For those issues linkage to other specific geodata makes sense. Due to their localization, pieces of geodata are always related. Coordinate projections are convertible, and only heterogeneous precision may lead to ambiguousness. Location referencing can be used to compensate that drawback. It enables mapping of elements from one map to another and can also be applied if a source element does not explicitly exist in the target map (Ebendt and Touko Tcheumadjeu, 2017).
Versioning of data plays an important role as well, especially if the data is describing traffic or energy flows. It can later be used for analysis of its progress and can feed simulations to better evaluate the (temporary) impact of, e.g. construction sites. It is done by storing different temporal versions of the same data layer as one consistent dataset or only corresponding elements are represented in multiple versions over time. They are still linked to related elements in different temporal versions.

Geodata processing toolchain
Just as the concept of the all-embracing geo-database, only one overall toolchain will not manage to process all the different data. Again there is a need for specific toolchains for each type of data and application. However, for all of them the following processing steps will be necessary:

Import
Integrating new data sources or updating existing data starts with the import. This has to be implemented per data format and can then be carried out in full-shift operation.

Cleaning
The loaded data has to be checked first, to remove glitches and outliers and, second, to adjust the modeling accuracy in some cases. This process can be automated as well but a final acceptance remains necessary.

Assessing
Every data source has to be evaluated regarding the provided quality. This is because every source is providing a different precision and level of detail, and is having different ages. Especially data derived from sensor networks, e.g. floating car data (FCD) from vehicle fleets, may be less accurate than that obtained by a calibrated measuring vehicle. This process of assessing can be automated per data source as well, and the results of the assessment can be stored as metadata.

Processing
More information can be derived from the imported and cleaned data after processing it rather than only using it directly. Laser scan raw data, e.g. can be used to calculate the latest diameter of tree crowns and tree heights. Aerial images can be used to determine the location and quality of road marks. Even the processing can be automated. This is true in particular when the data source is not changing and the structure of the data stays the same. If the latter changes, processing algorithms have to be adapted.

Fusing
Different data sources have to be fused to obtain an overall representation. For example, a road environment description consists of point information as well as of vector-based cadastral data derived from mobile mapping and aerial images. These different data has to be merged despite their temporal and spatial differences. For the fusing process results of assessment are useful to select the best source as the ground truth for all other sources. This selection has to be done for each crucial element.
The fusing of data is the most challenging part of the whole process chain. Especially if various and many heterogeneous data sources are necessary for further processing, the fusing process has to be adapted consistently. This is because the used sources are usually not providing data updates at the same time, or, sometimes even no data is available at all. Therefore, the selection of the ground truth may change as well. Information that is only loosely related to other data (e.g. data about urban parks) can easily be incorporated into the road environment description, whereas it is more complicated to accomplish this with data, which already represents a fusion of different data sources (e.g. road infrastructure).

Referencing
Using location referencing is an important part of the processing because, as already mentioned, a "world format" for the description of every piece of information does not exist. To meet the different requirements of the stakeholders, reasonable references have to be established. An example could be the power supply infrastructure related to the road environment to evaluate the impact on traffic flow due to construction activities. The linkage can be stored as additional attributes in the data itself or as additional data layer in a specific description language.

Storing
The cleaned, processed and fused data has to be stored somewhere and somehow. For this purpose, the straightforward and open description formats as described in the Section 4.1 about the all-embracing geo-database are used. They are implemented in corresponding geographic information systems. The data storing is fully automatable.

Exporting
Gathered and processed data has to be exported in different data formats to use it as, e.g. road lane information for automated driving or 3D visualization for decision making. Accordingly, every target format requires the implementation of its own exporter to avoid loss of information and accuracy along the downstream conversion chain. The export can run fully automated as well. Fig. 2 depicts the complex toolchain including dependencies of data. At the top the discussed processing steps are shown in horizontal alignment. Relevant data sources are aligned vertically. According to the processing steps, information about data handling or incorporation A. Richter, et al. Technological Forecasting & Social Change 155 (2020) 119970 is illustrated.

Interfaces and data formats
It is necessary to define and decide on interfaces and data formats needed to carry out the technical processing steps. It is obvious that the interfaces are relevant for data import and export and have to be adapted to the specific source and target formats. Ideally, well-accepted frameworks such as GDAL (OSGeo, 2018) or FME (Safe, 2018) could be used to minimize the own implementation and maintenance efforts on the one hand. On the other hand, data formats are key elements to enable utilization of the all-embracing geo-database. As already mentioned, open standards should be used as much as possible to enable additional (upcoming or not yet identified) stakeholders to use and to contribute to the database. Additionally, the use of open formats for data exchange facilitates the incorporation of the formats by other software developers. This direct support by third parties makes a widespread use of the platform more likely. Currently, only a few straightforward description formats are available for all domains involved in the urban development platform. Therefore this topic requires specific attention.

Feasibility of concept
Many projects fail because of trying to tackle the complexity of all challenges in one solution. The described integrated urban development framework does not present such an overall solution. Instead it combines and utilizes existing components and technologies in order to minimize friction loss. Ideally, some of these technologies and components are already in use and have given proof of their potential, thus they can be combined for the overall approach. Feasibility of the concept will be demonstrated by the following approaches dealing with multi-stakeholder platforms and managing big spatial data. The project "Virtual World" already aims at modeling complex urban environment. Such approaches can be the foundation of the outlined integrated urban development concept.

Applicability of multi-stakeholder platforms
In some other domains experiences with multi-stakeholder platforms are already gained, two examples showing some valuable outcomes.
For tackling the task of gaining large potential for energy efficiency measures of urban building stocks a stakeholder specific multi-scale spatial representation was developed (Österbring et al., 2018): The platform should be used for decision-making, planning as well as visualization of the current state and future development of urban building-stocks. During the project, the spatial visualization and communication of results had been designed and adapted to target specific stakeholders and their needs, which were identified using the city of Gothenburg, Sweden, as a case study. The project was a first step in an attempt to formalize and structure visualization and communication of results when using spatial building-stock modeling. While the extensive use of building-specific information is likely to be a limiting factor in transferring the approach to other cities, adapting the visualization and communication of results by targeting specific local stakeholders is universally applicable. Therefore different stakeholders such as the local energy company, large residential property owners, policy makers in building and environmental committees, energy and urban planners at the city planning office and environment analysts were able to work on the very same databases. The results are comparable among different cities, if the same approach is applied.
In Africa, multi-stakeholder platforms are used for addressing agricultural research enabling Climate Change Policy. Multi-stakeholder platforms should bring together representatives from different interest groups to discuss shared challenges, opportunities, policy A. Richter, et al. Technological Forecasting & Social Change 155 (2020) 119970 actions and advocacy strategies (Acosta et al., 2019) to tackle complex development challenges and to assist the upscaling up of necessary innovations, especially for collaborative, knowledge exchange and influence networks (Hermans et al., 2017). It was possible to foster the sharing of information among diverse stakeholders and to allow participatory approaches for influencing policy recommendations across multiple governance levels. Findings from the social network analysis suggest the importance of platform composition in the knowledge-exchange process. Despite the fact that multi-stakeholder platform processes have succeeded in enhancing agriculture science-policy dialogues and promoting evidence-based policy outcomes in East Africa, additional research is needed if the multi-stakeholder platform model is to be successfully replicated, elsewhere. Especially the balance between non-state actors (including the private sector) and government representatives in the platforms (Acosta et al., 2019) or the domination of non-governmental organizations with an apparent lack of involvement of the business sector or local organizations were an issue (Herman, et al., 2017). It is proposed that multi-stakeholder platforms should not be used as blueprint vehicle for supporting innovation and scaling, but that more research is required to understand how the institutional setting and under-representation of certain actors affect the ability of multi-stakeholder platforms to stimulate capacities for innovation and for achieving a development impact at scale.

Handling big spatial data
When integrated urban planning is discussed, a huge amount of data has to be handled. Next to transportation the Open Geospatial Consortium (OGC) mentions smart cities as one big trend of big data in the geospatial information domain (OGC, 2017). Therefore, different projects dealt with the challenges of working with large spatial datasets such as storing, managing, processing, analyzing, visualizing and verifying the quality of data (Li et al., 2016). It was identified that in particular spatial indexing and algorithms to handle real-time data are needed, efficient methods for exploring and displaying data as well as for effectively assessing data quality. Privacy and security are equally important and are key concerns, especially in geospatial big data handling. Answers to such kind of challenges can be found in concepts about metadata frameworks for spatial data warehouses (Laxmaiah and Govardhan, 2013), and big data analytical frameworks for spatial data (Shah and Chaudhary, 2018). Whereas the proposed metadata framework improves the efficiency of accessing data in response to frequent queries, the analytical framework makes use of cutting edge open source tools to perform analytics operations like filtration, aggregation, exact match, proximity and K nearest neighbor search. The proposed framework is able to accelerate ad-hoc query processing by diverting the user queries to the suitable framework, e.g. a low latency query can be diverted to Cassandra and aggregation and complex queries can be executed on a Spark frameworka strategy, which achieved an efficient storage management and high computational processing (Shah and Chaudhary, 2018). Providing a dynamic spatial data warehouse, which captures the information from various sources and brings various equipment to store miscellaneous formats and type of data. It is stored in its own uniquely designed standards and helps the system to process queries efficiently well and to make use of the best technical resources (Laxmaiah and Govardhan, 2013).

Virtual world project
The German Aerospace Center's project "Virtual World" aimed at processing heterogeneous geodata automatically to generate topological and topographical descriptions of the road and its environment. The outcome should be utilized in the development and test of driver assistant and automation systems (Richter et al., 2016). Various diverse data sources were incorporated to derive a comprehensive representation of the urban environment for simulations. Cadastral and land use data, survey data and processing of aerial images, crowd-sourced data as well as remote sensing data have been used. All these datasets were imported, cleaned, fused and additional data was derived. Finally, they were stored in a consolidated data pool while exporters facilitated the usage of this processed data to export different target formats. Fig. 3 depicts a visualization of combined data sources within a simplified 3D environment.
For the road description, the open format OpenDRIVE (Dupuis, 2015) was used and directly mapped to a database schema. During the project it became apparent that a more simplified road A. Richter, et al. Technological Forecasting & Social Change 155 (2020) 119970 description would make the maintenance of the database and the closely coupled processing steps more efficient (Richter and Scholz, 2018). Hence, the processing was divided into the road on the one hand and into the infrastructure on the other hand. As a result, it was much easier to update only components or sections of an area than to use native OpenDRIVE. Therefore, the database schema was shifted to Road2-Simulation, which is able to export OpenDRIVE data and to support a simpler data processing in the overall toolchain. City description was planned to be implemented similarly to the road description, i.e. as a parallel to OpenDRIVE using CityGML. However, due to the purpose of using the data in a driving simulator environment, a detailed city model was not necessary and it turned out that the detailed modeling of CityGML was not compatible with the sparse data available. Instead a rule-based approach using ESRI's CityEngine (ESRI Inc., 2018) was chosen to generate 3D models of the buildings based on a set of parameters, which were affected by data derived from different sources. The 3D models became more realistic the more parameters are determined by data. Otherwise random values from a range of plausible values were chosen. All this information is stored as attributes of simplified Shapefile polygons. This approach simplified the city modeling like the road description. Generated results of the city modeling can be exported as 3D model in OBJ format and integrated directly in the simulation database or as a CityGML file. Other data can be exported, respectively. For example, the road description can be exported as OpenDRIVE file as well as simplified navigation dataset or as a classical map view.
The project also focused on the updatability of all data sources. Due to the fact that different kinds of data sources with different update cycles were used, it is obvious that not all of them could be updated simultaneously. The more information was related with other data, the more complex the fusion process was. As a consequence, information about road infrastructure, i.e. road signs, traffic signals, street lights, and furniture, that might change their position and type more often, was separated from the topographical description of the built road. As a result it was possible to update the road infrastructure layer easier. The fusing of the road infrastructure, furniture and vegetation with the topographical road description was then performed during the export process. With the fusion it is still possible to perform necessary spatial corrections if road infrastructure etc. does not fit to the road layout completely. Having this correction "on demand" and not stored in the data, it is not necessary to revoke a correction for an old road description dataset, if the road description is updated.
The "Virtual World" project was able to automatically generate the total city region of Braunschweig, Germany. The outcome showed different qualities regarding accuracy and richness of details that directly correlated with the availability of input data. A good example for that was the application of the "Virtual World" methodology to a demo track in Stuttgart, Germany that had been undertaken during the Road2Simulation project (Richter and Scholz, 2018). Also, test field activities in Germany (Braunschweig (AIM, 2018) and Düsseldorf (KoMoD, 2018)) as well as in Graz, Austria (ALP.Lab, 2018) are using partial aspects of the "Virtual World" approach.
6. Discussion of the potential of an integrated urban development framework A growing number of stakeholders dealing with more and complex data for an increasing number of applications are calling for an integrated planning and processing. Even though some of the challenges may possibly be tackled with the further development of single components, only an integrated solution facilitates the work on more complex issues from different domains and the incorporation of their intelligent solutions.

Potential analysis based on a thought experiment
The main advantage of an integrated approach is the usage of a joint data pool. The following example will illustrate its potential: Let's assume that in the future a lot of automated pods are driving around in the city. Therefore, the clear borderline between the traffic areas, e.g. built with curbstones can be omitted due to the usage of shared spaces and ideally more urban parks. Complex intersections will be rebuilt to roundabouts and their centers are used as parking space for the pods to wait for their next mission. Now, the road network with its road topography and road topology can be transformed based on these requirements. It is exported twice for traffic flow simulation as well as for visualization. Therefore it is possible to show how the future city will look like and, with the help of augmented reality, also on site because all data is fully geo-referenced. Additionally, it is likewise possible to perform simulation-based checks whether the new road layout is appropriate to manage the future traffic demand, including entering and dismounting (and loading and unloading), or whether more space for the pods is needed. Then, the simulated traffic itself and changes can be visualized directly on site as well.
A key element is that every developer is using the same data with the same meta-information, with the same precision as well as with the same age and history. That way, it cannot happen that involved departments are working with different data, with the undesired consequence of disruption in the simulation and visualization toolchain during processing. There is no loss of information and precision as possibly caused by complicated data conversions. Information could only get lost during data export if the target format is not able to represent the entire information. With the help of location referencing (as described in the Section 4.2) it is possible to restore the relation in order to retrieve the information.
With the help of an adapted and enhanced toolchain it is possible to enable various stakeholders to update and extend the data pool. Thereby, the cleaning, processing and assessing of the data ensures that only correct data will be integrated. Additionally, the processing can guarantee that some specific data can only be changed or updated by one stakeholder that is in charge of the corresponding infrastructure (e.g. energy supply infrastructure) to ensure the data sovereignty.
The assessment of data sources plays an important role. Whenever data change, after a comparison to the current status its assessment can be used to decide whether it can be integrated into the data pool directly or whether it has to be verified first. For example, an update from a calibrated measuring vehicle can be integrated directly but changes reported by, e.g. fleet vehicles may have to be verified by other contributors (especially regarding their accuracy). Furthermore, also citizens may contribute to the quality and richness of detail, if crowdsourcing access like that of OpenStreetMap is guaranteed. However, this free data access is not necessarily a showstopper for business models. This is because highly precise data could be provided only to customers who provide high precision data either directly or by contributing to monetary funding of new survey campaigns. Therefore, it may be worthwhile for fleet operators to invest in a better sensor setup and to integrate it in their vehicle fleet. In doing so, vehicles can deliver more data of higher quality. Furthermore, the outlined business models can strongly benefit from recent trends to apply gamification approaches in transport (Shreenath et al., 2015). Individual citizens may not be able to contribute in that way, but usually they do not really need highly precise data. General data can be provided without additional costs. These general data would be sufficient for, e.g. bicycle navigation or neighborhood maps. Gamification in crowdsourcing (Morschheuser et al., 2017) is also a promising way to enlist the help of citizens with specific data gatherings (OSM, 2018). In general it is necessary to let citizens participate in the urban development framework: this highly raises the probability that people will accept decisions, which are based on the data (Beckwith and Sherry, 2018). A. Richter, et al. Technological Forecasting & Social Change 155 (2020) 119970 6.2. Overview about the advantages and drawbacks of the concept In the following, Table 1 gives an overview about the advantages and drawbacks related to the needs and requirements of the involved stakeholders: As stated in the beginning of this article, every stakeholder could continue working with their own solutions and just exchange data when necessary. This would lead to some drawbacks as stated in Table 1. For example data distributed to different stakeholders is "out of control" of the data owner and different versions of the very same data circulates. These issues do not exist if an integrated framework is used. However, an integrated framework is more complex to maintain and operate with respect to specialized data management solutions. Nevertheless every specialized solution has to be updated or adapted, if essential changes are necessary.

Conclusion
The challenges of urbanization, automatization and digitalization are more topical than ever. Partial aspects of these challenges are already addressed by working concepts such as the "Virtual World" project. It shows that there is enough potential for solving the remaining issues in future by applying and adapting the concepts to other domains and therefore can be seen as a pioneer project. Additionally, various mentioned projects are successfully dealing with big spatial data, multistakeholder platforms and comprehensive data modeling. It is important to note that our concept does not consider a monolithic solution, which is aiming to solve all issues at once. It rather suggests the agile adaption and utilization of current technologies and methodologies to achieve this purpose. It is also not necessary to wait for a technological leap. The examples dealing with road environment and for city modeling presented in this article are showing that complex data processing and fusing is feasible and already accomplishable today. It is possible to work on one dataset that integrates different kinds of data using views and references. To meet the requirements of different stakeholders that are interested on road and road infrastructure representation, the data should be modeled in a simplified way and not using complex description formats for storing and processing of the data. These specialized data formats can be provided using exporters. The same works for city model data, etc. References to different datasets are ensuring that no link is broken even if the data cannot be incorporated directly in the storage of the integrated framework. The accessing, processing, fusing, transferring, visualizing and storing are enabled by different toolchains adapted to the specific data source. Different processing steps of the toolchains ensure a constant check of the quality of the incoming data.
In addition to the combination of different data sources, the presented concept also integrates different stakeholders. Because of the growing complexity of technologies used, it is necessary that all involved stakeholders coordinate their activities and work on a joint solution and realization, instead of waiting for someone else (who has to know about all the requirements of the others) to do that. Only a joint approach will make the complex interaction in the shared and limited traffic area manageable. Moreover, this approach also supports new users with new ideas to utilize the data and come up with new business models because open interfaces allow them to access and contribute to the data pool. Hence, it is guaranteed that the data pool is used and maintained long-term without concentrating this effort on one single user. With new business models evolving and users continuously adapting them to the needs arising with the upcoming challenges, it can be expected that also the data pool will grow and will be improved.

Funding
This work at German Aerospace Center (DLR) was mainly funded by the Helmholtz Association (refers to the Project "Virtual World" and "Digital Atlas") but also partly funded by Audi, BMW, Daimler, Porsche and Volkswagen (refers to the Project "Road2Simulation").  Table 1 Comparison of using an Integrated Framework with the current situation.

Stakeholder need
Current situation (without integrated framework) Situation with using an integrated framework Number of available data sources Own database plus public available sources All-embracing Geo-database Linking to different data sources Has to be done manually and specific per data source Including a systematic approach how to link to other related data sets Quality of available data sources Heterogeneous regarding spatial and temporal information, in general no or only poor data quality description available Integrated Framework ensures the assessment of data quality; Geodata Processing Toolchain ensures a comprehensible data fusion Data updates Have to be done by each stakeholder on its own every time Updates provided by other stakeholders or derived from assessed data Ensure data sovereignty No issue with self-maintained databases Insert and update protection can be integrated in the processing toolchain; access to the data can be limited in export modules Extending database Has to be done with own development resources; no discussions needed Benefit from extensions of other stakeholders; collaborate for further developments; agreed approach needed Extending import/export capabilities Development has to be done by each stakeholder with own development resources Benefit from extensions of other stakeholders Enabling additional business cases Interfaces, roles and rights for external partners have to be developed and implemented by each stakeholder with own development resources; complicated access to local databases Onboarding of new stakeholders using the included roles and rights models Access of the database by third parties Third party has to conclude agreements with the provider of every new data source about data usage; data contribution often not included Third party can be on boarded to the framework; general roles and rights provides boundaries for data usage and contribution Ensure correctness of data used by third parties If data is exported once, no control or maintenance on user site possible Stakeholder is using the data that is still under control of the data owner Ensure the same age and quality of data used by third parties at the same time If data is not exported at the same time, every stakeholder is using a different data version Data is still under control of data owner, every stakeholder is using the very same data A. Richter, et al. Technological Forecasting & Social Change 155 (2020) 119970