AnchorState represents a node that provides the connection between indoor space and outdoor space. It refers to entrance doors. It can be used as a control point for indoor-outdoor integrations. It contains conversion parameters for transforming the local CRS coordinates of indoor geometry. In cases where the global CRS is used for indoor space, the conversion parameters are not necessary. The transformReferencePoint element describes a reference point that is used for the conversion. TransformReferencePoint is a point in the global CRS. TransformReferencePoint is represented geometrically as a Point in Geography Markup Language (GML). TransformReferencePoint must have an attribute crsName to represent the used CRS of the outdoor network. The duality element represents an association with the corresponding AnchorSpace class, which represents a special opening space. AnchorState has a geometry that is derived from State class, and it is one of the endpoints of the curve geometry of AnchorLink.

All AnchorState elements are used for conversion, except the duality and connects elements: transformReferencePoint \($p_{o}(x_{0},\ y_{0},\ z_{0})$\), rotationAngle \($R(s_{x},\ s_{y},\ s_{z})$\), rescailingFactor \($A(\alpha,\ \ \beta,\ \ \gamma)$\), and translationVector \($T(t_{x},\ t_{y},\ t_{z})$\). The conversion using these parameters depends on the order in which they are applied. This document assumes that the transformation is performed in the order, as shown in Figure 10: Rotation Scaling Translation. In the case of rotation, the rotation should be performed after shifting to the origin based on the AnchorState point \($p_{a}(a_{x},a_{y},\ a_{z}$\)) for simplification of the problem. Finally, the method to obtain the conversion result, \($\text{Convert}\left( x,y,z,p_{a},p_{o},R,S,T \right)$\) using the given parameters is as follows:

ExternalAnchorState represents a node that represents the position on the outdoor network. It is represented geometrically as a Point in GML and it is one of the endpoints of the curve geometry of AnchorLink. It also has references to outdoor networks in other standards;
e.g., CityGML, GDF, etc.

Figure 11 depicts an example of mapping relation between ExternalAnchorState and externalNetworkReference for each case: The shape of externalNetworkReference should be represented as one of those types; (a) a point type, (b) an edge type and (c) a polygon type.

In the case of (a) in Figure 11, externalNetworkReference is represented as a point that is the closest to the entrance of the building in the outside network. Similarly, in (b) in Figure 11, externalNetworkReference represents an edge that is the most adjacent to the opening of the building in the outside network. In this case, the geometry of ExternalAnchorState should be a point on the edge of externalNetworkReference. Lastly, in (c) in Figure 11, externalNetworkReference represents a polygon that expresses the area of the building. In this case, the geometry of ExternalAnchorState should be a central point of the polygon of externalNetworkReference.

AnchorLink represents an edge between the indoor network and outdoor networks. AnchorLink always connects AnchorState and ExternalAnchorState. For the geometrical representation of an AnchorLink, a Curve geometric primitive object from the GML is used.

CityGML is an OGC standard data model and exchange format for storing digital 3D models of cities and landscapes. CityGML supports a transportation model that focuses on thematic as well as on geometrical/topological aspects, as shown in Figure 12.

The main class is TransportationComplex, which is composed of the parts TrafficArea and AuxiliaryTrafficArea. In the 'LOD 0' level of detail, the transportation complexes are modeled by line objects establishing a linear network. On this level, pathfinding algorithms or similar analyses can execute.

Therefore, the geometry of ExternalAnchorState should be created as a point on the lod0Network and must have the source data information of the TransportationComplex using the GML ID or URL information, as shown in Figure 13. The geometry of AnchorLink can be derived from two points, which are the geometries of AnchorState and ExternalAnchorState.

The sample data for the use case have been conducted at a real site: AIST Tokyo Waterfront Annex in Japan, as shown in Figure 14. This sample data shows the basic structure of SeamlessNavigation module data and how the SeamlessNavigation module and CityGML Transportation model datasets are linked via external references.

For simplicity, the detailed structure inside the AIST building is not represented, and the data are constructed using only 2D geometry. All geometric data in the sample data are derived from the Open Street Map (OSM[3]) data and have the same CRS; EPSG:4326 (WGS 84). The IndoorGML data consists of two spaces: one CellSpace and one AnchorSpace. The CityGML data has only one TransportationComplex instance.

The detailed contents of sample data for the AnchorState class are as shown in Figure 15. This data consists of IndoorGML Core and Navigation modules. AnchorState can have a geometry derived from the State class. This geometry is used to create the geometry of an AnchorLink. It can have several elements for conversion. However, in this case, all geometries have the same CRS, so these elements are omitted. AnchorState must have a transformReferencePoint and connects element. The TransformReferencePoint must have CRS information, as shown in the yellow part of Figure 15. The connects element is represented by an xlink for the GML ID of the AnchorLink class instance, as shown in the green part of Figure 15 and Figure 18. AnchorState can have a duality association with the AnchorSpace class instance, as shown in the blue part of Figure 15.

Figure 16 shows the ExternalAnchorState sample data. It consists of three properties: externalNetworkReference, geometry, and connects. ExternalNetworkReference is a corresponding object in the TransportationComplex instance, as shown in the blue part of Figure 16 and Figure 17. The geometry of ExternalAnchorState is derived from one of the points on a lod0network, as shown in the yellow part of Figure 16 and Figure 17. connects is represented by xlink for GML id of AnchorLink class instance, as shown in the green part of Figure 16 and Figure 18.

AnchorLink sample data is shown in Figure 18. The association elements (connectToIndoor and connectToOutdoor) are represented by xlinks for GML ID of each class instance. The curve geometry is derived from the geometry of connectToIndoor and connectToOutdoor instances.

PNspec includes both indoor and outdoor network information. To use the SeamlessNavigation module, we need to convert the indoors content of the PNspec into IndoorGML.

This chapter describes how to convert PNspec to IndoorGML. Because both IndoorGML and PNspec have node and link-based network models, they can easily convert between each schema. However, some special cases have different parts. In the case of a staircase, the PNspec places nodes at the beginning and end of the staircase, then links the two nodes. However, in IndoorGML, a staircase is expressed as a single space, so it is expressed as a single State. To resolve these conflicts, we need the mapping rules shown in Figure 19.

Similarly, for gradients, PNspec places nodes at the beginning and end of the sloped space, then links the two nodes. However, in IndoorGML, the space with slope is expressed as a single space, so it is expressed as a single State. To resolve these conflicts, we need the mapping rules shown in Figure 20.

Finally, in the case of a step, PNspec places nodes before and after a step. In the case of IndoorGML, we can divide space around a step. However, we do not create a state around the step. Depending on the concept of cellular space of IndoorGML, multiple nodes will be mapped to a single State, as shown in Figure 21.

In addition, PNspec expresses a node having the same concept as an anchor node of this document as 'the in/out boundary of the facility.' However, in PNspec, an entrance is supposed to be a link. Depending on the characteristics of the AnchorState defined in this discussion paper, the entrance should be represented as a State. Therefore, the nodes and links representing the entrance in the PNspec should be represented by classes of IndoorGML Core and SeamlessNavigation module as shown in Figure 22.

The sample data for the use case have been conducted at a real site: Tokyo station, as shown in Figure 23. PNspec sample data is derived from data by the Government of Japan, and is provided through an open license ^[1]. This chapter shows how the SeamlessNavigation module and PNSpec datasets are linked via external references.

For simplicity, we used a part of Tokyo station data, as shown in Figure 24: four nodes and three edges.

The detailed contents of sample data for the nodes is shown in Figure 25. The PNSpec data provided by the GeoJSON format. Nodes can be distinguished by the ‘in_out’ attribute. In the case of an ‘in_out’ attribute of value ‘2’, this node represents the entrance of the building. And then, we can choose one node for connecting ExternalAnchorState, using the link attribute of the node. Figure 26 shows the sample data for edges that linked with the entrance of the building node with an ID of ‘00001B000000000309CC60A662D77FC1’. For making an ExternalAnchorState instance, we have to choose one of the connected nodes with the entrance of the building, and the ‘in_out’ value is ‘1’. In this sample data, there are three Nodes connected to the entrance of the building node. However, one of these nodes is located in indoor space: with an ‘in_out’ value of ‘2’. Therefore, we have to choose one node from the remaining two nodes.

The mapped ExternalAnchorState result is shown in Figure 27.

GDF is an ISO international standard that specifies the conceptual and logical data models and physical encoding formats for geographic databases for Intelligent Transportation Systems (ITS) applications and services. It has the reference number ISO 14825:2011.

Figure 28 shows that the overall conceptual data model of GDF 5.0. Within the GDF 5.0 model, a Feature is a database representation of a real-world geographic object: roads, buildings, etc. Each Feature must belong to exactly one FeatureClass and FeatureTheme. A Feature may have zero or more AttributeValue instances that serve to represent characteristics of a Feature. A Relationship is used to associate two or more Features together and may have zero or more AttributeValue instances.

In this discussion paper, we focused on how to connect the outdoor network and indoor network using the IndoorGML SeamlessNavigation module. Therefore, we have to make a connection between ExternalAnchorState and a specific feature of GDF 5.0; i.e., the entrance of the building, the element of pedestrian network, etc. Firstly, the entrance of the building element can be expressed in two ways: Using Relationship, Using Feature.

As shown in Figure 29, the entrance of the building can be expressed as a BuildingAlongRoadElement, one of the types of Relationship. BuildingAlongRoadElement identifies the RoadElement along which the entrance of the Building, SchematicBuilding, or BuildingUnit is situated. In the case of using BuildingAlongRoadElement, for connecting to ExternalAnchorState, we have to make externalReference based on roadElement ID, an element of BuildingAlongRoadElement.

As shown in Figure 30, the entrance of the building can be expressed as an EntryPoint, one of the Types of GeneralFeature. EntryPoint can be distinguished through the characteristics of the entrance. A “main” entrance is generally characterized by the following:

In the case of using EntryPoint, for connecting to ExternalAnchorState, we have to make an externalReference based on the EntryPoint ID.

The geometry of all Features in GDF 5.0 shall be expressed by Node, Edge, and Face. Figure 31 shows a UML diagram of the conceptual data model for PlanarTopoSimpleFeature, one of the types of graph topology.

The sample data for the use case have been conducted at a real site: AIST Tokyo Waterfront Annex in Japan, as shown in Figure 32. The GDF 5.0 sample data created was based on the XML schema that is provided in Chapter 13 of GDF 5.0. For simplicity, we elide DLS (Dataset, Layer, Section) information in sample data. The detailed contents of the GDF sample data are shown in Figure 33. This data consists of four Point Features and one Relationship.

Point Feature instances must have point_feat_ID, feature_code, and coord properties: point_feat_ID means identifier of Point Feature, feature_code means the four-digit code of the Feature Class to which the Feature in issue belongs, and coord means a position of Feature.

Relationship must have rel_ID and rel_code: rel_ID means identifier of Relationship and rel_code means (pre-defined or user-defined) relationship type code. And Relationship can have num_feat and rel_feature: num_feat means the number of features that belong to Relationship and rel_feature means the feature information belong to Relationship.

The mapped ExternalAnchorState result is shown in Figure 34.