If you are building indoor navigation, analytics, or a digital directory across more than one building, the map format you choose is not a detail you can defer. A floor plan drawn once for a single lobby can live in almost any format. The moment you need the same map to drive routing, feed a positioning layer, and stay consistent across ten venues authored by different teams, the encoding becomes the thing everything else depends on.
That is what indoor map data standards are for. They define a shared structure for what a building's interior contains, so a mapping engine, a routing engine, and an analytics layer can all read the same file the same way. This post explains the standards a GIS, product, or facilities team searches for by name: GeoJSON as the base encoding, IMDF as the venue-structured format built on top of it, and IndoorGML as the standard that models indoor space plus the network graph used for routing. For the workflow of producing a map from architectural source data, see from BIM to a wayfinding map; this post is the companion reference on the formats themselves.
What are the main indoor map data standards?
The most referenced indoor map standards are IMDF (Indoor Mapping Data Format), which structures a venue's floors, levels, units, and points of interest as a set of GeoJSON features, and IndoorGML, an Open Geospatial Consortium standard that models indoor space and the network graph used for routing. GeoJSON itself is the underlying encoding IMDF builds on. In practice, teams author geometry in CAD or BIM, then export or convert it into one of these standards so a mapping and routing engine can consume floors, connections, and destinations consistently across venues.
They are not competitors in a simple sense: GeoJSON is a general-purpose encoding, IMDF is a way of using GeoJSON for buildings, and IndoorGML is a separate standard that emphasises the routing network. Which one a team reaches for depends on whether the priority is a portable venue description or an explicit navigation graph.
GeoJSON: the base encoding for indoor features
GeoJSON is a format for encoding geographic data structures using JSON, published by the IETF as RFC 7946 (2016), which makes it an open, stable, widely-implemented specification rather than a vendor format. It is not specific to indoor mapping; it is the general encoding that a great deal of web and geospatial tooling already reads.
GeoJSON defines a small set of geometry types, including Point, LineString, and Polygon, wraps them in Features that carry properties, and groups Features into a FeatureCollection. For an indoor map, that vocabulary describes the raw shapes: a room is a polygon, a door is a point, a corridor centreline is a line, and each carries properties such as a name or category.
What plain GeoJSON does not give you is any indoor-specific meaning. It has no built-in concept of a floor, the relationship between a shop unit and the building that contains it, or how one level connects to the next. You could invent your own properties to express all of that, but then every team would invent them differently, and the consistency you wanted across venues is exactly what you lost. That gap is the reason IMDF exists.
IMDF: how it structures venues, levels, units, and points of interest
IMDF, the Indoor Mapping Data Format, was created by Apple and is stewarded by Apple as a published specification, and it has been adopted by the Open Geospatial Consortium as a Community Standard. Its central design choice is that it is built on GeoJSON. An IMDF dataset is a set of GeoJSON FeatureCollections, so anything that can already read GeoJSON is partway to reading IMDF.
What IMDF adds is a defined vocabulary of feature types organised around a venue. Rather than leaving you to invent property names, it specifies the categories a building is made of and how they nest. In broad terms an IMDF dataset describes:
- Venue and building. The site as a whole and the physical structures on it.
- Level. Each floor, with its ordinal so the software knows the stacking order.
- Unit. The individual spaces on a level, such as a shop, a room, or a walkway.
- Opening. The connections between units, such as doors and passages.
- Amenity and point of interest. The named destinations a visitor searches for.
Because those types and their relationships are fixed by the specification, a map exported to IMDF from one venue looks structurally like a map from any other. That is precisely the property a multi-building programme needs: a routing engine can assume it will always find levels with ordinals, units it can label, and openings it can treat as connections, without special-casing each site. IMDF's tie to GeoJSON is also why it slots into pipelines that already handle geospatial JSON.
IndoorGML: modelling space plus the routing network graph
IndoorGML is an Open Geospatial Consortium standard that comes at the problem from a different direction. Where IMDF is JSON built on GeoJSON, IndoorGML is expressed in GML, the OGC's XML-based Geography Markup Language, and its emphasis is not just the shapes of the space but the connectivity between spaces.
The distinctive idea in IndoorGML is a dual representation. On one side it describes cellular space: the rooms, corridors, and other bounded areas of a building. On the other it derives a node-relation graph, where each space becomes a node and each connection between adjacent spaces becomes an edge. That graph is exactly what a routing algorithm needs. To compute a path from a room on one floor to an exit on another, an engine traverses a graph of nodes and edges rather than reasoning about polygons directly, and IndoorGML makes that graph a first-class part of the standard rather than something each vendor rebuilds.
IndoorGML has been maintained by the OGC across more than one revision, so a team standardising on it should confirm the current version against the OGC's own register rather than assume a fixed number. The design intent is consistent across versions: model indoor space and, alongside it, the navigation network that routing depends on. That makes IndoorGML the natural reference point when the routing graph itself is the priority.
Standards comparison
The three standards are easiest to hold in your head side by side. The table below summarises what each is for and how they relate.
| Standard | What it is | Base format | Routing / network support | Steward | Typical use |
|---|---|---|---|---|---|
| GeoJSON | General-purpose geographic data encoding | JSON (its own format) | None built in; geometry only | IETF (RFC 7946) | Raw indoor geometry; the base other formats build on |
| IMDF | Venue-structured indoor mapping format | GeoJSON | Connectivity via openings; not an explicit graph standard | Apple; adopted as an OGC Community Standard | Portable, consistent venue description across many buildings |
| IndoorGML | Indoor space model with an explicit network graph | GML (XML) | Node-relation graph as a first-class concept | Open Geospatial Consortium | Routing-centric applications where the navigation graph is the priority |
The pattern is clear across the rows. GeoJSON gives you the shapes. IMDF adds a fixed venue structure that stays consistent across sites. IndoorGML adds an explicit routing graph. None of them, on its own, tells you where a visitor is standing right now. That is a separate layer, and the point this reference keeps returning to.
From CAD and BIM to a standard indoor map
Almost no indoor map starts life in one of these standards. It starts as an architectural drawing: the building was designed in CAD, or modelled in BIM, and the standard indoor map is derived from that source.
CAD files describe a building for construction and documentation. They are rich in line work and layers but were never meant to express navigable meaning: a CAD layer knows it holds walls, not that a given room is a shop unit a visitor can be routed to. BIM goes further, carrying structured objects and attributes rather than bare geometry, so more of the meaning a map needs is already present in the model.
The conversion does two things. It simplifies the source down to what navigation and analytics actually need, discarding construction detail that has no place in a wayfinding map. And it maps the remaining elements onto the target standard's vocabulary, so a modelled room becomes an IMDF unit or an IndoorGML space, a doorway becomes an opening or an edge, and each level is tagged with its ordinal. That translation step is the subject of the full from BIM to a wayfinding map walkthrough, and turning that flat description into a dimensional, multi-level model is covered in building a 3D indoor map.
Landing the result in a standard, rather than a bespoke export, comes back to consistency. When every venue's map uses the same vocabulary, the tools downstream stop caring which building they are looking at: a directory, a routing engine, and an analytics layer can each be built once and pointed at any venue. Skip the standard and you rebuild that integration for every site. For how these maps sit inside a navigation system, see how indoor wayfinding works.
Why standards matter for multi-venue positioning and analytics
A standard indoor map describes where the walls, units, levels, and destinations are. It does not, by itself, locate a person on that map. A navigation or analytics system needs both: the map for the building, and a positioning layer to place a visitor on it in real time, a separate technology decision surveyed in the positioning layer that uses the map.
For a programme running across many venues, standard maps make the positioning and analytics layer far simpler to operate. If every building's map shares the same structure, the layer that places visitors and measures movement can be configured once and reused rather than re-engineered per site. Consistent maps also make the outputs comparable: a count measured against an IMDF unit means the same thing in one venue as in another, which lets a team benchmark across a portfolio instead of reading each building in isolation. The same logic applies to placing points of interest in the map data itself.
Ariadne sits on the positioning-and-analytics side of that split. It consumes standard indoor maps under its positioning layer; it does not define these standards or ship a map-authoring suite. The map describes the building; Ariadne places movement on it.
Ariadne measures this with Hybrid Fusion, its patented camera-free method. Time-of-Flight depth sensing counts every visitor at the entrances, capturing geometry rather than images, while patented phone signal sensing follows movement through the interior, detecting the signals a phone emits even in airplane mode, and tracks that movement to about one-metre precision. The sensor streams both feeds to Ariadne, where Hybrid Fusion combines them into one trajectory per visit and computes counts, dwell, and paths. The streams carry no identifier: no MAC address, no device ID, no biometric data, and no camera is involved. Identifiers are stored only when a visitor explicitly opts in, which keeps the method GDPR-friendly and outside biometric territory.
That is why the map format is a real decision, not a formality. Keep the map consistent across venues and the positioning layer scales; let each venue drift into its own format and every measurement becomes a special case. To see the positioning side as a product, see Ariadne indoor navigation.
FAQ
What is the difference between IMDF and GeoJSON?
GeoJSON is a general-purpose format for encoding geographic geometry in JSON, published by the IETF as RFC 7946. IMDF is built on GeoJSON but adds a fixed vocabulary of venue, level, unit, opening, and point-of-interest feature types, so indoor maps stay structurally consistent across venues. In short, IMDF is indoor structure built on top of the GeoJSON encoding.
Is IMDF an open standard?
IMDF was created and is stewarded by Apple as a published specification, and it has been adopted by the Open Geospatial Consortium as a Community Standard. It is built on the open GeoJSON encoding, which means tools that already read GeoJSON have a head start on reading IMDF.
What is IndoorGML used for?
IndoorGML is an Open Geospatial Consortium standard that models indoor space and, alongside it, a node-relation graph of how spaces connect. That graph is what a routing engine traverses to compute a path, which makes IndoorGML the reference point when the navigation network itself is the priority.
Does a standard indoor map tell you where visitors are?
No. A standard map describes the building, including its floors, units, and destinations. Locating a visitor on that map in real time is a separate positioning layer. A navigation or analytics system needs both: the map for the structure and the positioning layer for live location.
Does locating visitors on an indoor map require cameras?
No. Ariadne counts with Hybrid Fusion: Time-of-Flight depth sensing plus patented phone signal sensing, never cameras. Time-of-Flight captures geometry rather than images, and signal sensing captures no MAC address by default, so the measurement involves no video, no faces, and no biometric data.
