Information Exchange between GIS and Geospatial ITS Databases Based on a Generic Model

Abstract

This study aims to improve interoperability between Geographic Information Systems (GIS) and geospatial databases for Intelligent Transport Systems (ITS). Road authorities maintain authoritative information for legal and safe navigation in GIS databases. This information needs to be shared with ITS databases for route planning and navigation, and for use in combination with local knowledge from vehicle sensors. Current solutions for modelling and exchanging geospatial information in the domains of GIS and ITS have been studied and evaluated. Limitations have been pointed out related to usability in the GIS domain and flexibility for representing an evolving real world. A prototype for an improved information exchange model has been developed, based on ISO/TC 211 standards, Model Driven Architecture (MDA), and concepts from the studied solutions. The prototype contains generic models for feature catalogues and features, with implementation schemas in the Geography Markup Language (GML). Results from a case study indicated that the models could be implemented with feature catalogues from the ITS standard ISO 14825 Geographic Data Files (GDF) and the INSPIRE Transport Networks specification. The prototype can be a candidate solution for improved information exchange from GIS databases to ITS databases that are based on the Navigation Data Standard.

1. Introduction

1.1. Geospatial Information in Intelligent Transport Systems (ITS)

Detailed geospatial information that represents road networks and the surrounding road environment is a critical component for route planning and navigation with Intelligent Transport Systems (ITS) [1]. Advanced Driver Assistance Systems (ADAS) and systems for autonomous driving depend on geospatial information from a variety of sources, as illustrated in Figure 1.

Modern vehicles contain a range of sensors from which they create local geospatial knowledge, and can share this information with map providers, Original Equipment Manufacturers (OEMs), and other road users. However, the local knowledge is neither sufficient for route planning nor for local navigation under challenging conditions, such as fog or snow-covered roads, and must be combined with geospatial information from pre-processed databases covering larger areas [2,3].

Commercial map providers and OEMs have created and delivered ITS databases and services for route planning and navigation for several decades and are extending their products to support ADAS and autonomous driving with High Definition (HD) maps. The databases are maintained through data capture from both professional mapping vehicles and private vehicles [4].

However, road authorities are the authoritative source for information needed for legal and safe navigation in the road network. Road authorities set regulations for road use and navigation and maintain geospatial information representing the road network, regulations, events, conditions, and road equipment, often in applications and databases from the domain of Geographic Information Systems (GIS). Furthermore, road authorities may have geospatial information for rural areas where fewer vehicles have travelled, as well as Building Information Models (BIM) with geospatial information representing new roads before the roads are opened. Meanwhile, mapping authorities, of course, maintain base maps of roads and the surrounding environment in GIS databases.

The users of ITS applications for route planning and navigation rely on accurate and updated geospatial information for the complete knowledge needed for legal and safe navigation. Map providers and OEMs need reliable and harmonized mechanisms that can provide them with information from authorities for further sharing with the road users [5], and for simulation and testing [6,7]. Sharing information from authorities may improve the data quality of ITS databases for route planning and navigation and thereby improve public safety, reduce the risk of damage to infrastructure and improve the quality of mobility services. To enable the flow of information, models that describe the real world and specifications for information exchange are needed [5,8].

1.2. Information Modelling

A foundation for information exchange is a common understanding of how data represents the real world by means of a standard way of information modelling [9]. The most often used language for information modelling is Unified Modelling Language (UML), developed by the Object Management Group (OMG) [10,11], who have also developed Model Driven Architecture (MDA) [12]. In MDA, conceptual models are developed at different levels of abstraction, independent of specific implementations. Implementation schemas for file and database formats are derived from the conceptual models, following rules for conversion. MDA gives flexibility for modifying and extending the models and ensures that conceptual models and implementation schemas match each other.

ISO/TC 211 and the Open Geospatial Consortium (OGC) are the main actors concerning international standardization in the GIS domain, and they have based their work on general information technology from UML and MDA [13]. ISO 19103 [14] describes a UML profile, modelling rules and an MDA approach, and ISO 19109 [15] describes a General Feature Model for geospatial information. Other ISO/TC 211 and OGC standards and specifications are based on ISO 19103 and ISO 19109. The UML models are maintained in a common harmonized UML model repository, where concepts defined in one standard are reused in other standards. Rules for conversion from UML to implementation schemas for the standardized Geography Markup Language (GML) format are described in ISO 19136 [16], and implementation schemas for other formats may also be derived in similar ways. Figure 2 illustrates the levels of abstraction in MDA according to ISO 19103.

The approach based on MDA and UML has been successful for developing interoperable standards in the GIS domain. The standards are widely adopted in applications and national and regional information models, including systems and databases for geospatial road-related information maintained by road and mapping authorities. Some examples of specifications based on ISO/TC 211 standards are the European INSPIRE specification on Transport Networks [17] and the OGC specifications CityGML [18] and LandInfra/InfraGML [19,20,21].

In the ITS domain, the Navigation Data Standard (NDS) and its free part, the Open Lane Model [22], is the standard for storing geospatial road-related information in ITS databases, while ISO 14825 Geographic Data Files (GDF) [23] is the official ISO standard for information exchange between databases with geospatial information for road navigation. Road and mapping authorities maintain some of the information described in these standards in GIS databases. However, the descriptions in the ITS standards are based on other information modelling principles than ISO/TC 211 standards. For the information exchange from road and mapping authorities’ GIS databases to ITS databases, the information requirements described in standards from the ITS domain must be described according to GIS standards and specifications.

Due to the lack of harmonized standards for the GIS and ITS domains, little information is currently exchanged between the two domains, and the exchange is likely to be based on proprietary solutions from each data owner. There has been some progress in Europe though, through the European Union Location Framework Transportation Pilot [5] and the TN-ITS GO project [24], where several European countries have implemented or plan to implement the specification TN-ITS [25]. However, the specification covers only a limited set of regulations for road use and navigation.

1.3. Research Question

The research question in this study is how to improve existing methods for exchange of geospatial information from road and mapping authorities’ GIS databases to geospatial ITS databases, illustrated by the three right-headed horizontal arrows in Figure 1.

2. Materials and Methods

2.1. Research Design

The research described in this paper was based on five steps, illustrated in Figure 3. The state of the art of solutions for information modelling and exchange, in and between the domains of GIS and ITS, was studied and evaluated in step one and two. A prototype for an improved information exchange model was developed in step three. Schema files for implementing the prototype in the GML format were derived from the UML models in step four, following the conversion rules from ISO 19136 [16] and by using the conversion software ShapeChange [26]. Finally, the model was tested and demonstrated in a case study with different feature catalogues in step five.

2.2. State of the Art

2.2.1. Literature Search

Literature presumed relevant for answering the research question was identified by using the search engines Oria and Google Scholar. Searches were based on keywords related to GIS such as “geospatial information,” “geographic information,” and “ISO/TC 211,” combined with keywords related to ITS such as “Intelligent Transport Systems,” “GDF,” and “Navigation Data Standard.” Searches in standards catalogues identified additional standards and specifications. A shorter list of literature was derived from the search results by studying titles and abstracts, and finally, the most relevant literature was selected by more detailed studies of the content. The results from the literature search included research articles, handbooks, standards, and specifications describing relevant solutions for information exchange.

2.2.2. Overview of Standards and Specifications

Several actors from the domains of GIS and ITS are involved in standardization concerning the modelling and exchange of geospatial road-related information. Of primary interest for this study are some official standards and specifications from the International Organization for Standardization (ISO) and the European Committee for Standardization (CEN), as well as open standards and specifications from industry actors such as the Navigation Data Standard (NDS) Association and OGC.

Table 1. Identified standards and specifications for geospatial road-related Information.

Standard/Specification	Title
GDF	ISO 14825:2011 Geographic Data Files (GDF) – GDF 5.0 [23] ISO/DIS 20524-1 Geographic Data Files (GDF) – GDF5.1 – Part 1: Application independent map data shared between multiple sources [27] ISO/CD 20524-2 Geographic Data Files (GDF) – GDF5.1 – Part 2: Map data used in automated driving systems, cooperative ITS, and multi-modal transport [28]
NDS Open Lane Model	Navigation Data Standard (NDS) Open Lane Model version 1.0 [22]
OpenDRIVE	OpenDRIVE version 1.5 [29]
TN-ITS	FprCEN/TS 17268 data exchange on changes in road attributes [25] Transport Network Intelligent Transport Systems (TN-ITS)
OpenTNF	Open Transport Network Format (OpenTNF) 1.0 [30]
INSPIRE TN	INSPIRE Data Specification on Transport Networks [17]
CityGML	OGC City Geography Markup Language (CityGML) Encoding Standard version 2.0 [18]
LandInfra/InfraGML	OGC LandInfra and InfraGML 1.0 Encoding Standard [19,20,21]
DATEX II	CEN/TS 16157 DATEX II data exchange specification for traffic management and information [31,32,33,34]
TPEG2	ISO/TS 21219 Traffic and Travel Information (TTI) via Transport Protocol Expert Group, Generation 2 (TPEG2) [35,36,37,38]

. presents an overview of identified standards and specifications.

2.2.3. Geographic Data Files (GDF)

GDF version 5.0 [23] is the ISO standard for exchange of information between databases with geospatial information for road navigation, and is referred to by several authors as the core standard for this purpose. Among them is [8], where the need for standards for the digital road network supporting automated driving is emphasized. GDF describes the network, regulations, and the surrounding road environment with a generic model (the feature model), a general topology model and catalogues with more specific models of features, relationships, and attributes. A new version of GDF is under development, with an extended scope that includes requirements from applications for Cooperative Intelligent Transport Systems (C-ITS), multi-modal transportation, and systems for automated driving [27,28]. Actions were taken in the development of GDF version 4.0 to harmonize the standard with ISO/TC 211 standards, but the work was not completed [39,40].

2.2.4. Navigation Data Standard (NDS) Open Lane Model

The Navigation Data Standard (NDS) is developed by the Navigation Data Standard Association, with a broad representation of OEMs and providers of services, and is considered an essential standard for geospatial ITS databases. While GDF is developed for information exchange, the scope of NDS is storage of vehicle navigation data in a size-efficient and standardized way. The NDS Open Lane Model [22] is an open specification that contains a limited set of features and functions from NDS, covering similar contexts as GDF. Of the 16 building-blocks in the complete NDS, the Open Lane Model is limited to three core blocks for navigation and map display: routing with the network model; lanes with the information for navigation at lane-level; and shared data with metadata [4].

2.2.5. OpenDRIVE

The OpenDRIVE specification [29] is an open XML file format for road networks and is described as the de facto standard for driving simulation [7]. The specification defines a navigable road network with centerlines, lanes, and road features, including marking, signals, and more. Some examples of the use of the OpenDRIVE specification are described in [6,7,41].

2.2.6. Transport Network Intelligent Transport Systems (TN-ITS)

The European TN-ITS specification [25] was developed in cooperation between road authorities and commercial map providers in the ROSATTE [42] and TN-ITS [5] projects, and was later standardized by CEN/TC 278. The scope of the specification is the exchange of changes in static road-related information, while the network and topology are outside of the scope. The information model is generic, with types and content of features and properties defined in extendible external code lists.

2.2.7. Open Transport Network Format (OpenTNF)

The open specification OpenTNF [30] describes a generic model for exchange of transport network related information. The specification contains a network model, a generic model of road features and road feature properties, and a model of feature catalogues. OpenTNF is described in [43] as a candidate model for exchanging road asset information between stakeholders in road construction and maintenance.

2.2.8. INSPIRE Transport Networks (INSPIRE TN)

The European INSPIRE Directive [44] defines the framework for spatial information for a range of themes in Europe. The transport networks (TN) theme [17] describes a multi-modal transport network based on the INSPIRE Generic Network Model (GNM) [45], with specific network elements and network properties for each transportation mode. The need for harmonized specifications for information that shall be provided according to the European ITS Directive [46,47] are discussed in [48], and the authors point at the INSPIRE TN specification as one possibility. INSPIRE TN is also described in [43] as a candidate model for the exchange of transport networks information outside of Europe.

2.2.9. CityGML and LandInfra/InfraGML

OGC has developed a range of specifications based on ISO/TC 211 standards. Two specifications that are relevant for this paper are CityGML [18], which defines a model for 3D city models, and LandInfra/InfraGML [19,20,21], which defines models for land and civil engineering infrastructure facilities, including road infrastructure. A model for detailed modelling of streets by extending CityGML is described in [49].

2.2.10. DATEX II and TPEG2

The scope of the European data exchange specification for traffic management and information (DATEX II) series of standards is dynamic information for traffic and travel. The European Commission has referred to DATEX II as the preferred method for providing real-time information according to the ITS Directive [46,47]. The scope of the Transport Protocol Expert Group, Generation 2 (TPEG2) series of standards is the broadcasting of traffic and travel information, mainly dynamic information. As the TPEG2 and DATEX II series of standards overlap to some degree, rules for converting DATEX II messages to TPEG2 messages have been defined through the EasyWay project [50]. A model for combining dynamic traffic information with the network from an NDS dataset is described in [51].

2.2.11. Other Research and Solutions

Several research projects have worked with specific models and solutions for geospatial ITS databases. Possible models for HD maps are described at an overview level in [1,2]. Conceptual models for transportation networks on different topology levels similar to GDF are described in [52,53], while [54] describes a conceptual UML model for multimodal transport. None of these describes mechanisms for information exchange. Solutions for dynamic update of ITS databases in vehicles from server databases are described in [3,55,56], and ref. [3] includes an overview of research on incremental map updates as well. A model for lane-level navigation is described in [57], and ref. [7] describes a simplified model for conversion between different ITS formats, such as OpenDRIVE and NDS. Finally, a specification of elements that make up a model for automated driving systems is described in [58].

2.3. Evaluation of Solutions

Identified relevant solutions were compared and evaluated against a set of requirements, listed in

Table 2. Requirements used in the evaluation of solutions.

Requirement	Description
ISO/TC 211 Model Driven Architecture (MDA)	The ISO/TC 211 MDA approach is the foundation of information modelling in the GIS domain. Adapting an information model based on a different approach for use in GIS may be a complicated task that requires fundamental changes. Therefore, solutions for exchanging information from GIS databases should be based on the ISO/TC 211 MDA approach.
GIS exchange format	Using a familiar exchange format from the GIS domain, such as GML or GeoPackage, is vital to avoid additional conversions and, thereby, to enable efficient exchange from GIS databases.
Feature catalogue	Advanced Driver Assistance Systems (ADAS) and systems for automated driving need a range of features for legal and safe navigation, including regulation features such as speed limits and other features such as lane dividers. Unambiguous descriptions of these classifications of the real world in a feature catalogue are essential for a common understanding of the exchanged information.
Feature catalogue exchange model	A feature catalogue exchange model is needed for sharing the classifications of the real world described in the feature catalogue with the users of the information. Furthermore, as the real world is changing (e.g., if a new valid value for speed limits is introduced, a new type of sign or a new kind of access regulation is introduced), the feature catalogue must also be modified and shared with receivers of the exchanged information. Using a feature catalogue exchange model for exchanging the feature catalogue together with the features gives the flexibility of maintaining a dynamic feature catalogue outside of the primary standard or specification. Contrary to this, a standardized feature catalogue in an ISO standard cannot be modified without revising the standard.
Network model	A navigable digital network is the foundation of route planning and navigation and must have both geometry and topology of the network elements, together with mechanisms for relating features to the network.
Generic feature exchange model	Feature exchange can either be based on specific feature models precisely as they are modelled in the feature catalogues, or on a generic feature model that refers to external descriptions of features and their properties in feature catalogues. The combination of a feature catalogue exchange model and a generic feature exchange model gives the advantage of keeping the main feature exchange model stable while the feature catalogue is modified, and the feature exchange model may also be used with different feature catalogues.

. The purpose of the requirements was twofold: Firstly, to evaluate the usability of the specifications for exchanging information from GIS databases, and secondly to evaluate the flexibility of the specifications for exchanging information representing an evolving real world.

Table 3. Evaluation of studied solutions.

Solution	ISO/TC 211 MDA	GIS Exchange Format	Feature Catalogue	Feature Catalogue Exchange Model	Network Model	Generic Feature Exchange Model
GDF	No	No	Yes	Yes	Yes	Yes
NDS Open Lane Model	No	No	Yes	No	Yes	No
OpenDRIVE	No	No	Yes	No	Yes	No
TN-ITS	Yes	Yes	No	No	No	Yes
OpenTNF	No	Yes	No	Yes	Yes	Yes
INSPIRE TN	Yes	Yes	Yes	No	Yes	No
CityGML	Yes	Yes	Yes	No	No	No
LandInfra/InfraGML	Yes	Yes	Yes	No	No	No
DATEX II	No	No	Yes	No	No	No
TPEG2	No	No	Yes	No	No	No

presents an evaluation of studied solutions against the requirements described in Table 2. Only standards and specifications are included, as none of the other solutions described in Section 2.2.11 is mature enough to be considered. The evaluation is generalized to a simple yes or no for each requirement, to simplify the presentation.

The analysis shows that none of the solutions meets all requirements. The GDF standard covers four out of six requirements, but as it is not based on ISO/TC 211 MDA and does not use an exchange format from the GIS domain, it cannot easily be implemented in a GIS. Like GDF, neither the NDS Open Lane Model nor OpenDRIVE is based on ISO/TC 211 MDA, and besides, they are missing a feature catalogue model and a generic exchange model. Nevertheless, the NDS Open Lane Model is essential for the further work, as it defines the model of the ITS database to which the information shall be exchanged. For DATEX II and TPEG2, the situation is different, as they are based on similar MDA approaches as ISO/TC 211 standards and may be converted to ISO/TC 211 MDA. However, they contain only the feature catalogue, and their main scope is limited to dynamic information.

Of the solutions that are based on ISO/TC 211 MDA, INSPIRE TN is a promising candidate, with a network model and feature catalogue described according to ISO/TC 211 MDA and with implementation schemas in the GML format. However, INSPIRE TN does not have a feature catalogue exchange model or a generic feature exchange model. Another candidate is TN-ITS with a generic feature exchange model described according to ISO/TC 211 MDA, but the specification does not have a network model, a feature catalogue, or a feature catalogue exchange model. However, both INSPIRE and TN-ITS may be extended to meet the remaining requirements. OpenTNF is also a promising candidate, even though it is not based on ISO/TC 211 MDA. The specification includes a network model, a feature catalogue exchange model and a generic feature exchange model and uses familiar GIS formats for exchange (SQLite and OGC GeoPackage). It is based on a conceptual UML model, uses some concepts from ISO/TC 211 standards, and the models may be modified to ISO/TC 211 MDA without fundamental changes.

The two last specifications based on ISO/TC 211 MDA are CityGML and LandInfra/InfraGML. The main scope of these specifications is not information for navigation, but rather visualization, planning, construction, and asset management. The CityGML specification is specific on this issue and refers to GDF for network topology. However, the specifications do contain road centerlines and road equipment that are needed for navigation, and most important, the information from construction projects may be delivered to road authorities and map providers for further preparation in network databases. Information exchange between CityGML, LandInfra/InfraGML, and ITS databases will probably be essential for maintaining HD maps in the future.

3. Results

3.1. A Generic Model for the Exchange of Road-Related Geospatial Information

As none of the studied solutions meets all of the requirements from Table 2, a prototype of an improved solution was developed. The goal was to support the information exchange illustrated by the three right-headed horizontal arrows in Figure 1 by fulfilling all requirements from Table 2. Furthermore, the prototype should enable the exchange of feature and relationship types defined in ISO 14825 GDF, as this is described as the core model for geospatial information for ITS applications. Exchange of feature types described in other feature catalogues should also be supported, such as INSPIRE TN. The prototype was based on concepts from the most promising solutions from the evaluation: GDF, INSPIRE-TN, TN-ITS, and OpenTNF.

The concepts of the prototype are illustrated in Figure 4, with three application schemas based on ISO 19109: the Feature Catalogue, the Feature Catalogue Exchange Model, and the Feature Exchange Model, and implementation schemas that are derived from the application schemas.

The Feature Catalogue application schema contains specific models for individual feature types. A feature type is defined in ISO 19101 as a class of features having common characteristics, while a feature is an abstraction of a real-world phenomenon [59]. Similar to this, GDF defines a feature as a representation of a real-world geographic object [23]. In the scope of ITS databases for route planning and navigation, a feature type will be a class of features related to the road, such as speed limits and other regulations, or road equipment and the surrounding road environment, such as signs and railings. As one of the goals was to enable the exchange of information based on different and dynamic feature catalogues, no specific feature types were defined in the prototype. Instead, any feature catalogue with feature types modelled in application schemas according to ISO 19109 can be used.

An implementation schema for a GIS database can be derived from the Feature Catalogue application schema, and the original GIS Database Instances (the records in the database) can be stored and maintained in a GIS database according to the implementation schema. The original GIS database may also have a different implementation schema (e.g., for a national road database), and the instances are then converted to feature types in the specified feature catalogue for exchange (e.g., to the INSPIRE TN feature types).

The Feature Catalogue Exchange Model defines the structure for exchange of a feature catalogue. This approach enables the use of dynamic feature catalogues, and the receiver of the information will have access to an updated version of the feature catalogue. Implementation schemas are derived from the application schema, while the Feature Catalogue Instances (the representation of each feature type and their characteristics) are derived from the Feature Catalogue application schema for exchange.

The Feature Exchange Model application schema defines the structure of the actual instances that shall be exchanged and consists of two main parts: The Network Model, with a navigable network, and the Feature Model, with the generic model of features and their characteristics. Each Feature Exchange Instance refers to a Feature Catalogue Exchange instance that defines the model for the feature. Implementation schemas are derived from the application schema, while the Feature Exchange Instances are derived from the GIS Database instances.

GML was used as the implementation format for both the Feature Catalogue Exchange Model and the Feature Exchange Model in the study. Implementation schemas for other exchange formats (e.g., GeoPackage), may also be derived from the application schemas.

3.2. Feature Catalogue Exchange Model

ISO 19110 [60] describes an abstract conceptual model of a feature catalogue for geospatial information. The model is a realization of the General Feature Model from ISO 19109, and defines concepts for the feature catalogue, feature types in the catalogue, and feature type characteristics such as attributes and association roles. As ISO/TC 211 MDA, with reuse of concepts from ISO/TC 211 standards, is the first requirement in Table 2, the Feature Catalogue Exchange Model in the prototype was developed as a realization of the abstract model from ISO 19110. The model is illustrated in Figure 5.

The core concept is the class FeatureCatalogue, where an instance must include one or more feature types as instances of the class FeatureType. Attributes of feature types are instances of the class FeatureAttribute and can be either local attribute types for a specific feature type, or global attribute types for use on several feature types in the feature catalogue. Attributes for identifiers and names are examples of properties that may be reused on several feature types. The content of an attribute can either be a simple value, a value from a code list, or a structured value based on a data type. Code lists are instances of the class ValueDomain, code list values are instances of the class ListedValue, and structured values are instances of the class DataType. Associations between feature types are instances of the class FeatureAssociation and must be related to two instances of the class AssociationRole. Like attributes, association roles are also defined as a property of feature types. As FeatureAssociation is a subtype of FeatureType, an association may have attributes, as in the Relationship concept in GDF.

The Feature Catalogue Exchange Model contains some modifications from the abstract model in ISO 19110. First, all aggregations and composite associations are set unidirectional, to avoid duplication of information. The navigable direction is set from the “whole” to the “part” (e.g., from FeatureType to FeatureAttribute), which fits the hierarchical structure in an XML implementation. For a relational database, they might instead be set navigable in the opposite direction. Second, a specific class in ISO 19110 for describing inheritance relations between feature types has been replaced with a self-association on the class FeatureType, to simplify the model. Third, the concepts for connecting global properties to feature classes have been simplified. Finally, the classes for value domains and data types have been added to the model based on experiences from the case study. These classes do not exist in ISO 19110.

3.3. Feature Exchange Model

The network model in the INSPIRE GNM is based on a link and node structure, which is a common way of modelling a network in GIS [61]. Furthermore, the network models in OpenTNF and the INSPIRE GNM are very similar, and the TN-ITS specification also refers to INSPIRE for network representation. The Network Model part of the Feature Exchange Model in the prototype was, therefore, developed with the INSPIRE GNM as a foundation. The model is illustrated in Figure 6.

The core concept of the Network Model is the class Network, which is an aggregation of the abstract class NetworkElement, with non-abstract subclasses for Link, Node, LinkSequence, and NetworkConnections. The class NetworkConnection is used for connecting several networks (e.g., for connecting networks in different countries, counties, or municipalities, or even networks representing different transportation modes). The classes that represent the actual network elements are Link, which represents the centerline geometry of road segments, and Node, which represents the point geometry of the intersections where links meet. Furthermore, an ordered set of Link instances can be described as an instance of the LinkSequence class. While each link usually goes from intersection to intersection, a link sequence can represent longer sections. Each Link instance must have a specified direction in the LinkSequence, relative to the direction of the centerline geometry.

The Network Model part of the prototype has two modifications from the INSPIRE GNM. First, the INSPIRE GNM is an abstract model that is further specialized into implementable classes in the INSPIRE theme models, such as the Road Network Model in the INSPIRE TN specification. This specialization is not necessary for the generic approach in the prototype, and instead, the classes from the INSPIRE GNM were set as non-abstract. Secondly, all associations were set unidirectional in this model as well, in order to avoid duplication of information.

The second part of the Feature Exchange Model is the Feature Model that describes the generic concepts for exchanging features and their characteristics. Table 3 shows that generic exchange models are defined in OpenTNF, TN-ITS, and GDF. Of these, the TN-ITS specification is the only one that is based on ISO/TC 211 MDA. The Feature Model in the prototype was, therefore, developed based on the TN-ITS specification. The model is illustrated in Figure 7.

The core concept in the Feature Model is the FeatureSet class, where an instance must include at least one Feature instance. A Feature instance must have one or more location references (e.g., coordinate-based geometry, linear referencing, or a dynamic location reference, as defined in TN-ITS [25]). Furthermore, a Feature instance can have properties as instances of the GenericFeatureProperty class. As defined in the Feature Catalogue Exchange Model, a property can be an attribute with a simple value, such as a speed limit value; a code list value, such as the type of railing; a structured value, based on a data type; or it can be an association to another feature.

The Feature Model is generic, without specific attributes or association for any specific feature type. Instead, mandatory associations to FeatureType and PropertyType instances in the Feature Catalogue are used for defining the model of each Feature and GenericFeatureProperty instance. This generic concept gives flexibility for exchanging any feature type with any attribute type or association, given that it is described as Feature Catalogue Exchange Instances that are derived from a Feature Catalogue.

4. Case Study

4.1. Purpose and Workflow

The use case for the case study was that road or mapping authorities wish to set up one single service that can provide geospatial road-related information for different user groups in the ITS domain. One group of information receivers are map providers that need updated geospatial information according to the GDF Standard, for updating ITS databases that are based on the NDS Open Lane Model. Another group are public transport planners that need an updated road network with network properties according to the INSPIRE TN specification. The purpose of the case study was to test and validate the prototype based on this use case and to demonstrate how it can be implemented with feature types from different feature catalogues.

The case study was conducted in five steps, as illustrated in Figure 8. A selection of feature types was chosen from the GDF standard as the core standard for geospatial databases for ITS, while a selection of feature types from the INSPIRE TN specification was chosen to represent information specified by other feature catalogues. The specific processes and results for each feature catalogue are further described in Section 4.2 and Section 4.3.

The derivation of Feature Catalogue Instances from the Feature Catalogue application schemas was solved with a script developed in the UML software, Enterprise Architect [62]. This step was the implementation of the dashed “derive” arrow between the Feature Catalogue application schema and the Feature Catalogue Instances in Figure 4, and the result was GML files with Feature Catalogue Instances according to the Feature Catalogue Exchange Schema.

The original GIS database was a national road database where information is maintained according to an internal database schema. Instances were converted from the internal database schema to the application schema with the ETL (Extract, Transform, Load) software, FME [63], and exported to GML files as Feature Exchange Instances. This last step was the implementation of the dashed “derive” arrow between GIS Database Instances and Feature Exchange Instances in Figure 4.

GML Application Schemas and GML files from the case study are available online at https://github.com/jetgeo/ITSGML.

4.2. INSPIRE TN

Five feature types were selected from the INSPIRE TN specification: The road network elements RoadLink, RoadNode, and RoadLinkSequence, and the network properties SpeedLimit and FunctionalRoadClass, as shown in Figure 9. These feature types were selected as they were considered particularly important information for route planning and navigation. The models were already conformant with ISO 19109, and the complete feature catalogue for the INSPIRE TN Specification could be derived to Feature Catalogue Exchange Instances in GML format without modification.

An extract of the derived Feature Catalogue Exchange GML is shown in Figure 10 with the instance for the FunctionalRoadClass feature type. Inheritance of characteristics from the TransportPropery class in the UML model is represented by the inheritsFrom tag and a link to the instance for that class. As shown in the UML model in Figure 9, FunctionalRoadClass has one attribute (functionalClass) with values from the code list FunctionalRoadClassValue. This code list is referred to in the GML file in Figure 10 with the valueDomain tag.

Extracts of the Feature Exchange GML file with instances of the feature types FunctionalRoadClass and SpeedLimit are shown in Figure 11 and Figure 12 References to definitions of feature types and attributes are represented by the featureTypeReference and propertyTypeReference tags. In the examples, these references are set to a local file (TransportNetworks.GML), but for real implementation, they would likely be set to a URL instead.

The FunctionalRoadClass instance in Figure 11 represents a road section classified as functional road class “thirdClass”, described by the valueReference tag. The SpeedLimit instance in Figure 12 represents a road section with a maximum speed limit of 50 km/h. The type of speed limit (maximum) is described by the valueReference tag, while the speed limit is described by the value tag.

4.3. GDF

From GDF, the feature types RoadElement and Junction and the relationship ProhibitedManoeuvre were selected as examples of network and network regulations, and the feature type PedestrianCrossing was selected as an example of information related to the network. The models had to be modified slightly to conform with ISO 19109, primarily by using stereotypes and datatypes defined in ISO 19103 and ISO 19109.

Figure 13 shows the ISO 19109 compliant model of GDF RoadElement, Junction, and Manoeuvre, where the network feature types RoadElement and Junction are modelled as subtypes of the general network elements Link and Node from the Network Model part of the Generic Feature Exchange Model. Figure 14 shows the ISO 19109 compliant model of GDF PedestrianCrossing, with a reduced number of attributes for the case study.

The modified extract of the feature, relationship, and attribute catalogues from GDF was derived to Feature Catalogue Exchange Instances in GML format. Figure 15 shows an extract of the Feature Catalogue Exchange GML file with the instance for the abstract Manoeuvre feature type with associations to RoadElement and Junction, and the ProhibitedManoeuvre feature type with an inheritance from Manoeuvre.

Figure 16 and Figure 17 show extracts of the Feature Exchange GML file with feature instances of the feature types ProhibitedManoeuvre and PedestrianCrossing.

5. Discussion

The comparison and evaluation of standards and specifications for geospatial road-related information in Table 3 shows that none of the studied solutions meets all the requirements described in Table 2. A prototype for an improved solution was, therefore, developed and implemented in a case study. In

Table 4. Evaluation of the prototype.

Requirement	Description	Requirement Fulfilled
ISO/TC 211 MDA	The application schemas in the prototype are based on MDA according to ISO/TC 211 standards, particularly the General Feature Model from ISO 19109 and the abstract conceptual feature catalogue model from ISO 19110. Implementation schemas are derived from the application schemas.	Yes
GIS exchange format	The exchange format used in the prototype is GML, which is the standardized GIS exchange format defined in ISO 19136. With the MDA approach, implementation schemas for other formats, such as GeoPackage, may also be derived.	Yes
Feature catalogue	The prototype does not contain a feature catalogue of its own, but can implement any feature catalogue modelled as an application schema according to ISO 19109. Selected feature types from the feature catalogues from INSPIRE TN and ISO 14825 GDF were implemented in the case study. The INSPIRE TN model was used directly, while the GDF model was modified to be compliant with ISO 19109.	Yes
Feature catalogue exchange model	The prototype contains the Feature Catalogue Exchange Model and a derived feature catalogue exchange schema for exchange in GML.	Yes
Network model	The Feature Exchange Model in the prototype contains the Network Model based on the INSPIRE GNM.	Yes
Generic feature exchange model	The Feature Exchange Model in the prototype contains the Feature Model, which is a generic feature model based on the TN-ITS model. An implementation schema for the exchange of network and features in GML was derived from the model.	Yes

, the prototype is evaluated against the requirements from Table 2. The evaluation indicates that the prototype meets all requirements used in the study.

In

Table 5. Comparison of concepts from feature catalogue exchange models.

Prototype	GDF	OpenTNF
Feature catalogue	GDF (the standard)	Catalogue
Feature type	Feature	Property object type
Feature association	Relationship	Property object type
Feature attribute	Attribute	Property object property type
Association role	Role in relationship	Property object property type
Value domain	Not defined	Value domain
Listed values	Attribute data type code list	Valid value
Data type	Composite attribute	Value domain and structured value domain property type
Global attribute types	All attribute types are global	All attribute types are local, but with global value domains
Inheritance	Not defined	Not defined

, concepts from the Feature Catalogue Exchange Model are compared to models from two of the studied solutions: The overall conceptual data model from GDF and the Transport Object Property Catalogue from OpenTNF. The comparison shows that the prototype covers the concepts for feature cataloguing defined in the two solutions, but with some improvements. First, the catalogue concept is not defined in GDF. Instead, the GDF standard is the catalogue. Furthermore, GDF does not have the concept of value domains. Global attribute types are not handled directly in OpenTNF, but rather through the concept of global value domains that may be related to many attribute types. Finally, inheritance relations are neither described in the feature catalogue models for GDF nor for OpenTNF, which means that every feature type must be described with all their properties individually.

The Network Model part of the Feature Exchange Model in the prototype is based on the models from INSPIRE, which are similar to the model in OpenTNF. In addition to these, Table 3 shows that the GDF standard and the NDS Open Lane Model contain network models as well.

Table 6. Comparison of concepts from network models.

Prototype	INSPIRE	OpenTNF	GDF	NDS Open Lane Model
Link	Link (GNM) Road link (TN)	Link	Non-planar topo line feature, Road (level 2) Road element (level 1) Edge (level 0)	Link, Road geometry line
Node	Node (GNM) Road node (TN)	Node	Non-planar topo point feature Intersection (level 2) Junction (level 1) Node (level 0)	Intersection
Link sequence	Link sequence (GNM) Road link sequence (TN)	Link sequence	Not defined	Not defined

presents a comparison of concepts from the Network Model in the prototype and the network models from INSPIRE, OpenTNF, GDF, and NDS Open Lane Model. The comparison shows that the two solutions from the ITS domain (GDF and NDS Open Lane Model) do not have the link sequence concept. The link and node concepts exist in all solutions in the table, which indicates that the Network Model in the prototype covers the fundamental concepts required for the exchange of network elements to ITS databases. However, the complexity described in GDF with different topology types and different levels of feature representation is not covered by the prototype. Furthermore, network information at lane-level is described both in the NDS Open Lane Model and in GDF 5.1 Part 2, but is not covered by the prototype. These issues may be topics for further studies.

The Feature Model part of the Feature Exchange Model in the prototype is based on the feature model in TN-ITS. In addition to these, Table 3 shows that GDF and OpenTNF also contain generic feature exchange models. The Feature Model in GDF is particularly essential, as GDF is the core standard for exchanging information for use in ITS databases. A comparison of the concepts in the Feature Model in the prototype and the equivalent models in TN-ITS, OpenTNF, and GDF are presented in

Table 7. Comparison of concepts from generic feature models.

Prototype	TN-ITS	OpenTNF	GDF
Feature	Road feature	Property object	Feature, Relationship
Association to location reference	Association to location reference	Network reference, Direct location reference	Node, Edge, Face
Association to Feature Type	Attribute: “type”, referring to code list	Attribute: Property object type	Reference to feature class ID
Feature property	Road feature property	Property	Attribute
Association to Property Type	Attribute: “type”, referring to code list	Embedded in attribute XML	Reference to attribute class ID

.

The comparison in Table 7 shows that the Feature Model in the prototype covers concepts described in other solutions, including the Feature Model in GDF. This implies that the Feature Model in the prototype covers the fundamental concepts required for the exchange of features to ITS databases. The prototype has the advantage of direct associations between features and properties and their models in the Feature Catalogue. GDF refers to class IDs that must be looked up in the standard, while TN-ITS refers to code lists without any further model details.

The prototype was tested for implementation in the case study, by using the feature catalogue from INSPIRE TN and a modified extract of the feature, relationship, and attribute catalogues from GDF. The results from the case study show that the prototype may be used with different feature catalogues if these are modelled according to ISO 19109. For the selected features from GDF, only minor modifications were needed, which indicates that the models of features, relationships, and attributes described in GDF can be modified according to ISO 19109. The prototype may then be used for exchanging features and their characteristics as described in GDF from GIS databases.

6. Conclusions

This study has analyzed existing standards and specifications for describing and exchanging road-related geospatial information from GIS to ITS databases, based on six requirements. The analysis reveals that none of the studied solutions meets all six requirements, but that several are promising candidates for further development of an improved solution. The GDF standard, the INSPIRE Transport Networks specification, the TN-ITS specification and the OpenTNF specification were considered as the most promising, while the NDS Open Lane Model was considered essential, as it defines the model of an ITS database.

A prototype for an improved solution was developed in the study, aiming to cover all six requirements and to enable the exchange of information described both by the GDF standard and by other feature catalogues. The prototype is based on the MDA principles from ISO 19103 and 19109 and is modelled in UML, with derived implementation schemas in the GML exchange format. Three application schemas conformant to ISO 19109 define the framework of the prototype: The Feature Catalogue, the Feature Catalogue Exchange Model based on ISO 19110, and the Feature Exchange Model with the Network Model and the Feature Model. The models are generic, and no specific feature types are defined in the Feature Catalogue. Instead, feature types from GDF and other solutions may be used. A case study was conducted to test and validate the prototype, with selected feature types from the INSPIRE Transport Networks specification and the GDF standard. The results from the case study show that feature types modelled according to ISO 19019 may be used directly in the model, and that feature types from the GDF standard may be used with minor modifications.

A comparison between the prototype and the most promising solutions from the initial studies indicates that the prototype covers the concepts defined in other solutions while having several improvements. Compared to GDF, which is considered the primary standard for exchanging geospatial information for use in ITS databases, the prototype is more suitable for implementation in GIS applications, and has more flexible handling of feature catalogues. The prototype may be a candidate for improved information exchange from road authorities’ GIS databases to ITS databases based on the NDS Open Lane Model. However, as it is a prototype, it is not complete and may be extended to cover topology levels and lane-level navigation, as well as implementation in other formats, such as GeoPackage.