User journeys and spatial data requirements
Version control for indoor maps is the practice of tracking every change to a floor plan, zone definition, coordinate reference or routing graph so that you can see what altered, when, by whom, and revert to a previous state if something goes wrong. It is not a luxury reserved for large airports. Any venue where the map feeds a live wayfinding system, triggers location-based content, or defines beacon zones needs some form of version discipline.
Indoor maps differ from street maps in a critical respect: they change frequently and often without public notice. A retail unit rebrands, a museum rotates an exhibition, an event reconfigures seating for a second day, or a venue closes a corridor for maintenance. Each of these changes can shift the coordinates that your navigation engine, zone triggers and analytics rely on. If the map data and the physical infrastructure drift apart, visitors receive wrong directions or notifications fire in empty corridors.
There are two layers to manage. The visual layer is the rendered floor plan that visitors see on a screen or kiosk. The data layer is the underlying coordinate set, zone polygons, point-of-interest markers and routing graph. A version control approach must cover both, and it must make clear which data version corresponds to which visual version. When a provider talks about "map versioning," establish whether they mean the image file, the structured data, or both.
Version control also matters for coordination between teams. Facilities management may update a CAD file, the marketing team may adjust point-of-interest labels, and the IoT integrator may reassign beacon identifiers to new zones. Without a single versioned source of truth, these parallel edits produce conflicting datasets that only become visible when a visitor reports a broken route.
Field verification and route modelling
Retail environments
Shop units change tenants, seasonal pop-ups appear in walkways, and store layouts shift during refits. In a shopping centre, a single floor might see several coordinate-level changes per quarter. Version control here needs to capture which zone polygon maps to which unit at which date, so that proximity notifications and analytics remain correctly attributed. If a beacon zone is not updated to match the new unit boundary, campaign measurement will attribute footfall to the wrong retailer.
Museums and galleries
Temporary exhibitions may occupy a gallery for three months, then be replaced. The navigation map must reflect the changed exhibit positions, accessible routes and exit points. A version-controlled map allows the venue to schedule the new layout in advance, test wayfinding against it, and push it live on the opening day while retaining the previous version for the permanent collection map that will return afterwards.
Events and conferences
Multi-day events often reconfigure floor plans between days. A keynote hall becomes a workshop space, signage moves, and entry points shift. Version control in this context is less about long-term history and more about rapid, reliable switching between known-good states. The operational priority is being able to roll back to yesterday's map within minutes if a last-minute change introduces an error.
Structuring versions
Some indoor mapping platforms offer built-in versioning with change logs and rollback. Others store a single current state and leave history to your own file management. Where built-in versioning is absent, a practical minimum is a naming convention that embeds the date, environment and a brief change description, stored in a controlled location with restricted write access. Semantic versioning (major, minor, patch) can work if your team understands what constitutes a breaking change versus a minor adjustment in your specific context.
Approval and testing workflows
A version is only useful if it passes through a check before going live. The practical workflow is: edit in a staging or draft state, test navigation routes against the new data, confirm that zone triggers fire in the correct locations, then promote the version to production. If your platform does not separate draft and live environments, you are testing changes in front of real visitors, which is a risk most venues should avoid.
Keep routes accurate after building changes
Versioning the image but not the data
The most frequent error is treating the visual floor plan as the map. A new PNG or SVG is uploaded, but the underlying coordinate set, zone polygons and routing graph are not updated to match. The map looks correct on screen but the navigation engine still routes visitors through walls that no longer exist or triggers a notification in a zone that has moved. Always confirm that a version update covers the structured data, not just the visual render.
No rollback capability
If a new map version introduces a routing error, you need to revert quickly. Some platforms allow instant rollback to a previous version; others require you to re-upload an older file manually, during which time visitors may receive broken directions. Ask your provider specifically how rollback works, how long it takes, and whether the previous version's zone and routing data are preserved intact.
Uncoordinated parallel edits
When two people edit the same map simultaneously, the last save typically overwrites the first. In an indoor map, this can silently remove a zone definition or shift a coordinate without any error message. Establish a single point of editorial control or use a platform that supports locking or branching to prevent concurrent overwrites.
Map versions out of sync with beacon configuration
If you update the map to reflect a new zone layout but do not update the beacon identifiers or RSSI thresholds assigned to those zones, the system will appear to work but will deliver incorrect analytics and misfired notifications. Treat the map version and the beacon configuration as a paired release: when one changes, the other must be reviewed and versioned alongside it.
Key questions for a provider
- Does the platform store a full version history with timestamps and editor attribution, or only the current state?
- Can you view a diff between two versions to see exactly what changed?
- Is rollback to a previous version instant, and does it restore both visual and data layers?
- Does the platform support draft and live environments, or are all edits immediately visible to end users?
- Can you export a versioned data file for your own backup, independent of the platform?
- How does the version system handle zone polygons and routing graphs, not just point-of-interest labels?
Limitations to accept
Version control does not fix inaccurate source data. If your original floor plan was measured imprecisely, versioning will faithfully preserve that inaccuracy through every iteration. It also does not substitute for physical verification: a map version that looks correct in the CMS still needs to be walked on-site with a test device before going live. Finally, version control adds process overhead. For a single-room venue with a static layout, a full versioning system may be unnecessary complexity. The scale of the approach should match the frequency and consequence of your map changes.
