TOWARDS APPLICATION OF LANDINFRA STANDARD FOR HIGHWAY MANAGEMENT IN KOREA

This paper presents the modeling of the 44 registration subjects officially recorded in the road register of Korea to an international geospatial open standard. Due to current requirements, needs in road management and maintenance, road register data management must be improved as more data is accumulated and collected. Most importantly the metadata concerning road register assets is increasingly important in terms of data quality. This work discussed how OGC LandInfra international open standard will possibly be applied to the Korean Road Register for Highway Management and Maintenance. As a result, we proposed an OGC LandInfra standardbased road data model showing the standard can possibly be applied to the road register.


INTRODUCTION
The road register is an official record of facilities and/or assets, and the geometry of the road to be managed and is maintained by the road management office. Also, it is mentioned officially in Article 24 of the enforcement rule of Article 56 of the Road Act and has been computerized and operated in a system, namely the National Highway Management Information System (NAHMIS) by the Ministry of Land, Infrastructure and Transport since 1989. The NAHMIS was upgraded and integrated with the Highway Management System (HMS) in 1995.
The road register comprises the lists (assets) including main facilities, geometry, geotechnical and drainage, safety facilities, additional facilities, and others (MOLIT, 2015). Figure 1 shows the general overview of the road register consisting of the 44 types of registration subjects. Also, each type of road register has a physical table (schema). However, this work excludes describing each type with its properties and their relations due to page limits.
The road registration subjects are now managed in the geospatial data format, e.g. Esri shapefile and some structural drawings stored in a CAD format. However, official records of roads are kept on a local standardization level and need to be improved in order to introduce recent technological applications, such as Building Information Model (BIM) and 3D GIS (Geographic Information Systems) for road data management. Moreover, it is necessary to manage the metadata of the road register subjects as more data is accumulated.
To address these kinds of requirements and issues, the locally standardized road register needs to be advanced to a comprehensive and flexible standard. Although there are many standards related to geospatial data management, this study is focused on investigating the application of the 'LandInfra', an * Corresponding author international open standard, to the current road register as it has a more specialized data model for roads. Therefore this study aims to investigate how the OGC LandInfra international open standard can possibly be applied to the Korean Road Register for Highway Management and Maintenance. In order to achieve the goal of the study, the paper is organized as follows. Section 1 introduces the background and purpose of this study. Section 2 presents an overview of LandInfra and recent studies related to it. Section 3 describes the application of LandInfra to the road register. Lastly, section 4 concludes the paper and describes further works. The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLIII- B4-2020, 2020 XXIV ISPRS Congress (2020 edition)

REVIEW ON LANDINFRA
Open Geospatial Consortium (OGC) published an international standard named "Land and Infrastructure Conceptual Model standard", LandInfra for short. It is a relatively new open standard for land and infrastructure, integrating concepts from Building Information Modelling (BIM) and Geographic Information Systems (GIS) (Kumar et al., 2019b).
LandInfra covers land and civil engineering infrastructure facilities including land features (e.g. topographic features, surfaces), facilities (e.g. buildings and civil engineering works), projects (e.g. design and/or construction), alignment (linear reference system for location), roads (including road crosssections), railways, surveys (e.g. acquisition of points, lines, surfaces), and land division (including condominiums). LandInfra is supported by UML (Unified Modeling Language) and implemented in GML (Geography Markup Language) encoding, InfraGML which is also an OGC standard. InfraGML is divided into eight parts including LandInfra Core, LandFeatures, Facilities and Projects, Alignments, Roads, Railways, Survey, and LandDivision respectively ( Figure 2).
The fourth part of LandInfra supports road applications among the InfraGML requirements classes and for road support, and as those applications must also be supported in the InfraGML Core, Facility, and LandFeature, requirements and may employ the Alignment requirements classes. The InfraGML core provides classes related to the metadata about each part and it is implemented in Part 0. LandFeature focuses on the features of the land, specifically naturally occurring water and vegetation. It is implemented in InfraGML standard Part 1. LandInfra requirement classes facilitates for the general support of other facilities, such as roads and is implemented in InfraGML standard Part 2. Alignment is a positioning element providing a linear referencing system essential for locating elements and is implemented in InfraGML standard Part 3. LandInfra requirement classes Road provide specified classes for roads and is implemented in InfraGML standard Part 4.
On one hand, few pieces of literature reviewed the application of LandInfra including the consideration of applying LandInfra for road asset information exchange (Niestroj et al., 2018), testing and implementing InfraGML with IFC (Industry Foundation Classes) Alignment for the verification of transferring information between different systems/software (Malmkvist et al., 2017), exploring the possibility of integrating BIM (IFC) and 3D GIS (CityGML) applications using LandInfra (Kumar et al., 2019b), also development of software application for InfraGML for storing LandInfra features in CityGML (Kumar et al., 2019a). A few pieces of literature showed an application of LandInfra, no examination exists for applying LandInfra for road management. Moreover, there is also no application of the LandInfra existing in the area of road management and maintenance. Thus this paper discusses how the OGC LandInfra standard can possibly be applied to the Korean road register within the scope of highway management and maintenance, and this work applied the standard as it has more features for roads as compared to other standards.

Mapping between LandInfra and the Road Register
As mentioned in the introduction section, the road register includes several groups of lists (classes); main facilities are in pink, geometry is in blue, geotechnical and drainage is in green, safety facilities are in purple, additional facilities are in yellow and, others are in orange respectively, as shown in Figure 3. In addition to these classes of groups, the road register has other classes including MROAD which is shown in dark green, REAL_BOUND, STATION and KM_POST are shown in gray. MROAD describes a section of a road centerline. All the classes from the other groups of facilities are part of MROAD, which is shown in a UML composition association. In most cases, MROAD class has zero or more related classes multiplicity respectively. Attributes of each class have been removed for the convenient visualization of classes of the road register. Thus, only class names with their relationship are shown in Figure 3.
In order to model the road register to LandInfra an investigation of corresponding classes between each data model is required. The first step is to map data models to each other and identify corresponding classes. The mapping of the road register to the corresponding LandInfra classes is illustrated in Table 1 with a brief description of the classes from the road register and its corresponding classes in LandInfra.

Results
LandInfra requirement classes Facility enables general support for infrastructure facilities such as dams, bridges, roads, and utilities, etc. Facilities may be broken down into FacilityPart, based on the type of the facility e.g. a shopping mall may include buildings, roads, site, drainage, water distribution, and wastewater (OGC, 2016). Some types of the road register including bridge, tunnel, box pipe (drainage), and eco corridor (environmental) can be a part of Facility part. The Facility part has some related classes describing physical and positioning characters. Figure 4 shows mandatory classes or Facility part in light blue and other related classes.
For the road register, the aforementioned types of bridges, tunnels, box pipes, and eco corridors can be modeled as subclasses of the FacilityPart class. The FacilityPart class has a FacilityPartType attribute which deals with types of facilities such as bridges, tunnels, and roads. Figure 4 shows newly added classes from the road register that are in dark green. Also, the FacilityPartType code, listed in gray, describes newly added types for FacilityPart including box pipes and eco corridors, besides the overlapping lists for bridges and tunnels.
On the other hand, the rest of types of the road register, other than those used for FacilityPart, can be modeled to Road elements.

Figure 2. LandInfra Requirements Classes (OGC, 2017)
The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLIII-B4-2020, 2020 XXIV ISPRS Congress (2020 edition) Road is a part of Facility that is a single segment and should be continuous, non-overlapping and non-branching (OGC, 2016). MROAD of the road register class corresponds to the Road class since road is a single segment and it describes a segment's main characteristics. Furthermore, classes of the road register except for classes those modeled to FacilityPart can be modeled as a subclass of RoadElement as it has a RoadElementType subclass. RoadFacilityPart is a collection of zero or more RoadElements (e.g., pavement layer, base coarse, sidewalk, curb, and gutter) (OGC, 2016). Thus, most types of road register, e.g. overpass, underground, sidewalks, and highroads can be modeled as a subclass of the RoadElement class.    Figure 5 illustrates the results of the modeling with Road part including mandatory classes and other related classes in light green. Classes of the road register are depicted as follows; MROAD classes are in dark green, modeled as a subclass of the Road class and, the rest of classes of the road register that are modeled to RoadElement class and the RoadElementType code list. Newly added code lists from the corresponding road register types for RoadElementType code list are shown in gray in Figure 5. RoadElementType code list of RoadElement class has many varying types from pavement group types, barrier, guardrail, curb, gutter, median and other those overlap with the road register types. Table 2 shows a comparison of types of road elements to the road register.

CONCLUSION
This paper presented how the current road register data model can be modeled to an international open geospatial standard, OGC LandInfra. We have examined the Facility part and the Road part aspects of LandInfra more specifically for the possible application to the road register. As a result, bridges, tunnels, box pipes, and eco corridors from the road register could be modeled to Facility part and the rest of the types from the road register were modeled to Road part respectively.

Road Requirements Classes with RoadElement context
The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLIII-B4-2020, 2020 XXIV ISPRS Congress (2020 edition) We proposed the LandInfra international open standard-based road data models showing the possibility of application in the scope of highway management and maintenance. The official road register is now kept in a locally standardized format that does not fulfill the current requirements for highway maintenance data management. The proposed data model can be used not only to ease information exchange but also to enable the management of the metadata of the road register. Also, the results of this study can be a basis for the application of BIM and 3D GIS road data management. Furthermore, the proposed data model should be further conformed using InfraGML encoding standards with LandInfra Core and LandFeature parts for implementation. Also, further studies need to be concerned with applying Part 3 Alignment to the road register as it has other features related to it.