Development of a Conceptual Data Model for 3D Geospatial Road Management Based on LandInfra Standard: A Case Study of Korea

Abstract

In practice, road management data are typically managed in two-dimensional (2D) geospatial forms. However, 2D geographic information system (GIS)-based road infrastructure management data have limitations in their representation of complex roads, such as interchanges, bridges, and tunnels. As such, complex and large road network management data cannot be adequately managed in a 2D GIS-based form. This study discusses the use of the LandInfra standard for road infrastructure management in Korea, considering its focus on land and civil engineering infrastructure facilities. To facilitate the transition from 2D to 3D GIS, we analyzed existing road management models of road pavement and road register information and created Unified Modeling Language (UML) class diagrams depicting these models. Then, existing road management classes and LandInfra classes were mapped. Based on the results, we propose a road management model based on the Facility, Alignment, and Road parts of LandInfra. For its implementation, several classes of the proposed data model were encoded into InfraGML using real-world data input. Taken together, this study shows how the LandInfra standard can be extended and applied to the field of road infrastructure management in Korea, supporting the transition from a 2D to a 3D GIS-based model.

1. Introduction

1.1. Geo-Information in Road Management

Roads connect transport systems and influence quality of life and economic development, in addition to being a promising player in increasing sustainability on a global level [1]. As a core component of transport networks, the quality of roads affects the daily lives and productivity of its users in terms of both time and cost [2]. Given the importance of road networks, the provision of good conditions for road traffic, as well as road maintenance and management, are indispensable. Road infrastructure requires effective and timely maintenance and management to extend its service life where possible [2]. Road infrastructure comprises all physical assets of the road, including all relevant road facilities and geotechnical works, drainage, and road structures (e.g., bridges and tunnels) [3]. An example of a typical road facility (i.e., physical assets) as a cross-sectional view is provided in Figure 1.

However, the management and maintenance of roads and highways require substantial data for decision making in relation to road repairs, as well as the monitoring and assessment of road conditions, roadwork prioritization, and the estimation of the relevant budgets. Other road maintenance activities include snow removal, road repairs, milestone management, and road furniture replacement [4]. At present, information related to road management and maintenance is generally digitized and stored in a GIS-based form in a database, known as the road management system, for use in the maintenance and management of road pavements [5,6,7], road assets (road register) [8,9,10], and integrated road management systems [11,12,13].

Most road management data in these systems are currently managed in two-dimensional (2D) geospatial forms. However, 2D GIS-based road infrastructure management data are limited in their ability to represent complex road asset information, including interchanges, bridges, tunnels, underpasses, and overpasses, among other road and roadside facilities [15,16]. Furthermore, within the context of road network management, which forms part of road infrastructure management, representing complex road networks and inventories and applications of intelligent transport systems, lane-oriented traffic flow analysis requires a multi-dimensional geodata model [17,18]. In this respect, 3D GIS-based road information can not only better represent the complexity of road assets but can also improve road management practices, with the possibility of accounting for the life cycle of infrastructure and city models [4,15].

Several studies have explored the application of 3D GIS to road management. For example, user requirements for 3D road inventories [15] and detailed information on different road assets, such as carriageways and intersections, were recently included in the CityGML Transportation module based on v2.0 [4]. CityGML is an open data standard that defines a conceptual model and exchange format for the representation, storage, and exchange of virtual 3D city models [19]. CityGML is used in many applications, particularly CityGML at the level of detail (LoD) 2, when representing 3D road traffic space [20], as well as describing road spaces [21,22] and road assets, such as bridges, tunnels, and city furniture (e.g., safety and traffic signs, bus stations, and street lamps), in detail [23].

In addition to CityGML, there are other standards related to the presentation and exchange of road and transportation information depending on the purpose; these include Land and Infrastructure (LandInfra), Infrastructure for Spatial Information in Europe (INSPIRE), Open Street Map (OSM), Industry Foundation Classes (IFC), Geographic Data Files (GDF), OpenDrive, RoadXML, and Austroads. A number of studies have evaluated these standards by reviewing and comparing them [4,21,22,24,25,26,27,28]. The objectives of these standards vary and can be summarized as follows: OpenDrive, GDF, and RoadXML are used for automobile applications; INSPIRE, OSM, and CityGML are used for digital urban modeling; LandInfra and IFC are used for civil engineering [22]; and Austroads is a data standard for road management and investment activities in Australia and New Zealand [26].

Although the LandInfra standard is a comparatively new standard and InfraGML has no explicit software implementation support, the standard is not often utilized in practice [10,22,29]. Several studies have discussed potential real applications of LandInfra in general, or roads in particular; these include implementing InfraGML with IFC Alignment for the verification of transferring information between different systems/software [30]; reviewing the application of LandInfra for road asset information exchange [25]; development of the CityGML application domain extension for LandInfra [29]; integration of data standards such as CityGML, IFC, and Building Information Model (BIM)-GIS using LandInfra for providing interoperability [31,32,33]; examining the applicability of LandInfra to street space modeling [21,22]; and transportation infrastructure [24]. Although other studies [11,14] have provided detailed approaches for applying LandInfra to a local road management system for application-specific cases, the LandInfra standard remains widely unused in practice.

In this study, a conceptual data model for road infrastructure management using the LandInfra standard in a local context in Korea was discussed in the context of implementing 3D geospatial road management taking into consideration the focus of this standard on land and civil engineering infrastructure facilities and its further potential. In the following section, an overview of the LandInfra standard for road infrastructure management is provided.

1.2. LandInfra Standard for Road Infrastructure Management

The Open Geospatial Consortium (OGC) first developed the international open standard LandInfra conceptual model standard in 2016 [34]. The LandInfra standard is based on a subset of LandXML functionality [34]. LandXML is an XML-based open data format used to store civil engineering and survey measurement data in the domains of land and transportation [35]. The LandInfra conceptual model is depicted on a Unified Modelling Language (UML) and implemented in the InfraGML encoding standard.

The requirements classes of LandInfra include LandInfra, Facility, Project, Alignment, Road, RoadCrossSection, Railway, Survey, Equipment, Observations, Survey Results, LandFeature, LandDivision, and Condominium. This study exclusively explores the requirements classes LandInfra, Facility, Alignment, and Road, as the specific application subject is roads. Among these, LandInfra is the core and only mandatory class. This class contains information about the datasets of all requirements classes, Facility comprising buildings, civil engineering works, and their related sites. However, Alignment is used as a positioning element and provides a linear referencing system for physical elements, while Road is used to represent road elements in 3D.

In support of the implementation of LandInfra, InfraGML can be divided into eight parts—LandInfra Core, LandFeatures, Facilities and Projects, Alignments, Roads, Railways, Survey, and LandDivision. The various InfraGML parts and their associations are depicted in Figure 2. The fourth part is Road, and for its support, an application should support InfraGML Core (Part 0), LandFeature (Part 1), and Facility (Part 2). Furthermore, it may support the Alignment (Part 3) requirements class. Each of these parts is implemented into the corresponding InfraGML parts.

This study builds on the findings of previous studies [10,13], with the aim of developing a conceptual data model based on the LandInfra standard for road infrastructure management in Korea in order to facilitate the support of road management by 3D geoinformation while also investigating potential further applications of LandInfra. To achieve this goal, the development of the LandInfra-based data model was investigated from two perspectives: (1) use of the standard as a leverage to improve the current 2D GIS-based road management model to the real-world 3D geospatial information-supported model; (2) definition of a platform-independent conceptual standard data model to facilitate the exchange of road information and its interoperability among other platforms, infrastructure projects, and standards, as well as a useful input for its possible implementation in smart cities and digital twin applications. Therefore, the overall research purpose was directed to answer the following questions in the context of enabling 3D geospatial road management: (1) How should the LandInfra standard be extended for the Korean road management model?; (2) Which classes of the Korean road management model can be mapped to LandInfra?; (3) How can the LandInfra-based country-specific model be encoded using the InfraGML encoding standard?”.

The remainder of this paper is organized as follows. Section 2 describes the methodology, wherein we analyze and present a UML class diagram of the road infrastructure management model for the national highway in Korea. In addition, for the development of the LandInfra-based conceptual data model, mapping between LandInfra and the road management model was performed. Section 3 presents the results of the study, which describe the creation of the LandInfra-based road infrastructure management data model using a UML class diagram; some instances were created using the InfraGML encoding standard. Lastly, in Section 4, the conclusions, limitations, and future perspectives of the study are discussed.

2. Materials and Methods

In this section, the methodology used in the present study is described. First, we discuss a road-management model for applying the LandInfra standard. In particular, we consider a road management model for the national highway management system in Korea [12]. Our scope was narrowed to road management systems of pavement and road registers. For the latter, we obtained and used publicly available data.

A data model of these systems is given by an entity relationship diagram (ERD) in Korean [12]. The comparison and modeling of the road management model to the LandInfra requirements classes required converting the ERD to a UML class diagram. After creating the UML diagrams, we mapped the corresponding road management classes to LandInfra. A data model of road infrastructure management was designed and proposed based on the counterparts of LandInfra. For implementation, several classes of the proposed models were encoded using the InfraGML encoding standard.

An analysis of highway management systems, including both road pavements and road registers, was performed, as described in Section 2.1, while the mapping results of the road management systems and LandInfra are discussed in Section 2.2.

2.1. Highway Management System (Model) in Korea

Generally, there are four stages in the life cycle of road assets: planning, construction, operation, and maintenance [37]. The majority of research studies in this field have discussed the operation and management of road-related assets, as information about road infrastructure plays an important role in better decision making [38]. Highway management system information is used for road management, operation, and maintenance alike.

In Korea, as of 2020, the national highway is approximately 14,098 km long and has 78 routes [39]. A representation of the national highway network is provided in Figure 3a. To manage roads and maintain good conditions, road maintenance and management systems were introduced in the Road Act of Korea, the operation of which allows for the systematic and scientific management of the main facilities of roads [40].

The main concepts of road maintenance and management systems, including the Highway Management System (HMS), Pavement Management System (PMS), Cut Slope Management System (CSMS), Bridge and Tunnel Management System (BTMS), Road Sign Management System (RSMS), Traffic Monitoring System (TMS), Road Snow Removal Management System (RSRMS), Road Problem Reporting System (RPRS), Road Occupation and Access System (ROAS), Road Statistics and Maintenance Information System (RSMIS), and Korea Road Register Information System (KRRIS), which are currently in operation, are illustrated in Figure 3b. Among these systems, the HMS has been developed and operated since 2003 for the management of national highways to integrate other systems [13]. The HMS was first introduced to provide geoinformation on road infrastructure, including road pavements, bridges, tunnels, road cut-slopes, road signs, traffic volume, and road registers (e.g., drawings and geometric design). Road management systems and our application subject systems are shown in Figure 3b (the road pavement and road register systems are in green).

2.1.1. Analysis of Pavement Management System

Since 1997, the pavement management system has been in operation to ensure efficient road maintenance, including managing the status of national highways by route, conducting pavement surveys and analysis of road sections, and selecting maintenance sections (including repair methods and costs) [40]. Based on the analysis of pavement conditions, sections with cracks or deformities are selected and maintained using the optimal repair method, within budgetary constraints [41]. Data that are run on the road pavement information system are collected through pavement surveys and analysis in the field [13], whereby the obtained information comprises several classes. Figure 4 shows the UML class diagram for pavement management information.

In this study, several classes of the PMS, including the pavement survey section, pavement analysis section, survey required section, rehabilitation history, and methods, were excluded considering the necessity to be modeled in LandInfra. In addition, we corrected several class names to improve readability. The pavement UML classes are listed in

Table 1. Road pavement class description.

No.	Class Name	Description
1	PMS_ROUTE_GENERAL	Route information
2	PMS_EVENT	Event information
3	PMS_EVENT_CODE	Event code
4	PMS_REHAB_CODE	Road maintenance code
5	PMS_TRF_VOL	Traffic volume
6	PMS_ROUTE_CODE	Route code
7	PMS_PR_CODE	Administrative area code
8	PMS_MCO_CODE	Management office code
9	PMS_ASP_STRUC	Asphalt structure
10	PMS_CON_STRUC	Concrete structure
11	PMS_PAV_SURV	Pavement condition

, with attributes such as road ID, offset (distance), and length.

PMS_ROUTE_GENERAL is the main class that represents the fundamental information of national highways, including the direction of the road, province (location), number of lanes, lane width, construction date, and the time that the road was first paved. The code PAVEMENT indicates whether a road was paved for the first time or repaved. The PMS_ROUTE_GENERAL class can have zero or more (0..*) PMS_EVENT classes, which describe the bridge name, length, lanes, and administrative boundary.

The classes PMS_EVENT_CODE and PMS_REHAB_CODE can have zero or more PMS_EVENT classes. PMS_EVENT_CODE describes events and has the codelist EVENT_DESC, which indicates whether an event is a bridge, administrative boundary, highway, expressway, or a local road. PMS_REHAB_CODE indicates road rehabilitation-related attributes and has the codelist REHAB_DESC, which indicates the type of treatment performed on the surfaces of roads with many lanes (e.g., 4 lanes and road patching, 4 lanes and surface treatment or 2 lanes and resurfacing, and 2 lanes and first pavement).

The PMS_ROUTE_GENERAL class can have zero or more PMS_TRF_VOL classes, which contain information regarding the traffic volume on a specific route or road. The PMS_TRF_VOL class has attributes of traffic volume observation point ID, year of traffic survey, and total average daily traffic (ADT) for light vehicles, buses, and trucks.

The classes PMS_ROUTE_CODE, PMS_PR_CODE, and PMS_MCO_CODE can have zero or more PMS_ROUTE_GENERAL classes. PMS_ROUTE_GENERAL must have one PMS_ROUTE_CODE, PMS_PR_CODE, or PMS_MCO_CODE class, and vice versa.

PMS_ROUTE_CODE describes the road ID and road code as the ROUTE_CODE list, which contains 78 routes of national highways. PMS_PR_CODE provides information on the province to which a specific road belongs and has a PR_CODE codelist providing the names of the Korean provinces, which are coded accordingly. PMS_MCO_CODE describes the road management office using the codelist MCO_CODE, wherein offices from each region and/or province are listed with their corresponding codenames.

The PMS_ROUTE_GENERAL class includes one or more (1..*) PMS_ASP_STRUC, PMS_CON_STRUC, and PMS_PAV_SURV classes. The classes PMS_ASP_STRUC, PMS_CON_STRUC, PMS_PAV_SURV, PMS_TRF_VOL, and PMS_EVENT must have one PMS_ROUTE_GENERAL class, and vice versa.

The PMS_ASP_STRUC, PMS_CON_STRUC, and PMS_PAV_SURV classes are core classes of pavement information that fundamentally describe the pavement types and layers and pavement condition information. In particular, PMS_ASP_STRUC describes the structure of the asphalt of the pavement and contains attributes such as the thickness of each layer (e.g., asphalt, bituminous, gravel), the number of lanes, and lane width. PMS_CON_STRUC provides information on the pavement concrete structure, including the attributes of the thickness of each layer (e.g., slab, base, subbase), the number of lanes, and lane width. Both of these classes can be attributed to a PAVEMENT codelist, which indicates whether that pavement has been paved for the first time or not (repaved). The PMS_PAV_SURV class is used to provide road pavement survey condition information, which includes attributes related to road damage and deterioration, such as rutting types, crack types, the international roughness index (IRI), and skid resistance. A schematic presentation of the pavement structure is depicted in Figure 5.

In Section 2.1.1, we discussed the data model of PMS in Korea in detail. We identified the main classes of road pavements with their respecting codelists for further modeling with the LandInfra standard. Since the main classes of pavement information are the pavement layer-related classes of PMS_ASP_STRUC and PMS_CON_STRUC, we have provided a simple illustration to help in the understanding. Furthermore, the aforementioned pavement information classes were mapped and compared to the classes of LandInfra to enable a possible extension of the standard for the Korean road management model of pavement in the context of facilitating 3D road geoinformation.

2.1.2. Analysis of Road Register Information System

The road register is an official record of roads, roadside facilities, and/or assets. Its maintenance is officially mentioned in Article 24 of the enforcement rule of Article 56 of the Road Act of Korea. Road register-related information is managed and maintained in the Korea Road Register Information System (KRRIS), which is not publicly available.

Road register information can be grouped into six main types—main facilities (e.g., bridges and tunnels), road geometry (e.g., road curves and longitudinal slopes), geotechnical and drainage (e.g., gutters and retaining walls), safety facilities (e.g., median strips and guardrails), additional facilities (e.g., underground facilities and signs), and others (e.g., land use and pay roads) [9]. Figure 6 provides a general overview of the road register, consisting of 44 types of registration objects (classes).

However, not all types of the aforementioned road register classes were used in this study because of the information provided by the report [13]. Instead, road register information consisting of 21 classes and 17 codelists were used. The UML class diagrams and codelists are presented in Figure 7 and Figure 8, respectively.

Table 2. Road register class description. Spatial data types and presence of data were confirmed against the data used in this study.

No.	Class Name	Description	Spatial Data Type	Presence of Data
1	MROAD	Road register	Line	Yes
2	REALNTH	Real length	Line	Yes
3	LANDUSE	Road space/area	Polygon	No
4	DETOUR_ROAD	Detour road	Line	No
5	SIDE	Side gutter	Line	Yes
6	STONE	Stone embankment	Line	No
7	XPOINT	Road geometry	Line	Yes
8	WALL	Retaining wall	Line	Yes
9	DEFENCE	Guardrail	Line	Yes
10	BOX_PIPE	Drainage culvert and pipe	Polygon	Yes
11	SIGN	Road sign	Point	Yes
12	NORI	Rockslide prevention facility	Line	No
13	PAY_ROAD	Toll road	Line	No
14	DIP_EQP	Underground facility	Line	Yes
15	DRAWING	Drawing	-	No
16	SLOPE	Longitudinal slope	Line	Yes
17	ROAD_AREA	Area near road	Polygon	No
18	BRIDGE_REGISTER	Bridge register	Polygon	No
19	BRIDGE	Bridge	Polygon	Yes
20	STR_DWG	Structural drawing	-	No
21	TUNNEL	Tunnel	Polygon	NA

provides a brief description of these classes and their spatial data characteristics.

The main road register comprises classes MROAD, REALNTH, LANDUSE, DETOUR_ROAD, SIDE, STONE, XPOINT, WALL, DEFENCE, BOX_PIPE, SIGN, NORI, PAY_ROAD, DIP_EQP, DRAWING, SLOPE, and ROAD_AREA. The road structure-related road register classes of BRIDGE_REGISTER, BRIDGE, STR_DWG, and TUNNEL are depicted separately in Figure 9.

The MROAD class contains attributes that are relevant to the general and fundamental information of the road register. MROAD spatially represents roads as a centerline, with attributes such as the relevant road section information regarding the section length and information on bridges, tunnels, land use, and road geometry. In addition, all classes include the following attributes: road management office, road number, section number, section start location in kilometers (linear reference), and road direction, (e.g., upward or downward). The MROAD class is associated with one or more road register classes.

The rest of the classes can be categorized into road register objects (assets), as shown in Figure 6: BRIDGE and TUNNEL for the main facilities; XPOINT and SLOPE for road geometry; SIDE, STONE, WALL, and BOX_PIPE for geotechnical and drainage; DEFENCE, NORI, and SIGN for safety facilities; DIP_EQP for additional facilities; and REALNTH, LANDUSE, PAY_ROAD, DETOUR_ROAD, and ROAD_AREA for other classifications.

In particular, the BRIDGE class covers the fundamental information with regards to bridges, including structure type, structure name, and structure level. BRIDGE can have zero or more BRIDGE_REGISTER classes, which provide the most important features of bridges, including bridge construction-related information (e.g., constructor, supervisor, and construction cost), bridge size information (e.g., height, width, road width, and sidewalk width), bridge material (e.g., wooden, steel, and reinforced concrete), facility information (e.g., tunnel and road area), and bridge-related geometries (e.g., minimum road width, radius of the curve, and longitudinal slope). BRIDGE and TUNNEL have zero or more structural drawings (STR_DWG). The TUNNEL class in the road register provides basic information regarding the nature of tunnels, including the tunnel length, road, sidewalk, and shoulder within a tunnel, as well as other information, such as height, light, and sidewall.

XPOINT provides information regarding road geometry, including the start and end of the curve, intersection angle, curve radius, and clothoid curve information, whereas SLOPE contains information regarding longitudinal slopes, including the section start height and slope length. SIDE is used to represent the gutter and its size information (e.g., length, height, and width) and has the accompanying codelist GUT_TYPE denoting the gutter types. STONE is used to denote a stone wall that retains earth stability, with attributes that include the facility length, height, and material information. WALL denotes a retaining wall, which, in addition to its facility length, height, and area, has a WALL_TYPE codelist. BOX_PIPE is used for drainage and culverts and provides dimensional information for pipes, such as diameter, length, facility material attributes, and PIPE_TYPE codelist.

DEFENCE denotes a protective wall and a guardrail and contains the FACIL_TYPE codelist, which indicates the composition of the material. NORI is a type of rockslide prevention facility that contains length, height, and material information and has a PIPE-TYPE codelist. SIGN is a road sign and includes information regarding the sign name, sign code, and day of installation. It contains the SIGN_TYPE (role of the sign) and INSTALL_TYPE (installation method of the sign) codelists. The DIP_EQP class represents underground facilities and their dimensional attributes such as size, length, and material; it has management office and occupation permission number attributes and the UNDER_FACIL_TYPE (types of underground facilities) codelist.

REALNTH is used to denote the real lengths of road elements, such as the lengths of roads, bridges, tunnels, sections, road widths, medians, left and right shoulders, and sidewalks. LANDUSE represents the land use type along a road, that is, the basic cadastral information around roads, such as section addresses, land use purposes, land used for roads, private lands, and permission numbers. It has the codelist LU_PURPOSE (the type of land use purpose). PAY_ROAD denotes toll roads and the lengths of facilities such as roads, bridges, and tunnels, and other toll-related information. DETOUR_ROAD denotes bypass roads and has attributes of the bypass start location in kilometers, as well as the length, width, and pass-through area. In addition, it has the ROAD_TYPE (types of code) codelist. ROAD_AREA denotes the area near roads and contains attributes such as road length, designated road area length, location, and poles on both the left and right sides.

In Section 2.1.2, we discussed the data model of the road register system in Korea specifically. First, we discussed the registration objects of the system, and then some of its relevant classes were discussed with their respective codelists in detail. The data model of the road register system was described in two parts: the road register classes of roads and roadside facilities, such as the road centerline model, road geometry, longitudinal slopes, and retaining walls, and road structure-related classes, namely bridges and tunnels. Moreover, classes of the road register information were mapped and compared to the classes of LandInfra to be extended for the Korean road management model in the context of enabling 3D road geospatial information.

2.2. Mapping between Classes from the Road Management Model and LandInfra

To apply road management classes to the LandInfra standard, an investigation of the corresponding classes between the road management classes and LandInfra requirements classes was required. This process is known as mapping, and the first step towards mapping is to match the corresponding classes by identifying each class [10,13].

For pavement information, the pavement classes PMS_ASP_STRUC and PMS_CON_STRUC are mapped to the RoadElement class, as these classes are considered elements of the road. PMS_PAV_SURV, which describes road condition information, corresponds to the PhysicalElement of the Facility part. PhysicalElement specifies the physical part of the Facility part [34].

PMS_ROUTE_GENERAL, which is a general route class, contains the route information. It corresponds to the Road class, as the Road class contains general information on a route. The PMS_TRF_VOL, PMS_ROUTE_CODE, PMS_PR_CODE, PMS_MCO_CODE, PMS_EVENT, PMS_EVENT_CODE, and PMS_REHAB_CODE classes indirectly correspond to the Road class through the PMS_ ROUTE_GENERAL class. These classes cannot be mapped to the LandInfra classes because of their supporting characteristics in the pavement information model. Specifically, PMS_TRF_VOL, which contains traffic volume information on a specific route, does not correspond to any class in LandInfra, as the standard only focuses on the physical elements of roads and infrastructure facilities.

For road register information, the MROAD, REALNTH, DETOUR_ROAD, and PAY_ROAD classes, representing parts or sections of roads, correspond to the Alignment class of the Alignment part. LANDUSE and ROAD_AREA classes, representing road spaces and areas near roads, can be the PhysicalElement class of the Facility part when FacilityPartType is set as a road. Since the SIDE, STONE, WALL, DEFENCE, BOX_PIPE, SIGN, NORI, and DIP_EQP classes support roads, these classes were mapped to RoadElement. As the XPOINT class describes the geometrical information of roads, including the curvature, the intersection angle, and the radius of the curve horizontally, this class can correspond to the Alignment2DHorizontal class of the Alignment part. The SLOPE class describes the road slope vertically, which corresponds to the Alignment2DVertical class of the Alignment part. Alternatively, SLOPE can correspond to the Road class, where attributes from SLOPE can be used to represent 3D roads.

The DRAWING and STR_DWG classes represent roads as computer-aided design (CAD) drawings. DRAWING, which denotes a sectional road plan or longitudinal view plan for road registers, was mapped to the Alignment class. STR_DWG, which denotes the structural drawing of bridges and tunnels, was mapped to the FacilityPart class along with the BRIDGE and TUNNEL classes.

BRIDGE_REGISTER, BRIDGE, and TUNNEL describe the structural information of roads, and these classes could correspond to the FacilityPart class of the Facility part because Facility has subtypes of such facilities. The mapping results are summarized in

Table 3. Mapping of corresponding classes between the road management model and LandInfra.

No.	Road Management Class	LandInfra Class	Part
1	PMS_ASP_STRUC	RoadElement	Road
2	PMS_CON_STRUC	RoadElement	Road
3	PMS_PAV_SURV	PhysicalElement	Facility
4	PMS_ROUTE_GENERAL	Road	Road
5	PMS_TRF_VOL	Road	Road
6	PMS_ROUTE_CODE	Road	Road
7	PMS_PR_CODE	Road	Road
8	PMS_MCO_CODE	Road	Road
9	PMS_EVENT	Road	Road
10	PMS_EVENT_CODE	Road	Road
11	PMS_REHAB_CODE	Road	Road
12	MROAD	Alignment	Alignment
13	REALNTH	Alignment	Alignment
14	LANDUSE	PhysicalElement	Facility
15	DETOUR_ROAD	Alignment	Alignment
16	SIDE	RoadElement	Road
17	STONE	RoadElement	Road
18	XPOINT	Alignment2DHorizontal	Alignment
19	WALL	RoadElement	Road
20	DEFENCE	RoadElement	Road
21	BOX_PIPE	RoadElement	Road
22	SIGN	RoadElement	Road
23	NORI	RoadElement	Road
24	PAY_ROAD	Alignment	Alignment
25	DIP_EQP	RoadElement	Road
26	DRAWING	Alignment	Alignment
27	SLOPE	Road	Road
		Alignment2DVertrical	Alignment
28	ROAD_AREA	PhysicalElement	Facility
29	BRIDGE_REGISTER	FacilityPart	Facility
30	BRIDGE	FacilityPart	Facility
31	STR_DWG	FacilityPart	Facility
32	TUNNEL	FacilityPart	Facility

.

3. Results

3.1. Proposed Data Model Based on LandInfra Corresponding Parts

This study presents a methodology that would facilitate the transition from the current 2D model to a 3D GIS-based model. The proposed LandInfra-based road management model is based on the mapping results presented in Table 3.

A road management model consisting of road pavement and road register data was modeled to the Road, Facility, and Alignment parts of LandInfra according to the mapping results. The results of the data modeling are illustrated in Figure 10, Figure 11 and Figure 12, wherein the proposed data model for road infrastructure management is based on the LandInfra counterparts. In Figure 10, the Facility requirements classes are shown in cyan, and their dependent classes are illustrated in yellow. Pavement and Road register-related classes are shown in gray with their respective class names. The classes used for InfraGML encoding are shown in green. The BRIDGE class was encoded as an instance from the Facility part and is depicted in green.

The LandInfra Requirements Class Facility provides general support for infrastructure facilities, including dams, bridges, roads, and utilities. From this perspective, the BRIDGE and TUNNEL classes were modeled as a subclass of FacilityPart. The BRIDGE_REGISTER and STR_DWG classes showed the same association with the BRIDGE class. The PMS_PAV_SURV, ROAD_AREA, and LANDUSE classes were modeled as a subclass of PhysicalElement. These classes can be considered physical elements that form FacilityPart when FacilityPartType is Road.

In Figure 11, the Alignment requirements classes are depicted in cyan, and their corresponding dependent classes are shown in yellow. Road register-related classes are shown in grey, along with their class names. The MROAD, XPOINT, and SLOPE classes are shown in green, and these classes were used for InfraGML encoding as instances.The Roads FacilityPart may have any number of alignments, and the centerline of the road can be an Alignment [34]. Therefore, the MROAD class was modeled as a subclass of Alignment. The DETOUR_ROAD, PAY_ROAD, DRAWING, and REALNTH classes had the same association with the MROAD class. These classes can be implemented through the MROAD class, which inherits all the attributes from the Alignment class. The XPOINT class contains road horizontal geometric information, and this class was modeled as a subclass of Alignment2DHorizontal. The SLOPE class covers the longitudinal slope of the roads and was modeled accordingly as a subclass of Alignment2DVertical.

In Figure 12, the Road requirements classes are shown in cyan, and classes on which road classes are dependent are shown in yellow. Pavement-and Road register-related classes are shown in gray, along with their respective class names. The SLOPE, WALL, and PMS_ASP_STRUC classes (shown in green) were used for InfraGML encoding.

The Road is part of a Facility that is a single segment and should be continuous, non-overlapping, and non-branching [34]. From this perspective, PMS_ROUTE_GENERAL, representing a single section of a route, was modeled as a subclass of the Road class. The PMS_MCO_CODE, PMS_PR_CODE, PMS_ROUTE_CODE, PMS_TRF_VOL, PMS_EVENT, PMS_EVENT_CODE, and PMS_REHAB_CODE classes maintained the same association with PMS_ROUTE_GENERAL that these classes can be implemented through PMS_ROUTE_GENERAL. The PMS_ASP_STRUC, PMS_CON_STRUC, DIP_EQP, NORI, BOX_PIPE, DEFENCE, WALL, STONE, SIDE, and SIGN classes were modeled as subclasses of RoadElement. All these classes inherit the attributes of the RoadElement class.

3.2. InfraGML Encoding of the Proposed Data Model for Road Management

InfraGML is an encoding standard for the implementation of the LandInfra conceptual model standard [36]. In Section 3.1, we proposed a data model for road management based on the corresponding counterparts of LandInfra, including Facility, Alignment, and Road. To implement the proposed model, these models must support the InfraGML Core, Facility, Alignment, and Road requirements classes.

Thus, the aim was to determine how to transform the current 2D GIS-based road management model into a real-world 3D geospatial-based model using LandInfra with the InfraGML encoding standard. In this section, we provide real-world examples based on the proposed model using the InfraGML encoding standard as a subsequent result of our study. The data used in the encodings as instances were obtained from road register information in the shapefile format (available at https://www.data.go.kr/data/3049884/fileData.do (accessed on 23 March 2022).

Based on the previous analysis, we considered several classes, including MROAD, WALL, BRIDGE, XPOINT, SLOPE, and PMS_ASP_STRUC, for encoding. Some of the corresponding data were placed briefly on the base map, as shown in Figure 13, except for PMS_ASP_STRUC, which had no publicly available data. In Figure 13, the classes of MROAD, WALL, XPOINT, and SLOPE are represented in the LineString form. While the MROAD and SLOPE classes were in a continuous line-shaped form, the XPOINT and WALL classes were in a non-continuous line-shaped form.

The BRIDGE class is represented in a non-continuous polygon form. In this section, each of these classes is encoded by InfraGML as an input. According to the InfraGML encoding standard, the Road class of the FacilityPart can be represented in four ways: RoadElements as solid (typically), surfaces as faceted (triangular) surfaces, StringLines as lines through roads longitudinally, and RoadCrossSections as 2D views cut perpendicular to the centerline of a road.

Figure 14 illustrates these methods, except for RoadCrossSections, which we did not employ. An application conforming to this class of Road requirements can include any of the first three representations, either alone or in combination [36]. In the present study, we represented roads by applying a triangulated surface, road StringLine (left, right, and centerline) representation, and RoadElement in Polyfacemesh. Figure 15 depicts a snippet of the results of InfraGML encoding, represented in triangular faceted surfaces based on the Road part. Note that not all data were encoded; however, all encoding results can be found at https://github.com/baataraa1/InfraGML-Encoding-Instances (accessed on 15 May 2022).

SLOPE InfraGML encoding begins with LandInfraDataset, which is from the LandInfra core [42] part and provides information regarding the data creation and date (i.e., metadata). Each encoded part begins with LandInfraDataset, and the SLOPE and WALL classes encoded to Road have one common LandInfraDataset.

For the Road part, in addition to the dataset class, SLOPE was used to represent the 3D road surface as a triangulated surface and StringLine. SLOPE was used as a RoadElement in Polyfacemesh to represent PMS_ASP_STRUC. To represent PMS_ASP_STRUC as an asphalt pavement course, we used both the SLOPE and MROAD classes; for the SLOPE class, we used values (e.g., height), and for the MROAD class, we used its attribute information that comprises the pavement thickness information (20 cm asphalt) as the input. For encoding, we used some georeferenced location data with longitudinal and transverse (offset) distance and height values as the geometric values.

In addition to these classes, a WALL class presenting retaining walls was encoded. It was represented in 2D LineString, and lines existed where the retaining wall was located. The basic attributes of the retaining wall, such as the maximum and minimum lengths of the retaining wall, were covered with the Road and RoadElement classes. The retaining wall was located along the road centerline, as depicted in Figure 13, and was approximately 13 m away from the road centerline. Thus, this information is included in encoding as the lateral offset distance. The length of the retaining wall used as an instance was 170 m, that is, the longest among the retaining walls in the data.

For the Facility part [43], the BRIDGE class was encoded to InfraGML. Encoding started with the LandInfraDataSet class, which describes metadata. Unlike other classes, BRIDGE was represented in a 2D polygon form. For the SpatialRepresentation attribute of FacilityPart, four coordinate values were obtained from the bridge edges and added as IndexedPoint. Furthermore, several attributes from BRIDGE, such as the bridge class, column type, and column quantity, were included in the Facility encoding as instances. On the other hand, the attributes of BRIDGE were divided by the upward and downward directions of the road; however, the data values for each direction were the same unless the length or other dimensions were different. Thus, the BRIDGE encoding was performed based on one record, as the records had the same values.

For Alignment [44], we considered MROAD as one carriageway, such that the road centerline would be an alignment, which is a continuous, non-overlapping, and non-branching line. The MROAD class was inherited from the Alignment part, and other MROAD attributes were encoded. In particular, the road centerline in 2D LineString was national highway 30, Section 5, with a length of approximately 7560 m. Subsequently, XPOINT, representing the road geometric information, was encoded for Alignment. It was also presented in the 2D LineString form; however, lines only existed where there were curved road sections. In the encoding, the basic attributes such as curve length, start and end positions, and other attributes from XPOINT were included. In the XPOINT data, the largest curvature length was approximately 1020 m, while the smallest was approximately 102 m. SLOPE represents the slope information along a road. SLOPE is similar to the MROAD centerline and was in the 2D LineString form. As such, the line continued from the beginning of the section to the end. The basic attributes, such as the slope length with the start and end positions, slope percentage, and beginning-point ground height, were included.

4. Discussion

We extended parts of LandInfra by applying a road infrastructure management model of Korea, although LandInfra does not explicitly support an extension. To extend the road management model to LandInfra, and in response to our study questions, we analyzed the current road management model. As a result, we created UML class diagrams for road pavement and road register models. Moreover, to compare and find similar classes between LandInfra and the road management model, a mapping procedure was performed, and we proposed a road management data model based on the parts of LandInfra—Facility, Alignment, and Road. Subsequently, the proposed models were encoded into InfraGML for implementation. We used real-world instances for encoding, and several classes from the road management model were utilized for each proposed model.

However, we did not have sufficient real-world data to cover our entire model, and only some road register information-related data were available. Furthermore, additional data with real-world coordinates would be needed for the visualization of 3D roads by applying and implementing the LandInfra and InfraGML encoding standards. In relation to the visualization of InfraGML encoding and for the further use of the standard, the absence of publicly available (e.g., open-source software) software support for LandInfra and InfraGML encoding standards causes more difficulty.

Alternatively, as suggested by Kumar et al., [29,31] LandInfra classes can be migrated to CityGML through LandInfra ADE, where a lot of support is available in the form of software and validators, as well as through JavaScript object notation (JSON)-based implementation, which avoids large XML, and vice versa. Therefore, an application or software is required to apply and visualize InfraGML encoding. Furthermore, the existence of such software, that is, one that can automatically convert geospatial or non-geospatial files to InfraGML, would allow academicians and practitioners to take advantage of LandInfra.

On the other hand, to support InfraGML implementation with IFC Alignment, Malmkvist et al. [30] suggested the transformation of information between different software or systems based on a standardized format using a commercial product such as Trimble Novapoint, which is for civil engineering projects and BIM support. In addition, they used Feature Manipulation Engine (FME) software, developed by a Canadian software vendor, to visualize and validate InfraGML data processed from Novapoint; however, they mentioned that the FME could not support InfraGML at that time, and a customized workspace was created instead.

Moreover, InfraGML would be an ideal candidate for the possible integration of CAD, BIM, and GIS. Since most of the civil engineering and road infrastructure works are depicted in a CAD environment, 2D and 3D CAD and BIM data models can be integrated into the GIS environment using the LandInfra/InfrGML standard. Particularly, to meet the demands for the GIS-based environmental impact assessment of construction projects, Schaller et al. [45] argued that the BIM (IFC) model can be exported from AutoDesk Revit, and after this process, BIM can be converted to the GIS format without information loss. In this process, InfraGML Alignment can be used along with IFC Alignment and probably with other relevant parts of LandInfra for information integration into GIS.

5. Conclusions

This study explored how to transform the current 2D road management model into a 3D GIS-based model using the international open geospatial standard LandInfra in Korea. LandInfra was chosen to take advantage of transitioning to 3D GIS-based road infrastructure management using the standard’s features on land and civil engineering infrastructure facilities. This study presents how LandInfra can be extended to include road infrastructure management information and how real-world road data can be implemented through InfraGML to facilitate 3D geospatial road management.

Furthermore, we concluded that we found answers to our study questions mentioned earlier on the introduction section. Our study analysis and results showed (1) how the LandInfra standard should be extended for the Korean road management model in general, (2) which classes of the Korean road management model can be mapped to LandInfra, and (3) how LandInfra-based country specific road management model can be encoded using InfraGML encoding standard in particular in the context of enabling 3D geospatial model.

Further studies need to be conducted by modeling the rest of the road management systems that deal with road infrastructure, such as bridge and tunnel management systems, cut-slope management systems, and road sign management systems in Korea. Furthermore, to implement 3D geospatial road management using the Road requirements class, additional data acquisition is required, either in the form of a solid, faceted surface, lines (e.g., left, right, and centerline), or road cross-sections. In addition, converting UML classes to InfraGML encoding with real-world data will help in the realization of this concept.

In the future, we expect that the proposed model—a platform-independent conceptual standard data model—will be used to facilitate the digital twin of roads and road infrastructure, as well as digital inventory and digital road asset management. We also expect that creating systems or databases using these types of standards will allow for not only maintaining and exchanging road information but also for enabling data analytics. However, to achieve this, further research is needed to evaluate the use of this standard alone or in combination with other standards.