restructure

Author: jillesvangurp

content/floor-plan-editor.md

@@ -2,70 +2,7 @@
 title: "Floor Plan Editor"
 description: "Browser-based indoor mapping editor for creating and maintaining floor plans and IMDF-ready venue data."
 draft: false
+layout: "product"
+product_key: "floor-plan-editor"
 github_url: "https://github.com/Open-Location-Stack/floorplan-editor"
 ---
-
-Floor Plan Editor is a browser-based map authoring tool for teams that need to create, adjust, and maintain indoor floor plans without building a custom editor from scratch.
-
-It is part of Open Location Stack's mapping work and focuses on the practical steps required to turn a venue into usable map data: place the building correctly, define floors, draw geometry, align floor plan images, and keep the project editable over time.
-
-## See it in action
-
-![Animated demo of creating a room polygon in the Floor Plan Editor](/images/floor-plan-editor-add-room.gif)
-
-*Draw rooms directly on the map canvas and build up floor geometry as structured vector data instead of painting on static bitmaps.*
-
-![Animated demo of hiding a bitmap floor plan overlay while keeping vector geometry editable](/images/floor-plan-editor-show-hide-bitmap.gif)
-
-*Use floor plan images as alignment aids, then hide them to inspect the actual editable map data underneath.*
-
-## Why it matters
-
-Most RTLS and indoor-location projects still treat map authoring as a side problem, which usually leads to ad hoc tooling, brittle import flows, and inconsistent map quality.
-
-Floor Plan Editor reduces that friction by giving teams a reusable tool for indoor map creation and maintenance. Instead of rebuilding a one-off editor for every deployment, teams can start with a tool that already covers the core editing workflow.
-
-Just as importantly, it shifts teams away from bitmap-first indoor mapping. Static image floor plans may be workable for small demos, but they do not scale well to industrial campuses, terminals, hospitals, and factories that span tens or hundreds of thousands of square meters. Vector map data stays crisp at every zoom level, is easier to validate and edit, and provides the structure needed for downstream applications instead of just a picture of a building.
-
-## What it does today
-
-- Interactive map editing on top of a live MapLibre-based map canvas.
-- Building and floor hierarchy with selection-aware editing panels.
-- Drawing and editing for points, lines, and polygons.
-- Adding and maintaining routable navigation paths for wayfinding-ready indoor maps.
-- Floor plan image overlays with corner-based alignment.
-- Local-first project storage in the browser with auto-save behavior.
-- Import and export workflows for GeoJSON and IMDF-oriented datasets.
-- Validation utilities to catch data issues earlier.
-- Address lookup and map recentering for faster setup.
-
-## Under the hood
-
-The current implementation is a React, Vite, and TypeScript application with a local-first browser architecture. Projects are stored in IndexedDB, map rendering is handled through MapLibre, and the editor includes IMDF-oriented import, export, and validation utilities so teams can move from raw floor plans toward cleaner interoperable venue data.
-
-IMDF matters here because it is more than a drawing format. It is a GeoJSON-based information model with a venue hierarchy for sites, buildings, levels, units, openings, amenities, and related features. That structure gives indoor maps both geometry and meaning, which downstream systems need for search, display, zoning, routing, and operations.
-
-The editor is also designed around navigable indoor space rather than static artwork. By supporting path creation as part of the authoring workflow, it helps teams build the navigation graph needed for wayfinding and point-to-point routing. Combined with vector geometry, that supports crisp rendering at any zoom level and applications that need to answer questions like how to get from one room, entrance, or work area to another.
-
-## Built for indoor mapping standards and tools
-
-If you are evaluating indoor mapping standards and downstream compatibility, these are useful starting points:
-
-- [OGC Indoor Mapping Data Format (IMDF)](https://www.ogc.org/standards/imdf/) for the open standardization path.
-- [Microsoft Places floorplans and IMDF guidance](https://learn.microsoft.com/en-us/microsoft-365/places/setting-up-maps-in-places) for one example of where structured indoor maps are already expected.
-- [Apple IMDF specification resources](https://register.apple.com/resources/imdf/) because Apple introduced IMDF and still publishes the core format material.
-- [Apple MapKit indoor map documentation](https://developer.apple.com/documentation/mapkit/displaying-an-indoor-map) for a concrete product-facing integration angle.
-
-## Product fit
-
-Floor Plan Editor gives Open Location Stack a practical authoring front end for indoor spatial data. It is where floor plans become structured map assets that downstream renderers, validators, hubs, and applications can use, including the [Open Location Hub](/open-location-hub/).
-
-For integrators, that means less time spent stitching together fragile map tooling. For product teams, it provides usable map data for workflows such as wayfinding, zoning, asset visualization, and operations.
-
-## Get involved
-
-Try it, stress it, file issues, and send pull requests if you want to help improve the editor.
-
-[Learn about Open Location Hub](/open-location-hub/)
-
-[View the repository on GitHub](https://github.com/Open-Location-Stack/floorplan-editor)

content/open-location-hub/_index.md

@@ -2,102 +2,9 @@
 title: "Open Location Hub"
 description: "OpenAPI-first hub for location position and event exchange, connector-driven integration, and federated multi-site deployments."
 draft: false
+layout: "product"
+product_key: "open-location-hub"
 github_url: "https://github.com/Open-Location-Stack/open-location-hub"
 aliases:
   - /open-location-stack-hub/
 ---
-
-Open Location Hub is an OpenAPI-first hub for interoperable location position and event exchange, built around the omlox hub specification.
-
-It is the integration counterpart to Open Location Stack's mapping work. Once indoor spaces are modeled clearly, for example with the [Floor Plan Editor](/floor-plan-editor/), the hub handles live location data, events, auth, connectors, and system-to-system interoperability.
-
-The project is moving toward a production-grade open source hub that teams can run, extend, adapt, and integrate without depending on vendor-specific middleware.
-
-The software documentation for the current implementation is published at [Open Location Hub Docs](/open-location-hub/docs/). The REST contract is available as an interactive [API Reference](/open-location-hub/docs/api-reference/).
-
-## Why teams use it
-
-Open Location Hub gives vendors, integrators, and enterprise teams a hub they can run in customer projects, extend for partner integrations, and connect to existing systems.
-
-Because the project is part of Open Location Stack's MIT-licensed codebase, it can be used, adapted, embedded, and white-labeled without licensing friction. That matters for teams that need a reusable hub without giving up their own service model, deployment approach, or customer-specific integration layer.
-
-It cuts repeated work in hub APIs, auth, connectors, and deployment plumbing so teams can spend more time on delivery and product-specific behavior.
-
-## Why it matters
-
-Many RTLS deployments end up depending on proprietary hub behavior, custom APIs, or narrow integration contracts. That makes federation, migration, and cross-vendor interoperability harder than it should be.
-
-Open Location Hub provides secure, testable, deployable hub infrastructure that can participate in real deployments.
-
-It is cloud-native, horizontally scalable, and lightweight enough to run in very different environments. Teams can run it on premises close to local devices, in a regional cloud deployment, or as part of a larger multi-region setup that aggregates multiple sites and multiple continents. The federation work in the repository supports that progression from small local setups to larger distributed deployments.
-
-## Connectors for existing deployments
-
-Open Location Hub is not a rip-and-replace story. In many cases, the practical requirement is to work with the hubs and deployments that already exist across plants, warehouses, terminals, and production environments.
-
-The hub supports integration with existing on-premise and cloud-based hubs such as Corriva Hub, Deephub, and other deployments already used for AGVs, fork lift trucks, and site-specific operational systems.
-
-Instead of asking every customer to standardize on one vendor stack immediately, Open Location Hub can aggregate, normalize, and route location flows from multiple sources. That lets integrators and solution providers connect systems while preserving existing investments.
-
-For location vendors and solution providers, contributed connectors can demonstrate compatibility and reduce one-off project work.
-
-## What it includes today
-
-- A normative OpenAPI contract for the hub API.
-- A Go server with strict handler interfaces and a low operational footprint.
-- Local runtime support for Postgres, Valkey, Mosquitto, and the application itself.
-- Authentication modes for OIDC, static JWTs, and hybrid setups.
-- RBAC and ownership-aware authorization building blocks.
-- Shared ingest and fan-out paths across REST, WebSocket, and MQTT.
-- An OMLOX RPC control plane for diagnostics and command routing.
-- Unit tests and an integration-test harness.
-- Engineering and architecture documentation for implementation planning.
-
-## Technology overview
-
-The hub is written in Go, which fits the deployment model well: low footprint, high performance, and simple operations. The current architecture separates durable storage, transient state, protocol surfaces, and shared hub logic so the same core behavior can support multiple transports and deployment shapes.
-
-At the API layer, the repository already shows a broad protocol surface:
-
-- REST for resource management, ingest, and standard hub APIs.
-- WebSocket support for the OMLOX wrapper protocol, subscriptions, and event fan-out.
-- MQTT integration for local device, adapter, and site-level integration patterns.
-- OMLOX RPC support for command and diagnostics flows such as `com.omlox.ping`, `com.omlox.identify`, and `com.omlox.core.xcmd`.
-
-That protocol mix matters because real deployments rarely have just one integration style. Some systems need CRUD APIs, some need streaming updates, some need local MQTT-based device integration, and some need controlled command execution without exposing devices directly to every consuming application.
-
-## Security and control plane
-
-The authentication model is standards-based JWT bearer auth with support for `oidc`, `static`, and `hybrid` verification modes. In OIDC mode, the hub discovers provider metadata and JWKS automatically, caches verifier state, and validates standard JWT claims. The repository includes a Dex setup for development, and the same model works with production OIDC providers such as Keycloak and other enterprise identity systems.
-
-Authorization is more than simple bearer validation. The hub already includes role-based and ownership-aware authorization, route-level permissions, RPC-specific method permissions, and separate WebSocket topic permissions. That makes it possible to use the hub as the policy boundary between user-facing applications and lower-level RTLS infrastructure.
-
-This is especially important for OMLOX RPC. Instead of letting applications talk directly to MQTT-connected devices or vendor adapters, the hub can act as the control-plane front door: authenticate the caller, authorize the method, log the request, route it to the right handler, and aggregate responses if needed.
-
-## Federated hubs for multinational operations
-
-The federation planning in the repository is not an afterthought. It is aimed at topologies such as on-premises plant hubs feeding regional cloud hubs, or regional hubs feeding aggregate hubs for global visibility. The goal is to preserve standard OMLOX-facing interoperability while allowing deployments to grow into federated architectures that remain auditable, replay-aware, and resilient to partial outages.
-
-Open Location Hub is designed to federate, aggregate, and partition data across sites, tenants, regions, and jurisdictions while remaining practical for smaller installations.
-
-For multinational and internationally operating companies, that matters because real deployments are rarely uniform. Different countries, business units, and sites often use different location technologies, local integrators, and a combination of on-premise and cloud infrastructure. A federated hub model makes it easier to aggregate those location flows without forcing every site into the same architecture on day one.
-
-In practical terms, Open Location Hub can sit above local hubs, beside existing vendor systems, or between regional and global aggregation layers while still respecting local operational constraints.
-
-## Product fit
-
-Open Location Hub is the integration hub in Open Location Stack. It can sit between location infrastructure, applications, enterprise systems, and federated site deployments while staying aligned with omlox-style interoperability.
-
-For integrators and vendors, it covers core pieces of the stack such as API contracts, auth, event exchange, deployment scaffolding, connectors, and federation patterns. For customers, it reduces dependence on closed middleware and makes multi-technology deployments easier to integrate.
-
-## Get involved
-
-If you care about interoperable location infrastructure, try the code, review the API direction, open issues, and contribute pull requests.
-
-[Browse the generated docs](/open-location-hub/docs/)
-
-[Open the API reference](/open-location-hub/docs/api-reference/)
-
-[Learn about Floor Plan Editor](/floor-plan-editor/)
-
-[View the repository on GitHub](https://github.com/Open-Location-Stack/open-location-hub)

data/en/products/floor-plan-editor.yaml

@@ -0,0 +1,97 @@
+sections:
+  - type: hero
+    eyebrow: "Mapping product"
+    title: "Floor Plan Editor"
+    text: "Floor Plan Editor is a browser-based indoor mapping tool for teams that need to create, adjust, and maintain floor plans as structured venue data. It covers the practical editing workflow from map setup and floor geometry to overlays, validation, and export."
+    actions:
+      - label: "GitHub"
+        href: "https://github.com/Open-Location-Stack/floorplan-editor"
+        style: "primary"
+      - label: "Open Location Hub"
+        href: "/open-location-hub/"
+        style: "secondary"
+    aside:
+      title: "Map authoring for real products"
+      text: "The editor helps teams move away from bitmap-first indoor mapping. Instead of shipping floor plan pictures, you can maintain crisp vector geometry and venue structure that downstream applications can actually use."
+      highlights:
+        - "Browser-based authoring workflow"
+        - "Vector geometry instead of bitmap-only maps"
+        - "IMDF-oriented import, export, and validation"
+
+  - type: media-grid
+    id: "see-it-in-action"
+    section_class: "border-y border-line bg-neutral-50/50"
+    title: "See it in action"
+    intro: "The current editor already covers the core interaction loop for building indoor map data on top of a live map canvas."
+    items:
+      - src: "/images/floor-plan-editor-add-room.gif"
+        alt: "Animated demo of creating a room polygon in the Floor Plan Editor"
+        caption: "Draw rooms directly on the map canvas and build floor geometry as structured vector data."
+      - src: "/images/floor-plan-editor-show-hide-bitmap.gif"
+        alt: "Animated demo of hiding a bitmap floor plan overlay while keeping vector geometry editable"
+        caption: "Use floor plan images for alignment, then hide them and inspect the actual editable map data underneath."
+
+  - type: card-grid
+    id: "why-it-matters"
+    title: "What it fixes"
+    intro: "Indoor map authoring is still too often handled with ad hoc tools, bitmap exports, and brittle import steps. That leaves teams with maps that are hard to edit, hard to validate, and hard to reuse in real products."
+    cards:
+      - title: "One-off internal editors"
+        description: "Use a reusable map authoring tool instead of building a custom editor for each deployment."
+      - title: "Bitmap-first workflows"
+        description: "Keep editable vector geometry and venue structure instead of treating indoor maps as static floor plan images."
+      - title: "Large multi-floor sites"
+        description: "Work with data that stays usable across factories, terminals, hospitals, and campuses with many floors and large footprints."
+
+  - type: card-grid
+    id: "what-it-does"
+    section_class: "border-y border-line bg-neutral-50/50"
+    grid_class: "mt-10 grid gap-4 md:grid-cols-2 xl:grid-cols-3"
+    title: "What it does today"
+    intro: "The current implementation already covers the editing features teams need to turn a venue into usable indoor map data."
+    cards:
+      - title: "Interactive editing"
+        description: "Edit map features on a live MapLibre canvas."
+      - title: "Building and floor hierarchy"
+        description: "Manage buildings and levels with selection-aware editing panels."
+      - title: "Geometry tools"
+        description: "Draw and edit points, lines, and polygons."
+      - title: "Routing paths"
+        description: "Maintain routable navigation paths for wayfinding-ready indoor maps."
+      - title: "Floor plan overlays"
+        description: "Align bitmap floor plan images with corner-based controls."
+      - title: "Validation and exchange"
+        description: "Use local-first storage plus import and export workflows for GeoJSON and IMDF-oriented datasets."
+
+  - type: feature-aside
+    id: "structured-map-data"
+    title: "Built around structured indoor map data"
+    intro: "The editor is more than a drawing tool. It helps teams build venue data that downstream systems can search, render, route through, validate, and connect to live operational data."
+    items:
+      - title: "Local-first architecture"
+        description: "The current implementation uses React, Vite, TypeScript, IndexedDB, and MapLibre so projects stay editable in the browser without heavy infrastructure."
+      - title: "IMDF-oriented workflow"
+        description: "IMDF brings venue hierarchy and semantics for sites, buildings, levels, units, openings, and amenities, not just coordinates and shapes."
+      - title: "Navigation-aware authoring"
+        description: "Path creation is part of the workflow, so teams can build the graph needed for wayfinding and point-to-point routing."
+      - title: "Operationally useful output"
+        description: "Structured venue data gives downstream renderers, validators, hubs, and applications a better base than static floor plan exports."
+    aside:
+      eyebrow: "Standards and fit"
+      title: "Designed to work with the rest of the stack"
+      text: "Floor Plan Editor turns indoor spaces into structured map assets that products such as Open Location Hub and downstream location applications can use."
+      actions:
+        - label: "Explore Open Location Hub"
+          href: "/open-location-hub/"
+          style: "primary"
+        - label: "Read IMDF"
+          href: "https://www.ogc.org/standards/imdf/"
+          style: "secondary"
+
+  - type: cta
+    id: "try-the-editor"
+    title: "Inspect the editor"
+    text: "Review the repository, try the current workflows, and use it as the mapping foundation for products that need structured indoor map data."
+    action:
+      label: "View on GitHub"
+      href: "https://github.com/Open-Location-Stack/floorplan-editor"