Vendor-specific hub APIs
Keep applications off proprietary hub contracts by putting an omlox-aligned API and policy layer in front of them.
Integration product
Open Location Hub
Open Location Hub is a cloud-capable hub of hubs for filtering and aggregating location data from on-premise omlox hubs. It gives business-facing applications one interoperable API layer for live locations, events, auth, and federation.
Common integration problems
Location deployments often end up with vendor-specific hub logic, custom APIs, and one-off middleware between devices, business systems, and applications. Open Location Hub gives teams one integration point they can deploy locally, in the cloud, or as a federated aggregation layer.
Repeated integration plumbing
Reuse auth, routing, connector, and event-exchange infrastructure instead of rebuilding it for each customer or site.
Mixed deployments
Connect existing on-premise hubs and multiple tracking technologies without forcing every site onto one stack.
The aggregation layer between local hubs and applications
Open Location Hub connects live location feeds, applies auth and policy, filters and aggregates hub data, and gives downstream applications one place to integrate.
Map-aware applications
Use one hub boundary for location-aware products, enterprise software, and operational workflows instead of wiring each system directly to local vendor infrastructure.
Shared policy boundary
Keep auth, permissions, RPC control, and event routing in one deployable component.
Cross-site aggregation
Move from on-premise installations to regional and global aggregation without replacing the integration model.
Connectors for existing deployments
Open Location Hub is not a rip-and-replace story. In real plants, terminals, warehouses, and production sites, teams usually need to connect on-premise hubs that already exist and add a cleaner interoperability layer around them.
Existing hubs
Connect on-premise omlox hubs such as Corriva Hub, Deephub, and similar implementations that already handle local device or site-level location traffic.
Mixed technologies
Bring together RTLS, GNSS, barcode, QR, and related tracking flows so downstream systems do not depend on one narrow vendor contract.
Incremental migration
Filter, normalize, and route location data across vendors while preserving existing site investments and operational constraints.
Partner-friendly extensibility
Contributed connectors make compatibility visible and cut one-off integration work for solution providers.
Companion CLI for omlox-compatible hubs
`olh` is the Open Location Hub CLI. It is designed to work with any omlox 2.0-compatible hub implementation, so teams can script setup, validate APIs, inspect streams, and run operational checks without building custom tooling first.
Install with Homebrew
Install `olh` from `jillesvangurp/tap/open-location-hub-cli` and use Bash or Zsh completions for repeatable local workflows.
Operate hub resources
Create, list, update, summarize, and delete zones, trackables, providers, and fences from the command line.
Ingest and inspect locations
Post locations and proximities, inspect transient state, and stream location, motion, fence, and collision events as NDJSON.
Use hub auth
Resolve credentials from flags, environment variables, or `~/.openlocationhub.env`, and fetch OAuth tokens automatically when settings are present.
Exercise the control plane
Discover and invoke JSON-RPC methods such as hub diagnostics and command-routing calls.
Automate compatibility checks
Use JSON output and scripted commands to test omlox-compatible hub behavior across local, on-premise, and cloud environments.
The semantic layer turns map data into addresses
Many workplaces already organize locations as hierarchies such as site, hall, aisle, area, line, or station. Outdoor operations do the same with countries, regions, cities, campuses, yards, and administrative zones. IMDF can capture those relationships in the map itself, so existing location structures become geocodable addresses.
Manufacturing and warehouse layouts
A position can be understood as Plant 3, Hall B, Aisle 12, Zone 4 instead of just a coordinate. That matches how operators, supervisors, and ERP or MMS users already talk about the site.
ERP and MMS master data
Many enterprise systems already store workspace hierarchies for assets, work centers, storage areas, and production zones. Putting the same hierarchy into the map creates a direct bridge between business data and location-aware applications.
Outdoor sites and public spaces
The same pattern works outside. Administrative hierarchies such as country, city, district, campus, yard, and gate help people find places and understand where events happened.
Geocoding for operational maps
When IMDF stores these parent-child relationships, applications can geocode them. That means people can search, route, and report against familiar addresses instead of raw coordinates or custom lookup tables.
What it includes today
The current repository already covers the hub contract, core runtime, protocol surfaces, and operational building blocks needed for serious implementation work.
Normative hub contract
An OpenAPI contract for resource management, ingest, and standard hub behavior.
Go server runtime
A Go server with strict handler interfaces and a low operational footprint.
Operational dependencies
Local runtime support for Postgres, Valkey, Mosquitto, and the application itself.
Authentication modes
JWT bearer auth with `oidc`, `static`, and `hybrid` verification modes.
Authorization building blocks
RBAC, ownership-aware authorization, route-level permissions, and WebSocket topic permissions.
Shared ingest and fan-out
Shared paths across REST, WebSocket, and MQTT plus an OMLOX RPC control plane.
Protocol and control plane
Real deployments rarely have one integration style. Open Location Hub is designed so CRUD APIs, streaming updates, local MQTT integration, and controlled command execution can live behind one hub boundary.
REST
Use standard APIs for ingest, resource management, and hub-facing application integration.
WebSocket
Support subscriptions, event fan-out, and the OMLOX wrapper protocol for live flows.
MQTT
Handle local device, adapter, and site-level telemetry patterns without pushing every consumer down to device-facing protocols.
OMLOX RPC
Use the hub as the control-plane front door for diagnostics and command routing such as `com.omlox.ping`, `com.omlox.identify`, and `com.omlox.core.xcmd`.
Federated by design
Open Location Hub is designed for deployment topologies where on-premise omlox hubs feed regional cloud hubs, and regional hubs feed a business-facing global aggregation layer.
Fit different site realities
Support countries, business units, and sites that use different location technologies, local integrators, and on-premise or cloud infrastructure.
Scale without flattening everything
Filter and aggregate across sites, tenants, regions, and jurisdictions while still respecting local operational constraints.
Stay practical for smaller installs
The same model can start at one local deployment and grow into a wider federated architecture over time.
Evaluate Open Location Hub
Start with the docs and API reference, then inspect the repository if you need to validate the architecture, auth model, or connector direction.