LocWeb2014@ShanghaiCS27b Lab. Kobe University Graduate School

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

Different characteristics of accuracy, resolution and cost of infrastructure deployment

No de-facto standard for IPS yet

3

IMES

The Cricket Indoor Location System

Locationbased services

Wi-Fi

JAXA: Japan Aerospace Exploration Agency

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

4

Image from http://ekimae.e-fukui.com/webapps/www/carpool/

N2N1 N4N3

S3S1 S4S2

using

vacant

Your car`s positionEntranceExit

N1, N2, S3 are vacant

Your car is parking at N1

Where is vacant Parking spot?

Where is my car?

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

5

InLAS

IPS1 IPS2

InLAS

Underground parking

management service

Using InfraredUsing Wi-Fi

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

Improve efficiency and reusability ofInLAS development

Scope of this research Designing data model in IPQS

DM4InL: Data Model for Indoor Location

6

IPS1 IPS2 IPS3

InLAS1 InLAS2 InLAS3

IPQS

Application-neutral APIs

Common Data Model

Outline Background Challenge Goal DM4InL

Location model Building model Object model

Case study Discussion and limitation Conclusion

7

Yuan pointed out that ”spatial object must have three attributes" [1]

Space attribute can be represented by following forms Geographic coordination

{lat.=38, long.=134} Relative coordination

{x=12m, y=35m, in=Shanghai 3rd Park}{name=Shanghai 3rd Park, lat.=38, long.=134}

Key idea for DM4InL

8[1] B. Li, G. Cai, A general object-oriented spatial temporal data model, J.ISPRS, XXXIV(4), 2002

Lat.=38Long.=134make=hondaowner=niutime=now

lat=35lon=135name=niuage=26time=2014-11-02

Space

Theme

Time

ObjectModel

LocationModel

BuildingModel

ObjectModel

Three models in DM4InL

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

Defines various objects e.g., people, vehicle and appliance

9

LocationModel

BuildingModel

ObjectModel

DM4InL

Location model

Building model

Object model

global position

Lat.: 34.72328Long.: 135.231454Altitude: 54.3

Location model

Defines indoor location information and geometric primitives Every indoor position is represented as relative coordinates (3D-

offset) 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.

10

X

Y

Z

Point

LinePolygon

space

Location model

Data schema in

Global position Including longitude, latitude and altitude

4 geometric primitives Point, line, polygon and space

11

Global Position (GPos) GPID. Longitude, Latitude, AltitudeGP01, 135.231454, 34.72328, 54.3

Local Line (LLN) BuildingID, LLNID, (LineCode)B0001-LLN01, (L0001)

LLNP

LPGP

Local Space (LSP) BuildingID, LSID, (SpaceCode), PolygonCode, HeightB0001-LS01, (S001), PG0001, 4.00

BuildingID, LPID, (PointCode) , x-offset, y-offset, z-offsetB0001-LP001, (P0001) , 5.50, 4.20, 1.00

Local Point (LP)

Local Polygon (LPG) BuildingID, LPGID, (PolygonCode)B0001-LPG01, (PG0001)

Location model

secondary key: external

entity can easily refer to it

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

12

GP01

Building model

X

Y

N1

Data schema in

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

13

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, …

BuildingID, GPID, name, type, …B0001, GP01, Shanghai 3rd Park, park, …

Building(B)

Building model

Parent-child

relatioship

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

14

Long niu, MaleChinese …

XXX corp. Xxx modelFamily car 2012/10/04…

Object

Data schema in

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

15

ObjectID, Type, PointCodeO001, People, P0006O002, Vehicle, P0009

ObjectID, Corp, Model, type, ProductionDay …O002, XXX, Xxx, Family car, 2012/10/04, …

ObjectID, name, sex, …O001, Long Niu, male, …

Vehicle(V)

People(P)

Object(O)

Object model

Sub-type relationship

Outline Background Challenge Goal DM4InL

Location model Building model Object model

Case study Discussion and limitation Conclusion

16

P0007

N1

Case study

Applying DM4InL to underground parking management service

17

Location model

Building model

S001 L0001 P0007GP01

GP01

X

Y

S001

L0001

N1

N1 N2 N3 N4

S1 S2 S3 S4

P0007

Case study

Applying DM4InL to underground parking management service

18

Location model

Object model

P0006 P0009 P0010 P0011 P0012 P0013 P0014

GP01

X

Y

P0006

P0009

P0010 P0011

P0012

P0013

P0014vacant

vacant

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