Discovering Indoor Environments and Positioning Systems

Maxim Van de Wynckel

Web & Information Systems Engineering Lab
Vrije Universiteit Brussel

About me

Maxim Van de Wynckel
E-mail[email protected]
Websitehttps://maximvdw.be
PositionResearcher at Vrije Universiteit Brussel
InterestsIndoor positioning systems, linked data, and interoperability of positioning systems

Current state of geospatial data

Outdoor data

Indoor data

Current state of geospatial data

Outdoor data

Indoor data

However, when it comes to indoor data, the situation is quite different. While there are services that collect or crowdsource geospatial data of indoor environments, they are not yet as complete as their outdoor counterparts. Furthermore, the collection of indoor environments is very scattered among different services. In a way, this makes sense, since indoor environments are more complex and diverse than outdoor environments. Users or building owners may not want to share their data with the public, which makes it harder to collect and share indoor geospatial data and to govern who publishes this data. But there are also some other reasons to consider, and one of those reasons is that there are a lot of standardisations to represent buildings or indoor environments in general. This makes it hard to create a service that can provide you with indoor data in the same way that you might expect.

Current state of positioning systems

Outdoor

Indoor

A similar story can be told about positioning systems. Outdoor positioning systems are well known and widely used. The Global Positioning System (GPS) is a prime example of this. If we are outdoors, we can easily determine our location using this single technology. That is not to say that there are no other technologies that can be used to determine your location outdoors, but GPS is by far the most widely used and standardised technology. Again, indoors the situation is quite different. There are several technologies that can be used to determine your location indoors, but none of them are as widely used or standardised as GPS. This makes it hard for developers to create applications that work indoors as well as outdoors and often leads to navigation applications that only work for one particular building, framework or event. Additionally, these positioning techniques often require knowledge about the building layout and infrastructure, which again leads to the original problem that this information is scattered among services.

Current state of positioning systems ...

Global and Local Geospatial Data Discovery

Global Discovery

Find data globally about a particular location

Local Discovery

Find data locally at a particular location

In general, we have to types of data or service discovery. We can have global discovery methods such as geocoding services that allow you to find information about a particular location without being at that location. It is by far one of the most common ways to discover data about a location and is used in many applications that require information about a given location. This type of discovery works when you are near a location, but it is not one of the requirements for this type of discovery. The second type of data discovery is also the most important type of data discovery for indoor environments. Local data discovery is about finding data at a location. With this type of discovery we assume we are near the location that provides the data pertaining to that location.

Geospatial-centric data discovery

Discovery of geospatial data through the very locations it represents, rather than predefined services.

Geospatial-centric data discovery ...

Challenge 1

How to discover data without relying on a discovery service?

Geospatial-centric data discovery ...

Challenge 2

How to understand the discovered data?

Geospatial-centric data discovery ...

Challenge 2

How to understand the discovered data?

Geospatial-centric data discovery ...

For more information, visit the FOSDEM 2022 talk of OpenHPS.

The first project I briefly wanted to introduce is OpenHPS. OpenHPS is an open source framework for hybrid positioning systems. I will not delve into the details, since it was already covered at a previous FOSDEM talk - but in general you should know that it is a TypeScript framework to develop positioning systems. It is low level, which means that you have a lot of freedom to design your own algorithms, but it also means it is not as easy to use as frameworks that provide you with a bunch of pre-made algorithms and even applications to create an indoor positioning system. The reason why I mention OpenHPS is because it is the foundation of the other projects I will introduce to you today. One issue we noticed after its development was that it was hard to share data between different positioning systems or different frameworks. This is where POSO comes in.

@openhps/rdf

RDF data model for OpenHPS
POSO integration
Serialisation and deserialisation

const position = new GeographicalPosition();
console.log(RDFSerializer.serialize(position));

@openhps/dht

@openhps/solid

Solid storage and access control
Solid as a communication broker

With the @openhps/rdf package we already had a way to store our data in a linked data format. However, if we talk about personal data or data that needs to be governed by a user, we also need a proper way to store this data. This is where the Solid project comes into place. For those who are unfamiliar with Solid, it is a project that allows users to store their data in a decentralised way. The data can be binary data, but also structured linked data. Users can assign access rights to the data so that only certain applications or users can access it. In addition to this, Solid offers specifications that enable applications to listen for changes in data - which is perfect for realtime applications such as positioning systems that want to use Solid as a communication broker.

dbr:Some_Unversity a ssn:Deployment .
<deployment/building_a> a poso:IndoorDeployment, geosparql:Feature ;
  rdfs:label "Building A"@en ;
  geosparql:hasGeometry [ 
      a geosparql:Geometry ;
      geosparql:asWKT "..."^^geosparql:wktLiteral ] .
  
<system/OPS> a poso:LocationBasedService ;
  rdfs:label "Outdoor campus positioning"@en ;
  ssn:hasSubSystem posoc:GPS ;
  ssn:hasDeployment dbr:Some_University .
<system/IPS> a poso:IndoorPositioningSystem ;
  rdfs:label "Indoor campus positioning"@en ;
  ssn:hasDeployment <deployment/building_a> ;
  ssn:implements posoc:KNNFingerprinting .
<system/CampusPositioning> a poso:IntegratedPositioningSystem ;
  rdfs:label "Hybrid campus positioning system"@en ;
  ssn:hasSubSystem  <system/OPS>, <system/IPS> ;
  ssn:implements posoc:WeightedAccuracyFusion .

dbr:Some_Unversity a ssn:Deployment .
<deployment/building_a> a poso:IndoorDeployment, geosparql:Feature ;
  rdfs:label "Building A"@en ;
  geosparql:hasGeometry [ 
      a geosparql:Geometry ;
      geosparql:asWKT "..."^^geosparql:wktLiteral ] .
  
<system/OPS> a poso:LocationBasedService ;
  rdfs:label "Outdoor campus positioning"@en ;
  ssn:hasSubSystem posoc:GPS ;
  ssn:hasDeployment dbr:Some_University .
<system/IPS> a poso:IndoorPositioningSystem ;
  rdfs:label "Indoor campus positioning"@en ;
  ssn:hasDeployment <deployment/building_a> ;
  ssn:implements posoc:KNNFingerprinting .
<system/CampusPositioning> a poso:IntegratedPositioningSystem ;
  rdfs:label "Hybrid campus positioning system"@en ;
  ssn:hasSubSystem  <system/OPS>, <system/IPS> ;
  ssn:implements posoc:WeightedAccuracyFusion .

The basic principle of our semantic beacon solution called SemBeacon is a Bluetooth Low Energy beacon that advertises two identifiers and a set of flags. Compatible applications that have no information about this beacon or the data it contains can then ask to retrieve an additional URI that redirects to linked data on the Web containing more information about the beacon, its position and more importantly also its environment. In our semantic data we can make use of existing and extended vocabularies such as the POSO ontology, GeoSPARQL, sensors and observations ontology. By using these existing vocabularies, SemBeacon becomes merely a communication protocol to make nearby devices aware of the data, and what they can expect when they visit the URI.

SemBeacon Namespace and Instance

SemBeacon Bluetooth Specification

BLE 4.X

AltBeacon + Eddystone-URL + Flags

BLE 5.X

No scan response

Our main solution in general consists of an AltBeacon advertisement with a namespace and instance identifier, a set of flags which we will discuss in a moment and an Eddystone-URL compatible scan response. It is the combination of the advertisement data along with the eddystone-url scan response that makes up SemBeacon. Similar to Eddystone-URL we perform encoding of the short URI without further extensions in order to prevent backwards compatibility with existing libraries that can scan for Eddstone. In addition to our backwards compatible BLE 4 advertisement we also have a work in progress BLE 5 advertisement specification. With the increased payload size for BLE 5 advertisements we can include both the namespace and instance identifiers and uri within a single advertisement. As we no longer have to ensure Eddystone-URL compatibility, we also extended the encoding for the the URI to enable a smaller payload for common linked data URIs, versioning, and a larger URI in general which could negate the need for URL shorteners. BLE 5 advertisements offer better range compared to legacy BLE 4 advertisements which is useful for positioning. Our arduino library already offers the capabilities to use this new service on newer BLE 5 compatible ESP32 hardware for both scanning and advertising. However, our mobile application currently does not scan for BLE 5 advertisements yet.

SemBeacon Bluetooth Specification

Flags

Bit (MSB)	Description	Example
0	Indicates if the beacon has a position.	0 = Unsure, 1 = Yes
1	Indicates if the beacon requires authentication.	0 = Public, 1 = Private
2	Indicates if the beacon is attached to a moving object.	0 = No, 1 = Yes
3	Indicates if the beacon has a positioning system.	0 = No, 1 = Yes
4	Indicates if the beacon has observable data.	0 = No, 1 = Yes
5	Indicates if the beacon provides actuable properties.	0 = No, 1 = Yes
6 - 7	Reserved for future use.

SemBeacon Bluetooth Specification

Flags ...

Bit	Axiom
0	`poso:hasPosition` min 1 `poso:AbsolutePosition`
1	N.a.
2	N.a.
3	`poso:inDeployment` min 1 `ssn:Deployment`
4	`ssn:hasProperty` min 1 `sosa:ObserableProperty`
5	`ssn:hasProperty` min 1 `sosa:ActuatableProperty`
6 - 7	Reserved for future use.

SemBeacon Mobile Application

Scans and Simulates SemBeacon, iBeacon, AltBeacon and Eddystone
Extracts and visualises SemBeacon encoded information

SemBeacon Mobile Application ...

... authentication and authorisation to Solid Pods
Enable access control to environment data

SemBeacon Example

:pl9_3 a ssn:Deployment, sosa:FeatureOfInterest, ogc:SpatialObject, schema:Accommodation, seas:Floor;
    rdfs:label "PL9.3"; ogc:sfWithin :pl9;
    schema:hasMap [ a schema:Map;
        schema:mapType "floorPlan";
        schema:image "https://static.observableusercontent.com/files/69f63f0ed4e82a459af0534c2a71756ef75b16a15df7228d96b7560b59e19bfbb0dc8d3753376271183028739c9f5be817bd5bcc4889cdec739eb297ea6afedf?response-content-disposition=attachment%3Bfilename*%3DUTF-8%27%27floorplan_medium%25401.png"; 
        schema:spatialCoverage [ a schema:Place;
            ogc:hasGeometry [ a ogc:Geometry;
                ogc:asWKT "POLYGON Z((4.392680949135989 50.820560314350246 91.99999999906868, 4.392518989118047 50.82049119550264 91.99999999906868, 4.39243849045628 50.82056647750913 92.00000000093132, 4.392322771133238 50.82051709238308 91.99999999906868, 4.3924032699815685 50.82044181037657 91.99999999906868, 4.392241310785677 50.82037269114458 92, 4.391888059447844 50.82070304624146 91.99999999906868, 4.3920500197895525 50.82077216547346 91.99999999813735, 4.392179670282718 50.820650918644354 91.99999999813735, 4.392295389937405 50.820700303770394 92.00000000093132, 4.392165739744715 50.8208215505995 91.99999999906868, 4.3923277009084885 50.82089066944712 91.99999999906868, 4.392680949135989 50.820560314350246 94.99999999906868, 4.392518989118048 50.82049119550264 94.99999999906868, 4.392438490456279 50.82056647750913 95.00000000093132, 4.392322771133238 50.82051709238309 95, 4.392403269981569 50.82044181037658 95.00000000093132, 4.392241310785677 50.82037269114457 94.99999999906868, 4.391888059447844 50.82070304624145 95, 4.392050019789552 50.82077216547345 94.99999999813735, 4.392179670282718 50.82065091864436 94.99999999813735, 4.392295389937405 50.82070030377039 95.00000000093132, 4.392165739744715 50.82082155059949 94.99999999813735, 4.3923277009084885 50.82089066944712 94.99999999906868, 4.392680949135989 50.820560314350246 91.99999999906868))"^^ogc:wktLiteral;
                ogc:coordinateDimension 3; ogc:spatialDimension 3;
                ogc:dimension 3 ];
        ]
    ] ;
    schema:floorLevel "3";
    ogc:hasGeometry [ a ogc:Geometry;
        ogc:asWKT "POLYGON Z((4.392680949135989 50.820560314350246 91.99999999906868, 4.392518989118047 50.82049119550264 91.99999999906868, 4.39243849045628 50.82056647750913 92.00000000093132, 4.392322771133238 50.82051709238308 91.99999999906868, 4.3924032699815685 50.82044181037657 91.99999999906868, 4.392241310785677 50.82037269114458 92, 4.391888059447844 50.82070304624146 91.99999999906868, 4.3920500197895525 50.82077216547346 91.99999999813735, 4.392179670282718 50.820650918644354 91.99999999813735, 4.392295389937405 50.820700303770394 92.00000000093132, 4.392165739744715 50.8208215505995 91.99999999906868, 4.3923277009084885 50.82089066944712 91.99999999906868, 4.392680949135989 50.820560314350246 94.99999999906868, 4.392518989118048 50.82049119550264 94.99999999906868, 4.392438490456279 50.82056647750913 95.00000000093132, 4.392322771133238 50.82051709238309 95, 4.392403269981569 50.82044181037658 95.00000000093132, 4.392241310785677 50.82037269114457 94.99999999906868, 4.391888059447844 50.82070304624145 95, 4.392050019789552 50.82077216547345 94.99999999813735, 4.392179670282718 50.82065091864436 94.99999999813735, 4.392295389937405 50.82070030377039 95.00000000093132, 4.392165739744715 50.82082155059949 94.99999999813735, 4.3923277009084885 50.82089066944712 94.99999999906868, 4.392680949135989 50.820560314350246 91.99999999906868))"^^ogc:wktLiteral;
        ogc:coordinateDimension 3; ogc:spatialDimension 3;
        ogc:dimension 3 ];
    sembeacon:namespaceId "77f340dbac0d20e8aa3af656a29f236c"^^xsd:hexBinary.

Contributing & Roadmap POSO ontology

Use cases for the POSO ontology usage https://github.com/OpenHPS/POSO/issues
Examples of POSO to describe positioning systems
Feedback on the current ontology design (1.1)
OpenHPS geospatial mapping to RDF
https://github.com/OpenHPS/openhps-rdf/tree/master/src/mapping/geospatial

Contributing & Roadmap SemBeacon

Mobile application
https://github.com/SemBeacon/app
1.1. Examples/implementations of unsupported indoor environment descriptions
1.2. iOS support (partially implemented)
Arduino library (ESP32_SemBeacon)
https://github.com/SemBeacon/arduino-esp32
2.1. No retrieval of (important) data
nRF5x library (WiP)
Specification improvements
https://github.com/SemBeacon/specification