Building the First Useful Map
An indoor map for wayfinding or proximity-triggered content is not simply a digitised floor plan. It is a structured spatial model that ties physical locations to zones, points of interest, navigation routes and, where relevant, beacon or sensor positions. The creation process turns raw plan data into something a navigation engine or content management system can actually use, and the update process keeps that model aligned with a space that rarely stays the same.
Creation and updating are fundamentally the same workflow applied at different points in time. During initial creation you build the geometry, define levels, label rooms and corridors, assign zone identifiers and connect the map to whatever backend triggers content or routing. During an update you repeat a subset of those steps for whatever has changed: a relocated exhibit, a closed entrance, a reconfigured retail unit. The discipline required is the same in both cases — the difference is scale and frequency.
For museums, the map might need updating every few weeks when temporary exhibitions change. For retail environments, unit turnover and seasonal refits can demand quarterly reviews at minimum. Event venues face the most compressed timeline: a floor plan may be valid for three days before the next build-out begins. Understanding this cadence at the outset shapes how you structure the map, what level of detail you commit to and who holds responsibility for keeping it current.
The map also sits between two neighbouring concerns that are covered separately. Where the underlying floor plan data comes from — CAD files, surveyed measurements, architectural drawings — is addressed in the discussion of floor plan data sources and formats. How you then verify that the finished map actually corresponds to the real space is covered under map accuracy and validation. This article focuses on the practical work in between: building the map, structuring it for use, and establishing a repeatable process for keeping it live.
Handling Closures and Venue Changes
Structuring the map for its intended purpose
Before drawing anything, clarify what the map needs to support. A map built solely for "you are here" displays on kiosks has different requirements from one that powers turn-by-turn indoor navigation on a visitor's phone. Navigation demands connected route graphs, decision points at junctions, and distance-weighted edges. A static display map can get away with labelled polygons and icons. If you are also triggering location-based notifications, the map needs clearly defined zone boundaries that align with where beacons, NFC tags or QR codes are physically placed.
Decide on a level of detail that serves the use case without creating an ongoing maintenance burden. A museum might need exhibit-level granularity — individual display cases as named points of interest. A conference venue might only need session rooms, catering areas and toilets. Adding detail that no feature actually uses means you have more to update when the space changes, for no operational benefit.
Zone definitions and content triggers
When proximity technology is involved, each zone on the map should correspond to a trigger rule in your content or notification system. If a beacon near the entrance is meant to welcome visitors, the map zone labelled "Main Entrance" must match the geofence or RSSI threshold configured for that beacon. Mismatches here are a common source of silent failures: the beacon broadcasts, the app receives the signal, but the zone lookup returns the wrong content because the map was updated and the trigger rules were not.
Document the relationship between map zones and trigger configurations. A simple register — zone ID, associated beacon or tag hardware ID, trigger rule reference, last updated date — prevents drift as changes accumulate over months.
Version control and change approval
Even a single-venue map will go through dozens of revisions over its life. Without version control you cannot reliably answer questions like "was the lift marked as out of service on the map when the visitor complained last Tuesday?" Use whatever system fits your operation — a shared drive with dated file names, a proper version-control system if your integrator provides one, or a dedicated indoor-mapping platform with built-in revision history. The requirement is the same: you must be able to retrieve any previously published version and see what changed between it and the current one.
Agree a change-approval workflow. In a museum, the exhibitions team might request a change, the operations team confirm it on the ground, and the digital team publish the updated map. In a retail environment, the facilities manager might approve layout changes that then cascade to the map. The exact chain matters less than having one that is documented and followed. Unauthorised or unrecorded map edits are a particular risk when multiple people have access to the editing tool.
Use-case-specific update patterns
Museums and galleries. Temporary exhibitions are the main driver of map updates. A practical approach is to treat permanent gallery zones as stable and temporary exhibition zones as modular overlays that can be added, modified and removed without touching the base map. This reduces the chance of accidental edits to long-lived content.
Retail environments. Unit changes, seasonal pop-ups and refits mean the map needs a quarterly review cycle at minimum. Coordinate with the leasing or facilities team so that map updates are part of the move-in or refit checklist, not an afterthought discovered weeks later.
Events and conferences. The challenge is compressed time. Floor plans may change between build days, and the map must keep pace. A practical approach is to assign a dedicated map coordinator for the event duration, equipped with a simplified update workflow that can publish changes within hours rather than days. Accept that the map will never be perfectly current during a fast-moving build and design the visitor experience to tolerate minor discrepancies — clear physical signage as a fallback, for instance.
Transport hubs and large venues. These environments often have multiple overlapping map consumers: a wayfinding app, accessibility route planners, staff operational maps and emergency evacuation plans. Updates must propagate to all consumers, and some may have different update cycles or approval requirements. A central map source with defined export formats for each consumer avoids maintaining multiple divergent copies.
Keeping Maps Legible and Trustworthy
Treating the map as a finished project
The most persistent mistake is treating map creation as a one-time project with a handover date. An indoor map is closer to a live dataset than a printed brochure. If the procurement, contracting and resourcing plans do not account for ongoing updates, the map will start degrading from the day it launches. Budget and assign responsibility for maintenance before going live, not after the first inevitable change request arrives.
Updating the map but not the surrounding system
When a physical space changes, the map is often updated in isolation. The beacon placement, zone trigger rules, content associated with the old location and any printed or kiosk-based wayfinding materials may all remain unchanged. The result is a map that accurately shows the new layout but triggers content for the old one. Build an update checklist that covers every system that references the map, not just the map file itself.
Insufficient detail at decision points
Wayfinding maps frequently under-specify junctions and decision points. A corridor drawn as a single line with no indication of where branches occur gives the navigation engine nothing to work with at the moment the visitor needs guidance. Check that every junction, stairwell entrance, lift lobby and fork in a corridor is represented as a distinct node in the route graph, not buried inside a generic corridor shape.
Over-detailing areas that do not need it
The opposite problem is equally common. Mapping every internal wall, pillar and minor obstruction in a back-of-house area that visitors never see adds complexity without serving any use case. It also means those elements must be maintained. Apply a simple test: if removing a feature from the map would not change any user-facing behaviour — a route, a notification, a point of interest label — it probably does not need to be there.
Key checks before publishing an update
- Zone alignment. Do the updated zone boundaries still correspond to the physical positions of beacons, NFC tags or QR codes? Walk the space if necessary.
- Route continuity. If a corridor or room has been closed or rerouted, does the navigation graph still contain a valid path between all open areas? Check for orphaned nodes or broken edges.
- Content consistency. Have all content triggers, notification rules and point-of-interest labels been updated to match the new map? Cross-reference the zone register.
- Version stamp. Is the new version clearly numbered or dated, and is the previous version archived?
- Multi-consumer sync. If multiple systems consume the map — app, kiosks, web, staff tools — have all been updated from the same source?
- Physical verification. Has someone walked the updated areas with the live map on a device to confirm it matches what a visitor will actually see?
Accepting the limitations
No indoor map eliminates the need for physical signage. Visitors who do not have the app, whose phone battery has died or who simply prefer not to look at a screen still need conventional wayfinding. Design the map update process to keep digital and physical signage in step, rather than assuming the digital map will replace everything else.
Similarly, accept that during periods of rapid physical change — event build-ups, major refits — the map will lag behind reality. The operational question is not how to prevent this but how to detect it, communicate it and recover quickly. A simple status indicator on the map interface ("last updated: date, known discrepancies: list") manages visitor expectations more honestly than a map that silently shows outdated information.
