Indoor Maps MSC Thesis

Indoor Maps
HENRIK SANDSTRÖM
and JOHANNES SVENSSON
Master of Science Thesis

Stockholm, Sweden 2010
Indoor Maps
HENRIK SANDSTRÖM
and JOHANNES SVENSSON
Master’s Thesis in Computer Science (30 ECTS credits)

at the School of Computer Science and Engineering
Royal Institute of Technology year 2010
Supervisor at CSC was Stefan Arnborg
Examiner was Johan Håstad
TRITA-CSC-E 2010:119
ISRN-KTH/CSC/E--10/119--SE
ISSN-1653-5715
Royal Institute of Technology

School of Computer Science and Communication
KTH CSC
SE-100 44 Stockholm, Sweden
URL: www.kth.se/csc
Abstract
This Master Thesis investigates how a solution for indoor
maps can be implemented. It proposes an XML-based for-
mat for storing the internal information of buildings. This
thesis shows how a format was created by first researching
present outdoor map formats, then combining the best con-
cepts from these formats with required indoor information.
The proposed format is focused on being easy to use and to
work with. The format takes advantage of important con-
cepts like layers, inheritance, and references, which makes
it flexible and to prevent redundancy.
This thesis also shows how the created format works in
different implementations. The main implementations are
an editor, which can quickly and easily create maps, and
a mobile viewer, which makes it possible to interact with
the maps from a cell phone. During the implementation
the format was improved to make it more understandable
as well as easier to work with. The problem with the lack
of an indoor positioning system is discussed. This problem
was solved in the viewer by using extensive search functions
and the possibility to scan available barcodes throughout
the building.
Sammanfattning
Inomhuskartor
Detta examensarbete undersöker hur en lösning för inom-
huskartor kan utformas. Arbetet föreslår ett XML-baserat
format för lagring av information om byggnaders struktur.
I rapporten visas hur ett format skapas genom att först
undersöka existerande kartformat, för att sedan använda de
bästa idéerna från dessa format kombinerat med nödvändig
information om inomhusmiljöer. Det föreslagna formatet är
fokuserat på att vara både enkelt att använda och arbeta
med. Det använder sig av viktiga koncept som lager, arv
och referenser för att göra formatet flexibelt samt för att
undvika redundans.
Denna rapport visar också hur det skapade formatet
fungerar i olika implementationer. De viktigaste implemen-
tationerna som gjorts är en editor som snabbt och enkelt
kan skapa kartor samt en mobil applikation som gör det
möjligt att interagera med kartor med hjälp av en mobil-
telefon. Formatet förbättrades kontinuerligt under imple-
mentationen för att göra det lättare att både förstå och
jobba med. Problemet med avsaknaden av ett inomhus-
positioneringssystem diskuteras. Detta problem löstes på
den mobila applikationen med hjälp av omfattande sök-
funktioner samt möjligheten att skanna streckkoder som
finns i byggnaden.
Contents
Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preface
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Division of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Structure of the Report
1 Problem and Purpose 1

1.1 Areas of Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Conferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Exhibitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.3 Home Users Sharing with Friends . . . . . . . . . . . . . . . . 2
1.1.4 Marketing of a Store . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.5 Shopping Centers and Malls . . . . . . . . . . . . . . . . . . . 2
1.1.6 Guidance for Emergency Personnel . . . . . . . . . . . . . . . 2
1.2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 User Perspective . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Map Creator Perspective . . . . . . . . . . . . . . . . . . . . 3
1.2.3 Developer Perspective . . . . . . . . . . . . . . . . . . . . . . 4
2 Background 5
2.1 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Adoption/Existing Implementations . . . . . . . . . . . . . . 5
2.1.2 Text-based Properties . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.4 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.5 XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.6 XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.7 XLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.8 XPointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 The IFC Building Model . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Important Ideas and Concepts . . . . . . . . . . . . . . . . . 7
2.2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 GML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 CityGML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 KML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6.1 Global Positioning System . . . . . . . . . . . . . . . . . . . . 18
2.6.2 Mobile Network Localization . . . . . . . . . . . . . . . . . . 19
2.6.3 Wireless Network Positioning . . . . . . . . . . . . . . . . . . 19
2.6.4 Hybrid Positioning . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.5 Indoor Positioning . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.6 Positioning With Only a Map . . . . . . . . . . . . . . . . . . 20
2.6.7 Positioning Conclusion . . . . . . . . . . . . . . . . . . . . . . 20
3 Method 21
3.1 Structure of the Work . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Choice of Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 The Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.1 Format Description . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.2 First Draft Results . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.3 Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.4 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.5 Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.6 Writing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.7 Graphical Representation . . . . . . . . . . . . . . . . . . . . 31
3.3.8 Licensing Fees . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.1 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.2 Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.3 Fast Floor Switching . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.4 Snap to point/axis . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.5 Underlay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.6 Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.7 Zoom and Pan . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.8 Import and Export of EIML . . . . . . . . . . . . . . . . . . 37
3.4.9 Marking Origo . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4.10 Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4.11 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4.12 Target Platform . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5 Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5.1 Target Platform and Hardware . . . . . . . . . . . . . . . . . 39
3.5.2 Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.5.3 Displaying and Navigation . . . . . . . . . . . . . . . . . . . . 41
3.5.4 Searching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.5.5 Area Interaction . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.6 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.6.1 Implementation Results . . . . . . . . . . . . . . . . . . . . . 44
4 Results 47
4.1 Use of other formats . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.1 Format Structure . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.2 Object Orientation and Inheritance . . . . . . . . . . . . . . . 48
4.1.3 Object References . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.4 Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2 Open Vs. Closed data . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.2 Effects of an Open Format . . . . . . . . . . . . . . . . . . . 49
4.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.1 Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.2 Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.3 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.4 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.5 Positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.5.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.6 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.7 Implementation results . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.7.1 Usage of SVG . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5 Conclusion 55
6 Future Work 57
6.1 Tag List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2 Positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3 Customizable Container . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.4 Time Dependent Objects . . . . . . . . . . . . . . . . . . . . . . . . 58
Bibliography 59
Abbreviations
CityGML (City Geography Markup Language)
CityGML is an information model used to define a set of 3D urban objects. It is
also able to define relationships between these objects. CityGML is based on GML
and is a standard of the Open Geospatial Consortium.
DTD (Document Type Definition)

DTD is an XML schema which includes a set of markup declarations that define a
document type for an XML-based markup language.
EIML
EIML is the name given, by us, to our newly constructed format for storing indoor
maps.
GML (Geography Markup Language)

GML is an XML grammar that is used to express geographical features. GML is
defined and maintained by the Open Geospatial Consortium (OGC). GML only
defines geographical features and it does not define how these can be represented
visually.
GPS (Global Position System)

GPS is a space-based global navigation satellite system. When in reach of 4 satellites
it can determine your position (latitude, longitude, and altitude) within about 5
meters depending on the conditions. GPS only works with an open view of the sky.
GSM (Global System for Mobile Communications)

GSM is the most common standard for mobile telephone systems.
HTML (Hyper-Text Markup Language)

HTML is a very common markup language used to create web pages. HTML is
defined as an application of SGML.
IFC (Industry Foundation Classes) Building Model

IFC is an object oriented file format with a data model that facilitate interoperability
in the building industry. IFC is developed by BuildingSMART (also know as IAI,
International Alliance for Interoperability) and is an open specification that anyone
can use.
KML (Keyhole Markup Language)
KML is an XML-based language schema for expressing geographical annotation and
visualization on maps. KML specializes on Internet-based maps and was originally
developed for the Keyhole Earth Viewer which later was acquired by Google Inc.
and renamed to Google Earth. KML is an open international standard of the Open
Geospatial Consortium.
OGC (Open Geospatial Consortium)

The OGC is an international voluntary consensus standards organization. OGC has
over 370 members world wide which include commercial, governmental, nonprofit,
and research organizations. OGC is working with standards for geospatial content
and services, GIS data processing, and data sharing.
POI (Point of Interest)

A POI is a specific point that, to the user, is interesting or useful. This point can
be defined by anyone and is widely used in cartography.
SGML (Standard Generalized Markup Language)

SGML is a standard for defining generalized markup languages for documents.
SGML is, just as XML, based on tags to structure information, however, SGML is
less strict than XML.
SVG (Scalable Vector Graphics)

SVG is an XML-based file format for describing two-dimensional vector graphics.
Graphical objects can be grouped, styled, transformed, and composited into previ-
ously rendered objects. It is an open standard developed by the W3C.
W3C (World Wide Web Consortium)

The W3C is the main international standards organization for the World Wide Web
(abbreviated WWW or W3). The W3C consists of member organizations and is
active in education, software development, and development of new standards.
XHTML (Extensible Hyper-Text Markup Language)

XHTML is an extension of HTML that is based on XML instead of SGML, which
makes it stricter. XHTML is a W3C recommendation.
XML (Extensible Markup Language)

XML is a widely used and accepted text-based file format for easy storing of infor-
mation using tags. It is an open standard developed by the W3C.
XML schema
An XML schema defines a set of rules which an XML file must follow to be regarded
as valid.
XML Schema
XML Schema (with capital s) is a type of XML schema which defines a set of rules
which an XML file must follow to be regarded as valid. Is itself an XML document
which can be validated with a DTD file. It is an open standard developed by the
W3C.
XSD (XML Schema Definition)

XSD is an XML Schema file used for validating XML files.
XSLT (Extensible Stylesheet Language Transformations)

XSLT is an XML-based language that is used for transforming XML documents
into other XML documents. It is an open standard developed by the W3C.
Preface
This report is a Master Thesis in Computer Science at CSC, Royal Institute of

Technology. The project was issued by Ericsson AB and the work was performed
mainly at Ericsson Research under the supervision of Hjalmar Olsson and Richard
Carlsson. It was mentored by Stefan Arnborg at the Royal Institute of Technology.
Acknowledgements
We want to thank our supervisors at Ericsson for the opportunity to investigate this
thesis and also for the help and guidance throughout the project. We also want to
thank Stefan Arnborg for the insight and help with our project.
A special thanks goes to Alessandro Pieropan at CVAP for taking his time to
review our work with us.
Division of Work
The most important part of this Master thesis, which also required the most ex-
pertise, was the format for storing indoor maps. Therefore, we decided to do the
background study together so that we would be able to discuss the format with each
other.
For the implementation part we decided to divide the work as much as possible.
The class structure was shared by all implementations, and was therefore a combined
effort. However, the work of parsing (described in Section 3.3.5) and writing (Section
3.3.6) the format was done individually; Henrik did the parsing and Johannes the
writing.
In the early stages we also did some work on small, but important, aspects of the
format’s use. Most of this work is mentioned shortly in the report and was divided as
follows: Henrik worked with SVG conversion with Java (described in Section 3.3.7),
validation with XML Schema and Java (Section 3.3.4). Johannes worked with SVG
conversion with XSLT (Section 3.3.7), initial work on map drawing algorithm which
was later used in the viewer and the editor (Section 3.3.7).
The two biggest implementations of the format were the editor and the mo-
bile viewer. These were worked on separately with Johannes creating the editor
(described in Section 3.4) and Henrik creating the viewer (Section 3.5).
Structure of the Report
The first part of this report contains the background study. In this section we have
summarized the, for us, most important parts of the literature study.
After the background study is the Problem and Purpose section where we explain
how our work can be used and also what our goals were. The Method section of
the report contains our practical work. It explains the different parts of the format
and the implementations of the format. Each section contains a description of what
we did, how we did it, and the direct result. In the Result section are the results of
our work. This includes for example how the different components performed and
what we learned from creating and using them.
The last section after the Conclusion is the Future Work section. In this section
we highlight what we felt should be added to the format in the future.
When the term the format is used in the report it refers to the format that we
created during the project.
Chapter 1
Problem and Purpose
The initial problem formulation of this Master Thesis was described as follows:
Indoor location based services can be considered the next step within
location-based services. Although it seems to have much in common with
the currently existing outdoor solutions it differs quite much when you
compare the map data, positioning technologies, and user interaction.
This Master thesis will investigate how a solution for indoor maps can
be implemented.[11]
The main goal of this Master Thesis is to create a useful format for storing
indoor maps and to make implementations that show how the format, which was
named EIML, is used effectively. The format must first and foremost be easy to
use. This means that it must be easy for a user to both understand and use it in an
implementation. To accomplish this it was decided that different use cases would
be created to show the possibilities of the format. Before the use cases could be
created, possible areas of usage were discussed. The implementation part focused
on creating software as a proof of concept. However, we made our best to ensure
that it would be possible for others to continue work on the software in order to
make it widely usable.
1.1 Areas of Usage

There are several different situations and cases where an indoor map format can
be useful. This section shortly mentions some of these cases to show a few of the
possibilities with indoor maps.
1.1.1 Conferences
At conferences it can be useful to have an indoor map of the building or buildings
that are relevant for the conference so that visitors can find their way around the
1
CHAPTER 1. PROBLEM AND PURPOSE
conference. Such an indoor map could also change with time to always show the
current speaker in the right section of the conference.
1.1.2 Exhibitions
At an exhibition an indoor map could be of great importance. Such a map would
allow the visitor not only to get an overview of the complete exhibition, but also
search for and highlight the parts of the exhibition that are the most interesting for
the visitor. The map can also guide the visitor to these points of interest (POI).
1.1.3 Home Users Sharing with Friends

Sharing among friends has become increasingly popular lately. In online communi-
ties people share almost anything in their lives. These people might also want to
share, for example, how they live or how they have decorated their new living room.
This could be done with the help of indoor maps.
1.1.4 Marketing of a Store

If a big company is going to open a new store, they probably want to share this
with the public. An effective way to really show what they have to offer is to give
their costumers an overview of the complete store, including what the sections of
the store contain. This could be done with the help of indoor maps.
1.1.5 Shopping Centers and Malls

A common problem with shopping centers and malls is that the visitors do not know
where to find certain stores or products. Visitors of the mall could use an indoor
map to plan their shopping route or to find information about where the toilets,
parking garage, or exits are. The indoor map could also be combined with social
media. An example of this could be that the user would be able to see which shops
his or her friends are in. Another implementation of social media would be to let
the user leave comments and ratings about the different shops for other users of the
indoor map to see.
1.1.6 Guidance for Emergency Personnel

An indoor map could be of help to emergency personnel trying to get a quick
overview of the building or floor they are about to enter. An indoor map combined
with a HUD (Heads-Up Display) could be used to provide real time information to
the emergency personnel while exploring the building.
2
1.2. USE CASES
1.2 Use Cases

A use case was created for every key aspect of how EIML can be used. This was
done to understand and foresee most of the functionality that is wanted from the
format. The use cases were then used throughout the development to ensure a good
user experience when working with the maps, from the creation to the viewing and
using of the finished map. The use cases also assisted us in making the structure of
the format intuitive for the developers who come in contact with this format.
1.2.1 User Perspective

The first use case was created to show how a user might interact with the mobile
map viewer. The use case explains how Bob uses the viewer to navigate through
Corp Inc.’s building for the first time.
Bob wants to visit a specific conference room. The core of the indoor
map application is already on his phone, however, he does not have a
map of the building he is in. He scans a barcode in the reception that
tells the indoor map viewer application to download the latest version of
this building’s indoor map. When the map is downloaded the barcode
information is still available and tells the application where Bob is in
the building and shows the correct position on the map. He now has the
map on his phone and knows where on that map he is located so that
he can start navigating.
Bob does a search for the conference room in the viewer and it tells
him that he only has to take the elevator to the next floor and then take
the first left in the first corridor on the right. Furthermore the viewer
shows the location of the final destination on the map on the screen.
1.2.2 Map Creator Perspective

The second use case is aimed at the map editor and how it could be used. It shows
how Ben, a Corp Inc. employee, who has been assigned the task of mapping the
fifth floor of the Corp Inc. office, used the indoor map editor to map the floor.
Ben has an image of the floor plan that he wants to use for guidance
when drawing the new indoor map. Ben starts the indoor map editor
and is presented with a single clean floor of a new building. He then
adds the floor plan image as an underlay in the editor. He controls the
scale of the image and the opacity of the underlay so that he can draw
effectively on top of it.
Ben wants the map to be in the right scale. To achieve this he draws
a wall that he knows the length of. He then selects the option to set
the scale for the wall to the real world length of that wall. The editor
now knows the wall’s exact length and it will draw all other objects in
3
CHAPTER 1. PROBLEM AND PURPOSE
the correct scale. Ben now draws wall lines where the underlay image
indicates that walls are located. He then switches draw tool to draw
windows instead and creates a few of those. After that Ben switches to
the tool for drawing doors and adds doors to the rooms. He is now done
with the drawing of the basic structures on that floor.
Ben now wants to define the conference rooms on the map as well as
add additional information about these rooms. He switches to the area
select mode. In this mode Ben can easily select the lines that will act
as the barrier for the conference rooms. When the selected lines make a
complete polygon, that is accepted by the format, the editor will create
the area and clear the selection. Ben stays in this mode to create a few
more areas. After this, Ben wants to change the name and description
of one of the newly created areas. He then goes back in to the edit mode
to right click on one of the lines of the area. Ben is then presented with
a drop down menu with options relevant to that line. He selects the
option to set the name of the area and is presented with an input box
where the current name of the area is already filled in. Ben selects a
name for the conference room and confirms the change. He then right
clicks again on a line on the edge of the area and selects the option to
set the description of the area. After setting a description for the area
Ben feels as if he is done with the map and chooses to save the file.
1.2.3 Developer Perspective

The third and last use case was aimed at a potential developer who wants to use
the format. Brian is hired by Corp Inc. to create a specialized viewer for the needs
of Corp Inc.
Corp Inc. wants their own viewer with company specific graphics
and information to perfectly fit their target audience. To accomplish
this task, Brian first wants to parse a given format file to his own class
hierarchy to then be able to paint and perhaps also modify the data.
Since the format is based on an open format for storing information in
files, it is very easy for Brian to use a readily available parser to parse
the format file. He can then create the wanted class hierarchy while
parsing the file. When Brian wants to export the indoor map data to
file he can easily use a readily available serializer for the open format,
for storing information in files, to create a file.
4
Chapter 2
Background
There is no standardized method for storing information about and drawing simple
maps of an indoor environment. However, there exist formats for modeling outdoor
environments and formats that model buildings from an architectural point of view.
We have studied these other formats and summarized the most important key con-
cepts and ideas. We have also studied other areas that are relevant to our format.
The key ideas that we feel are the most important and relevant for the creation of
our maps are presented in this section.
2.1 XML
XML (Extensible Markup Language) is a widely used and accepted open standard
for storing information in files[8]. It is a text-based file format where the information
is structured with tags. This makes the XML files relatively easy for a human to
understand and edit directly with just a text editor. XML is extremely strict, it
has a rule that if a document is found to have any error, missing tag or other,
the parser must exit directly. Since the XML format was introduced more than
ten years ago it has implementations and tools for almost every single platform.
This makes it a good candidate for our format. Several of the latest and most used
outdoor map formats like GML (Geography Markup Language) and KML (Keyhole
Markup Language) are based on XML.
2.1.1 Adoption/Existing Implementations

XML is an open standard developed by the W3C (World Wide Web Consortium).
There exist a great amount of different XML-based formats. This also means that
there exist implementations for XML parsing, editing, generation, and transfor-
mation on nearly all types of platforms and for almost every single programming
language.
5
CHAPTER 2. BACKGROUND
2.1.2 Text-based Properties

One of the main reasons for using XML is that it is completely text-based. To
inspect and/or edit an XML file you only need a text editor. If an XML document
is correctly written, and indented, it is self-documenting. This means that there
should not be a need for comments for the data you are specifying.
2.1.3 Validation
A big advantage with using XML is that the XML files can be validated using an
XML schema. An XML schema contains a set of rules that can validate XML files.
2.1.4 XML Schema

An XML schema defines a set of rules which an XML document must follow to be
considered valid. XML schemas are used to validate XML formats so that the user
can be notified directly if the document the user is working on is valid. This means
that it is possible to write an XML schema for a format which ensures that all files
of our format are valid. This makes it easier to create implementations for a certain
format since the developer knows exactly how the format is laid out.
The XML Schema standard allows the use of regular expressions to make it
easier to explain how a valid document must be formatted. The XML Schema
standard also contains a set of predefined data types which can help to ensure that
the right data types are used.
2.1.5 XSLT
XSLT (Extensible Stylesheet Language Transformations) is an XML-based language
with the purpose of describing how an XML format is translated into another XML
format. XSLT is also an open standard, and just as XML, developed by the W3C.
This format can, for example, transform the XML-based KML format for outdoor
maps into the XML-based SVG (Scalable Vector Graphics) image format[9].
2.1.6 XPath
XPath is a query language for selecting nodes from any XML document. While
doing this selection, XPath is also capable of computing values. It is possible to
change the navigation and selection depending on these calculated values and also
according to other local criteria. XPath is also an important part of XSLT.
2.1.7 XLink
XLink is a specification that provides methods for creating internal and external
links within XML documents. It is also possible to associate meta-data with the
links that are created. With XLink it is only possible to link to a complete document.
An XLink is almost as an XHTML (Extensible Hyper-Text Markup Language) link
6
2.2. THE IFC BUILDING MODEL
but it can do much more. An XHTML link is only unidirectional where as an

XLink can be bidirectional. It is possible to define links from any element in an
XML document.
2.1.8 XPointer
XPointer is a standardized way to create hyperlinks in to specific parts of an XML
document. An example of how XPointer can be used:
href=http://www.zoo.com/zoolist.xml#id(’animal’).child(5,item)
This creates a link to zoolist.xml and finds the tag labeled animal and retrieves the
fifth item under that tag.
2.2 The IFC Building Model

2.2.1 Overview
The IFC (Industry Foundation Classes) Building Model is a data model developed
by the International Alliance for Interoperability (IAI) to facilitate interoperability
in the building industry. This model is object-oriented and can define a building
down to its bolts. Besides physical building materials, it also supports definitions
for personnel and material costs. IFC is developed and maintained by the Building
Smart Alliance[3]. It has an open specification which anyone can use.
2.2.2 Important Ideas and Concepts

Layer Division
The items represented in the model are divided into four different layers. Each layer
contains several diverse categories or schemas. Within these components, individual
entities are defined. One example of this is the Wall entity. The Wall entity is called
IFCWall and is in the Shared Building Elements schema which in turn belongs to
the Interoperability layer[2].
The design of the layer system is constructed in such a way that an entity in a
specific layer only can relate or refer to entities in the same layer or lower layers.
It can never refer to a higher layer. The goal of this construction is to make the
model easier to maintain and grow. Objects in lower levels can be reused in higher
layers[1].
The different layers are (defined from the lowest layer to the highest):
• Resource Layer – Used for geometry, material, quantity, measurements, date

and time, cost that are not specific to the building. These are then later used
in the higher layers.
7
• Core Layer – This layer defines core concepts such as actor, group, product,
and relationships which are all used in the higher layers.
• Interoperability Layer – This layer contains the most common building com-
ponents such as walls, beams, columns, doors, etc. It also contains services
such as fluid flow and sound properties.
• Domain Layer – The highest level which contains concepts for architecture,
structural engineering, facilities management, etc.
See figure 2.1 for an overview of what these layers contain.
Building Plumbing Structural Structural

Controls FireProtection Elements Analysis
Domain Domain Domain Domain
Construction Facilities
HVAC Electrical Architecture
Management Mgmt
Domain Domain Domain
Domain Domain
Shared Bldg Shared Shared Shared Shared

Services Component Building Management Facilities
Elements Elements Elements Elements Elements
Control Product Process

Extension Extension Extension
IFC2x2 platform Kernel IFC2x3 final

- IFC2x part equal
to ISO/PAS 16739 Architecture
short form distribution
non-platform part
Material External Geometric Geometric

Actor DateTime Geometry Material Measure Cost
Property Reference Constraint Model
Resource Resource Resource Resource Resource Resource
Resource Resource Resource Resource
Repres-
Profile Property Quantity Topology Utility
entation
Resource Resource Resource Resource Resource
Resource
Presentation Presentation Presentation Presentation Presen- Time Structural Profile

Constraint Approval
Dimension Appearance Definition Organization tation Series Load Property
Resource Resource Resource Resource Resource Resource
Resource Resource Resource Resource
Figure 2.1. A visual overview of the layers and what they contain[4].
8
2.2. THE IFC BUILDING MODEL
Representation of Space
Many formats do not have a definition of space because it does not exist as a physical
object. However, in the IFC model, space is included and can be defined and used in
relations. The reason for this is that space can play an important role when talking
about, for example, heating placement and cost. In this case there is a relationship
between how much space we need to heat and what kind of surfaces that are related
to that space.
Inheritance and Object Hierarchy

Since the IFC model is object-oriented it has the ability to use inheritance and create
a hierarchy for components with similar features. As an example, the IFCWall is a
subtype of IFCBuildingElement. But it does not end there, the hierarchy continues
with IFCElement, IFCProduct, IFCObject, to the top class which is IFCRoot.
The IFCRoot contains attributes that all elements must contain like GlobalID,
OwnerHistory, Name and Description. All elements from IFCBuildingElement to
IFCRoot are abstract classes so they cannot be instanced by themselves.
Relationships
Relationships are an important part of the IFC model. As mentioned earlier, there
are relationships between, for example, walls and spaces. The relationships which
are defined in the model are very flexible. It is not necessary to relate a wall to
the space that it encloses, instead it can be related to the floor. Relationships are
defined as classes in the IFC model and there are five different kinds of relations.
Custom Entities
When working with the IFC model it is possible to define new entities. These
entities are called products or proxies and can be defined in the same way as all
other predefined entities are defined.
External References
External references are often accessed through a HTTP access protocol. There are
three different types of external references in the IFC model. These are document
reference, classification reference, and library reference.
Defining Abstract Components

One main idea in the IFC data model is the possibility to define all elements needed
for a building to be built. This means that not only tangible components but also
abstract components can be defined. Some examples of these abstract components
are schedules, activities, spaces, organizations, and construction costs. The latest
release of the IFC model has definitions for a total of 623 different entities. One
9
example of this usage is the possibility to define an actor, see figure 2.2. This actor
has nothing to do with the materials that the building should consist of, but he plays
an important role in the construction. An IfcActor can then even be related to an
organization and be assigned a profile containing name and other information[5].
Figure 2.2. Overview of the IfcActor in the IFC model[4].
Concept of a Library
It is possible to reference objects and concepts that are in an external library.
Product information might be stored in the supplier’s database and updated by the
supplier. The possibility to reference this information makes it possible to always
have the latest values. Another benefit is that a library reference places a significant
amount of data outside of the IFC model which keeps down the size and complexity
of the file.
Measurements
The measurements in the IFC model need to have some kind of unit. In this aspect
the model displays great flexibility, offering both imperial and metric units and even
the ability to convert between them.
2.2.3 Conclusion
The IFC building model does not only define how a building looks, it defines ev-
erything that is needed to construct that building. Everything from material and
10
2.3. GML
their cost to the human resources and organizations that need to be involved can
be modeled with IFC. This makes the format very useful for architectural projects.
2.3 GML
GML (Geographic Markup Language) is an XML-based standard for expressing
geographical features. The grammar is defined by the Open Geospatial Consortium
(OGC)[22]. GML is only used for expressing features and does not say anything
about how these could be represented graphically.

Standardization
The idea behind GML is to standardize geographical data so that anyone who needs
the data can use it. It must also consider that geographical data does change and
that the data can come from many different sources. This means that the format
needs to be flexible and that everyone also can use it for their own purpose. When
considering all these variables, the abstraction level of GML becomes very high.
Main Ideas
These are the main ideas of the GML standard[22]:
• provide an open, vendor-neutral framework for the description of geospatial
application schemas for the transport and storage of geographical information
in XML
• allow profiles that support proper subsets of GML framework descriptive ca-
pabilities
• support the description of geospatial application schemas for specialized do-
mains and information communities
• enable the creation and maintenance of linked geographic application schemas
and datasets
• support the storage and transport of application schemas and datasets
• increase the ability of organizations to share geographic application schemas
and the information they describe
Difference between Geographical Data and Graphic Interpretation

One of the biggest concepts of GML is that it should only store geographical data
and say nothing about graphic interpretation. This means that GML only stores
information about the world in spatial terms, it does not say how this data can be
visualized.
11
Feature
A feature is defined as an abstraction of a real world phenomena and it is associated
with a location relative to the Earth. This means that a digital representation of the
real world may be thought of as a set of features. The state of a feature is defined
by a set of properties, where each property may be thought of as a combination of
a name, a type, and a value.
GML Application Schema

When using GML, a designer is able to extend or restrict types in the GML schema
to fit his needs. Such an extension or restriction is defined in XML Schema. In this
way GML is extensible.
Root Element
GML has a root XML type from which XML types for all GML objects must be
derived.
Dynamic Features and Time Objects

In GML it is possible to define dynamic features such as movement of tectonic plates
or weather developments. It is thereby also possible to define objects that change
with time. These events can be set to happen according to two different time scales:
interval or ordinal.
Referencing
In the GML format it is possible to reference not only other parts of the same
document, but also any site or location on the Internet. This is done with XPointers.
Users
GML is emerging as the international standard for outdoor geographical data. To-
day, over 250 companies and agencies around the world use GML.
GML Simple Features Profile

The Simple Features Profile defines a subset of the GML format. This profile
is meant to lower the implementation bar for creating an application that uses the
GML format. The profile is more restricted than GML partly because there are only
eight available data types and geometry is limited to points, lines, and polygons.
This is mainly because the normal user does not need any more complex geometry
or data types[22].
12
2.4. CITYGML
2.4 CityGML
2.4.1 Overview
CityGML (City Geography Markup Language) is a concept for modeling and ex-
changing of 3D city and landscape models. It is implemented as an XML application
schema and a subset of GML and is an official OGC Standard that can be used free
of charge. CityGML does not only have support for the visual objects in a city but
can also be used to model traffic and other abstract dynamic objects.[21]

Level of Detail
CityGML has five well-defined consecutive Levels of Detail (LOD). These are as
follows[21]:
• LOD 0 – regional, landscape
• LOD 1 – city, region
• LOD 2 – city districts, projects
• LOD 3 – architectural models (outside), landmarks
• LOD 4 – architectural models (interior)
These levels can be processed and viewed independently depending on the needs
of the user. Objects may also be modeled in different LOD simultaneously which
enables the analysis and visualization of the same object with regard to different
degrees of resolution. See figure 2.3 for a visual example of LOD.
Grouping
In CityGML it is possible for the user to define groups. These group aggregates
arbitrary city objects according to user-defined criteria. These groups can also be
assigned different attributes. It is, for example, possible to define a fire escape
plan and have multiple houses with the same meet-up place. These houses can be
grouped in a grouped and assigned properties that they all share.
Prototypic objects
CityGML allows the definition of prototypic objects. These objects can be trees,
traffic lights, cars, people etc. These objects can then be referenced into a point
according to a world coordinate reference system and a transformation matrix that
facilitates scaling, rotation, and transformation of the prototype. It is also possible
to make external references to objects.
13
Figure 2.3. Illustration of the different levels of detail[21].
Extending the Format

The CityGML model can be extended with additional classes and object types
through the Application Domain Extension (ADE). With ADE it is possible to
create classes that handle, for example, the number of inhabitants of a building.
This kind of extension can be validated with an ADE schema[21].
2.5 KML
2.5.1 Overview
KML was originally developed by Keyhole, Inc, which was acquired by Google Inc.
in 2004. This format is a simplification of the GML format with several additions
for storing geographical annotation and visualization. KML is based on the XML
format with tags and nested elements and attributes.

Features
KML files can store and reference to information such as 3D models, coordinates,
polygons, lines, curves, sound files, textures, photo overlays, and custom data[15].
In Google Earth, the imported 3D models are scaled, rotated and translated to fit
in with the rest of the world.
14
2.5. KML
Standard
The KML format is an open standard developed by the OGC. The KML format is
based on the GML format, but has only kept a small portion of it since the KML
format is supposed to be easier to use and grasp. KML is only about one tenth of
the size of GML[23].
Profiles
The KML specification defines a set of profiles that defines which elements and fea-
tures of the KML format that need to be supported for each profile. Developers can
then choose to target one or several of these profiles to ensure that their application
has the level of functionality the user expects.
The profiles specified in the OGC KML Engineering Report are; mobile devices
(mobile); Web browsers (browser); 3D spinning globes (3D); and GIS desktop ap-
plications (GIS)[24], see figure 2.4. Mobile devices are not expected to support the
same level of detail as 3D geobrowsers that run on desktop computers.
The profiles are built by combining smaller modules describing different areas
of functionality, see figure 2.5. These modules are:
• Core: describes the core functionality needed for an application to be called

a KML reader.
• Mobile: the elements that must be supported on a mobile device (cell phone,
PDA, etc.).
• Styling: elements describing how placemarks and similar items must look.
• Extended data: specify untyped and typed data (with its defining schema).
• 3D: the elements used to specify 3D information, such as 3D models and the
placement of those.
Extended
Mobile Styling 3D
Data
Core
Figure 2.4. The KML profiles[24].
There are XML schema files for validating the separate profiles and modules
available[26][25].
15
Mobile Phone Core Mobile
Extended
Weblog/CMS Core Mobile
Data
Extended
Web Map Core Mobile Styling
Data
Extended
3D Geo-browser Core Mobile Styling 3D
Data
Figure 2.5. The KML modules[24].
Viewers
There are several applications available that can read the KML format since this
format has been widely accepted by the public and industry. There are viewers
available for most platforms, both as web-based and native clients. Since KML is
based on the XML format it is easily parsed with any XML parser available.
Compression
The KML files and the eventual related images can be compressed with the ZIP
format to form a KMZ file. This can provide up to 90% compression to minimize
the amount of data that needs to be transferred[17]. This KMZ file must contain
one main KML file and other possible files in subdirectories. The general suggestion
is to create a KMZ archive when either the size of the main KML file exceeds 10
KiB or if additional files, such as images, sound files, or 3D models, are referenced.
File references
From time to time the user might want to reference to other KML or KMZ files.
This can be done in KML by using the Link and NetworkLink tags specify where
the referenced file is to be fetched from. The NetworkLink tag contains a Link
tag which can refer to a file on a network, in a KMZ file, or the file directly. The
referenced files can be raster images, 3D COLLADA models, other KML files, etc.
16
2.5. KML
Overlays
KML supports defining overlays, such as a compass or other information, directly
in the format. This is done by using the ScreenOverlay tag which references an
image file which is to be used as an overlay.
Custom data
KML supports, so called, vendor tags which means that custom tags can be added
to KML files. There are three ways of adding custom data to KML[16]:
• Data element - allows you to add untyped name/value pairs to the user data
associated with a given Feature (NetworkLink, Placemark, GroundOverlay,
PhotoOverlay, ScreenOverlay, Document, or Folder). These name/value pairs
are displayed in the balloon by default. This information can also be used for
entity replacement in the text element of BalloonStyle. (See the section on
Using the BalloonStyle Element as a Template.)
• Schema and SchemaData elements - allow you to add typed data to the user
data associated with a given Feature.
• Arbitrary XML data - allows you to preserve user data within a KML file.
Google Earth passes this data along with the file and saves it, but does not
use it.
LookAt
Since KML is meant to visualize geographical data, one of its primary elements
is the LookAt element. With this element KML can help the client application
position the map view for the user. This is to help the user to quickly view an area
of interest on the map, related to the information in the KML file.
Regions
This KML feature enables the user to add very large datasets without risking de-
creased performance. Data in regions are only loaded when the objects are large
enough to be visible in the viewer. The second most important aspect of regions are
LOD (Level of Detail). You can specify how many pixels that are needed for objects
to be shown. Regions can also be nested to provide, for example, increasingly higher
resolution images the more you zoom. If you have a big image, you can split it into
several smaller images, this enables the viewer to only show the nearest parts with
higher resolution[15], see figure 2.6.
Expiration
Data that is loaded into the Google Earth viewer can be refreshed if the user adds
the refreshMode element, with the data onExpire in it, to a Link element. This
17
Figure 2.6. This is a large image split into a set of smaller images which can be
rendered with different resolutions based on how far away they are.[15]
enables the content to be refreshed, either based on the HTTP server expiration
time or the time specified by the expire tag in the, by the href tag, referenced
Python script.
2.6 Positioning
Positioning is an important part in navigation and there are many different posi-
tioning systems today that can accurately determine your position depending on
your environment. This section summarizes how these systems work and when they
work.
2.6.1 Global Positioning System

The Global Positioning System (GPS) is the most commonly used positioning sys-
tem today. Many mobile devices come with a built in GPS receiver that is able to
position the device within about 5 meters depending on the conditions.
GPS is dependent on three different parts. First there are the GPS satellites
orbiting the Earth. Secondly there are the monitoring stations on Earth. The third
part is the GPS receiver which the user has in his or her device.
18
2.6. POSITIONING
The GPS satellites that orbit the earth transmit one way signals that gives
the current location of the satellite and the current time. The monitoring stations
on earth control the satellites’ orbits and adjusts the satellites’ clocks. The GPS
receiver picks up the signals from the satellites and with the information in those
signals the device can locate itself with a longitude, latitude, and altitude[10].
To be able to make this positioning the GPS receiver needs to intercept the
signal of at least 4 satellites. With one satellite it is possible to determine how far
from that satellite you are. This means that you are somewhere on the sphere that
can be drawn around the satellite. With two satellites your position is somewhere on
the intersection of the spheres that two satellites produce. With three satellites the
intersection of the three spheres becomes two possible points. If a fourth satellite
is added, there is only one possible point in 3D-space.
Usually it is not a problem to intercept these signals when the receiver is posi-
tioned outdoors. However, indoors the signal is blocked by roofs and walls and does
not reach the receiver. Therefore it is not possible, or at least extremely hard, to
position a GPS receiver indoors[29].
2.6.2 Mobile Network Localization

Mobile network localization, for example using GSM (Global System for Mobile
Communications), is based on measuring the strength of the signals which a partic-
ular device receives from the base stations. The distance between a receiver and a
base station can be modeled as a function using the signal strength. The locations
of the base stations are known and with the signal strength from three base stations
it is possible to determine the device’s position. This uses the same principle as
GPS, but does only locate the user in 2D, leaving the height undetermined. The
height cannot be determined because there is not much height difference between
the towers.
This is because of the base stations similar height over the ground. They are
almost placed on a plane surface which makes it very hard to determine the height
of the user.
It is possible to use mobile network localization indoors; however, the accuracy
of the position decreases when obstacles are in the way which influence the signal
strength.
2.6.3 Wireless Network Positioning

Today, there are more and more organizations and even individual people who create
their own wireless networks. These networks send out a signal with a unique ID.
In the same manner as mobile network positioning, it is also possible to position
devices with the signal strength from wireless networks if the router’s location is
known.
19
2.6.4 Hybrid Positioning

It is common to use two or more positioning techniques to get a more accurate
position of a device. The problem with using hybrid positioning is that the device
must support multiple different standards and have multiple receivers that can
interpret the signals from these different systems.
2.6.5 Indoor Positioning

Indoor positioning is still a problem that has no standardized solution. The ear-
lier mentioned positioning systems do not work well indoors. However, there is a
significant amount of research being done on this subject. There are different sys-
tems that utilize transmitters that are positioned throughout a building to locate
receivers accurately indoors. These systems are not widely used since there are not
many applications for them yet and therefore they are not considered worthwhile.
2.6.6 Positioning With Only a Map

When trying to positioning oneself on a map there are different hints that we look
for. Researchers at the Nokia Research Center have studied the difference between
how we position ourselves using an indoor map and an outdoor map[28]. When mak-
ing case studies in the Finnish shopping mall Kamppi, they came to the conclusion
that indoor maps need to be very different from outdoor maps. On an outdoor map
the streets have names compared to indoors where there is no equivalence. Another
problem indoor is the vertical positioning, how to know which floor you are on. The
researchers at Nokia came to the conclusion that a good indoor map should focus
on heavy pruning of details and simplification of the graphical layout. The map
should clearly mark important landmarks and features that differ from the rest of
the building since it is these features we look for when we try to position ourselves.
2.6.7 Positioning Conclusion

Indoor positioning is a research topic that has received more and more attention
during the last years. We believe that an indoor positioning system will eventually
be something that the every day man uses and that with such a system in place,
indoor maps will become even more important. However, even without such a
system, good indoor maps can play a crucial role for navigation inside buildings.
20
Chapter 3
Method
This chapter discusses the methods used throughout the project and how the work
was carried out. It covers the languages used in this project, the format itself, the
editor and lastly the viewer with an additional section on routing.
3.1 Structure of the Work

The implementation was divided into two main areas. The first area covers the
creation of the format and the second covers its different uses. The first draft of the
format was achieved by considering the knowledge from the literature study and
creating several different sketches of how a good format for storing indoor maps
might be structured. These sketches were then discussed and the best parts were
combined to create a first version of the format.
The main purpose of the implementations was to highlight the flaws and diffi-
culties in the first draft of the format so that it could be improved in later versions.
The implementation was carried out in several different iterations and between
each iteration both the format and possible improvements were discussed. The
main implementations that were created are an editor and a mobile viewer. These
implementations share the same class structure which was created before the im-
plementation of the editor and the mobile viewer was started.
3.2 Choice of Languages

Our format uses XML to store all information. This was decided after looking at
the background study. One of the goals with EIML is that it should be easy to
work with. XML makes this possible because it is humanly readable and it can be
opened and read in a simple text editor. Another reason for using XML is that
the most common formats for outdoor maps are based on XML. This means that a
user who knows GML or KML, which are XML-based, can understand our format
easily.
21
CHAPTER 3. METHOD
All implementations are in Java. Some of the main reasons for this choice are
that Java has a wide range of open libraries to use with XML, which allows us to
easily parse and write data. Java is also used on many mobile platforms which
means that the same code can be used on both stationary and mobile devices. Java
is platform independent which means that it is possible to use the same program
on Windows, Linux, UNIX, or any other operating system with support for a Java
virtual machine. For an example of how our format could be used, see figure 3.1.
Figure 3.1. An overview of how the different parts of the project could interact.
3.3 The Format

This section describes how the format is structured and how different tasks, like
parsing and writing, are done. The first draft of the format is presented followed
by the different improvements that were made.
3.3.1 Format Description

In the first draft of the format the focus was on keeping the format simple while
at the same time supporting a good amount of features. The format is in 2D
since creating a 3D capable format would increase the complexity of this project
immensely.
The format has the name EIML and starts out with a root tag, <eiml>, which
distinguishes XML files using our format from other XML files. Inside this tag it is
possible to define one or more buildings with the element named Building.
This is an example of how an EIML file can look with two buildings in it:
<eiml>
<Building id="B1">
...
22
3.3. THE FORMAT
</Building>
<Building id="B2">
...
</Building>
</eiml>
The Building element contains all the information about a specific building. All
buildings are required to have a unique ID so that it is possible to refer to them.
Under the building tag, EIML divides the building into floors. By doing this,
the user does not need to define the specific height of different objects and features.
Every Floor element has to have an ID just like the Building element. A Floor
element also needs to have a number assigned to it which refers to the order of the
floors (e.g., floor number 1 is below floor number 2). The Floor tag also supports
information about the altitude of a certain floor relative to the ground.
With this new information added to the previous example it can look like this:
<eiml>
<Building id="B1">
<Floor id="F1" number="1">
...
</Floor>
...
</Floor>
...
</Floor>
</Building>
<Building id="B2">
...
</Building>
</eiml>
Under the Floor element the format starts to get really interesting and at the
same time more complex. At the floor level of a building, everything that can be
on that floor is defined. This includes both structural features like walls, doors,
and windows as well as abstract features like rooms and areas. These features are
grouped in different containers. The most important container is the Structure con-
tainer. This container holds the definition of all walls, doors, and windows. These
features are separated from other features since they are present in all buildings and
cannot be moved.
Example of the Structure element:
<Structure id="S1">
23
CHAPTER 3. METHOD
<Wall id="W12">0.0,0.0 0.0,15.0</Wall>

<Wall id="W13">0.0,15.0 20.0,15.0</Wall>
<Wall id="W14">20.0,15.0 20.0,0.0</Wall>
<Wall id="W15">20.0,0.0 10.82,0.0</Wall>
<Wall id="W16">10.0,0.0 0.0,0.0</Wall>
<Wall id="W17">5.0,15.0 5.0,11.0 5.5,13.0</Wall>
<Wall id="W18">4.5,10.0 0.0,7.5 2.75,7.7</Wall>
<Door id="D3">5.0,11.0 4.5,10.0 4.9,10.4</Door>
<Window id="Win1">10.0,0.0 10.82,0.0</Window>
</Structure>
EIML also has support for the defining of rooms. This container is called Area,
since a room is basically an area. A key aspect for the ability to define areas
is exhibition halls where several exhibitors share a large area, which is often not
divided by walls. An area can have a name, description, and a defined area size.
The shape of an area is defined in the container Enclosure. The reason for using
an enclosure is that it is possible to restrict an area within a set of walls. To refer
to a wall the tag WallRef is used. WallRef uses the attribute called ref to refer
to other, already defined, walls. However, it is not enough to only define a room
as being contained by walls since two rooms might not be separated by a wall but
by an open space. Therefore, it is possible to define lines inside an enclosure. The
last container inside an Area is the ObjectList. With the ObjectList it is possible to
place objects in the area with coordinates relative to that area.
This is an example of how an AreaList element can be structured:
<AreaList id="AL1">
<Area id="A1">
<name>My room</name>
<description>This is where I keep all stuff!</description>
<Enclosure id="E1">
<line>9.0,0.0 9.0,15.0</line>
<line>9.0,15.0 20.0,15.0</line>
<WallRef ref="W8" />
<line>20.0,0.0 9.0,0.0</line>
</Enclosure>
<ObjectList>
<ObjectRef ref="O1" id="DISK4" translate="1.0,1.0"
rotate="2.0" scale="0.01,0.01" />
</ObjectList>
</Area>
</AreaList>
If the Structure and AreaList elements were added to the Floor element it might
look like this:
24
3.3. THE FORMAT
<Floor id="F2"
<Structure id="S2">
<Wall id="W8">20.0,15.0 20.0,0.0</Wall>
<Wall id="W6">20.0,0.0 0.0,0.0</Wall>
<Wall id="W11">9.0,10.0 9.0,15.0</Wall>
<Door id="D2">9.0,8.5 9.0,10.0</Door>
</Structure>
<AreaList id="AL1">
<Area id="A1">
<name>My room</name>
<description>This is mine!description>
<Enclosure id="E1">
<line>9.0,0.0 9.0,15.0</line>
<line>9.0,15.0 20.0,15.0</line>
<WallRef ref="W8" />
<line>20.0,0.0 9.0,0.0</line>
</Enclosure>
<ObjectList>
<ObjectRef ref="O1" id="DISK4" translate="1.0,1.0"
rotate="2.0" scale="0.01,0.01" />
</ObjectList>
</Area>
</AreaList>
</Floor>
The last element in EIML is the ObjectLibrary. The ObjectLibrary is placed right
under the eiml tag. The concept of an ObjectLibrary is to hold all the information of
all the objects that can be placed inside a building. An object that is created in the
ObjectLibrary describes all the properties of that object. This makes it possible to
refer to that object with a simple reference from the basic structure of the building.
The advantage of referencing objects, instead of duplicating the information, is that
it puts a significant amount of information outside the basic building and makes
the format easier to grasp.
Coordinate System
EIML has a coordinate system with origo in one predefined point of the building.
All structural objects are defined in the same global coordinate system. The only
place were objects can be placed in a local coordinate system is when objects are
placed in an Area.
25
CHAPTER 3. METHOD
Units
For ease of use the format keeps all measurements in meters. However, it is possible
to use other measurements for objects in the ObjectLibrary and then scale them
when they are placed in the building. The global use of meters also opens for the
possibility to translate a feature’s location into a location based on longitude and
latitude.
Building Location
The position of a building is defined with the GPSData element. This element
specifies the location of the building’s origo using longitude and latitude. To get
the rotation and height information there are also the attributes angle and height.
This element is located directly under the Building tag.
<Building id="B1">
<GPSData longitude="59.403175" latitude="17.948484"
rotation="30.0" height="BoundGround"/>
...
</Building>
3D Model of Building
A user has the possibility to define a 3D model of the building that can be used
to, for example, display the house in a 3D geobrowser. This model has to be a
COLLADA file and it can be loaded from any URI. The Model element is defined
under the building element.
<Building id="B1">
...
<Model ref="http://www.myhouse.com/gremlings/model.dae"/>
...
</Building>
Raster Image
The Raster element is used to either complement the floor data or to be used in
case of missing floor data. If the user scans a blueprint of a very complicated floor
plan, this could be used instead of the user having to place all the walls, doors,
windows, etc. This element is optional and can be placed inside the Floor element.

...
<Raster ref="www.myhouse.com/fourthfloor.jpeg" origo="0.0,0.0" />
...
</Floor>
26
3.3. THE FORMAT
Order
The order of the definition of the elements are important since the default for XML
Schema validated documents is used, in which the elements must be in a certain
order. This can both be helpful to the user, because of the consistency, but it can
also hamper the user since they are not allowed to place a Building element after
the ObjectLibrary element.
Drawable
EIML contains a specified drawable interface. All objects that can be drawn inherit
from this interface in some way. The first layer, under the drawable interface,
contains the basic draw elements like line, point, curve and polygon. Below these
there are more concrete features like, for example, a wall inherits from a curve.
3.3.2 First Draft Results

The first draft of EIML proved to be effective and easy to work with. The over-
all structure did not need to be changed. However, the implementation part and
the discussion with Alessandro Pieropan at CVAP revealed possible improvements
to the format. This is discussed in the next section. After implementing these
improvements we ended up with the structure that can be seen in figure 3.2.
3.3.3 Improvements
During the implementation of the first draft of EIML it was continuously improved.
There was never any need for a complete change of the design of the format. How-
ever, there were improvements made that were necessary to make EIML fully usable
for our use cases.
To get some input on our format we contacted Alessandro Pieropan who has
experience working with maps. In one of his projects, he created an XML-based
map format for virtual pedestrians. This format is called EDML, Environment
Distrimobs Markup Language, which is used to create city plan and architectural
representation for simulations.
Alessandro Pieropan gave some valuable input on our format, both to improve
the structure of it and to make implementation easier. He thought that we had
a good ground structure and that we should be able to use the structure for our
intended use. The most valuable input was his thoughts on the 2D structure of
our format. He meant that it would be very hard, if not impossible, to completely
convert the format to 3D. However, he also thought that our solution with holding
3D models on top of the map, might work out.
We also discussed the implementation part with Pieropan and he warned us
about the size of the format, that it might become too much data for a computer
or cell phone to hold the information.
27
CHAPTER 3. METHOD
Figure 3.2. An overview of EIML.
WallRefs Changed to DrawRefs

When defining areas in our format, it was possible to reference walls using the
element WallRef. At the same time it was, and still is, possible to complement
these walls with invisible lines that closed certain areas. These lines could not be
reused in the first version of EIML. However, as one of the first changes, we decided
to replace the WallRef instance with DrawRefs. This makes it possible to reference
not only walls but all drawable objects, including invisible lines.
Outlining a Floor
It is possible to define a BoundingBox to each floor. This element specifies what
part of a map actually contains building information and what part is outside the
28
3.3. THE FORMAT
building.
Improvements of Enclosures
The definition of enclosures was made more strict. The reason for this is to know
exactly how a user wants an area to look. The first version of EIML had very
loose definitions of areas and if a mistake was made in the Enclosure element it
was difficult to find the error. By making the enclosure definition more strict it
is harder to make mistakes because the user gets immediate feedback if an area is
questionable. In the final version of the format an enclosure has to consist of a set
of connected lines and the first point for the first line has to be in the same place
as the last point of the last line.
Building and Floor Names

When using the format and navigating between files it became clear that the build-
ing needs more than an ID, it also needs a name. This name property is not set as a
required attribute because every building might not have a specific name, however,
it is highly recommended to name every building.
3.3.4 Validation
Implementation
Validation is an important part of the XML environment. Validation can be used
both to tell the user if he has created a valid document and it can guarantee pro-
grams that the input file is a correctly structured document. In our format there are
several different parts that have to be validated and the validation process might
not be trivial.
An XML Schema has been created that validates the structure of EIML. It checks
that all start tags have end tags and that it is a well-formed XML document[30].
The XML Schema is not only used for validating but it can also give the user a
good overview over the structure of the format.
During the implementation of EIML it was realized that the XML Schema would
not be enough to validate the format. For example, when creating an area in our
format there are a set of restrictions on that area. The area defined must be a valid
polygon, which means that it must be closed and not contain any trailing points.
This is not possible to do in XML Schema so it was critical to extend the validation
with a Java component. This Java component validates all of the information that
the XML Schema validated and also makes sure that the polygons are correct.
Result
The validation was very useful while developing the editor. It provides a fast way to
validate that the created files were structured correctly. The XML Schema is very
29
CHAPTER 3. METHOD
useful to find errors in created files. It finds most of the errors and in most cases the
Java validator is not needed. In the small number of cases where the Java validator
proved to be useful, it found small but significant errors that passed through the
XML Schema.
3.3.5 Parsing
Implementation
The conversion from an EIML file to a class structure was an important part of
the implementation. The goal was to create a flexible solution that allows us to
alter the structure of the format and still be able to correctly parse it after minimal
code changes. To achieve this a SAX-parser is used. The SAX-parser simplifies the
parsing by handling the processing of the file. A SAX-parser is event-driven, which
means that for every reached tag the parser extracts the information from that tag
and asks what to do with it. With the help of an interface called ParsableWritable,
which holds information about how classes can be parsed and written, this infor-
mation can then be sent to the class that represents that specific tag.
Result
The goal of keeping the parser flexible was definitively achieved. Making structural
changes to the format can be easily done and in very little time. The SAX-parser
worked perfectly with our data and allowed us to effectively parse data.
3.3.6 Writing
Implementation
An XML serializer is needed to write EIML data to file. The XML serializer in
Android was tested and the conclusion was that it was perfect for our purposes.
However, it could not be used in our implementation since it is not present in the
Java standard library. Since we needed a way to write XML data to file both on
the Android platform as well as on a standard computer running the indoor map
editor, we chose to implement it ourselves.
The XML serializer that we implemented is very similar to the one found in
Android. We added some improved functionality, simplified the API, and made the
tag formatting a little bit smarter compared to the XML serializer in Android.
Result
The result is an easy to use XML serializer that can generate XML files. It is used
in the editor for the exporting of indoor maps to file.
30
3.3. THE FORMAT
3.3.7 Graphical Representation

There was a need for a graphical representation that is easy to both grasp and create.
Using basic graphical structures, it is possible to create accurate representations of
the floors that were modeled.
EIML supports straight lines as well as quadratic Bézier curves for all the dif-
ferent types of structures. See figure 3.3 for an example of the graphical structures
available. We think that this enables the user to quickly create a fairly accurate
model of a floor by only using these two line types.
Figure 3.3. The editor showing some of the graphical structures. Yellow dots are
the guiding points for the Bézier lines. Green dots are the end points of the lines.
The editor shows walls as black lines, doors as red lines, and windows as blue lines.
To represent areas we use a set of lines, straight and/or Bézier, to define a

polygon that can then be filled with a, partially opaque, color.
SVG
The first graphical representation, that was created from EIML, was an SVG image
that was created from the information stored in the format. The SVG file was first
created by using XSLT and the final version uses Java.
31
CHAPTER 3. METHOD
XSLT
XSLT is an XML-based format with which you can describe how to transform one
XML format to another XML format. Since both the EIML format and the SVG
image format are XML-based, XSLT was used to transform the EIML format into
an SVG file. This worked very well until more complex information such as the
object library and draw references were introduced to the format. This made it
very hard to use XSLT to generate the SVG files.
Java
The Java class structure has a method for writing an SVG file. This feature was
added because of the problems with XSLT. This method is implemented in the same
way as the method that writes the XML data. The SVG writer is defined for each
element with a method that writes the corresponding SVG tag and then calls this
method in any existing elements lower in the class hierarchy.
Result
The SVG writer provides a good overview of what a map looks like. In the early
stages of the project this was the only implementation showing a finished map. The
SVG writer makes it possible to create simple sample maps that can be used for
debugging.
Because of the problems with XSLT combined with the fine integration of the
SVG generating Java code in the class structure, we decided that the Java was the
best to use.
3.3.8 Licensing Fees

Only open standards and software that do not require licensing have been used
throughout the project. This makes it possible for our code to be used freely both
by other companies and individual users.
3.4 Editor
The editor was an important part of the project because it makes it possible to
quickly create maps with the help of a graphical user interface. Before the editor
the only way to create a map was by editing the XML file with a text editor. The
editor has been created with the use case of the user creating the maps in mind.
See figure 3.4 for a view of the editor with a clean slate.
3.4.1 Usability
The editor is simple to use and first and foremost it allows the user to quickly create
maps so that the user can concentrate on creating accurate maps instead of rushing
it because of a bad workflow. To enable fast creation of indoor maps, keyboard
32
3.4. EDITOR
Figure 3.4. The editor with a clean slate.
shortcuts are a key aspect of the editor. These shortcuts make it possible to change
tools instantly instead of having to move the mouse to a toolbar to select a tool
there. Keyboard shortcuts can enable instant switching of tools with some training,
while moving the mouse around to switch tools is never instantaneous. This is due
to the required mouse movement between the drawing panel and the toolbar.
3.4.2 Modes
The editor is designed with three different modes representing the key aspects of the
editor. The first mode is used to preview how the map looks in the mobile viewer,
the second mode is for editing the map, and the third mode is to create new areas
within the map. These modes are constructed so that they respond differently on
the user input. The user interface is also different for the separate modes.
View mode
The view mode gives the user a preview of what the map looks like in the mobile
viewer, see figure 3.5 for an example. This mode does not react to any user input
other than that of the user requesting to change mode as well as panning or zooming
of the map.
Edit mode
The key aspect of the editor is to draw new, modify, or delete lines to define the
structures of a building, see figure 3.6. Since this is the mode that is used most of
33
CHAPTER 3. METHOD
Figure 3.5. The editor in the view mode with an image underlay to guide the
drawing.
the time, the editor is set to this mode when it starts.

The user can choose what structural object he wants to create by using the
number keys (i.e., 1, 2, and 3) which gives him the choice of drawing a wall, a door,
or a window.
Here is a list of extended options that are available when right-clicking on struc-
tures in edit mode:
• Right-click on Line
If the line is part of an Area, it is possible for the user to view and change the
ID, name, and description of the Area. It is also possible to delete that area.
The user is able to set the scale of the line, i.e., how long the line is in meters
in the real world. This enables the user to make sure that the coordinates
throughout the map correspond to the real world coordinates.
The user is able to delete the Line.
• Right-click on Point
The user is able to delete the Point.
34
3.4. EDITOR
• Right-click on a guiding point for a Bézier line

The user is able to delete the guiding point.
Figure 3.6. The editor in the edit mode with an image underlay to guide the
drawing. Showing the popup menu for one of the walls surrounding an area.
Area select mode

To create areas, a special area select mode is available. In this mode the user is able
to select lines until a complete polygon is formed. When the polygon is complete,
the area is created and added to the format. A requirement of EIML is that the
polygons must be complete. This means that every end point in the polygon must
connect to another unique line in the polygon. We made this decision so that the
XML is easy to read and understand as well as to make it easier to parse.
The user does not have to choose the lines in any special order since the editor
tries to create a well-formed polygon after each line selection. The selected lines
are drawn as thicker red lines while the polygon is not complete. However, they
are converted into an area as soon as the last line that completes the polygon is
selected. After the area is created, the lines are drawn like they were before. This
35
CHAPTER 3. METHOD
is made so that the user easily can see that the lines have been selected and then
get a visual confirmation that the area is successfully created.
When an area has been created the user has the choice to either select lines to
create a new area or to go back to the edit mode.
3.4.3 Fast Floor Switching

We believe that it should be quick and easy to switch floors when working with a
building consisting of several floors. This is possible to do with keyboard shortcuts
like Shift+1 for the first floor, Shift+2 for the second floor and so forth. This enables
the user to switch back and forth between floors really quickly to, for example,
compare the different floors.
3.4.4 Snap to point/axis

To give the user the possibility to connect lines at the exact same point and to
keep the focus on enabling fast creation of our maps, the editor has an automatic
snapping functionality. This snapping functionality combines points that are close
to each other. For example, when dragging one point of a line close to a point of
a second line, the first point snaps to the second point, joining the two lines. The
user can then choose to either release the mouse button and by that verifying that
the snap is approved or keep moving the point away which makes it break away
from the second point again.
The snapping is also applied along the x-axis and y-axis when drawing lines.
This enables the user to draw straight lines. If a user tries to draw a line parallel
to the x-axis, the second point snaps to that axis, which will result in a completely
horizontal line. The same procedure applies for a vertical line.
3.4.5 Underlay
The editor has the possibility to show a partially transparent image under the
drawing panel, see figure 3.7. This enables the user to import an image of a floor
plan and draw the walls and other structures with the guidance of that image. The
image can be scaled so that it has the same scale as the drawn lines.
The user might want to be able to change the opacity of the underlying image.
This is possible to do with fast keyboard shortcuts as well as through the menu.
3.4.6 Scale
Since the coordinate format of EIML is in meters, it is important that the user can
make sure that the length of lines in the editor corresponds to the lines (e.g., walls)
in reality. The user is able, in the editor, to set the real world length of a line. This
scales the rest of the information in the EIML file accordingly.
36
3.4. EDITOR
Figure 3.7. The editor in the edit mode with an image underlay to guide the
drawing.
3.4.7 Zoom and Pan
To enable fine tuning of lines and drawing of small or very large structures it is
important for the user to be able to both zoom and pan the map. By scrolling the
mouse wheel, the editor zooms in or out at the location of the mouse pointer. By
clicking the middle mouse button and dragging the map, the user can pan the map.
3.4.8 Import and Export of EIML
The existing Java classes are used to parse and import EIML files into the editor. By
using the Java classes it is possible to change the data directly by holding references
to the parsed data. It is then possible to easily export the modified map to an EIML
file by calling the method on the root object of the class hierarchy that exports the
XML information.
37
CHAPTER 3. METHOD
3.4.9 Marking Origo

The origo is marked as the crossing of the x-axis and y-axis. This makes it easy for
the user to see where the building should be placed. The mouse pointer’s current
coordinate is also shown in the status bar to help the user decide where to draw.
3.4.10 Menu
The menu bar is generated with all the buildings from the parsed file and under
each building menu are the selectable floors. Almost all of the actions described
in this section are also available in the menu. See figure 3.8 for an example of the
available options.
Figure 3.8. The editor in the edit mode showing some menu options.
3.4.11 Validation
Since the editor uses the Java class structure for the parsing of the EIML file that
the user would like to import, the parsing makes sure that the imported file is
validated and well-formed. The user does not need to worry about the correctness
of the edited or exported file.
38
3.5. VIEWER
3.4.12 Target Platform

Since we have used Java with Swing to create this editor, it is cross platform com-
patible and runs on all modern operating systems. The system requirements for
this editor is very low and works on almost any hardware.
3.5 Viewer
To view the maps a map viewer application for a mobile device was created. The
goal of the viewer is to give the user the ability to navigate in a building using a
mobile device. The following list describes the features of the viewer. This list is
inspired by the predefined use cases.
• Parse a correctly structured map file
• Displaying the map on the screen of the mobile device
• Showing points of interest on the map
• Scan and parse general barcodes
• Displaying and interacting with conference rooms
• Ability to choose which floor to display
• Search for a person, room, or point of interest
• Control the map with panning and zooming
Besides these points the viewer supports outdoor maps and makes it possible to
select a building on an outdoor map. When a building is selected on the outdoor
map the user receives information about the building and is also presented with the
choice to enter that building and see the indoor map.
3.5.1 Target Platform and Hardware

The target platform for the viewer is the Android operating system, which is main-
tained by Google Inc.[13]. There are several reasons for this choice. The main
reason is that the Android platform uses Java which our other modules are written
in. This makes it possible to use the same code base for both the editor and the
viewer. One other important reason is that Sony Ericsson released an Android pow-
ered mobile phone, which was a perfect target for our maps. The close relationship
between Sony Ericsson and Ericsson made it possible for us to use phones from
Sony Ericsson.
The Sony Ericsson mobile phone powered with Android is called the Xperia™
X10[7] and was released in May 2010. The late release date meant that all implemen-
tation and testing had to be done on other phones or with the help of an emulator.
39
CHAPTER 3. METHOD
The Android system allows users to follow certain guidelines to create applications
that are compatible with all phones which was helpful for the implementation.
The implementation and testing was done in an emulator, on the HTC Magic[12],
and on the Google Nexus One[18]. The emulator made it possible to test the
implementation with different resolutions. The HTC Magic and the Google Nexus
One also have different hardware which made them good candidates for our testing.
The main differences between the two phones are different screen size and resolution,
processor speed, and camera image quality.
Besides the difference in hardware between the phones there are a few co-existing
versions of the Android operating system deployed currently. Our implementation
is targeted at version 1.6. This was influenced by the Xperia™ X10 since it runs
Android 1.6. However, we also decided to test it on all the major versions of Android,
which are 1.5 through 2.2. See figure 3.9 for an example of the Android versions
and resolutions that were tested.
Figure 3.9. Four different instances of the emulator running different Android
versions with different screen sizes. From left to right: 1.5 with 320x480, 1.5 with
320x240, 2.1 with 400x800, 1.6 with 320x480.
3.5.2 Parsing
Because the reading and parsing are implemented in Java they were easily converted
and used in the viewer. The only problem was that the SAX parser, which is used
in the parsing algorithm on the server side, is not supported in the Android Java
Library. However, there is an almost identical parser available which is used and
allows the use of the same general parsing code by only making minor changes to
the structure of the parser.
40
3.5. VIEWER
3.5.3 Displaying and Navigation
It is possible to view the maps in the editor as they would look on the mobile
device. Therefore, the editor code has to be flexible so that it can be used for
drawing the maps both in the editor and the viewer. To make this possible the
viewer implements parts of the editor.
To make the application easier to use for the user, it is possible to view the
map in both landscape and portrait mode, see figure 3.10. Android phones have a
rotation sensor that indicates how it is rotated. This sensor is used to automatically
change the view of the map to help the users as much as possible.
Figure 3.10. Viewer shown in landscape and portrait mode under Android 1.5 with
resolution 480x320 and 320x480 respectively.
To navigate the map the user can simply hold and drag it. All Android phones
come with touch screens which makes this the easiest way to navigate. The user
can also zoom in and out with help of two buttons in the top corners of the screen.
Another important aspect of the navigation is the presentation of different op-
tions. The only visual elements that the user can see when the viewer has started
is the map itself and the zoom buttons. The reason for this was to give the map
as much space as possible on a small mobile screen. All other options are hidden
until the menu button is pressed. All Android devices have a menu button which is
always accessible in some way. When the menu button is pressed different options
are presented to the user.
41
CHAPTER 3. METHOD
3.5.4 Searching
To make it easier for the users to find conference rooms, people etc., there are
multiple search functionalities included in the viewer. The most common way is
to use a text search to search for someone’s name, room number, or conference
room name. Another way to search is by scanning barcodes which provides location
information.
Text Search
The viewer contains a plain text search option. This option is selectable from the
menu and gives a single text field for the user to type the search query. To make
the searching easier for the user the text field is equipped with an auto complete
function. While a user types in the search field different possible results, containing
the typed text, appears. These results are selectable and can be accessed as soon
as they appear. When a result is selected the map puts an arrow on the result’s
target and moves the map so that the arrow becomes visible. If the result is on a
different floor, the floor is changed.
Barcode Scanning
The barcode scanner is implemented in the viewer to help the user retrieve the
correct maps as well as for positioning purposes. The barcode scanning functionality
comes from an external library, from the ZXing Team[6]. This scanner can read
a variety of barcodes and return the information from those codes to the viewer.
To use the barcode scanner the user selects the Scan option from the main menu.
When the Scan option is selected the mobile phone’s camera is activated and the
scanning interface combined with the input from the camera are displayed on the
screen. The user scans a barcode by holding the camera in front of it. When a
barcode is scanned the result is parsed by the viewer and the appropriate action is
taken.
One major advantage of the barcodes is that they are already in use today. The
uses today are not only on grocery store products but also to identify electrical
cabinets or rooms. In the Ericsson building, where this project was done, every
room had a barcode by the door outside the room. With the barcode scanner in
the viewer it was possible to read these codes and then use them to help a user
position himself in the building. See figure 3.11 for two examples of barcodes that
the viewer can read.
Manual Searching
It is possible for a user to search for a conference room or similar by navigating
the map. The user can press the menu button to select what floor he wants to see.
When a certain floor is selected it is easily navigated and the user can press on
different areas to get more information about them.
42
3.6. ROUTING
Figure 3.11. Two different barcodes that the viewer can read.
3.5.5 Area Interaction
It was possible to interact with areas that were defined in the map structure. These
areas were marked with a light green color just like in the editor. In the viewer,
every area is clickable. When a user presses down on an area, the information for
that area is displayed. The information is taken from the EIML file.
3.6 Routing
The routing ability is one of the most utilized features in the mobile Android version
of Google Maps. Android users have navigated more than 1 billion miles during the
last 6 month with this feature[19]. The routing feature can also be useful indoors
since one of the most common uses for a map is to find your way to a destination.
There are a few different possible implementation solutions to enable routing in
our format. One possible solution is to let the creator of a map place waypoints
in the map and then connect these waypoints. This makes it easy for the software
developer to create the routes at the same time as it would take longer time for the
creator of the map to actually create the map. Another way is to let an algorithm
scan the map and automatically determine what possible routes there are. This
solution means more job for the software developer at the same time as it takes less
time to create the map.
Our goal was to make it easy to create maps, therefore we implemented an
algorithm that automatically creates the possible routes.
43
CHAPTER 3. METHOD
3.6.1 Implementation Results

To create an algorithm that automatically generates routing information there are
certain challenges available. The information that is present from a map gives
information about position of the walls, doors, windows, and defined areas. There
is no information about which doors are connected to which rooms. There is also
no information about corridors or intersections of corridors that could be useful to
tell the user to, for example, turn left at the next intersection.
The way this problem was approached was to first create the data that tells
which doors are connected to each other. With this information it would then be
possible to tell the user which doors he needed to go through to reach his goal.
An example of this would be if a user, Steve, wanted to move from area A1 to
Area A3 with the map shown in the figure 3.12. The algorithm would then look
at Steve’s position and find the connected door or doors. In his case it would only
be D1. It would then look at the goal position which is A3, and see that D2 is the
connected door. The algorithm then uses the data of the connected doors to see
that D1 is connected with D2 and thereby it can tell Steve to exit A1 through D1
and then enter A3 through door D2. This data could then later on be expanded by
telling Steve how he would navigate through A2 to reach D2.
Figure 3.12. A visualization of Steve’s map.
The algorithm used to find which doors are connected is a Depth First Search
(DFS). The reason for this choice is that an exhaustive search of the whole area
is needed to identify which doors were connected to it. A Breadth First Search
could have been used to get the same result, however, the DFS algorithm provides
a better memory efficiency.
First the structure of the building is drawn to an image to set up the boundaries
44
3.6. ROUTING
for the search. Then a search is performed from every door and area to see which
other doors and areas can be encountered. The search starts at one door and
continues until a black wall, green area, blue window, or a red door is encountered.
If the search encountered a wall or a window it is terminated. If the encountered
object is an area or door it is connected to the original door or area. All the
connections are saved in a graph representing the connected areas. This graph can
then be traversed to calculate routing options.
45
Chapter 4
Results
This chapter presents, in detail, the results we achieved in the different parts of the
project. The main outcomes of this work are:
• EIML format
An XML-based format for storing indoor map information. EIML is object
oriented and focused on ease of use.
• Editor
An application for graphical creation and modification of EIML files. The
editor supports all aspects of the EIML format and provides a visual assistance
while working with maps.
• Viewer
A mobile based application for viewing an indoor map. The viewer supports
interaction with the maps as well as navigation and positioning systems.
4.1 Use of other formats

The other map formats that we studied gave some good guidelines and helped with
important decisions for our format.
4.1.1 Format Structure

When reading about other format we realized that XML is the best structure for
our format. The newest and currently most used formats, like GML and KML,
use XML for storing the geographical information. This does not only mean that
a substantial amount of people know XML, it also means that there are good tools
for working with XML available.
47
CHAPTER 4. RESULTS
4.1.2 Object Orientation and Inheritance

All three of GML, KML, and IFC used some kind of inheritance to classify objects.
This concept is taken into consideration as much as possible. For example, to
define an area in EIML there needs to be an enclosed area that specifies where that
area is. This enclosure needs to be defined by walls, lines, windows, doors, and so
on. Instead of specifying all of this information for each area a drawable class was
created. All objects can then inherit from the drawable class and it is possible to
express that each area must be enclosed by drawables.
4.1.3 Object References

Referencing objects is an important part in many of the other formats we have looked
at. The reason for its importance is because of the problems that the redefinition of
objects create. If basically the same object is defined multiple times it is harder to
edit the file and the file would also be bigger. We tried to use referencing as much
as possible in EIML. First of all we took all objects that are not part of the basic
structure of the building and placed them in an object library. The table needs to
first be created in the object library if it is to be placed in a building. It can then
be placed in the format and then referenced.
The referencing is taken one step further with the definition of areas. The most
common areas in a building are enclosed by already defined walls, windows, and
doors. When defining an area in our format the outline of the area can be defined
by referencing walls, windows, or any other drawable object. This means that it is
possible to change the location or dimensions of a room and the area information
follows.
4.1.4 Layers
A vital part of GML and the key aspect of KML is that information is structured
in layers. KML offers a wide variety of possibilities to define overlays to already
existing maps. EIML took advantage of this concept by separating the structural
information from the general information and interior design of a building. The
basic building blocks of a building (i.e., walls, doors, and windows) are defined in
a separate container. However, the information from this container could still be
used for various tasks like restricting areas.
4.2 Open Vs. Closed data

4.2.1 Overview
One important issue with outdoor maps today is getting the data. With outdoor
maps it is the person or company who owns the data who is in control. However,
this creates the problem of sharing the data without giving it away. This can be
done in some different ways. The most common way, which for example Google
48
4.3. TESTING
Maps[14] uses, is to render images from the data and only send these images to
the user. It is also possible to keep the data open like, for example, Open Street
Map[27]. The advantage of this is that anyone can contribute and improve the data.
In our implementation we decided to keep the data open. This would allow more
freedom to the user and it would make it possible to an independent user to publish
his own map. It would also be possible to create a community, like Open Street
Map, where the users could create and update maps. The more products that have
integrated our maps the more likely it is to get more users and developers.
4.2.2 Effects of an Open Format

With an open format some implementation details have to be considered when
implementing the viewer. The viewer could either read the format or work with
already created map images. The advantage of creating the map images in advance
would be that they are faster to process but they are bigger in size. With mobile
networks today it is best to send as little data as possible which makes reading the
format the better choice. Another advantage of having the viewer read the map is
that there is little or no flexibility in statically created maps. Due to these reasons
we decided that the viewer would read the format and draw the maps at runtime.
4.3 Testing
Testing was carried out continuously during the implementation. To simulate a case
as close to our use cases as possible it was decided to map the floor of the building
that we were working in. The building is an Ericsson owned building and is located
on Färögatan 6, Kista, Sweden. The building has 8 floors and about 200 rooms per
floor.
The main goal of the testing was to ensure the usability of EIML and to find
possible ways to improve on the format. At the same time the testing also helped
with improving the implementations.
4.4 Performance
4.4.1 Viewer
The viewer performed well on the 528 MHz processor of the HTC Magic as well as
the 1 GHz Snapdragon processor of the Nexus One and Xperia™ X10. The only
part that slowed down the user experience was the loading of the map which has to
be done when the program starts. This was mainly because of the large input file
that had to be parsed. The barcode scanning in the viewer worked well and was
able to correctly scan all of the barcodes that we tested.
49
CHAPTER 4. RESULTS
4.4.2 Editor
The mapping of one floor in the Ericsson building, including all windows, doors, and
walls, took around 3 hours which is fast considering that the floor had over 1800
structural items. There were no computational performance issues with running
the editor on a modern computer.
4.4.3 Format
The only performance issue with EIML is that a large building can take some time
for a standard computer as well as a mobile device to process all the information.
This is an issue with all XML-based formats that contain much data but has not
been an issue during this project. To prevent this from being a problem in the
future it is possible to prioritize important data during the parsing.
Transferring a large EIML file is not an issue since it is possible to compress it
to about 10% of the original size with a common compression algorithm.
4.4.4 Usability
The goal of EIML and the implementations was not to create software for an end user
but to create a proof of concept to be able to show the use that indoor maps might
have. Therefore, no usability testing was performed besides our own evaluations.
Viewer
The viewer was easy to use and its interface was easily understood. By hiding all
buttons except those for zooming, the exploration of the map was simplified.
Editor
The editor has, like all software, a small learning curve that a user has to get over
before he can use the editor effectively. An important part of the editor is the
keyboard shortcuts that allows the user to quickly change between different modes,
tools, buildings, and floors. When a user has learned these shortcuts he can quickly
create large maps.
Format
We believe that we were able to create a format for storing indoor maps that is
easy to both read and use. Even with a large building like the Ericsson building, it
was possible to open the file with a text editor and both find and edit information
about rooms and similar items.
50
4.5. POSITIONING
4.5 Positioning
Indoor positioning is an area of research that has been getting more and more
attention during the last years. We believe that an indoor positioning system will
eventually be something that anyone uses and that with such a system in place,
indoor maps will become an even more important part of our lives. However, even
without such a system, good indoor maps can play a crucial role in navigating inside
buildings. Indoor positioning still has a long way to go before it can be used along
with indoor maps.
4.5.1 Conclusion
The mobile network, GPS, and wireless network positioning were the three types
of positioning systems that can be used in modern cell phones. Currently these
systems were not nearly accurate enough for use with indoor maps.
Some testing was performed with two modern cell phones (HTC Magic and the
Nexus One) with GPS, mobile network, and wireless network positioning activated.
The results were that the cell phone was able to locate us within a circular area
with a radius of about 50 meters. From this data it might be possible to locate the
building that a cell phone is in, but not much more. For effective positioning indoor
the radius should not be more than a couple of meters.
Another big problem is the altitude. The mobile network and wireless network
localization are not able to determine the altitude of a cell phone. Altitude is an
important part of localization indoors because it can be very hard for the user to
determine what floor he is on[28].
We believe that in the future this problem will be solved with either a new
positioning technique or with external tools to improve the accuracy of current
technologies. An example of this would be if it was simple enough to install GPS
repeaters in a building[20].
A GPS system cannot be used indoor because the signal does not penetrate solid
objects like roofs and other objects in the way.
4.6 Routing
The initial idea was to perform the routing on the mobile device. Because of this
the routing algorithms were from the beginning heavily optimized with the help of
profilers. In the case of a small indoor map with around 50 doors it took less than
one second to calculate all of the routing possibilities. However, for larger maps like
the Ericsson building on Färögatan 6, Kista, Sweden, the routing took too much
time to be performed on a mobile device. The routing code is written in Java and
could easily be moved to a server so that the calculations could be done there.
51
CHAPTER 4. RESULTS
4.7 Implementation results

As mentioned earlier in this report in the implementation section, we decided to
build our implementation in Java. To be able to use the format in Java we needed
a class structure to hold all of the information that our format could contain. We
used an object oriented approach for this problem. For almost every tag in our
format there is a corresponding Java class. This makes it easy to see a direct
connection between the XML file and the Java class structure. A simplified example
is illustrated in the figure 4.1.
Figure 4.1. An example of how the Java class structure is similar to the XML file.
This structure allowed us to treat every tag independently and we could write
and execute tag specific code. This makes EIML very flexible. We could easily
change or extend the format with new tags by only changing the affected places.
To further utilize this structure we said that every class, which represented a
tag, must extend an interface. This interface requires that the class has methods
which handles both parsing and writing. This interface is called ParsableWritable.
Later on, ParsableWritable was extended to contain methods that can validate a
tag as well as methods that can write the appropriate SVG code for that tag.
4.7.1 Usage of SVG

SVG is a good standard that describes scalable images which is preferable when
creating maps. The first version of the mobile viewer worked with images created
with SVG instead of drawing the maps like the final version did. The reason for
switching away from SVG for the viewer was to keep the map flexible and customiz-
able. Handling a large file does not work well on a cell phone and there is no good
way to strip down the SVG file to only show the important information at a certain
point of time. When using the same drawing algorithm as the editor in the viewer,
52
4.7. IMPLEMENTATION RESULTS
it is possible to only draw the vital parts. The drawing algorithm also allowed us
to easily add specific features and alter the map to our liking.
53
Chapter 5
Conclusion
In this report we have described a possible solution for an indoor maps implemen-
tation. We have created EIML, an XML-based format, which can store indoor map
information. Then we have built software that creates, modifies, and navigates
indoor maps in this format.
The format that was created and improved throughout this report meets the
goals of being flexible and easy to use. Because the format is XML-based, it is easy
to understand and to get an overview of the file. For someone who has experience
with XML it is also possible to get a good grasp of how EIML works by looking at
the XML Schema.
The final version of EIML stores all the information that is needed to create
an indoor map which can model a general office building. It has also enough infor-
mation to store information about conference rooms and such as well as perform
routing.
The implementation part was very helpful for improving the format and it is
also a good way to show that it is possible to work with EIML. Working with the
format gave good insight to which problems EIML had and made it possible to
adjust the flaws we found in the process of implementing.
The editor is very easy to work with and it proved to be a valuable tool for
creating the indoor maps. It is very resource efficient and provides a streamlined
workflow enabling the user to quickly create accurate maps.
The viewer is a good way to show how the maps can be used. It provides us with
a real life example of how indoor maps can be used in a useful way. The viewer also
proposes an interesting solution to the lack of a positioning system. With the help
of barcodes it is both possible to identify the current building and also identify the
location of the barcode. The barcode scanner works better than we initially could
have expected and we were able to successfully scan the barcodes already present
in the building we worked in.
Many different graphical representation possibilities were explored throughout
the project. Early on, the focus was at creating scalable images in the SVG format.
These images were useful to get a view of what a map might look like, but it was
55
CHAPTER 5. CONCLUSION
hard to use these images in the viewer or the editor. The solution to this was to
create a drawing function in the editor to show what the map looks like and then
use the same drawing code in the viewer. This makes it easier to display and modify
the map in both the editor and the viewer.
56
Chapter 6
Future Work
During the creation of EIML we always strived towards creating a flexible format. It
was our goal to have a format that could easily be expanded with new features. This
means that many of the features in this section are not problematic to implement
but were excluded due to lack of time.
6.1 Tag List

EIML should support a tag format that can hold information about important
objects and places in different maps. A tag would contain a position or area and
some information about that place. It should be possible to place the tag list either
inside or outside the main EIML file. This opens for the possibility of users creating
their own tag data and assigning it to an already existing map. A tag list could
be used for a variety of different purposes including routing. Instead of doing the
routing on the fly a user could predefine routing points that the system could use
instead. Tags could also be used to mark points of interest.
6.2 Positioning
We believe that an indoor positioning system solution will be available in the near
future. If such a system would become popular and widely adopted it would be
easily implemented in our format. EIML can store information about where the
building is located in the terms of longitude, latitude and altitude. Even though
only one such point is defined, the longitude, latitude, and altitude can be calculated
for any other point in the building because all other measurements are defined.
6.3 Customizable Container

In EIML, under the floor tag, we have defined multiple containers that hold various
information about that floor. In the current state, these containers are predefined
for their own specific use. However, it is possible to implement new containers at
57
CHAPTER 6. FUTURE WORK
this level. It would be good to have a general container that could be customized for
specific uses without having to change the code or definition of the format. Example
of such a container would be a fire route. It would be possible to let this container
contain drawables and information about these drawables in a flexible way so that
a viewer could show them, with or without modifications to the viewer.
6.4 Time Dependent Objects

There are many different objects in a building that can change properties during a
normal day. Some examples of such objects are elevators and time activated door
locks. These objects could play an important part in, for example, routing and path
planning because everyone might not have access to the whole building at all times.
58
Bibliography
[1] AECBytes. The IFC Building Model: A Look Under the Hood, 2004. http://
www.aecbytes.com/feature/2004/IFCmodel.html Accessed on 2010-03-08.
[2] AECBytes. AECBytes, 2010. http://www.aecbytes.org/ Accessed on 2010-

03-12.
[3] buildingSMART Alliance. buildingSMART Alliance, 2010. http://www.

buildingsmartalliance.org/ Accessed on 2010-03-19.
[4] buildingSMART International. IFC Documentation, 2004. http://cig.bre.

co.uk/iai_international/Technical_Documents/iai_documents.html
Accessed on 2010-03-19.
[5] buildingSMART International. IFC Implementation guide, 2004.

http://cig.bre.co.uk/iai_international/Technical_Documents/iai_
documents.html Accessed on 2010-03-01.
[6] Inc. Denso Wave. ZXing, 2010. http://code.google.com/p/zxing/ Accessed

on 2010-07-14.
[7] Sony Ericsson. Xperia X10, 2010. http://www.sonyericsson.com/cws/

products/mobilephones/overview/xperiax10 Accessed on 2010-07-14.
[8] Bill Evjen, Kent Sharkey, Thiru Thangarathinam, Michael Kay, Alessandro
Vernet, and Sam Ferguson. Professional XML. Wrox Press Ltd., Birmingham,
UK, UK, 2007.
[9] Michael Fitzgerald. Learning XSLT. O’Reilly & Associates, Inc., Sebastopol,
CA, USA, 2003.
[10] U.S. Government. National Space-Based Positioning, Navigation, and Timing

Coordination Office’s GPS information, 2010. http://gps.gov/ Accessed on
2010-07-14.
[11] Sandström Henrik, Svensson Johannes. Master Thesis Specification, Indoor

Maps. KTH, Ericsson Research, Kista, 2010.
59
BIBLIOGRAPHY
[12] HTC. HTC Magic, 2010. http://www.htc.com/www/product/magic/

overview.html Accessed on 2010-07-14.
[13] Google Inc. About Google Inc., 2010. http://www.google.com/about Ac-

cessed on 2010-07-14.
[14] Google Inc. Google Maps, 2010. http://maps.google.com Accessed on 2010-

07-14.
[15] Google Inc. KML Documentation, 2010. http://code.google.com/apis/

kml/documentation/ Accessed on 2010-03-19.
[16] Google Inc. KML Documentation, Custom Data, 2010. http://code.google.

com/apis/kml/documentation/extendeddata.html Accessed on 2010-03-16.
[17] Google Inc. KML Documentation, KMZ, 2010. http://code.google.com/

apis/kml/documentation/kmzarchives.html Accessed on 2010-03-18.
[18] Google Inc. Nexus One, 2010. http://www.google.com/phone Accessed on

2010-07-14.
[19] Tom Krazit. Google I/O keynote day 2: Android day (live blog), 2010. http:
//news.cnet.com/8301-30684_3-20005447-265.html Accessed on 2010-07-
14.
[20] Darren Murph. Underground / Indoor GPS Repeater Main-

tains Your Position, 2010. http://www.engadget.com/2007/02/21/
underground-indoor-gps-repeater-maintains-your-position/ Accessed
on 2010-07-14.
[21] Open Geospatial Consortium, Inc. City Geography Markup Language

(0.4.0), 2004. http://portal.opengeospatial.org/files/?artifact_id=
22120 Accessed on 2010-03-13.
[22] Open Geospatial Consortium, Inc. GML Documentation, 2010. http://www.

opengeospatial.org/standards/gml Accessed on 2010-03-15.
[23] Open Geospatial Consortium, Inc. KML Documentation, 2010. http://www.

opengeospatial.org/standards/kml Accessed on 2010-03-17.
[24] Open Geospatial Consortium, Inc. KML Engineering Report, 2010. http:
//www.opengeospatial.org/standards/kml Accessed on 2010-02-17.
[25] Open Geospatial Consortium, Inc. KML Module Schemas, 2010. http://www.
ogcnetwork.net/schemas/kml/ows5/xsl/ Accessed on 2010-03-15.
[26] Open Geospatial Consortium, Inc. KML Profile Schemas, 2010. http://www.
ogcnetwork.net/schemas/kml/ows5/profile/ Accessed on 2010-03-15.
60
BIBLIOGRAPHY
[27] OpenStreetMap. OpenStreetMap, 2010. http://www.openstreetmap.org/

Accessed on 2010-07-14.
[28] Arto Puikkonen, Ari-Heikki Sarjanoja, Merja Haveri, Jussi Huhtala, and Jonna
Häkkilä. Towards designing better maps for indoor navigation: experiences
from a case study. In MUM ’09: Proceedings of the 8th International Conference
on Mobile and Ubiquitous Multimedia, New York, NY, USA, 2009. ACM.
[29] Dharma P. Agrawal Rashmi Bajaj, Samantha Lalinda Ranaweera. GPS:

Location-Tracking Technology, 2002. http://www.computer.org/portal/
web/csdl/doi/10.1109/MC.2002.993780 Accessed on 2010-07-14.
[30] W3C. Definition of Well-Formed, 2010. http://www.w3.org/TR/REC-xml/

#sec-well-formed Accessed on 2010-07-14.
61
TRITA-CSC-E 2010:119
ISRN-KTH/CSC/E--10/119--SE
ISSN-1653-5715
www.kth.se

Indoor Maps MSC Thesis

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Indoor Maps MSC Thesis

Uploaded by

Copyright:

Available Formats

Indoor Maps

Master of Science Thesis

Master’s Thesis in Computer Science (30 ECTS credits)

Royal Institute of Technology

Structure of the Report

1 Problem and Purpose 1

DTD (Document Type Definition)

GML (Geography Markup Language)

GPS (Global Position System)

GSM (Global System for Mobile Communications)

HTML (Hyper-Text Markup Language)

IFC (Industry Foundation Classes) Building Model

OGC (Open Geospatial Consortium)

POI (Point of Interest)

SGML (Standard Generalized Markup Language)

SVG (Scalable Vector Graphics)

W3C (World Wide Web Consortium)

XHTML (Extensible Hyper-Text Markup Language)

XML (Extensible Markup Language)

XSD (XML Schema Definition)

XSLT (Extensible Stylesheet Language Transformations)

This report is a Master Thesis in Computer Science at CSC, Royal Institute of

Problem and Purpose

1.1 Areas of Usage

1.1.3 Home Users Sharing with Friends

1.1.4 Marketing of a Store

1.1.5 Shopping Centers and Malls

1.1.6 Guidance for Emergency Personnel

1.2 Use Cases

1.2.1 User Perspective

1.2.2 Map Creator Perspective

1.2.3 Developer Perspective

2.1.1 Adoption/Existing Implementations

2.1.2 Text-based Properties

2.1.4 XML Schema

but it can do much more. An XHTML link is only unidirectional where as an

2.2 The IFC Building Model

2.2.2 Important Ideas and Concepts

• Resource Layer – Used for geometry, material, quantity, measurements, date

See figure 2.1 for an overview of what these layers contain.

Building Plumbing Structural Structural

Shared Bldg Shared Shared Shared Shared

Control Product Process

IFC2x2 platform Kernel IFC2x3 final

Material External Geometric Geometric

Presentation Presentation Presentation Presentation Presen- Time Structural Profile

Inheritance and Object Hierarchy

Defining Abstract Components

Figure 2.2. Overview of the IfcActor in the IFC model[4].

2.3.1 Important Ideas and Concepts

Difference between Geographical Data and Graphic Interpretation

GML Application Schema

Dynamic Features and Time Objects

GML Simple Features Profile

2.4.2 Important Ideas and Concepts

• LOD 0 – regional, landscape

• LOD 1 – city, region

• LOD 2 – city districts, projects

• LOD 3 – architectural models (outside), landmarks

• LOD 4 – architectural models (interior)

Figure 2.3. Illustration of the different levels of detail[21].

Extending the Format

2.5.2 Important Ideas and Concepts