CS27b 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 The Cricket Indoor Location System Location based 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 N2N1N4N3 S3S1S4S2 using vacant Your car`s position Entrance Exit 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 Infrared Using 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 of InLAS development Scope of this research Designing data model in IPQS DM4InL: Data Model for Indoor Location 6 IPS1IPS2IPS3 InLAS1InLAS2InLAS3 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 3 rd Park} {name=Shanghai 3 rd 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.=38 Long.=134 make=honda owner=niu time=now lat=35 lon=135 name=niu age=26 time= Space Theme Time Object Model Location Model Building Model Object Model

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 Location Model Building Model Object Model DM4InL Location model Building model Object model

global position Lat.: Long.: Altitude: 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 Line Polygon 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, Altitude GP01, , , 54.3 Local Line (LLN) BuildingID, LLNID, (LineCode) B0001-LLN01, (L0001) LLNP LPGP Local Space (LSP) BuildingID, LSID, (SpaceCode), PolygonCode, Height B0001-LS01, (S001), PG0001, 4.00 BuildingID, LPID, (PointCode), x-offset, y-offset, z-offset B0001-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 3 rd 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, Male Chinese … XXX corp. Xxx model Family 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, PointCode O001, People, P0006 O002, 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 S001L0001P0007GP01 X Y S001 L0001 N1

N2N3N4 S1S2S3S4 P0007 Case study Applying DM4InL to underground parking management service 18 Location model Object model P0006P0009P0010P0011P0012P0013P0014 GP01 X Y P0006 P0009 P0010P0011 P0012 P0013 P0014 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