CS27b Lab. Kobe University Graduate School
LocWeb2014@Shanghai
Considering Common Data Model for
Indoor Location-aware Services
Graduate School of System Informatics
Kobe University, Japan
Long Niu, Shinsuke Matsumoto,
Sachio Saiki, Masahide Nakamura
Outline
 Background
 Challenge
 Goal
 DM4InL
 Location model
 Building model
 Object model
 Case study
 Discussion and limitation
 Conclusion
2
Indoor Positioning System (IPS)
 Estimate position of people and objects in indoor space
 Solution based on sensor or wireless devices
 Rapid research and development
IMES
Wi-Fi
Location
based services
The Cricket Indoor
Location System
 Different characteristics of accuracy, resolution and cost of
infrastructure deployment
 No de-facto standard for IPS yet
JAXA: Japan Aerospace Exploration Agency
3
Indoor Location-aware Services (InLAS)
 Automatically performs appropriate actions and
behaviors, according to position of user or object
 Navigation service of a shopping mall
 Exhibition guidance service for a museum
 Underground parking management service
 Provide location information of the park, and represent indoor
position of vehicles and users
Where is vacant
Parking spot?
Where is my car?
Image from http://ekimae.e-fukui.com/webapps/www/carpool/
N1
N2
N3
N4
Entrance
Exit
S1
S2
S3
S4
using
N1, N2, S3
are vacant
Your car`s position
vacant
Your car is parking at
N1
4
Challenge
 Determine how to represent and manage indoor location
information obtained from IPS
 Conventional systems
 InLAS and IPS are tightly coupled
 Cannot share or reuse the data and common procedures
 Complicate implementation of InLAS
 Increase development cost and effort
Underground parking
management service
InLAS
InLAS
Using Wi-Fi
Using Infrared
IPS1
IPS2
5
Long-term goal and scope
 Providing cloud-based architecture for InLAS
 Indoor Position Query Service (IPQS)
 Gather location information from various IPS
 Provide application-neutral APIs to various InLAS
⇒Achieve loose coupling of InLAS and IPS
 Facilitate share and reuse of
indoor location information
and common procedures
InLAS1
 Improve efficiency and
reusability of
InLAS development
 Scope of this research
 Designing data model in IPQS
InLAS2
InLAS3
Application-neutral APIs
IPQS
Common
Data Model
IPS1
IPS2
IPS3
 DM4InL: Data Model for Indoor Location
6
Outline



 DM4InL
 Location model
 Building model
 Object model
 Case study
 Discussion and limitation
 Conclusion
7
Key idea for DM4InL
 Yuan pointed out that ”spatial object must have three
attributes" [1]
Location
Model
Lat.=38
lat=35
Space
Long.=134
lon=135
Object
make=honda
name=niu
Theme
Model
owner=niu
age=26
time=2014-11-02
time=now
Time
 Space attribute can be represented by following forms
 Geographic coordination
{lat.=38, long.=134}
 Relative coordination
Object
{x=12m, y=35m, in=Shanghai 3rd Park}
Model
{name=Shanghai 3rd Park, lat.=38, long.=134} Building
Model
[1] B. Li, G. Cai, A general object-oriented spatial temporal data model, J.ISPRS, XXXIV(4), 2002
8
Three models in DM4InL

Location model
 Defines global position for building
 Defines geometric primitives for representing space attribute of
spatial objects inside a building
 e.g., point, line and polygon

 Defines building and geographic
elements within it
 e.g., spot, route and partition

DM4InL
Building model
Location
Model
Building
Model
Object
Model
Object model
 Defines various objects
 e.g., people, vehicle and appliance
9
Location
Location model
model
 Defines indoor location information and geometric
primitives
 Every indoor position is represented as relative coordinates (3Doffset) from reference point
 Reference point is defined by global position
 Space attribute of spatial object is represented by 4 geometric
shapes (point, line, polygon and space)
 e.g., Location of my car is represented by a single point,
location of parking spot is represented by a space.
Z
Point
global
position
Lat.: 34.72328
Long.: 135.231454
Altitude: 54.3
X
space
Y
Line
Polygon
10
Data schema in Location model
 Global position
 Including longitude, latitude and altitude
 4 geometric primitives
 Point, line, polygon and space
Global Position (GPos) GPID. Longitude, Latitude, Altitude
GP01, 135.231454, 34.72328, 54.3
Local Line (LLN) BuildingID, LLNID, (LineCode)
B0001-LLN01, (L0001)
LLNP
secondary key: external
entity can easily refer to it
Local Point (LP) BuildingID, LPID, (PointCode) , x-offset, y-offset, z-offset
B0001-LP001, (P0001) , 5.50, 4.20, 1.00
LPGP
Local Polygon (LPG)
BuildingID, LPGID, (PolygonCode)
B0001-LPG01, (PG0001)
Local Space (LSP)
BuildingID, LSID, (SpaceCode), PolygonCode, Height
B0001-LS01, (S001), PG0001, 4.00
11
Building model
 Represents spots, routes and partitions as a geographic
element within building
 Every building has global position ID and some attributes (e.g.
name, # floors, owner)
 Each geographic element is located by corresponding entity in
the location model
 This model gives concrete meanings for some shapes defined in
location model
X
N1
GP01
Y
12
Data schema in Building model
 Building
 Reference to a global position ID
 Defines some theme attributes
 Geographic elements
 Associated with a building ID
 Reference a space/line/point Code
 Define theme attribute
Building(B) BuildingID, GPID, name, type, …
B0001, GP01, Shanghai 3rd Park, park, …
Parent-child
relatioship
Partition(P) BuildingID, PID, SpaceCode, name, …
B0001, P001, S002, N1, …
Route(R) BuildingID, RID, LineCode, name, …
B0001, R001, L0001, evacuation route, …
Spot(S) BuildingID, SID, PointCode, name, …
B0001, S001, P0008, enter, …
13
Object model
 Defines various movable objects in a building
 In the real world, there are various kind of objects (people and
vehicle) whose attributes may vary
 Abstract object only has type attribute and space attribute of
current position
 Define each concrete object as a sub-type of abstract object
Object
Long niu, Male
Chinese …
XXX corp. Xxx model
Family car 2012/10/04
…
14
Data schema in Object model
 Object
 Defines type and references a point code
 Sub-Types of Object
 Defines necessary attributes for the type of object
 The sub-type object and the abstract object have the
same object ID as a primary key
Object(O) ObjectID, Type, PointCode
O001, People, P0006
O002, Vehicle, P0009
People(P)
Sub-type relationship
ObjectID, name, sex, …
O001, Long Niu, male, …
Vehicle(V) ObjectID, Corp, Model, type, ProductionDay …
O002, XXX, Xxx, Family car, 2012/10/04, …
15
Outline







 Case study
 Discussion and limitation
 Conclusion
16
Case study
 Applying DM4InL to underground parking management
service
Building model
GP01
N1
S001
L0001
Location model
P0007
X
N1
S001
L0001
GP01
P0007
Y
17
Case study
 Applying DM4InL to underground parking management
service
Object model
P0006
P0009
P0010
P0011
P0012
P0013
P0014
Location model
X
P0009
vacant
N1
N2
P0012
P0014
N3
N4
P0006
GP01
S1
P0010
S2
P0011
S3
vacant
P0007
S4
P0013
Y
18
Discussion
 DM4InL can be applied in variety of InLAS
 Automated operation of home appliances (context-aware)
 Automatically turning on/off light and TV, when a user moves to other
room
 Route guide service
 Provide optional route to a spot in a museum
 DM4InL APIs
 We are currently developing the following API
 Location API
 Query for obtaining location information of a given spatial element
or object
 Attribute API
 Query for obtaining attributes with respect to an object or a spatial
element
19
Limitation
 Not yet consider the time concept in the model
 Not supposed to represent past or future locations
 Cannot to derive uncertainty of the location data, or to estimate
the future location of the object
 Representation of local space
 Defined each space as a pillar-shaped space
 In order to represent dynamic context, object model
should be defined further detail attributes
 Dynamic context includes current action of person, a status of a
device, shape or direction of vehicle, etc.
20
Conclusion
 We have proposed DM4InL
 A common data model and schema to represent indoor location
information
 Achieve loose coupling of InLAS and IPS
→improve the efficiency and reusability in the InLAS development
 Future work
 Evaluation of the data model with practical use cases of InLAS
 Design and implementation of the query API for DM4InL
 Extension of DM4InL
 Developing the IPQS
21