Indoor Positioning

Indoor positioning determines a user's location inside a building. Satellite-based positioning, such as GPS, is not reliable indoors because the signals in use do not penetrate building structures. Cellular positioning can provide a rough location, but it is often not accurate enough to place a user on the correct floor or in front of the correct storefront.
For this reason, Mappedin Web supports several positioning methods that produce an accurate indoor location. Each method provides the user's position, and where supported, their heading, to be displayed as a Blue Dot on the map.
Indoor Positioning Systems
An Indoor Positioning System (IPS) is a technology that determines a device's location while it is inside a building. Satellite signals are unavailable indoors, so an IPS instead relies on technologies such as Wi-Fi, Bluetooth Low Energy (BLE) beacons, or a visual scan of the surrounding environment.
Mappedin Web can display a location provided by an IPS. When a position is supplied, Mappedin Web renders a Blue Dot on the map so a user can see their location and navigate from it.
Apple Indoor Positioning
Apple Maps Indoor is an IPS that provides indoor location on Apple devices. It works natively in the browser on iOS devices, requiring no additional setup in Mappedin Web. When an Apple device supplies an indoor location, Mappedin Web can use that position directly.
To use Apple Maps Indoor, the venue must be registered with the Apple Maps Indoor Program. A Mappedin map can be exported to Indoor Mapping Data Format (IMDF) and imported into the Apple Maps Program. For more information, refer to the Mappedin IMDF Export Page.
Mappedin Visual Positioning System
Mappedin's Visual Positioning System (VPS) determines a precise indoor position and heading by scanning the user's surroundings with the device camera. Unlike an IPS that relies on radio signals, VPS compares the camera view against the venue's visual map data to determine where the user is and which direction they are facing.
VPS runs within Mappedin Web using the browser's camera. After a scan, the user's position and heading are set on the map as a Blue Dot. VPS is useful when no other indoor positioning source is available, or when a heading is required in addition to a position — for example, to orient the user before starting step-by-step directions.
Third-Party IPS
Mappedin Web can also receive position updates from a third-party IPS. This is useful when an organization has an existing IPS, such as a Wi-Fi or BLE beacon deployment, and wants Mappedin Web to use its positions rather than the browser's GPS.
To use this method, Mappedin Web is embedded inside a host container, such as a native application using a WebView or an iframe. The host application owns indoor positioning and sends position updates to Mappedin Web. While this mode is active, Mappedin's VPS and the browser's GPS is not used and other on-device positioning sensors are disabled, so the host's positions are the source of truth.
This capability is not enabled by default. Mappedin must enable a third-party IPS for the map before position updates are accepted.
The host sends each position update to Mappedin Web using a postMessage call with the following message shape:
{
type: "mappedin:bluedot:position",
payload: {
lat: number, // Required — latitude
lon: number, // Required — longitude
bearing: number, // Optional — compass heading in degrees, 0 to 360
floorLevel: number, // Optional — the floor elevation
accuracy: number, // Optional — accuracy in meters
}
}
lat and lon are required and must be numeric values. The remaining fields are optional and can be provided when the IPS measures them.
The following example shows a host page sending a position update to Mappedin Web embedded in an iframe:
const iframe = document.getElementById("mappedin-map");
iframe.contentWindow.postMessage(
{
type: "mappedin:bluedot:position",
payload: {
lat: 43.86,
lon: -79.34,
bearing: 90,
floorLevel: 1,
},
},
"https://<domain-hosting-the-map-page>",
);
The host controls how often position updates are sent. Each new update moves the Blue Dot to the reported position.
The targetOrigin argument should be set to the origin of the page that displays the map — the scheme, host, and port (if non-default) of the document loaded in the <iframe> or WebView, with no path. Since the payload carries location data, restricting the target origin prevents the message from being delivered to a different window if the iframe is redirected.
In a React Native application the app itself is the host, and Mappedin Web is loaded inside a WebView (using react-native-webview). There is no parent page and no cross-origin iframe, so the targetOrigin consideration above does not apply. The native side computes the position and sends each update into the WebView as a JSON string using the WebView's postMessage method, or by injecting JavaScript to call window.postMessage:
const webViewRef = useRef();
// Send a position update from the native host into the WebView
webViewRef.current.postMessage(
JSON.stringify({
type: "mappedin:bluedot:position",
payload: {
lat: 43.86,
lon: -79.34,
bearing: 90,
floorLevel: 1,
},
}),
);