Vendor-specific hub APIs
Keep applications off proprietary hub contracts by putting a stable API and policy layer in front of them.
Integration product
Open Location Hub
Open Location Hub is an OpenAPI-first hub for location updates and event exchange. It gives vendors, integrators, and enterprise teams a deployable base for auth, connectors, federated topologies, and interoperable APIs.
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 and control themselves.
Repeated integration plumbing
Reuse auth, routing, connector, and event-exchange infrastructure instead of rebuilding it for each customer or site.
Mixed deployments
Connect existing hubs and multiple tracking technologies without forcing every site onto one stack.
The integration layer between maps, devices, and applications
Open Location Hub connects live location feeds, applies auth and policy, exposes interoperable APIs, 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 vendor infrastructure.
Shared policy boundary
Keep auth, permissions, RPC control, and event routing in one deployable component.
Cross-site aggregation
Move from local 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 what already exists and add a cleaner interoperability layer around it.
Existing hubs
Connect on-premise or cloud hubs such as Corriva Hub, Deephub, and similar systems 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
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.
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
The federation work in the repository is aimed at deployment topologies such as plant hubs feeding regional cloud hubs, or regional hubs feeding a 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
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.