bigml: a location model with individual waypoint graphs ... · bigml: a location model with...

PIK, Vol. 13, pp. 261267, Dezember 2010 Copyright c by Walter de Gruyter Berlin New York. DOI 10.1515/piko.2010.045

BIGML: A Location Model with Individual Waypoint Graphsfor Indoor Location-based Services

Moritz Kessel

Mobile and Distributed Systems GroupInstitute for InformaticsLudwig-Maximilians-UniversityMunichOettingenstr. 6780538 [email protected]

Moritz Kessel is a research associate at the Mobile and DistributedSystems Group at LMU Munich. His main research interests in-clude location models for LBS, especially inside of buildings, in-door navigation systems and positioning systems.

Peter Ruppel


Peter Ruppel is a research associate at the Mobile and DistributedSystems Group at LMU Munich. His main research interests in-clude location-based services, positioning, navigation and mobilecommunications.

Florian Gschwandtner


Florian Gschwandtner is a research associate at the Mobile andDistributed Systems Group at LMU Munich. His research inter-ests include location-based services, both in indoor and outdoorenvironments and navigation in indoor environments.

Abstract

Indoor Location-based Services (I-LBS) provide informationthat is compiled by taking into account the current locationsof targets as well as models of surrounding buildings. Beside

navigation applications there are lots of other examples on thefield of workflow optimization or logistics. A key role amongthe value chain of I-LBS is a location model provider thatdelivers topological and geometric information about a build-ing. This includes for example computing the walking dis-tance between two locations, finding certain points of interestor looking up the room name for a targets coordinate, whichhas been measured by an arbitrary indoor positioning system.Building models have already been studied in the past. How-ever, existing approaches focus either on the visualization ofa building or they are intended to support architects in theprocess of constructing the building. In this paper we iden-tify requirements for future I-LBS and we present a new loca-tion model that allows to store both topological and geometricproperties of buildings. The model is specified as an applica-tion schema for the Geography Markup Language (GML).It enables a location model provider to utilize automaticallygenerated waypoint graphs that can be individually adaptedto the requirements of the specific I-LBS. Further more thewaypoint graphs can easily be replaced leaving the remaininggeometrical and topological properties unchanged. The feasi-bility of the model for I-LBS as well as different approachesfor automated model generation are also demonstrated by aworking prototype.

1 Introduction

The exploding number of smartphones as well as various mar-ketplaces for mobile applications have greatly favored thegrowing popularity of mobile services. Together with accu-rate outdoor positioning technologies such as GPS, Location-based Services (LBS) have entered the mass market. Atthe same time so-called Indoor Location-based Services areemerging. However, the spread of I-LBS is currently limitedmainly by two factors: First, indoor positioning systems areeither expensive or they lack the needed accuracy. Second,the lack of comprehensive indoor location models makes itdifficult to offer attractive services to the user.

Location models for outdoor environments have beenexamined in detail in the past years, especially the OpenGeospatial Consortium (OGC) has published standards forlocation modeling such as KML [17] and CityGML [18] andhas as well standardized the creation of application schematafor location models with GML [16]. Another example isgiven by the Openstreetmap [8] project, which has grown ex-tensively in the recent past and offers a flexible approach formodeling semantically enriched maps.

I-LBS require not only accurate indoor positioning tech-nologies, but also location models that reflect a buildingsgeneral structure and topology. The de facto standard for ex-changing architectural plans, AutoDesk DXF [11], was notdeveloped to contain the semantic information needed by

Bereitgestellt von | Universitaetsbibliothek der LMU MuenchenAngemeldet

Heruntergeladen am | 05.11.15 14:20

mailto:[email protected]:[email protected]:[email protected]

262 Moritz Kessel, Peter Ruppel and Florian Gschwandtner

most I-LBS. Existing standards for indoor location modelssuch as IFC [6] and CityGML offer various options to de-scribe the properties of buildings. However, these standardsfocus either on the visualization of building information orthey are intended to be used mainly by architects. Future I-LBS will require additional information, especially the ac-cessibility and general topology of rooms, floors and otherparts of a building. Such information can be expressed forexample by using waypoint graphs and the geometric shapeof objects. Among the value chain of I-LBS (compare [20])this task is accomplished by the role of the location modelprovider, which encapsulates the location model and providesinterfaces to the I-LBS provider.

Given that different I-LBS require various levels of detailof the building, the location model provider should also beable to deliver topological information with a varying gran-ularity and accuracy. An example could be that a simplewalking distance calculator will only need a very coarse way-point graph, whereas an augmented navigation applicationwill greatly benefit from a high resolution path through thebuilding.

Existing location models for I-LBS do not allow an easyexchange of walkability information and they are not orientedtowards automated waypoint graph generation so far.

In this paper we present BIGML, a new location modelthat takes into account the special requirements of I-LBS. It isspecified as an application schema for GML 3.2 and it allowsto separate the waypoint graph and its granularity from therest of the geometric and topological aspects. This enablesthe exchange of the underlying graph structure by choosingdifferent algorithms for automatic waypoint graph creation.Being outside the scope of this paper, the automated way-point graph generation has been successfully demonstratedwith various algorithms including triangulation, convex par-titioning, corner graphs and straight skeleton [19].

BIGML also allows to explicitly describe points of interest(POI) as well as areas of interest (AOI). The latter is a conceptto group areas outside the strict hierarchy of rooms and floors.Furthermore, the model can be created automatically fromexisting CAD data, which is demonstrated by a prototype thatparses DXF files.

The remainder of this paper is structured as follows: In thefollowing section requirements for a location model for futureI-LBS are identified and discussed. Section 3 introduces thelocation model, describes the contained elements in detail andelaborates on automated waypoint graph creation. Section 4shows the results of an empirical evaluation. Section 5 coversrelated work and Section 6 concludes the paper with someremarks on future work.

2 Location Models for I-LBS

Location models for I-LBS have several requirements that aredifferent from outdoor LBS models. These result from theroles and actors involved as well as from available indoorpositioning technologies and the class of service being pro-vided. Given that already today there is a variety of I-LBSavailable and running, each service has slightly different re-

quirements with respect to the location model. To meet theserequirements, we analyzed several existing I-LBS of varyingclasses, including information, navigation, tracking and man-agement services [10, 15, 23, 24], adapting the classificationfrom [20] for indoor environments.

A targets position, which has been measured by a posi-tioning system, needs to be mapped onto the location modeland vice versa. The location model itself can be expressedeither in a symbolic, geometric or hybrid fashion [12]. Sym-bolic models involve the assignment of human-readable des-ignators to locations and they can be further subdivided intoset-based and graph-based approaches. The geometric mod-els use spatial coordinate systems to store location data andare essential for computations such as distance between coor-dinates or rendering of maps. A hybrid location model com-prises both symbolic and geometric features. Given that manypositioning systems deliver coordinates on a local scale it isdesirable for a location model to allow easy transformationbetween model-specific and other coordinate systems.

A second fundamental requirement is that routes can becomputed. Optimal paths based on the walking distance arerequired not only by indoor navigation applications, but alsofor example for logistics, maintenance scheduling or work-flow optimization. Other applications may also require con-straints to be taken into account such as the maximal widthalong a path or a turn radius. A waypoint graph can be used todetermine a desired route. In most cases the waypoints of thegraph will also be linked to geometric coordinates in order toconnect topological with geometrical information. However,the required resolution and accuracy of waypoints may varyfrom application to application. Thus the creation of a graphshould not affect the buildings structure and topology.

Querying k nearest objects of interest is another mecha-nism required by many I-LBS. The objects can be sorted withrespect to the walking distance, the Euclidean distance or de-pending on other attributes. Also the query can refer to staticor dynamic targets. Depending on the mobility of the target,this information is either stored in the static location model oris directly kept in the applications memory.

In contrast to the nearest neighbor query, a range queryqueries for all objects of a certain type in a fixed geographicarea. To support range queries, a location model has tomodel object positions. Containment of symbolic coordinatesshould be explicit by construction, e.g. a building should con-tain its floors which in turn contain their rooms, while thecontainment of geometric coordinates in a given area can betested on demand.

When it comes to the visual presentation and map render-ing for a location model it is vital to have geometric informa-tion about the locations and orientations of rooms, floors andbuildings available.

In addition to the fundamental shape of a building and itsrooms, it is also necessary to describe POIs, which can berelated to a certain object or asset. Besides single points itis also desirable to model whole AOIs at which the coveredarea does not necessarily correspond to the topology of thewaypoint graph (meaning that an AOI can cover e.g. two sub-areas in adjacent rooms which are separated by a wall andthus two points in the AOI might not be directly reachablewithout leaving the AOI).



BIGML: A Location Model with Individual Waypoint Graphs for Indoor Location-based Services 263

The diversity of I-LBS is the reason for another require-ment for a comprehensive location model: In order to be ableto model every possible feature of an object that can be ofinterest to a service, a flexible way to store the properties isrequired. Free tagging describes the possibility to assign anynumber of additional attributes to existing objects.

Existing location models achieve already various of theserequirements. However, an explicit and flexible representa-tion for waypoint graphs is missing so far, especially onethat allows an easy and automated graph generation based onvarying waypoint graph generation algorithms.

3 BIGML: A Location Model for I-LBS

In the following, we present BIGML1, an application schemafor GML. GML already offers a huge variety of types andelements for the presentation of geometric, topological andtemporal information [16]. It serves as a construction kit forapplication specific schemas. A list of existing applicationschemas such as the Canadian Road Markup Language, theClimate Science Modeling Language or XPlanGML, can befound at [2].

In this section the relevant elements and correspondingconcepts are introduced. Figure 1 shows a UML diagram andgives an overview on the classes, associations and inheritedclasses involved. At the end of the section the integrationof different automatically generated waypoint graphs is dis-cussed.

3.1 Location Model Elements

GML offers a wide range of so called data types, which arespecifications of value domains. We introduced a data typenamed PropertyTag which is a key-value pair fulfilling therequirements of free tagging. It enables the model providerto store additional content and information in the model. Thetwo attributes of a PropertyTag element, key and value, arestrings with any content.

The class GlobalCRSReferencePoint inherits from Ab-stractGeometry. Each GlobalCRSReferencePoint consists oftwo gml::Point objects, one with coordinates in the local sys-tem and the other with coordinates in a wellknown systemsuch as WGS84. While the topic of coordinate transforma-tion and map projection is outside the scope of this paper,three common points in two coordinate systems (CS) are suf-ficient to compute the transformation parameters. Those pa-rameters are required to map a point from one CS into theother and vice versa. No explicit transformation is given, be-cause the model should be as simple as possible, enabling themodel creator to choose the reference points manually. Thelocal coordinate system is given as a child element of the site,which is described later on.

Features are represented by the abstract superclass Ab-stractBuildingInformation, which is derived from the GML-class AbstractFeature. An AbstractBuildingInformation el-

1The full XML-schema file can be downloaded from: http://www.mobile.ifi.lmu.de/schemas/bigml

ement has an arbitrary number of PropertyTags as describedabove. The subclasses represent abstractions of the real worldphenomena [13] such as rooms, doors, entries or POIs. Directsubclasses are listed in the following paragraphs.

A Site represents a site or real estate, which can hold oneor more buildings, several entries of type SiteEntry and a ref-erence to all BuildingPortals, connecting the inside of build-ings with the outside world on the site. Furthermore eachSite has a local coordinate system localCS, which is the ref-erence system for all geometric coordinates of the model (ex-cept for the globalPoint children of any globalCRSReferen-cePoint). The geometric representation of the Site is givenby a gml::Polygon in the outline child of the site. With atleast three optional globalCRSReferencePoints a transforma-tion between two reference systems becomes possible. A Sitehas the optional string-attributes class and usage, which de-scribe the kind of site and the actual usage of the site. Themechanism is adopted from CityGML where such attributesare given for buildings and rooms [18, Annex C]. An optionalowner and any number of associated websites can be given.Only the globally unique URI is mandatory and should beused to identify the site. Last but not least every site has angraph object containing the waypoint graph that can be re-placed as described in 3.2.

A Building represents a building or building part thatholds one or more floors and belongs to exactly one site. It isalso linked to a gml::Polygon representing its outline and theoptional attributes class and usage, whose domain is spec-ified by the German authoritative standards ALKIS/ATKIS[9]. In addition, the number of levels above (storeysAbove-Ground) and below the surface (storeysBelowGround), theheight and depth of the building, the heightAboveNN (heightof ground floor above sea level) and a yearOfConstructioncan be given. All length attributes such as height are of thegml::LengthType, which gives the possibility to define theunit of measure.

A Floor represents a floor or structural level of a building,containing at least one room and belonging to exactly onebuilding. It has a gml::Polygon as outline and the requiredattributes heightAboveGround, which describes the height ofthe floor above ground level, which we define as the lowestlevel above ground, and level, which is the integer number ofthe floors level. The level attribute also defines the verticalorder of the floors.

A Room represents a single room, containing any numberof POIs, AOIs, portals and nodes, referencing to the way-point graph. However, this does not conflict with the abilityto replace the waypoint graph as we will describe in 3.2. Ev-ery room has a gml::Polygon as outline and references thefloor it is on. A Room has the optional attributes class andusage, whose domain is specified by the SIG 3D. The op-tional heightOfCeiling parameter is used to create simple 3Drepresentations of the room by combining the outline as 2Dpolygon with a third dimension. However, this mechanism isnot sufficient to model complicated structured ceilings, likeroof pitches or galleries. The latter information is often notneeded by I-LBS and seldom included in available CAD data.3D shapes would also result in slower computations, be moreexpansive in size and have a serious impact on human read-ability.



http://www.mobile.ifi.lmu.de/schemas/bigml


FeatureBuildingInformation

Featuregml::Feature

+id: ID+description: gml::StringOrRefType [0..1]+name: gml::CodeType [0..n]+boundedBy: gml::Envelope [0..1]

DataTypePropertyTag

+key: String+value: String

BuildingInformationBuilding

+class: BuildingClassType [0..1]+usage: BuildingUsageType [0..1]+storeysAboveGround: int [0..1]+storeysBelowGround: int [0..1]+height: gml::LengthType [0..1]+depth: gml::LengthType [0..1]+heightAboveNN: gml::LengthType [0..1]+yearOfContruction: gYear [0..1]

BuildingInformationSiteEntry

BuildingInformationAddress

+address: xAL::AddressDetails

PortalBuildingPortal

PortalDoorPortal

PortalStairPortal

PortalEscalatorPortal

PortalElevatorPortal

PortalRampPortal

BuildingInformationPortal

+angle: gml::AngleType [0..2]

GeometricPrimitivegml::Polygon

CoordinateSystemgml::CartesianCS

AbstractGeometryGlobalCRSReferencePoint

BuildingInformationSite

+class: SiteClassType [0..1]+usage: SiteUsageType [0..1]+owner: String [0..1]+URI: anyURI+website: anyURI [0..n]

TopologyGraph

TopologyNode

TopologyEdge

+length: gml::LengthType

BuildingInformationFloor

+heightAboveGround: gml::LengthType+level: int

BuildingInformationRoom

+class: RoomClassType [0..1]+usage: RoomUsageType [0..1]+heightOfCeilling: gml::LengthType [0..1]

BuildingInformationPOI

+class: POIClassType [0..1]+URI: anyURI+description: String [0..1]+angle: gml::AngleType [0..2]

BuildingInformationAOI

+class: AOIClassType [0..1]+usage: AOIUsageType [0..1]+URI: anyURI+description: String [0..1]

GeometricPrimitivegml::Point

0..n propertyTag

1 localCS

1 graph

0, 3..nglobalCRSReferencePoint

0..naddress

1..nsiteEntry

1..n

edge

2..n node

1..n

building

1isOn

1..nbuildingPortal

1 outline1 outline

1outline

1outline1outline

2globalPoint & localPoint

1position1

node

1..n

1..nfloor

1 building

1..nroom

1floor

0..npoi

1 room

0..naoi

1 room

0..n

portal

1belongsTo

1..nlinksTo

GeometricPrimitivegml::Ring

0..1

geometry

1

node

0..1

poi

1edge

0..1portal

1node

0..ncontainedNode

0..1room

0..npropertyTag

0..npropertyTag

Figure 1 BIGML UML-diagram. Inherited classes from GML 3.2 are shown in gray.

A POI represents a single point or object of interest. Itreferences a node in the graph, containing the exact topolog-ical and geometrical position of the POI. Therefore this nodeshould not be overridden when an new graph is assigned tothe model. In addition, a POI references the room it is in andhas a unique URI and the optional attributes class, descrip-tion and two angles (measured anti-clockwise from the firstaxis of the coordinate system), which define a sector withinwhich the POI is visible. This attribute is needed by severalI-LBS that utilize line-of-sight.

The class AOI extends the mechanism of POI to wholeareas of interest. An AOI is not simply a POI with a geomet-rical extension, but a new powerful concept to define parallelhierarchies. The URI is no longer unique, but gives the pos-sibility to aggregate several AOIs to a larger area, which canbe outside the hierarchy of buildings, floors and rooms. Inthis context, all AOIs with the same URI are seen as a part ofthe larger area of interest, which is their union. This mecha-nism can be used to combine several rooms on different floorsor even in different buildings, for example in order to modeldepartments in a company or wards in a hospital. Figure 2shows an example how areas of interest can be used to grouprooms. Every AOI element references the containing room,has a gml::Polygon as outline and has the optional attributesclass, usage and description.

A Portal represents a connection between rooms or a siteand a room. Each portal belongs to a single room or site andis linked to at least one other portal of the same type. AnAbstractPortal element can be instantiated by a DoorPortal,

Figure 2 Several areas (different scales of gray) and anautomatically created waypoint graph (dark grey edges) in auniversity building.

StairPortal, ElevatorPortal, EscalatorPortal, RampPortal ora BuildingPortal. Every Portal references an edge and a node.These edges and nodes cannot be replaced together with thewaypoint graph. The reason is, that the Portals also remainfixed, because they belong to the geometrical or structuralrepresentation of the building. As described in 3.2, the nodesand edges referenced by portals are needed to model the walk-ability between rooms, floors and buildings. In addition thegeometry of the portal is stored in a gml::Ring object, whilethe viewing angle of the portal entry is modeled by two anglesof gml::AngleType. For these angles the same convention isused as with POIs.




A SiteEntry represents an entry point to the site from theoutside world. It references a single node that is part of thetopological model of the site. This node is also fixed and notexchangeable.

An Address contains the representation of an address inthe extensible address language [4] and references a SiteEn-try, which the address belongs to. It can be seen as a doorplateat the referenced entry, which can include additional informa-tion within the property tags.

The following types do not inherit from AbstractBuilding-Information, but extend the GML type AbstractTopology.

The class Graph contains a list of all nodes and edges ofthe waypoint graph. There is only one graph object for eachsite, which should be connected to ensure the reachability ofall nodes.

GML offers already a topological type for node elements.It offers many possibilities like pointers to other topolog-ical structures containing the node, e.g. faces or topologi-cal solids. Since we only need the reference to edges andsome building information elements, we define a new typeNode which references at least one edge, exactly one position(a gml::Point in the local coordinate system) and optionallya single POI, room, portal or SiteEntry. Because Node doesnot inherit from AbstractBuildingInfromation it has explicitlyany number of additional PropertyTag elements as children.

The class Edge is out of the same reasons not an extensionof the GML type edge. The edge defined here is just a simpleconnection between nodes with a weight and arbitrary addi-tional properties. Every Edge references exactly two nodes,a length of gml::LengthType and any number of Property-Tags.

3.2 Individual Waypoint Graphs

BIGML allows arbitrary waypoint graph generation ap-proaches to be applied. The possibility to exchange graphsoffers a range of opportunities, e.g. the on-demand creationof parts of the graph or offering waypoint graphs with varyinggranularity for different I-LBS. In the following paragraphs,the stepwise replacement of the graph is described.

We require a predefined set S of nodes and edges whichwe call static, representing the topological structure (connec-tions between rooms, floors, etc.) of the site. It should staythe same for any underlying waypoint graph. The same ap-plies to the points of interest, which should still be reachablewithin the new waypoint graph. This set is easily identified:For every edge e which is referenced by a portal and for ev-ery node n that references to a portal, site entry or POI theelement is added to the set. The remaining nodes and edgesare deleted.

In the next step the graph is computed for every room andevery part of the site that is not covered by buildings. Thealgorithm creating the graph can have a large impact on thenumber of nodes, the length of ways and even the simplicityof ways. Figure 3 shows for example the resulting waypointgraph for a specific room using four different algorithms. Anevaluation and discussion on automated waypoint graph gen-eration for I-LBS can be found for instance in [19].

The resulting waypoint graph for each room and the site isconnected to the corresponding nodes in S . Different algo-

(a) Corner graph (b) Convex partitioning

(c) Triangulation (d) Improved corner graph

Figure 3 Waypoint graphs resulting from different al-gorithms. Black nodes and edges: doors. Gray nodes andedges: exchangeable graph elements.

rithms can be used for the connection, such as connecting thestatic nodes with all new nodes in line of sight or only withthe next new node. Either way it must be ensured that everystatic node of every room has at least one connection to thenew graph of each room.

4 Evaluation

The presented model offers three main advantages: first, itcan be integrated into a variety of existing tools for automaticcode generation. That allows an easy adoption and instantia-tion of the model. Second, the geometric and topological ele-ments of the model are independent from each other and canbe handled by appropriate algorithms. Given that the searchspace representation is not restricted by the model, the ap-plication developer can e.g. deploy her own R-Trees or A*heuristics. The proposed graph structure of the model also al-lows hierarchical graphs to be applied. Third, the model sup-ports various types of walkability information. The simplestway is to utilize only existing polygon points and to createe.g. a corner graph. Also the straight skeleton or the medialaxis of polygons can be computed and utilized for routing.Furthermore the generation of triangulations, Delaunay trian-gulations and especially constrained Delaunay triangulationsdeliver even more information: such navigation mesh can beadopted to calculate shortest paths with a minimal width orfor objects with limited turn radii.

The model was created automatically from CAD data, ac-cording to the schema specified in Section 3. The CAD datacontained a building with five stories, more than 800 roomsand over 1000 portals such as doors, escalators, stairs and el-evators (see Figure 4 for the first three sample floors).

Seven different algorithms were successfully used for au-tomated graph generation. A Corner Graph, a variation of




Figure 4 Example: CAD data source for automated loca-tion model generation.

the corner graph with waypoints moved to the interior ofthe polygon, two different algorithms for convex partition-ing, a Delaunay triangulation with two different methods forwaypoint generation from the resulting triangles and an algo-rithm to create a straight skeleton were applied. The numberof created nodes was in between 2000 and 6500, the numberof edges ranged from 5800 to nearly 20000 (depending on thealgorithm used). The size of the uncompressed XML file isbetween 6 MB and 13 MB, mostly influenced by the numberof graph elements. Given that the model is rather small interms of memory space, a complete model can be loaded intothe computers memory for faster access. It is also suitablefor deployment on mobile phones.

After generating the model, a map-based routing applica-tion and a room management service were implemented toevaluate empirically the applicability of the model. The appli-cations were able to calculate routes and find required roomsas expected. Since the model meets the requirements listedin Section 2, there should hardly be any problems to use themodel for other I-LBS.

It has to be stressed that consistency and integrity of theCAD data is of major importance. We tried to parse datafrom several organizations and buildings, but only very few ofthem were sufficient to automatically extract a location modelwithout manual modifications.

The model has some limitations, as it is not able to de-scribe complex 3D content. As soon as more 3D I-LBSevolve, the model might need additional information, depend-ing on the required level of detail. So far the model supportsonly one graph at a time. This is a limitation, because thereplacement of the whole waypoint graph is to slow to be car-ried out on demand. However, it is possible to generate sev-eral instances of a buildings model, each one with a differentwaypoint graph.

5 Related Work

The topic of location models has been the focus of extensiveresearch in the past years. There exist three categories of lo-cation models: pure indoor location models, outdoor locationmodels and overall location models capable of modeling in-door and outdoor environments.

Existing indoor location models often have their origin inarchitectural plans, such as CAD or IFC. The de facto stan-dard of architectural CAD from AutoDesk, DXF [11], is usedmainly as an exchange format for building plans. It is noteasily extensible, because it uses a proprietary data format,and was initially not intended to model topologies. Industrial

Foundation Classes (IFC) [5], currently at version 2x3, is astandard of the building industry. It relies on a object orientedmodel describing all architectural information of buildings.Being a comprehensive and extensive model, IFC also aimsmainly for architects and facility management. The same ap-plies for other approaches for standardizing building informa-tion, such as the Building Information Spatial Data Model [1]and Green Building XML [3]. Like IFC, these models are farmore extensive than BIGML, but are not intended for use onmobile clients in I-LBS. Indoor location models for I-LBSsuch as the Facility Map Framework [25] often use a propri-etary data format not publicly available.

Overall location models often originate from or focus onoutdoor location models, since outdoor-LBS is far more com-mon. However, CityGML [18], an application schema forGML, offers a comprehensive approach which has turned re-cently into a standard of the Open Geospatial Consortium(OGC). It was initially developed to model cities or urbandistricts in five different levels of detail, ranging from LOD0,a large overview over whole cities, to LOD4 a representationof the inside of buildings. With the LOD4, CityGML offersan indoor location model that is especially suited for visual-ization, as the geometrical shape of objects is explicitly mod-eled in 3D. So far it offers no concept to explicitly describethe walkability inside of buildings.

Some research focuses not only on overall location mod-els, but also on platforms to offer and request location infor-mation from several sources. Nexus [22] for example offerssuch a platform which accesses the Nexus Augmented WorldModel [21]. The latter models many aspects of outdoor andindoor environments, focused on the integration of location-based services.

Several location models such as KML [7] and Open-StreetMap [14] are mainly used for outdoor location model-ing, especially for enriching maps and serving for navigationpurposes. They fulfill many requirements such as the model-ing of POIs and free tagging, may contain a waypoint graphand are already used by mobile clients. However, they offerlimited possibilities to describe both structure and topologyof buildings in three dimensions.

6 Conclusion and Outlook

In this paper we have presented BIGML, a new locationmodel for Indoor Location-based Services that allows to storeboth topological and geometric properties of buildings. WithBIGML the underlying waypoint graph for a specific buildingcan be individually adjusted for different classes of I-LBS.The model offers a hybrid location model with symbolic andgeometric coordinates, it is of hierarchical structure, graphbased, extensible and flexible. BIGML is specified as an ap-plication schema for GML. For these reasons, the model canbe applied directly to different I-LBS with little effort.

Currently we are working on an approach to dynamicallyfetch parts of the model from applications that run on mo-bile devices. By transferring only the routes and polygonsto the mobile device that are needed to answer the local re-quest of the mobile user, we aim to minimize the amount of




transmitted data. Such strategies need to take into account forexample the mobility of the target or dynamic changes on theroute.

Another open problem remains in the lack of integrity ofexisting CAD plans. Therefore we are working on a set of al-gorithms and tools to further support the model creation pro-cess. Last but not least, future work will include feasibilitystudies on utilizing the model to support existing 3D I-LBSsuch as visually enriched indoor navigation.

References

[1] Building Information Spatial Data Model. http://bisdm.org, last visited 07.09.2010.

[2] GML Application Schemas and Profiles. http://www.ogcnetwork.net/node/210, last visited07.09.2010.

[3] Green Building XML. http://www.gbxml.org, lastvisited 07.09.2010.

[4] Extensible Address Language (xAL) Standard Descrip-tion Document for W3C DTD/Schema. Technical re-port, Organization for the Advancement of StructuredInformation Standards, 2002.

[5] IFC2x3 TC1 Documentation. online, June 2010.http://www.iai-tech.org/ifc/IFC2x3/TC1/html/index.htm.

[6] ifcXML Schema. online, June 2010. http://www.iai-tech.org/ifcXML/IFC2x3/FINAL/IFC2X3.xsd.

[7] KML Reference. online, June 2010. http://code.google.com/intl/de-DE/apis/kml/documentation/kmlreference.html.

[8] OpenStreetMap. online, June 2010. http://wiki.openstreetmap.org/wiki/Main_Page.

[9] Arbeitsgemeinschaft der Vermessungsverwaltungen derLnder der Bundesrepublik Deutschland. Dokumen-tation zur Modellierung der Geoinformationen desamtlichen Vermessungswesens, 6.0 edition, April 2008.Available at http://www.adv-online.de.

[10] Abhaya Asthana, Mark Cravatts, and PaulKrzyzanowski. An Indoor Wireless System forPersonalized Shopping Assistance. Technical report,AT&T Bell Laboratories, 1994.

[11] AutoDesk. DXF Reference, 2007.

[12] Christian Becker and Frank Drr. On Location Modelsfor Ubiquitous Computing. In Ubiquitous Computing,volume 9, pages 2031, 2004.

[13] International Organization for Standardization. ISO19101 Geographic information Reference model,2002.

[14] Mordechai (Muki) Haklay and Patrick Weber. Open-StreetMap: User-Generated Street Maps. IEEE Perva-sive Computing, 7:1218, 2008.

[15] Christian Harr. Mobiles Navigationssystem fr Medio-Vis. Masters thesis, Universitt Konstanz, 2006.

[16] Open Geospatial Consortium Inc. OpenGIS R Geogra-phy Markup Language (GML) Encoding Standard, 082007.

[17] Open Geospatial Consortium Inc. Keyhole MarkupLanguage 2.2, 2008.

[18] Open Geospatial Consortium Inc. OpenGIS R City Ge-ography Markup Language (CityGML) Encoding Stan-dard, 08 2008.

[19] Moritz Kessel. Erzeugung von Umgebungsmodellenaus digitalen Gebudeplnen fr Ortsbezogene Dien-ste. Masters thesis, Ludwig-Maximilians-UniversittMnchen, 2010.

[20] Axel Kpper. Location-Based Services: Fundamentalsand Operation. John Wiley and Sons Ltd., 2005.

[21] Jens Memer. Modellierung der Augmented World inNexus. Masters thesis, Universitt Stuttgart, 2001.

[22] Daniela Nicklas. Ein umfassendes Umgebungsmodellals Integrationsstrategie fr ortsbezogene Daten undDienste. PhD thesis, Universitt Stuttgart, 2005.

[23] Reinhard Oppermann and Marcus Specht. A Context-sensitive Nomadic Information System as an ExhibitionGuide. Technical report, German National ResearchCenter for Information Technology Institute for Ap-plied Information Technology, 2000.

[24] Peter Ruppel, Florian Gschwandtner, Corina KimSchindhelm, and Claudia Linnhoff-Popien. Indoor Nav-igation on Distributed Stationary Display Systems. In33rd Annual IEEE International Computer Softwareand Applications Conference, 2009.

[25] Steven A. Shafer. A Framework for Creating and UsingMaps of Privately Owned Spaces. In LoCA, pages 174191, 2009.



http://bisdm.orghttp://www.ogcnetwork.net/node/210http://www.gbxml.orghttp://www.iai-tech.org/ifc/IFC2x3/TC1/html/index.htmhttp://www.iai-tech.org/ifcXML/IFC2x3/FINAL/IFC2X3.xsdhttp://code.google.com/intl/de-DE/apis/kml/documentation/kmlreference.htmlhttp://wiki.openstreetmap.org/wiki/Main_Pagehttp://www.adv-online.de

IntroductionLocation Models for I-LBSBIGML: A Location Model for I-LBSLocation Model ElementsIndividual Waypoint Graphs

EvaluationRelated WorkConclusion and Outlook

/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 150 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 600 /GrayImageDepth 8 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.01667 /EncodeGrayImages true /GrayImageFilter /FlateEncode /AutoFilterGrayImages false /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 1200 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 2400 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.00417 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects true /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile (None) /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName (http://www.color.org) /PDFXTrapped /False

/CreateJDFFile false /SyntheticBoldness 1.000000 /Description >>> setdistillerparams> setpagedevice

bigml: a location model with individual waypoint graphs ... · bigml: a location model with...

Documents