Open Location Stack

Indoor maps need to grow up

Mon, 27 Apr 2026 13:00:00 +0000

Most companies that use indoor maps still treat them as an afterthought. They’ll buy an expensive location system, for example based on ultra-wideband, and spend a lot of money installing the necessary infrastructure and dialing that in. But the maps that go with this system do not get much attention from a practical or aesthetic point of view. Most people base their maps on architectural drawings. The dominant aesthetic is that of a technical drawing. Quite often these come in bitmap form. You can see this clearly when zooming in. The edges get all pixelated and the text labels become blurry.

Open Location Hub 0.1.0 is out

Tue, 14 Apr 2026 08:06:00 +0000

Open Location Hub 0.1.0 is now published.

This is the first public release of Open Location Hub. Our goal with this release is to offer a full implementation of the current API surface and solicit feedback that helps define what the eventual 1.0 release should look like.

What is in 0.1.0

For the initial 0.1 scope, Open Location Hub now implements the full omlox API surface planned for this release.

Benchmarking Open Location Hub with OpenSky and replayed traffic

Wed, 08 Apr 2026 08:00:00 +0000

We wanted a benchmark built from real traffic, easy to rerun locally, and good at showing where Open Location Hub starts to drop work.

Intro: OpenSky and the benchmark input

OpenSky Network publishes live aircraft state data from a community-operated sensor network. For this benchmark we used the Germany preset, captured about five minutes of traffic, and stored the raw location_updates stream as NDJSON.

The input is both realistic and repeatable. We start from a real capture and replay the same file against the hub whenever we change the runtime.

Easter Update: soft launch, public repositories, and rapid hub progress

Thu, 02 Apr 2026 07:00:00 +0000

Open Location Stack has moved from a private build effort to something partners can inspect, test, and challenge directly.

At LogiMAT in Stuttgart, we soft-launched the Open Location Stack website. The goal was simple: show the work to RTLS partners early, while the architecture is already credible and still open to feedback.

At the same time, we made our first two GitHub repositories public:

Open Location Hub on GitHub, which is the integration backbone of the stack and the first component we expect many partners to evaluate seriously.
Floor Plan Editor on GitHub, which gives the stack an open indoor mapping foundation for creating and maintaining structured venue data.

That order matters. For many teams, the hub is where the value becomes concrete. It can sit between existing RTLS deployments, normalize location flows, and open a path toward mixed-vendor interoperability without forcing a rip-and-replace project.

API Reference

Mon, 01 Jan 0001 00:00:00 +0000

Architecture

Mon, 01 Jan 0001 00:00:00 +0000

This page is generated from the Open Location Hub source documentation and should not be edited in the website repository.

Layers

cmd/hub: process bootstrap and wiring
internal/config: environment-driven configuration
internal/httpapi: API surface and handlers
internal/ws: OMLOX WebSocket wrapper protocol, subscriptions, and fan-out
internal/storage/postgres: durable store
internal/mqtt: MQTT topic mapping and broker integration
internal/auth: token verification middleware
internal/rpc: local-method dispatch, MQTT RPC bridging, announcements, and aggregation
internal/hub: shared CRUD, ingest, derived event generation, collision evaluation, and internal event bus emission

Metadata And Hot State

Postgres is the durable source of truth for hub metadata, zones, fences, trackables, and location providers.
The runtime resolves the singleton hub metadata row before the service starts so one stable hub_id and label are available for startup validation, internal event provenance, and identify responses.
The hub loads those resources into an immutable in-memory metadata snapshot before it accepts traffic.
Successful CRUD writes update Postgres first, then update the in-memory snapshot, invalidate any affected derived metadata such as zone transforms, and emit a metadata_changes bus event.
A background reconcile loop reloads durable metadata periodically and emits the same metadata_changes notifications when it detects out-of-band create, update, or delete drift.
Decision-critical ingest state is kept in process memory:
- dedup windows
- latest provider-source locations
- latest trackable locations and active motion state used for collision work
- optional per-trackable Kalman filter state and retained samples
- proximity hysteresis state
- fence membership state
- collision pair state

Event Fan-Out

REST, MQTT, or WebSocket ingest enters the shared hub service.
The hub validates, normalizes, deduplicates, and updates in-memory transient state on the ingest path.
A buffered native-publication stage emits native location and motion events without blocking ingest on downstream fan-out.
A second buffered decision stage applies optional per-trackable Kalman filtering before alternate-CRS publication, geofence evaluation, and collision preparation.
Decision work is sharded by provider/source so one hot stream does not serialize the entire derived path, while updates for the same stream stay ordered on the same worker.
The sharded decision workers drain queued locations in bounded batches before processing them so bursty ingest spends less time on per-item queue churn.
When Kalman publication throttling is enabled, the decision stage may suppress some derived location and trackable-motion events while still running geofence and collision work on every accepted normalized point.
Collision evaluation runs as its own downstream stage fed from the decision output so pairwise collision work does not block the rest of the derived path.
Collision work prefers normalized WGS84 motions when the derived transform exists; otherwise it falls back to normalized local motions for local-only streams so indoor UWB-style zones still produce collision events.
MQTT and WebSocket consume the resulting internal event stream and publish transport-specific payloads in batches.
When any non-critical queue fills, the hub drops newer work on that path rather than backpressuring raw ingest.

Implications:

Authentication and Authorization

Mon, 01 Jan 0001 00:00:00 +0000

This page is generated from the Open Location Hub source documentation and should not be edited in the website repository.

This project supports standards-based JWT bearer authentication for the REST API and an authorization model built around JWT claims plus a server-side permissions file.

The same token verifier is also used for the OMLOX WebSocket surface, but WebSocket authentication happens per message through params.token instead of the HTTP Authorization header.

Configuration

Mon, 01 Jan 0001 00:00:00 +0000

This page is generated from the Open Location Hub source documentation and should not be edited in the website repository.

All runtime configuration is environment-driven.

Runtime lifecycle behavior:

the hub process runs from a single signal-aware root context created from SIGINT and SIGTERM
startup failures return structured process errors instead of panicking during early config or logger initialization
graceful shutdown uses a bounded timeout so HTTP shutdown and internal event-publisher fan-out can complete deterministically after a stop signal

Core

HTTP_LISTEN_ADDR (default :8080)
HTTP_REQUEST_BODY_LIMIT_BYTES (default 4194304)
LOG_LEVEL (default info)
HUB_ID (optional UUID bootstrap or reset value for the persisted hub identity)
HUB_LABEL (optional bootstrap or reset value for the persisted human-readable hub label)
RESET_HUB_ID (true/false, default false; when true, overwrite stored hub metadata with explicitly supplied env values)
POSTGRES_URL (default postgres://postgres:postgres@localhost:5432/openrtls?sslmode=disable)
MQTT_BROKER_URL (default tcp://localhost:1883)
WEBSOCKET_WRITE_TIMEOUT (duration, default 5s)
WEBSOCKET_READ_TIMEOUT (duration, default 1m)
WEBSOCKET_PING_INTERVAL (duration, default 30s)
WEBSOCKET_OUTBOUND_BUFFER (default 256)
EVENT_BUS_SUBSCRIBER_BUFFER (default 1024)
NATIVE_LOCATION_BUFFER (default 2048)
DERIVED_LOCATION_BUFFER (default 1024)

Hub metadata bootstrap behavior:

Connector Guide: MQTT

Mon, 01 Jan 0001 00:00:00 +0000

This page is generated from the Open Location Hub source documentation and should not be edited in the website repository.

Use MQTT when your deployment already centers on a broker, when trusted edge adapters naturally publish broker messages, or when broker-based routing fits better than a long-lived WebSocket client connection.

This repository ships a concrete MQTT connector example in connectors/gtfs/README.md. The MQTT connector path is documented here against the hub’s implemented OMLOX MQTT surface. Transport details live in specifications/omlox/mqtt.md.

Connector Guide: WebSocket

Mon, 01 Jan 0001 00:00:00 +0000

This page is generated from the Open Location Hub source documentation and should not be edited in the website repository.

Use WebSocket when you want the simplest connector path into the hub. It maps well to the current bundled demos, it works cleanly with the hub’s auth model, and it does not require you to design topic routing beyond the OMLOX WebSocket topic names.

The bundled connector demonstrators in this repository currently use this approach:

Connectors

Mon, 01 Jan 0001 00:00:00 +0000

This page is generated from the Open Location Hub source documentation and should not be edited in the website repository.

This repository keeps connectors outside the hub runtime. A connector is a small process that reads data from some upstream system, maps that data to the hub’s OMLOX-facing model, and submits it through the hub’s supported transport surfaces.

The key point is simple: creating a connector is easy. You do not need to patch the hub. In most cases you only need:

FAQ

Mon, 01 Jan 0001 00:00:00 +0000

What license will Open Location Stack use?

Everything is released under the MIT License.

That gives hardware vendors, software vendors, and integrators room to adopt, extend, and embed the software without negotiating around restrictive licensing terms.

Why is FORMATION doing this?

After years of delivery work with RTLS partners, we kept seeing the same pattern: each company rebuilt its own hub adapters, middleware, map tooling, and integration glue.

FORMATION deals with that fragmentation directly in customer projects. Different vendor stacks, different APIs, and different map formats create avoidable integration cost. Open Location Stack is our response: build the shared parts in the open so teams can spend more time on the parts that actually differentiate their product.

Floor Plan Editor

Mon, 01 Jan 0001 00:00:00 +0000

Getting Started

Mon, 01 Jan 0001 00:00:00 +0000

This page is generated from the Open Location Hub source documentation and should not be edited in the website repository.

If you want to try Open RTLS Hub on your laptop, this repository includes two ready-made local runtime paths:

a basic compose stack from docker-compose.yml with the hub, Postgres, Mosquitto, and Dex
a local demo stack with observability in local-hub/ with the hub, Postgres, Mosquitto, Dex, SigNoz, ClickHouse, and the OpenTelemetry collector

Use the basic stack if you want the shortest path to a working hub runtime. Use the local demo stack if you also want observability while you experiment.

Imprint

Mon, 01 Jan 0001 00:00:00 +0000

FORMATION GmbH
Workplace Technologies
company data according to § 5 TMG

Urbanstraße 71
10967 Berlin
Germany

Email: open-rtls@tryformation.com
Web: tryformation.com

Entry in the Commercial Register: Berlin
Registration Court: Amtsgericht Charlottenburg (Berlin)
Registration Number: HRB 218133

Executive Manager: Ian Hannigan

USt.-ID (VAT ID): DE332537362

Parties responsible for content according to § 55 Abs. 2 RStV: Ian Hannigan

Note: Despite careful measures to control content at the point a link is added to our website, we assume no liability for the content of external links. The content for linked pages are the sole responsibility of their operators.

Privacy

Mon, 01 Jan 0001 00:00:00 +0000

Privacy notice for openlocationstack.com

This website is operated by FORMATION GmbH, Urbanstraße 71, 10967 Berlin, Germany. You can reach us at open-rtls@tryformation.com.

We use a self-hosted analytics service for openlocationstack.com to understand how the site is used, improve content, and maintain the website. Analytics is only activated after you explicitly consent through the banner shown on the live site.

If you accept analytics, our website sends pseudonymous usage data to analytics.tryformation.com. This may include:

RPC Guide

Mon, 01 Jan 0001 00:00:00 +0000

This page is generated from the Open Location Hub source documentation and should not be edited in the website repository.

What RPC is

RPC is the hub’s command and diagnostics interface.

Use it when you need to ask the hub or a downstream RTLS device/controller to do something right now. Examples:

check whether the control path is alive
identify a reachable handler
send an OMLOX core command through the hub

Do not use RPC for normal CRUD resource management. Use:

Search

Mon, 01 Jan 0001 00:00:00 +0000

Open Location Stack

Indoor maps need to grow up

Open Location Hub 0.1.0 is out

What is in 0.1.0

Benchmarking Open Location Hub with OpenSky and replayed traffic

Intro: OpenSky and the benchmark input

Easter Update: soft launch, public repositories, and rapid hub progress

API Reference

Architecture

Layers

Metadata And Hot State

Event Fan-Out

Authentication and Authorization

Configuration

Core

Connector Guide: MQTT

Connector Guide: WebSocket

Connectors

FAQ

What license will Open Location Stack use?

Why is FORMATION doing this?

Floor Plan Editor

Getting Started

Imprint

Privacy

Privacy notice for openlocationstack.com

What we collect after consent

RPC Guide

What RPC is

Search