Status message

This proposal has been approved and the SpatialIndoor project has been created.


This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project: 

In Outdoor Location we have maps and understand the available sensor positioning technologies such as GPS, cell tower triangulation and drone imagery. In indoor location the concept of a map is typically an unmensurated image or a CAD file. Indoor Location is a relatively new domain for research and commercial usage.

There are several available sensors available for detecting an individuals location indoors where GPS positioning is not available. These include;

  • Image feeds
    • Detecting, recognizing and tracking individuals through object recognition
  • WiFi
    • Monitor Mode
  • Bluetooth
    • iBeacon / altbeacon
  • Ultrasound
    • measures the traveling time of sound

In the passive detection schemes the sensor can either provide a general proximity value or by using tri-lateration algorithms an approximation of the location of the detection event.

There is a lack of community data standards for both real time sensor and historical data. The aim of defining these formats is to aid interoperability between software solutions and sensing technologies. In addition reference software on commodity hardware would be useful in the adoption and understanding of Indoor Location as a commercial and research domain.


SpatialIndoor provides interoperability standards for and reference implementations of both real time sensor and historical data for tracking the location of a user moving in an indoor space.

  • Provides JSON standards for real time sensor event data, archived sensor event data, indoor site and floor maps;
  • Defines Indoor Coordinate Systems; and
  • Develops software to take input images and to create spatially referenced indoor maps in JSON format
Activities include, but are not limited to:
  • Develop a plugin for https://openwrt.org/ to ease use of WiFi sensing in monitoring mode when using open firmware;
  • Develop Bluetooth and WiFi location detection sensors with a budget board (e.g. Software to run on a Raspberry Pi); and
  • Collect and identify mac address patterns as a database to determine whether the user is using Apple, Blackberry or Android.

SpatialIndoor is a project for those developers and consumers who are interested in the spatial positioning of a user moving in an indoor environment using passive sensor technologies.

Why Here?: 

Open indoor geospatial software is crucial to widespread adoption and enabling many applications and services. The vendor neutrality of LocationTech and the engagement of people from industry/academia/government in the LocationTech ecosystem makes it the ideal place to host this project. The services LocationTech provides will help us build a community and encourage adoption.

Project Scheduling: 
  • Releases
    • Raspberry Pi WiFi Proximity Sensor software
    • Bluetooth Proximity Sensor software
    • Raster to Vector tool
    • Positioning plugin for open firmware WiFi software
  • Community
    • Sensor Event format description
    • Indoor Mapping format description
    • Open database of mac address patterns to determine the device a user is using
Future Work: 

Further development of the event and mapping formats. Additional sensing technologies.

Source Repository Type: 
Project Leads: 
Interested Parties: 

IBM Mobile First

Initial Contribution: 

The project has existing code for a Raspberry Pi WiFi proximity sensor.

The project also has a strawman proposal for extending GeoJSON with ellipses and circles and defining an indoor coordinate system.

jenny brown's picture

Now we can get the sims freeplay cheats online at http://www.cocgemsbox.com/ for the simoleons and lp.

Carl Reed's picture

Adding to Steve's and Ki-Joune's comments.

I have participated in related standards work in the IETF, JTC1 the OGC, BIM, and NENA. A driving use case is emergency response. This particular use case has an outdoor to indoor navigation requirement. Will that be considered? Further, as mentioned, existing indoor location/model/sensing related standards already have agreed to semantics and vocabularies. Will these be reviewed and incorporated into the work of the SpatialIndoor group?

Also, before coding any approach I would hope that the group defines models such as for floor maps. FYI, there is also already considerable work in that area. Having a model would allow implementation patterns beyond JSON.

From a modelling perspective, I would really encourage this group to look at InDoorGML, SensorThings, and OGC/ISO Observations and Measurements. 

Thanks for listening.

Ki-Joune Li's picture

It looks a great project proposal. Some comments about this project;

1. Standard for indoor spatial information: As mentioned by Steve, OGC published an international standard for indoor spatial modeling, called IndoorGML, which is an application schema of GML. It provides a standard framework for indoor spatial model. The official website of IndoorGML is found at http://www.opengeospatial.org/standards/indoorgml, where you can get a basic idea about it.I hope (and believe) that we may contribute many things for this projects from IndoorGML SWG.

2. Open source s/w for indoor space: Some open source softwares are being developed in Java to support IndoorGML such as IndoorGML editing tool, JOSM plugin for indoor space, 3D indoor spatial data server (an extension of GeoTools), etc.

3. GeoJSON for indoor map: even though IndoorGML is in GML, I believe that it can be converted to GeoJSON (and vice-versa) without any big problem. Of course GML has quite strong expressive power, some information could be lost during the conversion from IndoorGML to GeoJSON. We are planning to develop it in this year in Java.

4. CRS: I agree with Steve. Although local CRS may be used in many applications, absolute CRS like WGS84 seems better.



Steve Liang's picture

Re: "There is a lack of community data standards for both real time sensor and historical data."

In fact, Geospatial communities has data standards for both real-time sensors and historical data.  It's called Open Geospaital Consortium Sensor Web Enablement.  Examples are OGC/ISO 19156:2011 Observations and Measurements (O&M), OGC SensorThings API, SOS, SPS, SensorML, WaterML, etc. Open sources implementations are available as well (52North, GeoServer, istSOS, GeoCENS, etc.).  In my opinion, it's quite important to use these existing sensor web data standards rather than implementing a new one.

Can you please also clarify what do you mean by "sensor event" data?  Do you mean by Observations? or a generic Event (in the context of event processing framework?)?  There are existing definitions in the Sensor Web area.  To avoid confusion, it is desireable to use common standard definitions for sensor webs (e.g., Sensor, Actuator, Observation, Observed Property, Feature of Interest, etc.) They can be found from the two links above.


The latest IETF GeoJSON clearly indicated the Coordinate Reference System is WGS84. In many cases, indoor location information needs a local CRS. This direction might create issues and confusions.

Re: Indoor location model

There is an international standard called IndoorGML, provides a comprehensive data model/encoding for indoor information (http://indoorgml.net/).  There is a JOSM plugin that integrate Open Street Map and IndoorGML. Please use existing international standards rather than reinventing new ones.