Define routes, zones and points of interest
Before any indoor navigation system can calculate a route or position a blue dot on a map, it needs a structured digital representation of the building. That representation has to come from somewhere, and it has to arrive in a format the mapping platform can actually use. The gap between what a venue holds in its filing system and what an indoor positioning system requires is where most mapping projects stall or produce inaccurate results.
Floor plan data sources fall into a small number of practical categories. The most common starting point is an existing CAD file, typically in DWG or DXF format, produced during the building's design or fit-out. Many venues also hold PDF floor plans, which are convenient for printing but fundamentally unsuitable for navigation without conversion. Some sites, particularly older buildings or those with complex recent alterations, rely on surveyed measurements captured by a building surveyor. A minority have geospatial data already structured in formats such as GeoJSON or Shapefile, usually because the venue sits within a wider campus GIS.
The formats themselves divide into two broad families. Vector formats store geometry as coordinates, lines and polygons, which means the mapping platform can interpret individual rooms, corridors and obstacles as distinct objects. Raster formats store the plan as a grid of pixels, essentially a photograph of a drawing. Raster plans can serve as a visual backdrop, but they cannot define navigable paths or zones without a separate layer of vector data traced over the top.
Vector Formats
- DWG and DXF: The native and exchange formats of AutoCAD. Widely available from architects and facilities teams. Contain rich layer and block information, but that information is rarely organised the way an indoor navigation platform expects.
- GeoJSON: An open standard based on JSON. Increasingly common as an interchange format because it is human-readable and well-supported by web mapping libraries. Requires a defined coordinate reference system to be useful indoors.
- IndoorGML: An OGC standard specifically designed for indoor spatial information. Supports multi-floor topology and navigation semantics. Supported by a limited but growing number of platforms.
- KML: A Google-originated format common in outdoor mapping. Can represent indoor features but lacks native support for multi-floor relationships and indoor-specific semantics.
- SVG: Useful for simple, single-floor diagrams where the plan needs to render cleanly in a browser. Lacks the geospatial rigour of GeoJSON or IndoorGML but can be sufficient for basic wayfinding overlays.
Raster Formats
- PDF: The most commonly held format in venues. A PDF floor plan is almost always a raster image embedded in a document. It conveys layout visually but contains no machine-readable geometry.
- PNG and JPEG: Straightforward image files. Sometimes the only surviving record of a building layout, particularly in older heritage venues. Require georeferencing and vectorisation before they can support navigation.
The critical distinction is not which format sounds most modern, but which one preserves the spatial relationships the navigation engine needs. A DXF file with well-separated layers for walls, doors and rooms is far more useful than a GeoJSON file where every feature has been flattened into a single geometry collection with no attributes.
Build the map around real movement
Matching the Source to the Use Case
A retail unit needing a simple zone-based notification system can often work from a traced raster plan. The zones do not need centimetre precision; they need to correspond roughly to departments or aisles, and the visual backdrop just needs to look correct to the operations team configuring the campaign. In this scenario, a clean PDF exported from the store's fit-out drawings, manually traced in the mapping tool, may be entirely adequate.
A hospital or large museum requiring turn-by-turn indoor navigation demands structured vector data with correct topology. Corridors must connect to rooms through defined doorways. Stairwells must link floors. Obstacles must be closed polygons, not loose line segments. Here, the source data needs to support that level of rigour from the outset, which usually means starting from a well-layered CAD file and investing in proper conversion rather than manual tracing.
Event venues face a distinct problem: their floor plans change frequently. A conference centre may reconfigure hall layouts weekly. In these cases, the data source question is less about format and more about process. The venue needs a base building shell in a stable vector format, with a separate overlay layer for temporary layouts that can be swapped without reprocessing the entire plan.
Coordinate Systems and Scale
Indoor plans frequently arrive without any coordinate reference system. CAD files are often drawn in arbitrary units that correspond to millimetres or centimetres at the origin point, with no real-world geolocation attached. For indoor navigation, this is not necessarily a problem if the system works in a local coordinate space. It becomes a problem the moment the indoor map needs to align with an outdoor map, integrate with GPS, or share data with a campus-wide GIS.
When real-world alignment is required, the plan needs at least two known reference points tying the local coordinate space to a standard system such as OSGB36 (the Ordnance Survey National Grid) or WGS84. These reference points are typically established through a site survey. Without them, any claim of alignment between indoor and outdoor maps is speculative.
Metadata and Layer Structure
The usefulness of a vector floor plan depends heavily on what attributes are attached to each feature. A polygon representing a room is significantly more valuable if it carries attributes for room name, room number, floor level and usage category. A line representing a corridor is more useful if it is tagged as navigable rather than just a visual element.
In practice, CAD files from architects often have layers named after drafting conventions rather than navigation requirements. A layer called "A-WALL-INT" tells the mapping technician nothing about whether those walls are load-bearing, full-height or movable partitions. Part of the data preparation process is mapping the source layer structure to the target platform's expected schema, which is a manual, case-by-case task that cannot be automated reliably.
Fallbacks and ongoing map maintenance
Assuming a CAD File Is Ready to Use
The single most common mistake is treating a received DWG or DXF file as a finished indoor map. Architectural CAD files are built for construction documentation, not navigation. They contain hatching, dimension lines, annotation text, furniture blocks, section markers and a host of other elements that are visually meaningful on a drawing but geometrically confusing to a mapping engine. They also frequently contain errors that are irrelevant to construction but fatal to navigation: unclosed polygons, overlapping lines, zero-length segments and features drawn on the wrong layer.
Before a CAD file can feed an indoor navigation system, it needs cleaning, filtering and restructuring. This is not a trivial step, and underestimating it is a reliable way to blow a project timeline.
Using Raster Plans Without Understanding the Consequences
Converting a PDF or image to a usable navigation asset means either manual vectorisation or automated tracing. Manual tracing is slow and introduces human error. Automated tracing tools can produce acceptable geometry for simple layouts but struggle with complex or cluttered drawings. In either case, the resulting vector data has no inherent attributes: every traced polygon is just a shape until someone manually labels it. For a venue with hundreds of rooms, that labelling effort is substantial.
Raster plans also introduce scale uncertainty. If the original drawing was printed at an unknown scale and then scanned, the pixel dimensions bear no reliable relationship to real-world measurements. Any navigation system built on that plan will position the user's dot incorrectly unless the scale is calibrated against known measurements on site.
Ignoring Floor-Level Relationships
A set of individual floor plans, one per level, does not constitute a multi-floor indoor map. The vertical connections between floors, stairwells, lifts and escalators, must be explicitly modelled. Most standard floor plan formats do not include this information. DXF files are inherently single-floor. GeoJSON can represent it but only if the data author has included the relationships. IndoorGML handles it natively, but converting from DWG to IndoorGML requires the vertical connections to be added during the transformation, not extracted automatically.
If a venue needs multi-floor routing and the source data does not include vertical links, those links must be surveyed and added manually. This is not a format problem; it is a data completeness problem that the format choice alone cannot solve.
Key Checks Before Committing to a Data Source
- Currency: Does the plan reflect the current building state? Ask when it was last updated and what changes have occurred since. Walk the space with a printed copy and mark discrepancies.
- Completeness: Are all floors present? Are all areas within the navigable space included, or have service corridors, storage areas and secondary entrances been omitted?
- Geometry quality: Open the file in a viewer and inspect for obvious errors: gaps in walls, duplicated lines, features extending beyond the building outline. These will cause problems in any navigation engine.
- Layer or attribute structure: Can rooms, corridors, doors and obstacles be distinguished programmatically, or does everything sit on one or two undifferentiated layers?
- Scale verification: Measure at least two known distances on the plan against real-world measurements. If they do not match within an acceptable tolerance, the plan cannot be used for positioning without correction.
- Format compatibility: Check the target platform's documentation for supported import formats. Do not assume that because a format is widely used, your specific platform handles it correctly. Test with a small section of the plan before committing to full conversion.
The practical outcome of evaluating floor plan data sources and formats is not choosing the "best" format in the abstract. It is determining whether the data you can actually obtain, in the condition it actually exists, can be brought to a state where your chosen platform can use it reliably, and what effort that transformation requires. That effort, not the format label, is the figure that should shape your project planning and budget.
