What Is IMDF? A Practical Guide to the Indoor Mapping Data Format

IMDF is map data for people finding their way

An architect's CAD drawing tells you where the walls are and how the services run. IMDF answers a different set of questions: what is this space called, what is it for, where are its doors, how do you get from this floor to that one, which shop is inside, and when is it open.

That split shapes what IMDF looks like. It doesn't draw wall thickness or record materials. It uses polygons and points to describe the things people can find and walk to, and every record has to sit on real-world longitude and latitude. That is why IMDF data can be laid straight onto a phone map and a CAD drawing can't. One does not replace the other; IMDF is usually derived from CAD drawings or floor plans.

What's inside an IMDF archive

Unzip an IMDF archive and you'll find a manifest.json and a set of .geojson files, one feature type per file. Only three are mandatory: manifest.json (version, creation time and default language), venue.geojson (the venue itself; an archive can contain exactly one) and address.geojson. The other fourteen are optional.

Optional doesn't mean you can skip them. The validation rules require every building to have at least one level and every level to have at least one unit, so if you want any floor to show on a map, Level and Unit are unavoidable. In practice the feature types fall into four groups:

The most misunderstood pair: Occupant and Anchor

An Occupant (usually a shop) has no geometry in IMDF. It doesn't know where it is; it only knows which Anchor it hangs from, and the Anchor is a point inside a Unit. Name, category, opening hours, phone and website all live on the Occupant, along with a validity field for the period it applies to.

For a venue that has to be maintained for years, this is the most useful design decision in IMDF. Shops in malls and terminals change constantly. If a shop's name were written onto the space's polygon, every new tenant would mean editing the map. With the two separated, spaces and shops are managed independently: a tenant change touches one Occupant record and none of the map geometry.

Multiple languages, one map

Name fields in IMDF are objects keyed by language tag, so one space can carry zh-Hant, en and ja names at once, with the default language set in the manifest. A trilingual wayfinding map is one dataset to maintain, not three. The validation rules also reject blank names and invalid language tags.

Why IMDF rather than a format of your own

Plenty of venues have an indoor map that their wayfinding app vendor drew along the way, stored in the vendor's own format. It works fine until the day you change vendors, want to appear in Apple Maps, or want the same map in your internal work-order system.

IMDF is a public standard that any tool reading GeoJSON can open, so the data isn't locked into anyone's proprietary format. The same dataset can go to Apple Maps and also feed the venue's own web map, app and internal operations systems. And if your venue is an airport, shopping center or train station, Apple's specification includes separate modeling guidance for exactly those three, so you aren't starting from scratch.

Our own map platform is built this way. The data is native IMDF, and the front end runs on the open-source MapLibre GL engine with PMTiles static tiles, so there are no map engine license fees. A venue embeds the map in its website or app with an iframe or WebView, without installing an SDK. Because the data and the display are separate, swapping out the front end one day doesn't mean redrawing the map.

IMDF is a data format, though, not a navigation system. It describes spaces, openings and connections between levels, but working out how to get from A to B is the job of whatever application uses it, and knowing where you are right now needs a separate layer of positioning technology. More on both later.

Building it: from floor plan to a valid IMDF archive

1. Gather the inputs. Floor plans for every level (CAD is ideal; plain floor plans can be traced), the name and use of each space, how the levels relate to each other, and the list of amenities and businesses to show. Whatever is missing here is what you'll get stuck on later.
2. Georeference. GeoJSON requires WGS 84 longitude and latitude, but floor plans use local coordinates. Align the plans to the earth with control points first, or the map will land on the building next door when it's laid over a phone map.
3. Model from large to small. Venue, Building and Level first, then cut Units, then add Openings, Fixtures and Amenities, and finally hang Occupants on Anchors. Every Unit needs a category (walkway, restroom, room and so on); that is what lets a wayfinding map search and filter by type.
4. Validate. The specification comes with a full set of validation rules at two levels, Violation and Warning.
5. Publish or use it yourself. To appear in Apple Maps, submit through the Indoor Maps Program on Apple Business Register. For your own use, connect it straight to your own map platform.

Where validation usually fails

Violations are hard errors. Feature IDs must be unique v4 UUIDs, every referenced ID must resolve, an archive may contain only one Venue, and an Anchor must sit inside the Unit it references. These usually come from the production tooling and only need fixing once.

Warnings take judgement. Units on the same level shouldn't overlap, together they should cover the whole level, and openings should lie on a unit's boundary; an opening wider than 45 meters or narrower than 0.8382 meters (33 inches) is flagged as suspicious. Real buildings don't always follow these rules. A narrow back-of-house door or the hole an atrium leaves in a floor plate can both trigger warnings. You don't have to clear every warning, but someone should have looked at each one and know why it stays.

Not in the spec, but essential: stable IDs

IMDF only requires IDs to be unique UUIDs. It doesn't require them to stay the same from one version to the next. Plenty of production pipelines issue a fresh batch of UUIDs on every rebuild, and the archive still validates. The trouble is downstream: every "view on map" link on a website, every maintenance record attached to a space, every saved place in an app points at the old ID, and each new map version breaks them all.

We treat an ID as a space's identity card. However many times the map is revised, the same space keeps the same ID; a new one is issued only when a space is actually demolished or merged. Each landmark's dedicated link and every maintenance record attached to a space depend on that. Decide this in the very first build. Retrofitting it after other systems already reference the map costs far more.

Getting into Apple Maps: who can apply and what it takes

Apple's Indoor Maps Program is run through Apple Business Register and is aimed at the owners or operators of large venues; Apple's examples are airports, shopping centers, arenas and hospitals. In other words, whoever submits must be able to speak for the venue. A consultant or build vendor prepares the data; it doesn't apply on the venue's behalf.

Apple also provides the IMDF Sandbox, where you can view your IMDF on the web and make minor edits. To show "you are here" on an iPhone indoors, you run an RF survey with Apple's Indoor Survey app; Apple states that its indoor positioning uses the venue's existing Wi-Fi access points and needs no additional hardware.

Being in Apple Maps means iPhone users opening Apple Maps can see your interior. The venue's own website, app, Android users and staff still need a map platform of their own. That's why we recommend building IMDF as an asset the venue owns, with Apple Maps as one of the places that use it.

After the build: a map starts going stale on acceptance day

The part of an IMDF project most often underestimated is what comes after. Tenants move in and out, opening hours change, areas close for works, and the content shifts daily. An indoor map nobody maintains will eventually walk someone to the door of a shop that has already gone.

Maintenance starts with three questions: who can edit, who approves, and how do you roll back a mistake. Our platform turns those into a fixed workflow. Venue staff edit in the back office or on a phone, changes go live only after approval, and every version keeps a snapshot that can be restored in one click. The Occupant validity field mentioned earlier helps here too: a pop-up shop with a fixed term can carry its validity period directly.

One more thing belongs in the contract: who owns the copyright in the map data. For the partner airport we serve, the copyright in the map data belongs to the airport, and because the format is open IMDF, it can be taken along in full when changing vendors. If your contract doesn't say this, it's worth adding before you sign.

Airports, hospitals and government agencies often have data residency or no-interruption requirements, and a cloud-only map platform may not pass their security review. Fortunately the map output is just static tiles and JSON, so mirroring it to an on-premises host at the venue is cheap, and service can switch to the on-premises copy if the cloud fails. Deployment options and published pricing are on the IMDF Map Hosting page.

After the map: positioning is a separate layer

IMDF answers "where are things", not "where am I". To show a blue dot in your own app you need to choose an indoor positioning technology:

Which one fits depends on the venue. In 2017 we took part in a Bluetooth iBeacon deployment at Hong Kong International Airport, with more than 700 beacons providing positioning and navigation across the whole site. At Computex 2014 we deployed 5,000 beacons across three exhibition halls; when on-site WiFi and 3G failed at peak times, navigation kept working. The architecture trade-offs from that event are in Why Indoor Navigation Fails When an Exhibition Fills Up. Whatever the technology, the coordinates it produces end up on a map, and if the map is wrong, an accurate blue dot doesn't help.

Frequently asked questions

Does it cost anything to use IMDF?

The format itself is free. IMDF is a public OGC Community Standard, and Apple states that it charges no fees for registration, for use of IMDF, or for its indoor positioning service. The real cost is the labor of building and maintaining the map data: we quote builds by floor area and number of levels, and upkeep depends on how often the venue changes.

What software opens an IMDF file?

An IMDF archive is a set of GeoJSON files in a ZIP. Once unzipped, any GIS tool that reads GeoJSON, such as QGIS, can open it. Apple also offers the web-based IMDF Sandbox, where you can view a whole dataset and make minor edits.

Is IMDF only for Apple Maps?

No. IMDF is an OGC Community Standard that any application can read. A venue can use the same IMDF to build its own web or app wayfinding map and to feed internal work-order and facility systems; Apple Maps is just one of the places it can go.

A venue has several buildings. How many IMDF archives does it need?

One. The specification requires exactly one Venue per archive, and a Venue can hold several Buildings, each with its own levels and footprints.

Is there a newer version of IMDF?

Not at the moment. 1.0.0 is the only version: OGC approved it as a Community Standard in February 2021, and the specification says the manifest's version field may only contain 1.0.0.

References

• OGC: Indoor Mapping Data Format standard page
• OGC 20-094: full IMDF 1.0.0 specification and validation rules
• Apple: IMDF specification with airport, shopping center and transit station guidance
• Apple: Indoor Maps Program

---

Related Solutions

• IMDF Map Production — the first step for a new venue: building specification-compliant IMDF data
• IMDF Map Hosting — monthly hosting after the build, with a management sandbox and hybrid cloud/on-premises deployment, at published prices
• Lightweight BIM Viewer — starting from existing as-built drawings or floor plans, with 2D, 3D and IMDF from one source
• Indoor Positioning — the layer after the map: WiFi fingerprinting, Bluetooth iBeacon and UWB