Abstract
Focus on indoor spatial applications has been rising with the growing interest in indoor spaces. Along with the widespread use of mobile devices and the internet, it has increased demands for indoor location-based services (LBS), demanding more efficient representation and management of indoor spatial data. Indoor points of interest (Indoor POI) data, representing both spaces and facilities located indoors, provide the infrastructure for these services. These datasets are vital in delivering timely and accurate information to users, such as in cases of managing indoor facilities. However, even though there are studies that explore its use across applications and efforts exerted towards the standardization of the data model, most POI development studies have focused on the outdoors and remain underdeveloped in the indoors. In this paper, we propose a spatial-temporal Indoor POI data model to provide direction for the establishment of indoor POI data and to address limitations in currently available data specifications. By exploring how different Indoor POIs are from its outdoor counterparts, particularly on extending its outdoor counterparts’ functions on searching, sharing, and labeling, we describe the data model and its components using the Unified Modeling Language (UML). We perform an SQL-based query experiment to demonstrate the potential use of the data model using sample data.
1. Introduction
Nowadays, day-to-day human activities have been closely tied with the use of mobile devices and gadgets, most equipped with GPS receivers and cameras, and are continuously improving in terms of features and speeds while decreasing in size [1, 2]. With this, the demand for information arose through location-based services (LBS), which aim to give users relevant and timely information based on their positions [1, 3], and augmented reality (AR) applications that combine images from the real-world to virtual images in three-dimensions [4]. These services form part of the core requirement of Smart Cities, as localities around the world aim to establish seamless integration of technology to the daily life of its citizens.
Now, as interest in indoor space continues to rise [5], the demand for spatial applications and services also increases. These technologies that signal that we are now living in a digital world spark interest in digitizing real-world indoor scenes [6].
Indoor POI is a location in indoor space where information regarding a particular place, service, facility, or event is available, in contrast to traditional POIs located in outdoor environments. A reliable Indoor POI dataset is vital to provide the fundamental infrastructure to LBS, to provide successful services to users. This approach, however, is faced with several difficulties. First, Indoor POIs are not always identified by a proper name, as most features that they represent in indoor space consists of facilities, such as ticket machines, CCTV cameras, or fire extinguishers. Second, Indoor POIs are more appropriately referred to by their type, or classification, shifting the general POI idea of a location that is identified by a unique name. The basic definitions of POI from W3C [2] and OGC [7] have stated that a name is a primary component, together with ID and location. Third, most indoor LBS are still providing viewer-level service [8], due to existing data models being underdeveloped in the indoor aspect and not differentiated with its outdoor counterparts. Established standards regarding primarily dealing with indoor data have dealt more with navigation, such as Open Geospatial Consortium (OGC) standard Indoor Geography Markup Language (IndoorGML) [9], not on representing features and spaces for LBS, and they have no precise specifications regarding Indoor POI in their respective models.
This paper is motivated by the requirement for the formalization of Indoor POI, to expand services such as in facilities management, simulation, and monitoring. As current applications demand further classification of POIs into levels—named objects with ID and location as Level 1, locations that include unnamed real objects such as indoor or outdoor facilities as Level 2, and intangible assets or events as Level 3 [2]. Indoor POIs, for instance, take prime importance in Level 2, as this has gained interest in the increasing demand for indoor applications, including indoor LBS, indoor facility management, increase in accessibility for disabled persons, evacuation for emergencies, and even commercial or robotic applications.
In response to the difficulties faced in dealing with Indoor POI stated above, this study proposes a data model that characterizes its vital aspects as essential elements in providing spatial services. Identifying these aspects and formalizing this model is key for assuring data quality, provide prospects for validation, encourage analysis, and at the same time, promoting data sharing and integration. Furthermore, we intend to demonstrate the potential and usability of the proposed data model through an implementation.
This paper is structured as follows. The next section discusses studies on efforts on POI standardization and data model, as well as notable utilization across application domains. The third section presents the characteristics of the Indoor POI data model, followed by the proposed spatial-temporal indoor data model. We conduct an experimental implementation of the data model through a use case involving facility management to demonstrate its various aspects through a small sample dataset, and the last section focuses on conclusions and limitations of this study to be addressed by future work.
2. Related Research
The rapid growth of mobile devices and internet technology has led to the acceleration of LBS applications, with a special interest in the indoors [10–12] due to its strong influence in people’s daily lives [13], and recognition that these spaces are even as dynamic as its outdoor counterparts [14]. In recent years, the indoor environment has been a target of a wide area of research ranging from data acquisition, 3D data modeling, and indoor navigation [15].
Though the progress in outdoor mapping and navigation applications encourage the interest of its indoor counterpart, the indoor case postulates problems in the direct application of technologies as they exhibit different characteristics [16]. These problems include the lack of cheap and convenient positioning systems and the availability and complexity of maps [17]. However, as the key enabler for Indoor LBS [18], Indoor POI can help augment these shortcomings, together with other datasets. Indoor POI is essential in positioning indoors as much as how GPS has enabled this outdoors [19].
To date, organizationally agreed-upon models regarding Indoor POI are still, and a standard is yet to be acknowledged [2]. One major problem that having an Indoor POI data standard would resolve is having separate sets of POIs for every application or infrastructure. In a study for the development of a participatory collection of Indoor POI, despite crowdsourcing having the advantage of a large volume of data, there is a necessity for data quality control and assurance due to the massive number of users and variety of devices. As such, a data model would prove useful in performing data integrity checks.
Tracing the timeline of POI standard development would begin with nodes in OpenStreetMap (OSM), KML, and Places Library of Google Maps but individually lacks in aspects that are essential to the direction of applications where POIs are going [3, 20] place identifiers in ISO 19112 [21] and ISO 19155 [22]. Specifically, the World Wide Web Consortium (W3C) POI Special Working Group (SWG) has become the first step towards the standardization for the definition and exchange with a focus on web architecture and in AR applications. SWG has published the Point of Interest Core (POI Core), describing eight categories to describe POI with attributes and various location types [1, 3].
Commercial GIS providers have also observed the emerging need for Indoor POI. ArcGIS Pro by ESRI has also included a provision for Indoor POIs through ArcGIS Indoors. In this application module, Indoor POIs can represent features on an indoor map. These Indoor POIs have two levels of classification, the first one being broader classes of people, places, events, and objects [23].
In parallel, industry stakeholders, including car industry specialists and experts in mobile technology, navigation systems, and digital maps, formulated a general-purpose specification called point of interest exchange language (POIX) and submitted this as a preliminary proposal to W3C. However, this lacked in categorical, descriptive, and temporal aspects and seemed inclined towards car navigation [20]. In Korea, the Telecommunications Technology Association (TTA) established a data model and other private companies, including Naver and Daum, to establish portal and navigation services. Government agencies also partner with research and development institutions to study POIs in the context of positioning and human-oriented geographic information [2].
A spatial-temporal model based on the W3C data model was proposed by [2], based on the W3C data model, extending certain aspects to the goal of expanding the utilization of POI. This model emphasized the three major roles and characteristics of POIs in providing LBS—in searching, in display, and in sharing—and is subsequently formulated according to each of these individual functions. Time series management is also enabled by expanding definitions for temporal aspects of POI in terms of changes in location over time for a POI (feature-based) and change in the POI over a period time for a location (location-based) [24]. However, this standard tackles the first level of POI, where a unique name refers to each feature and suggests that expansion towards the higher levels is necessary in future studies.
The concept of Indoor POIs has been used by [8] to represent facilities for an indoor LBS. Spatial relationships between the Indoor POI and the indoor spaces abstracted with topological data provided by IndoorGML are defined to provide an indoor patrol service. Also, in an indoor setting, [25] proposed a location-aware POI recommender system based on user preferences mined from social networking data. Indoor POIs have also been used to build an indoor facility information and visualization system [26], annotators to denote user visits in urban areas [27], generating large scale maps [28] and in labeling objects and spaces in AR platforms [29] and navigation systems [30–32]. These applications, however, focused on utilizing Indoor POI as a marker for objects in indoor space, rather than differentiating its identity from POIs in the outdoors.
In literature, indoor navigation is one of the major uses for Indoor POIs, such as in determining best routes for a context-aware systems for navigation [17], ubiquitous indoor navigation [33], web-based navigators [18], WiFi-assisted path planning [34], and point planning for robotic navigations [35, 36]. It is also interesting to note that studies cite Indoor POI data as an environmentally crucial component, especially in cases where navigation is critical. Several studies use them as navigation guides in indoor wayfinding systems for visually impaired situation awareness [37–40] or those physicallyimpaired [41] as path determinants or as indicators for hazards. Most importantly, Indoor POI integration with datasets based on international data standards, such as IndoorGML, is possible to more accurately portray and perform applications in indoor space [42].
Indoor POIs also play a key role in the indoors as landmarks, not only objects to denote the location of objects or spaces but also as guides for users to form mental spatial representations of their surroundings. Especially in situations where users are unfamiliar with the surroundings, these POIs aid route decision-making and orientation [43], as well as reference points that assist in recreating physical layouts of buildings [34]. These features are highlighted as important elements of the user line of sight and as background knowledge that moderates how users perceive the indoor environment [44].
Studies have also explored the localization of and using Indoor POIs. Since these objects are distinguishable from their surroundings, they are ideal for localization. Referred to as beacons, range-only SLAM (simultaneous localization and mapping) was able to identify positions of POIs using only distances with the assistance of the strength of radio frequency signals [45]. Similarly, WiFi signals which are readily available indoors plus radio FM (frequency modulation) signals permit indoor localization of POIs by similar principles [19]. Conversely, these POIs have assisted pedestrian dead-reckoning [46] and applications on indoor look-up services [47]. On a related note on the Indoor POIs as landmarks, it is possible to achieve adequate indoor localization using only these objects through a fingerprinting-based approach [48].
Various motivations have sought the extension of POI’s nature as being an entity with a location and some attributes. OGC defines POIs as “a location (with a fixed position) where one can find a place, product or service, typically identified by name rather than by address and characterized by type, which serves as a reference or a target in an LBS request, e.g., as the destination of a route” [7]. [4] pointed out that the term itself distinguishes between what is “interesting” and what is not, depending on the available context, but the OGC definition does not consider this subjective component [20].
A resolution to this gap is providing context in the usage. In 3D environments, especially indoors, apart from being key features that are essential for specific user tasks, these data also provide insight for visualization and navigation. In this case, however, Indoor POI visualization would have to deal with issues that are not usually present in 2D, such as occlusion, perspective, and scene complexity. An approach using a cloud of interest (COI), was proposed maximizing the information that the user is receiving without context distortion, too much cluttering, and additional cognitive task of looking through multiple views at the same time and still be suitable for small viewing spaces, hence bridging the challenge of creating models for mobile 3D geovirtual environments [4]. As 3D visualization of POI in the indoor environment representing both objects and spaces are emphasized [49], this emphasizes the need for a formalized data model that enables linking with other data.
On a related note, studies have shown that semantic models based on international standards such as CityGML and IFC (Industry Foundation Classes) have enriched thematic information of each other [50–52] or of other datasets like 3D mesh data used in solar potential analysis [53]. In contrast, while studies have also shown that application flexibility is enhanced utilizing semantically enriched POIs [54], this enrichment may come from the semantic models. In both outdoors [1] and indoors, POI data is essential for ontology-based recommender systems in different applications. Studies have used Indoor POIs in recommender systems utilizing shopping trajectories to model user behavior and preferences [25, 27]. Literature also cites that having an alias database management system would increase the efficiency of POI data, that is, obtaining the same level of richness of information even with a significantly smaller size of dataset [55].
Semantic hierarchies in the indoor environment have been demonstrated by [56–59] through describing how indoor spaces are related to its subunits and how this relationship plays a role in various aspects. The concept of space subdivision and aggregation enhances how space is perceived cognitively, particularly in as an essential in providing descriptive information on location, determining functional areas within indoor space, and determining which parts are suitable for navigation. The BOT (building topology ontology) is an effort to evolve existing IFC-specified standards towards Linked Data practices for modern web-based applications. Similarly, in the context of building and construction field, BOT presents spatial 3D volumes as zones that may contain other zones in a hierarchical manner—sites that may contain buildings, buildings that may contain building levels, and building levels that may contain spaces. Furthermore, this specification also defines tangible elements that either comprise or contained within these zones [60, 61].
The lack of support for temporal data for available models has also been raised [1, 20]. Data such as opening/closing times of establishments, the amount of time that people spent, or real-time data about services enrich the attribute content of POIs, which may be crucial to many applications. Some characteristics and even the location may change over time. From tracking datasets, novel query methods of two types—snapshot (on a given time point) or interval (over a given period)—have determined frequently visited Indoor POIs [62]. Keeping multiple versions of the Indoor POI has also been suggested to maintain information content [63]. To maximize this information in studying change and patterns, the data model must incorporate these.
For most cases, a name has been an identifier for an outdoor POI. However, this identifier would not mean that an Indoor POI corresponds to one and only one exact string of text. Users may vary in keyword use, and typographical errors are not impossible, so more than one keyword may exist, called an alias. This case is especially true for Indoor POI that may be referred to with similar characters, due to it not being identified by name. In a crowdsourcing-based collection method for Indoor POI, multiple names may refer to a single location [10]. To develop a system for managing aliases, [55] classified POI alias attributes and used word similarity measurements to input and retrain an alias database containing nonofficial names for POI.
Based on the developmental direction from POI towards Indoor POI data models, as well as primary usage domains for Indoor POI evident from previous studies, namely, searching, data labeling, and sharing, and identified areas of improvement and development, we propose the spatial-temporal indoor POI data model in the next section.
3. Proposed Spatial-Temporal Indoor POI Data Model
In Section 3, we consider the considerations for the spatial-temporal data model proposed in this study. We investigate the attributes of the Indoor POI in terms of its main usage and identify critical points that the data model must define.
3.1. Characteristics of Indoor POI
Indoor POIs may represent indoor spaces such as a room, corridor, lobby, or stairwells, as well as facilities, movable or immovable, located in those spaces such as furniture, installations, or equipment. Previous studies discussed in the preceding chapter have shown extensive use of Indoor POIs across a wide range of application domains. These features are present in navigation as either targets (e.g., what is the route from my current position going to Indoor POI 1?), guides (e.g., in calculating a route from point A to point B, avoid Indoor POI 1 and pass through Indoor POI 2), or both. In terms of localization, they have been vital in both finding positions of other objects (e.g., given the coordinates of visible Indoor POI 1, 2, and 3, what is the coordinates of the user), or the targets of localization using various measurements (e.g., given the WiFi signal strength from routers A, B, and C, what is the position of Indoor POI?). Indoor POIs are essential in 3D indoor visualization as landmarks to improve users’ mental recognition of their surroundings or even as merely labeling features to increase information content. Furthermore, these features provide rich content that enables spatial and temporal queries in LBS applications.
The Indoor POI data model proposed in this paper considers the same aspects as the previous data model [2], with particular consideration to the specific cases of indoor space, as compared to outdoor space. This proposed data model does not restrict a generic set of objects to be represented as Indoor POIs. Instead, any indoor facility (in the spatial range of a room), as well as the room containing these facilities (in a corridor’s spatial range), may be represented. In this regard, inclusion relationships may also form between the former and the latter. Moreover, in the indoor environment, the difference in spatial range is more apparent, the presence of Indoor POIs in say, a corridor would have a difference in contrast to those present inside a room in different aspects. Moreover, facilities and other objects represented by Indoor POIs are more mobile, i.e., movable and can change location over time, and conversely, a location may have various Indoor POIs over a specified period.
Figure 1 improves upon the developmental direction of the outdoor POI proposed in [2]. The essential POI purposes of sharing, labeling, and searching remain to be the motivation of the development of the Indoor POI data model; however, specific key characteristics shared between these purposes are differentiated according to the importance and vital differences with the case of outdoors. Between the three primary purposes are the corresponding aspects of Indoor POI that are imperative in developing the data model. First, the data model’s management of aliases level of detail is critical for purposes of search and labeling. These aspects are crucial in datasets to improve searching and managing the amount of information that the screen presents to the user, respectively. More importantly, information about spatial hierarchy, which corresponds to the spatial relationships of indoor space with either other indoor spaces or objects found indoors, is critical since this is more apparent in the case of indoors. In relation to Indoor POI sharing and searching functions, the aspects of maintaining a classification scheme and handling of multitemporal information are crucial driving points. Finally, as an identifier for places to their specific location, this aspect of Indoor POI is more crucial in its role in data sharing. These characteristics are elaborated in the sections to follow.
3.2. Indoor POI Nomenclature
Even if a feature does not have a unique name, Indoor POIs can still serve its purpose as an identifier, since it still connects an “indirect” geographic reference to a specific location. Intuitively, this classification aspect would more often be the more practical or in some cases the only existing nomenclature to identify a particular Indoor POI, as most objects found that indoors, despite being tangible objects, do not have a specific name. We can only refer to them through their generic names, such as a fire extinguisher, a CCTV, or an ATM. Providing a classification scheme for Indoor POIs would provide not only a uniform method of defining and differentiating features but also an opportunity for faster queries by narrowing down POI results depending on the purpose of the user. It also improves efficiency in query-based implementations, as classifications would also enable grouping and subgrouping of similar features. In the data sharing aspect, classification provides an identifier for linking data from external sources, such as the code list from CityGML, for example.
Hence, a classification scheme to categorize Indoor POI is necessary to encourage utilization, increase query efficiency, and avoid duplications in datasets. A scheme also supports the Indoor POI functionalities of sharing and searching. In Table 1, we illustrate a sample of a classification of Indoor POIs, created based on the ESRI POI classification scheme [23], categorizing each feature in three levels of increasing specificity, and each category would correspond to a 6-character category code as an attribute for the Indoor POI.
This classification scheme does not intend to provide an exhaustive list of all possible types of objects and spaces but rather as an illustration of possible varieties of what an Indoor POI can represent. For example, “Vending Machine” and “Drug Store” may both be represented even though they are differentiated by [42] as nonnavigable facilities and navigable facilities, respectively. The previous examples are actual objects located indoors, while the latter represents the spaces that may contain the former.
In developing LBS applications, and even though conventional models only require a name alongside a location to define a POI even outdoors, aliases are existing because of the nonniformity of the keywords that users key-in for searching, and typographical errors are not impossible to occur. Even if an Indoor POI has an official identifier, be it a name or its classification, the data model should be able to incorporate aliases. Having an alias database would improve searching while ensuring a practical and flexible, yet efficient delivery of information to users.
Managing descriptive information of the Indoor POI is also essential to maintain data integrity and quality. As data sharing is encouraged by a standardized data model, the author of the dataset must also be included to ensure efficient management, accountability, and facilitation of data reuse and updating. Similarly, successful LBS is possible if the Indoor POI can carry attributes apart from its name, classification, and location. Other descriptive information that may widely vary in data type, length, and value should be managed by the data model so rich information may be maintained and furnished to users.
3.3. Spatial Hierarchy and Spatial Relations
For Indoor POIs, spatial relationships may exist in two ways. First, a spatial hierarchical relationship may exist between an Indoor POI and another Indoor POI, as expressed in the previous research for outdoor POI [2], say, for example, an Indoor POI representing a floor level, and the Indoor POI representing the rooms in that level. This case represents the aggregation of smaller spatial units in one hierarchical level (the rooms, in this case) towards a larger spatial unit in a higher hierarchical level (floor). Second, an inclusion relationship exists between Indoor POIs that represent space and those that represent objects located inside those spaces, say for an Indoor POI representing a library, and for Indoor POIs inside representing shelves. These relationships must be maintained in the data model to facilitate query analysis and extend into applications such as navigation, facilities management, or patrol services to fulfill its roles in searching and feature labeling properly. Also, this provides an opportunity for the improvement of data integration with other standards dealing with indoor spatial information such as IndoorGML.
We express these relationships in the data model as a self aggregation of the IndoorPOI_Basic class. Each POI instance has a 0~1 parent or a 0~ child, as shown in Figure 2(a). This multiplicity specifies that an Indoor POI may not have a parent class, but if it does, it cannot have more than one parent having a higher spatial hierarchy. A child class for an IndoorPOI_Basic instance may not be present, but should it be, this instance may have one or more child classes having a lower spatial hierarchy. For example, a space-based hierarchical structure exists between a POI representing a floor level of a building, and the corresponding POIs representing the rooms and facilities existing within that floor level, as in Figure 2(b).
(a) UML
(b) Spatial hierarchy instance
3.4. Spatial Depth
In the display of spatial data to users, the scale plays an important factor in how much information is visible and intelligible. As with any conventional or digital map, at varying spatial scales, Indoor POI must be expressed efficiently in a proper level of detail. Hence, a different set of Indoor POIs must be visible in larger scales compared to smaller scales. This aspect is crucial in order for it to achieve its role in feature labeling.
One of the main challenges in creating LBS platforms is screen size, due to the limitation of the devices where they run on [4]. As POIs and Indoor POIs are mainly geared towards providing LBS and as trends point toward more portable and handheld devices, the display restricts the relay of the richness of information to the users. Smaller screen size, as well as the size limitation in the indoor space themselves, command methods for efficient expression of Indoor POIs and their respective attributes.
Although closely related, spatial depth does not directly equate to spatial hierarchy. The self-aggregation for the latter refers to the relationship of an Indoor POI parent node containing another smaller spatial unit represented by an Indoor POI child node, for example, the cases of between a building (parent) and floors (child), and between the floors (parent) and rooms (child). Differently, this may also refer to the inclusion relationship between a space represented by an Indoor POI (room) and the objects inside the room (desks).
On the other hand, two Indoor POIs having the same spatial depth may belong in different hierarchical levels, say, for example, Indoor POIs for a cinema lobby and a ticket machine. Both may be displayed at the same time (same spatial depth) even though the lobby has an inclusion relationship with the ticket machine (different spatial hierarchies). Indoor POIs at the same hierarchical levels may also belong in different display levels, for example, Indoor POIs representing a shelf and books. Both are at the same hierarchical levels below a room Indoor POI, but in an application, displaying all books might be illegible for display, unless a larger scale is visible.
POI display on the application is expressed for each scale level through the definition of spatial depth, through a user-defined InPOI_SpatialDepth attribute. Indoor POIs having the same integer value for this attribute would be displayed together at the same scale level. Additionally, an aggregation relationship, shown in Figure 3(a), between the IndoorPOI_Basic class and the IndoorPOI_DisplayInfo class having the expression level as the attribute, allows users to display Indoor POI descriptions in levels independent of the spatial depth, depending to the user’s intent, or the importance of a POI in a particular context. It has a 1~ child multiplicity, expressed as an Indoor POI on multiple levels, say an important facility such as an elevator used to transport between floor levels. Figure 3(b) shows an example of Indoor POIs having different spatial depths. An entire building is expressed as a single Indoor POI at spatial depth 0, while individual rooms may be expressed distinctly at Spatial Level 1. Further, Spatial Level 2 shows objects found inside the rooms at Spatial Level 2. Expanding to further spatial depths is possible, if necessary, depending on the datasets and the application.
(a) Aggregation relationship for display
(b) Spatial depths
3.5. Spatial-Temporal Information
Despite being indoors, we cannot expect entities that are represented by Indoor POIs to be stationary, as most objects existing in those locations are mobile. For example, equipment transferred from one area of a room to another, or an entirely new location within the same building. Similarly, descriptive information (such as usage, schedule) regarding a space (such as a room) may be dynamic due to relocations, reconstructions, or maintenance. For instance, an ordinary classroom transformed into a computer laboratory, in the case of a school. These changes, that is, the change history of either the locations or the features themselves, may be permanent or temporary. Regardless, keeping track of this information must be maintained in the data model so Indoor POIs can improve its functions in information query or searching.
This proposed model introduces two ways of time series management for Indoor POI, feature-based and location-based. Feature-based management means management of the locational changes that a single Indoor POI undergoes over periods, as shown in Figure 4(a). A certain POI object named “Student Lounge” in Room 714 of the 21st Century Building from 13 September 2001 to 14 April 2003 was moved to Room 104 of the same building from 15 April 2003 to 13 August 2015.
(a) Feature-based
(b) Location-based
Time series management of Indoor POIs based on location means monitoring the Indoor POI located at that fixed position over periods, as shown in Figure 4(b). For example, on the location of Room 104 of the 21st Century Building, a specific Indoor POI for a Photocopy Room exists from, 13 September 2001 to 14 April 2003 but was changed to the Student Lounge starting 15 April 2003 to 13 August 2015. If applications manage temporal information like this, both management of feature changes and locational changes for Indoor POI and positions are possible, enabling historical search in various forms and implementations.
An association class SpatialTemporalHistory was added in the association relationship of IndoorPOI_Basic class and IndoorPOI_Location_Basic class to accommodate these time series management concepts to the Indoor POI data model. Figure 5 illustrates this relationship. In the generic data model from [2], these classes had a one-to-one association, but considering a feature-based time series management, the IndoorPOI_Basic now has a one-to-many association relationship with the IndoorPOI_Location_Basic class through the SpatialTemporalHistory Association class. On the other hand, a one-to-many association from IndoorPOI_Location_Basic class to the IndoorPOI_Basic class through the SpatialTemporalHistory class corresponds to the location-based management approach.
3.6. Spatial-Temporal Indoor POI Data Model
In this chapter, we discuss the structure of the spatial-temporal Indoor POI data model, from the considered characteristics in the previous section based on primary Indoor POI functions of searching, sharing, and labeling and is built upon the generic POI data model by [2]. The classes reflected in the data model represent the essential aspects of an Indoor POI based on the discussions in the preceding sections, as guided by previously proposed models for conventional POI models and considering the case of the indoors. We designed this data model to align implementations towards establishing actual Indoor POI data, while addressing current limitations of available data models.
The data model consists of 9 classes, namely, IndoorPOI and IndoorPOI_Location abstract classes, IndoorPOI_Basic class, IndoorPOI_Location_Basic class, IndoorPOI_Authority class, IndoorPOI_Alias class, IndoorPOI_Properties class, IndoorPOI_DisplayInfo class, and the SpatialTemporalHistory Association classes. The UML Diagram in Figure 6 describes each of these classes and their respective relationships.
The IndoorPOI_Basic class is the class that expresses the Indoor POI object, which may represent facilities or indoor spaces, which characterizes spatial hierarchy through its self-aggregation and multiple expressions across varying spatial depths through the one-to-many aggregation with child class IndoorPOI_Basic. The IndoorPOI_Basic class has a one-to-one relationship with the IndoorPOI_Location_Basic class, a one-to-many relationship with attribute information through the IndoorPOI_Properties class, and copyright information with its one-to-one association with the IndoorPOI_Authority class. To increase effectiveness and efficiency in managing the Indoor POI information, it implements alias management through the IndoorPOI_Alias class.
The IndoorPOI_Basic class and the IndoorPOI_Location_Basic classes inherit from the abstract classes IndoorPOI, and IndoorPOI_Location, respectively, thus obtaining their attributes for each instantiation. First, the IndoorPOI_Basic class has an ID, Name, CategoryCode, UpdateInfo, spatial depth, and child (parent) as attributes. The ID is a unique 12-digit character combining the information from the linked authorized agency and the serial number of the object. The attributes include a name, as an InPOI_NameType, official or not, that may include English, Korean, or alphanumeric characters. We reflect the classification discussed in Section 3.1 in the CategoryCode, UpdateInfo contains data on the creation and updating of other attributes, and the SpatialDepth for expressing display and hierarchical aspects.
The IndoorPOI_Location_Basic class inherits the IndoorPOI_Location abstract class. It has the unique ID, as an IndoorLocation_ID Type, position expressed a 3-dimensional IndoorLocationPointType, address as a LocationAddressType similar to the POI data model [2], accuracy information depending on location data collection method such as survey, grant of address position, and drawing, and the LinkInfo as a LinkInfoType for other linked location information.
IndoorPOI_Properties class has attributes of serialNumber, attributeCode, attributeValue, and UpdateInfo. The serialNumber is the serial number of the object, the attributeCode is a predefined attribute value according to the type, attributeValue may take any value in various types (anyType), and the UpdateInfo contains information on the update of the attribute.
The IndoorPOI_Alias class is the critical feature for alias management in Indoor POI, which helps significantly to manage the data efficiently. This class includes information on the alias name, as well as create and delete, which corresponds to the alias creation and deletion dates from the alias database, respectively. The IndoorPOI_Basic class is for how the POI is displayed visually to the user, according to user specifications. It contains attributes on level of detail (LOD) in level, supporting multiline or single-line descriptions in descriptionForMultiLine and descriptionForSingleLine. Finally, the IndoorPOI_Authority class expresses the author of the Indoor POI, which is responsible for the information in the feature, indicating the attribute author for the name of the author and LinkInfo for the corresponding agency or organization where the author is affiliated.
The association class SpatialTemporalHistory described in the preceding section represents the time series management for both feature-based and location-based management in the data model, having association relationships with the IndoorPOI_Basic and IndoorPOI_Location_Basic class. This class contains attributes dateStart and dateEnd to describe the period and the respective linked InPOI_ID and InLocationID. This period denotes the validity of the existence of the Indoor POI in a particular location, whether it is a feature-based or location-based approach. It also neither refers to the actual creation and deletion dates of the POI in the dataset nor the existence or removal of the real-world feature or space it represents.
We incorporate these measures to the Indoor POI data model, resulting in the spatial-temporal Indoor POI data model shown in Figure 6. We add the SpatialTemporalHistory association class and the multiplicity of the association relationships between IndoorPOI_Basic and IndoorPOI_Location_Basic classes. This approach presents a more compact approach to the one applied to the spatial-temporal POI data model presented in [2], which used four more classes—separate ones for the location and history information for each of the two time series management methods.
4. Experimental Implementation
The described Indoor POI data model describes spatial relationships between Indoor POI entities having a hierarchical structure and considers time series management in mind. To demonstrate this, we conduct an experiment considering a use case for the management of facilities located in the interior of a building. We do this for sample Indoor POI objects through spatial hierarchy and historical attribute query in this section using a sample set of 10 Indoor POI objects listed in Figure 7(a). For simplicity, these points represent selected locations in the 21st Century Building of the University of Seoul campus. At the topmost spatial depth, an Indoor POI representing the whole building exists, followed by an Indoor POI for the 3rd- and 6th-floor levels, respectively, of the whole building. Within the 6th-floor level, in the next spatial depth are Indoor POIs representing two rooms on that floor, and the final spatial depth contains objects each contained respective rooms, as illustrated in Figure 7(b).
(a) List of Indoor POIs
(b) Spatial relationship of Indoor POIs
To evaluate the potential benefits of the data model, we show to demonstrate the key characteristics of Indoor POI by constructing a relational database and implementing SQL-based queries. For simplicity, we mapped each concrete class as a single table in the database schema to more clearly see how each UML class works. This mapping is also an ideal strategy since class hierarchies in the model are shallow. Since the classes specify IDs explicitly, we were able to use these as keys in order to map the respective relationships directly. We entered the sample data as features in PostgreSQL, a free and open-source relational database management system, through the devised database schema shown in Figure 8, based on the UML model Figure 6.
For instance, the facility manager would like to know which facilities are present inside a room. To do this, we attempt to search Indoor POI that exhibits the self-aggregation relationship for expressing spatial hierarchy. Figure 9(a) illustrates the hierarchical relationships among Indoor POIs based on information illustrated in Figure 7. We perform an SQL query on the IndoorPOI_Basic class to identify child nodes lying within a node (in this case, a parent), as shown in Figure 9(b). The result of the query for Indoor POI for “Room 609” as a parent node shows a list of all Indoor POIs inside that entity, i.e., its child nodes, namely, “Water Dispenser”, “Air Conditioner”, and “Printer”.
(a) Illustration of Indoor POI hierarchy
(b) Spatial hierarchy Indoor POI query
On the other hand, time series management measures of the proposed data model enable search of historical attributes of both features and locations having this information, say the facility manager wants to identify locations where a facility presently and previously exists, so to demonstrate a feature-based history such as a facility being moved in different locations on different times, as shown in Figure 10(a). Figure 10(b) shows the result of the location history of the “Printer” Indoor POI from the SQL query on the SpatialTemporalHistory attribute, enumerating the various locations that it has existed at and each corresponding period.
(a) History of Indoor POI location
(b) Feature-based spatial-temporal Indoor POI query
Similarly, historical attribute search also enables management of the POI history of a particular location, if the facility manager wants to know which locations a facility has been used and transferred to across time, requiring the data model to handle location-based management, such as in Figure 11(a). Figure 11(b) shows the result of the POI history of a location names “Table Number 2”, having two Indoor POIs existing in history, namely, “Printer” and “Water Dispenser”, as well as their corresponding validity periods. Experimental results from this section show that the data model can express spatial and temporal information management through hierarchical and historical queries, respectively.
(a) Feature history on a location
(b) Location-based spatial-temporal Indoor POI query
5. Conclusions and Future Studies
POI is an essential element in providing LBS across a wide array of application domains. While there have been numerous efforts and studies regarding its expansion, utilization, and standardization, there is still a limited outlook on how this concept extends towards the indoor environment. Considering important characteristics of Indoor POI in several aspects, in contrast to conventional POIs used in outdoor space, there is a need to specify a data model to assure data quality, provide means of validation, and enable analysis.
This paper proposes an Indoor POI data model considering various spatial aspects and time series management. Based on the three roles of POI, searching, sharing, and labeling, we improved upon a previous generic POI data model, to formulate the spatial-temporal Indoor POI data model with components for temporal information management. This data model enables alias management, expression of spatial hierarchy, display across various levels, uniform categorization, unique type identification, and management of historical information for efficiency, user-friendly and directed display, and cross-platform and cross-application sharing. This data model enables the extension of creating POIs to POI Level 2—for unnamed facilities such as CCTVs, restrooms, or other features or spaces that exist indoors. In addition, this paper has demonstrated the data model’s support for hierarchical and historical information management through querying.
There are some limitations of this paper that the authors would like to address in future studies. First, this data model presents only the data model of the Indoor POIs themselves. Its implementation in more LBS-specific cases and applications, such as user location-based queries or pathfinding, would necessitate methodologies for integration with other datasets, for instance, IndoorGML in cases of use cases in indoor navigation platforms. Furthermore, avenues for visualization, such as with omnidirectional images, which have been demonstrated in the literature to provide effective and efficient visualization indoors, may be explored. We demonstrated that the use of the data model using a sample dataset, as no extensive yet compatible Indoor POI dataset, is obtainable. Should it be made available, investigations on the storage efficiency and more detailed comparisons with the traditional POI model are possible. This small size of the sample dataset, although successfully demonstrating the features of the proposed model, enabled us to perform a simple approach in designing the database schema. Hence, the MDA (model-driven architecture) approach may be suitable for more massive datasets aimed for more sophisticated applications. Finally, since Indoor POIs deal with the second level of POIs, extending into the third level, i.e., intangible assets or historical levels, should be incorporated.
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that they have no conflicts of interest regarding the publication of this paper.
Acknowledgments
This research was supported by a grant (20NSIP-B135746-04) from the National Spatial Information Research Program (NSIP) funded by Ministry of Land, Infrastructure and Transport of Korean government.