agile2014 fhc25 using open street maps data and tools for indoor mapping in a smart city scenario

Using Open Street Maps data and tools for indoor mapping in a Smart City

scenarioAngel Ramos

Javier FernándezÁlvaro Arranz

Guillermo Amat

About FHC25

• FHC25 is the research company of Zed• Zed is a digital marketing/entertainment leader • U-TAD is Zed’s University and is focused on digital business, engineering, art and design

About Percepción project

This work was performed under the scope of Percepción project. We wanted to research fields such as augmented reality, speech recognition, indoor location and computer vision.

OSM was not a target at the beginning

1.- INIT Group University Jaume I of Castellón. Specialized in geographicinformation systems, biometrics, human behavior…

2.- Pattern Recognition and Human Language Technology Group from thePolytechnic University of Valencia. Specialized in human language recognition.

Indoor Location Biometrics Human Language Augmented Reality

The prototype

Smart Campus is a smart city prototype deployed in a smaller space, a university campus. The system offers information services to students, teachers and university staff adapted to new technologies and mobile devices.

Despite being developed as a Percepción testing scenario, the solution is exportable to any type of venue and even entire cities.

U-TAD’s main building is our smart city prototype

Why Open Street Maps?

• Crowsourced data / Community• Availability of additional software components• Data Flexibility• GIS tools: JOSM• Open Data Commons Open Database License (ODbL)

Why not?

"The unstoppable advance of OpenStreetMap", Richard Fairhurst: Good enough and OpenStreetMap: https://www.youtube.com/watch?v=Geq-bCD3zN8

http://opendatacommons.org/licenses/odbl/

Creation process

Indoor mapping WI-FI fingerprint acquisition

Creation of services

Mobile app adaptation

Building structure

and meta data

Wi-Fi signal acquisition, filtering and grouping

Information

regarding

locations,

navigation,

reservations…

Corporative

customization and

service binding

System architecture

1. Data Persistency (Mongo DB)- Provides storage for geographical information and also geospatial queries

2. Web Services + Security- The data layer is accessed by public REST web services and presented in JSON format. - Communications are encrypted using SSL certificates

3. Client (Android app)- Android native application which consumes the REST services ¡- OSM Maps are displayed using MapsForge

The solution has a common three layer architecture

Mapping steps

1. Create the indoor model and data(IndoorOSM draft proposed byGomar1985)

2. Design navigation paths (Nair Alves, Jorge Rocha)3. Add labels to help the speech recognition system 4. Points of interest

We used OSM data and JOSM as editor

Mapping the building – The model

Every room, corridor or facility has to be represented in the model.

1 - We only have the shell of the building

We download the building shell from OSM


Load a level image• We need an image of each level• Then we use PicLayer plugin in JOSM to draw everything

The image is loaded in a new JOSM layer


• Transform the image to match the building in OSM• After resizing and rotating we can draw over the image

PicLayer plugin allows to transform the picture

Mapping the building – Introducing

data

Roomsbuildingpart= roomname=*

Corridorsbuildingpart=corridor

Doorsdoor=yes

Buildingpart is used to differentiate spaces and

We have to tag everything in our model as explained in IndoorOSM draft: http://wiki.openstreetmap.org/wiki/IndoorOSM


dataStairs: buildingpart=verticalpassagebuildingpart:verticalpassage=stairsbuildingpart:verticalpassage:floorrange = x to ylevel= zname=*

Elevators:buildingpart=verticalpassagebuildingpart:verticalpassage=elevatorbuildingpart:verticalpassage:floorrange= x to y level= z name=*

Elevators and stairs are tagged in a similar way


dataLevels• Each level is mapped as a relation• This relation should include all corridors, rooms, etc. taking the role of a

building part.• An additional way is required to represent the outline of the level

We need one relation per level

We followed the previous work by Alves (Uma solução para navegação indoor)

• Use JOSM to build a graph representing the ways and possible destination or intermediate points.

• Then, this information was processed in order to be used with Open Trip Planner.

• New ways included in this step should be connected to the already existing outdoor roads.

• This configuration enables route calculation combining both outdoor and indoor spaces.

Navigation graph

Nair Isabel Braga Simões Alves, Uma Soluçao para navegaçao indoor : http://hdl.handle.net/1822/23407

16Navigation graph: corridors

• highway=footway• indoor=yes• level=z• name=*

When drawing a corridor: do not create loops!

Navigation graph: stairs

• highway=steps• indoor=yes• level=z• name=*• oneway=no

Stairs are segmented in different levels

Navigation graph: elevators

• highway=elevator• name=*

Elevator connections are represented as ways

Navigation graph: doors and

entrancesDoors:• door= yes• level= z• name=*• room=yes|class

Building entrances• door=yes• entrance=yes

Doors can be used as destination points

This project includes the implementation of a voice interface:• Used to invoke services through natural language. • The result could be a route or general information regarding the inquired site.

Mapping for human language recognition

Our ASR components (IATROS + Freeling) have some configuration requirements.

• These configuration files need to assign values to some entities, in our case: We need to define the name of the items Secondly we use categories to determine the speech context Then the ASR components needs identifier tags Finally there is an entity called states which are alternatives to item names

• The idea was to auto generate configuration files from the .osm one. • The problem was to identify the proper OSM tags matching all this


First we tried to find existing tags for every entity

In addition there is the need to support several languages


Tags will depend on the ASR component you chose

We use the standard tag name and some custom defined tags identified by a prefix (asr_ )

• For item names, we use name tag with its language domain: name:es = Biblioteca name:en = Library

• Categories are internal codes and don’t need translations: asr_category = SERV-FOOD

• ASR internal identifier tags asr_tags

• For the alternatives to item names we also use a language extension: asr_states:es= el baño;el aseo;el lavabo asr_states:en=the toilet;the lavatory; the water closed

Data conversion – Source data

JOSM Indoor data

.OSM file.OSM

file

OSM Servers

We have produced all the data we need using JOSM

All our data is in an .osm file

Data conversion

Indoor data

.OSM file.OSM

file

MongoDB

Geodata layers

OSM file is processed by some batch scripts, the data is converted to GeoJSON and stored in MongoDB

We need to convert .OMS files (XML) to JSON

Data storage – using MongoDB

Our goal has been to include all the produced information in a non relational data base: MongoDB, this allows a performance improvement when doing queries from mobile applications

Another feature that has affected on a decisive way in its choice for the project is that it is able to support geographic data and queries:

• Proximity queries, where documents are sorted by proximity (nearest to farthest) with reference to a geographical point. Results contain the distance

• Bounded queries, whose result is a set of documents that are inside of an area (a rectangle, circle or polygon).

Remember: is a non relational data base

Web services – REST + JSON

• The project is divided into some sets of services grouped by their functional domain.

• Each one is offered as a REST web service with their respective resources. • The data transport is done via HTTP and the representation is done in JSON

format.

REST + JSON is a good combination for smart phone applications

Web services – core services

1. A service to importing a map created in OSM which transforms a OSM file to GeoJSON.

2. A service for querying maps metadata. This service returns a set of data that client needs to draw the map (maximum longitude and latitude, minimum longitude and latitude, map checksum, etc.)

3. A search service that queries both features and map areas. It is possible to query different layers because points of interest and map are stored in different collections in MongoDB.

4. Services providing navigation routes. Departure and destination points are sent to the system and Open Trip Planner calculates the path.

5. Points of interest management.6. Services for speech recognition and dialogue management.

Core services are related to the data introduced in JOSM

Web services – additional services

The are unlimited possibilities:• Services for students, teachers, visitors…

Facilities reservation Classroom information Teachers availability …

• In a smart city• Public transport scheduling• Air pollution• …

• Shopping center• Office buildings• …

Any service available as open data can be included

Smartphone application

Firstly, the background map is rendered. This background has the information equivalent to the one that can be found in the OSM servers, i.e. the streets, building outlines and orographic information. For this task, the Mapsforge Android library is used.

Mapsforge is the responsible of displaying the map

An Android application is responsible for displaying all the visual information related to the indoor localization and navigation.


The second step consists of rendering an overlay over the background representing the indoor structure of the building. • Using the data we introduced in the model

containing ways, nodes and metatags.• The level relation helps to draw only the floor we

are. Also, a selector is built in the application for switching between different floors.

Polygons can be filled with different colors using buildingpart tag


Points of interest can be loaded using a layer selector. Then we can overlay:

• Restaurants• Shops• Transport facilities• Hotels• …

We can also show a route between to points combining indooor and outdoor departures and destinations

Conclusions

• IndoorOSM draft is good for the required indoor representation.• Routes can be calculated using Open Trip Planner after following Universidade do

Minho example• In this kind of systems, speech recognition can be supported using OSM tags• It is possible to create high quality mobile applications using OSM based

components• The experience using Open Street Maps data, standards and tools demonstrates an

easy and fast deployment of an indoor location solution with minimum cost.

OSM data and tools are good enough for building smart city project

Thank you!

Guillermo [email protected]