All articles Industry

AI Wayfinding Assistant for Venues

By The Kaleidr Team · Published August 27, 2026 · 19 min read

An AI wayfinding architecture separates destination discovery, route computation, and optional indoor positioning before showing validated map guidance.

An AI wayfinding assistant interprets a natural-language navigation request, resolves a destination from trusted venue records, and coordinates map or route guidance without treating discovery, routing, and positioning as one capability. A visitor can ask which entrance to use, how to reach Hall B, or where the nearest accessible restroom sits. The language model can recover those fields as inspectable intent; the venue system, the routing engine, and any positioning infrastructure remain authoritative for geometry, connectivity, access, and live location.

The sections below cover destination resolution, indoor connectivity, accessibility and access filters, origin sources, shared wayfinding state, Kaleidr’s current public fit, measurement, and failure modes. Related reading includes AI Venue Map for Events, How to Build a Map-Aware AI Assistant, Location Intelligence Customer Experience Maps, AI Guest Concierge for Hotels, and Private Location Data for AI Map Workflows.

AI wayfinding essentials

  • Discovery is not routing: Resolving Hall B is not the same as computing a connected path to Hall B.
  • Routing is not positioning: A valid route can exist before the product knows where the visitor stands.
  • A floor-plan image is not a network: Indoor guidance needs topology among spaces, doors, corridors, and floor transitions.
  • Accessibility and access are hard filters: Stairs, staff corridors, and closed edges must leave the graph, not merely score lower.
  • The language model interprets intent: Geospatial and venue systems calculate routes; the host validates map actions.

An AI wayfinding architecture separates destination discovery, route computation, and optional indoor positioning before showing validated map guidance.

What Is an AI Wayfinding Assistant?

An AI wayfinding assistant is a customer-facing layer that answers where a person should go in a complex place and how that person should travel there, using conversation, map context, and trusted location data. Ordinary search can return a room name. A static poster can show a drawing of the building. Neither encodes origin, floor, ticket eligibility, accessibility, live closures, and the currently displayed route as one inspectable state. Conference halls, campuses, hospitals, airports, resorts, and malls create that compound request every few minutes. The useful product keeps destination, route, and floor visible on the map rather than leaving the visitor to reconstruct them from signage, PDFs, and a chat panel that cannot move the camera.

Kaleidr’s Spatial AI page lists Navigate among map experiences and describes routes that fit the way a user travels (AI Map Chat for Customer Discovery). That page is authoritative about Kaleidr’s own outdoor and travel-oriented navigation positioning. Indoor turn-by-turn guidance is a different contract: destination intelligence, a routable network, and, only when the deployment actually has it, a positioning system. Customer-facing location intelligence still uses Discover → Compare → Act. Discover retrieves an eligible destination. Compare makes floor, travel relationship, accessibility, and access inspectable. Act is a highlight, a floor switch, a route request where routing exists, or a staff handoff.

The job should be written before the stack. A venue visitor may need the entrance closest to a seat. A conference attendee may need a path from the current hall to the next session. An airport passenger may need an eligible lounge near a gate. A campus user may need the building entrance closest to a classroom. A hospital visitor may need imaging from the public entrance. Each task changes candidates, hard constraints, vertical transitions, and whether live position is required. Starting from “indoor AI navigation” collapses those differences and invites a product claim the venue cannot support.

Why Must Discovery, Routing, and Positioning Stay Separate?

Destination discovery answers which place is relevant. Route computation answers which connected path an eligible visitor may use. Positioning answers where the visitor is now, on which floor, and, if the hardware supports it, which way the visitor faces. The three layers can cooperate. None substitutes for the others. A floor-plan image can show Room 204 and still lack corridor connectivity, open doors, accessible transitions, elevator service to the target floor, and a trustworthy origin. Turn-by-turn wording such as “turn left in ten meters” needs both a route and a live position with usable accuracy and orientation. The language model can coordinate the request. The language model cannot supply missing topology or a blue dot.

The Open Geospatial Consortium’s IndoorGML 2.0 Part 1 conceptual model is the current OGC conceptual schema for indoor navigation networks. The standard models spaces and space subdivisions, geometric and semantic properties, types of connectivity, and logical and metric navigation networks (OGC IndoorGML 2.0 Part 1 – Conceptual Model, OGC 22-045r5, published 26 June 2025). A production product does not have to serialize IndoorGML. The product does have to respect the same distinction: visual geometry is not a navigation graph. OGC’s 28 August 2025 publication notice described IndoorGML 2.0 Part 2 encodings as forthcoming (OGC Publishes IndoorGML 2.0 Part 1 Conceptual Model Standard). IndoorGML 1.1 remains a published encoding-oriented IndoorGML standard (IndoorGML 1.1, OGC 19-011r4, 5 November 2020). Cite Part 1 for the conceptual contract; do not treat a GML, JSON, or SQL IndoorGML 2.0 encoding as a published implementation standard until Part 2 exists as one.

The Indoor Mapping Data Format is a complementary OGC Community Standard for indoor location archives used for orientation, navigation, and discovery, including modeling notes for airports, shopping malls, and train stations (Indoor Mapping Data Format, OGC 20-094, version 1.0.0, published 18 February 2021). IndoorGML 2.0 Part 1 itself describes IMDF as providing a comprehensive model from which applications may derive paths, while IndoorGML aims at a unified space-graph approach. For an AI wayfinding assistant, the operational lesson is narrower: structured indoor data should exist before conversation promises navigation.

Outdoor wayfinding is often simpler because road or pedestrian networks, routing APIs, and GNSS already exist. The assistant can then geocode a destination, request a route from a provider, and draw the result. Indoor and hybrid campus flows usually need extra infrastructure: floor state, vertical transitions, access-controlled edges, and an origin that may not come from the browser. A campus path may stitch an outdoor GNSS leg to a building entrance and then an indoor graph. The conversational layer can explain the transition. The route engines still own each leg.

How Should Destination Resolution Work Before Routing?

Routing to the raw string “Hall B” is a product defect. The application should resolve a stable destination identifier, building, and floor before the routing engine runs. Display names collide: Gate 12 and Entrance 12 are different typed entities. Room, booth, and session identifiers collide in human language for the same reason the AI venue map keeps geometry separate from event overlay. Typed records for buildings, floors, entrances, rooms, gates, booths, restrooms, elevators, stairs, parking zones, and service desks keep search, map, route, accessibility, and analytics synchronized when labels change.

{
  "destinationId": "hall_b",
  "buildingId": "expo_center",
  "floorId": "floor_1",
  "type": "hall"
}

Eligibility belongs in the same step. A physically connected lounge can still be forbidden by ticket class, security zone, or staff-only designation. Candidate spaces should pass authorization and operating status before spatial comparison and explanation. Restricted polygons should be filtered before retrieval so the language model never has to “remember” which corridors are private. OWASP’s LLM01:2025 Prompt Injection describes how user or retrieved text can alter model behavior, including influence over connected functions. The OWASP Top 10 for LLM Applications 2025 lists LLM06:2025 Excessive Agency: damaging actions from unexpected or manipulated model output when a system is granted too much functionality, permission, or autonomy. A wayfinding assistant should propose a destination and an allowed action. The host application should execute the camera move, floor switch, or route request after schema, access, and network-state validation.

Ambiguity is a first-class outcome. “Main entrance,” “north entrance,” and “VIP entrance” can all be valid parses. The product should ask, list typed candidates on the map, or require a tap rather than guessing from string similarity. Direct destination search must still work when conversation fails. A visitor who types Hall B should not need a dialogue. Deterministic lookup, filters, map, and conversation for compound questions should share the same identifiers.

Why Does Indoor Routing Need Connectivity, Not a Floor-Plan Image?

Place lookup highlights a geometry. Indoor routing calculates across a connected graph: room to corridor to door to stair or elevator to another floor. Display polygons and routing nodes can be separate on purpose. A room polygon can attach to a doorway node; corridor edges carry travel; elevator and stair edges carry floor change, accessibility, and operational status. A raster floor plan with a decorative polyline is not that graph. The venue map guide draws the same line between showing a room and claiming a turn-by-turn path.

A multi-floor venue map is paired with its routing graph to show that indoor navigation depends on explicit connectivity between spaces, doors, corridors, elevators, and floors.

Multi-floor state has to be explicit. Origin and destination should carry building and floor identifiers. The UI should show when a route changes floors rather than hiding the transition inside a single 2D line. Vertical edges need typed attributes: stairs, elevators, escalators, ramps, accessibility, served floors, and open or closed status. The routing engine uses those attributes. The language model can explain them after the engine returns structured steps. Preferred flow is route engine to structured steps to clearer wording, not free invention of directions. Landmark-relative instructions such as “continue toward the central lobby, then use the east elevator” remain usable when compass heading is unavailable.

Temporary closures are operational records, not cartographic decoration. An escalator outage, blocked hallway, closed entrance, restricted floor, or elevator fault should mark an edge closed and force recomputation. The explanation the visitor reads should reflect the current route version. Stale geometry drawn in conversational prose is a safety issue in live venues, not a copy problem. Re-routing belongs to the engine: when origin changes or an edge closes, the previous route becomes invalid and a new route is computed. Asking the language model to patch coordinates is the wrong control surface.

How Do Accessibility, Access Rules, and Closures Filter Routes?

Required accessibility is a hard routing constraint. If the visitor asks for an accessible route, stair edges may be excluded. A complete accessible path can require step-free travel, a working elevator, an accessible entrance, and doorway width that the venue has actually recorded. Mixing accessibility into a soft preference weight can still rank an inaccessible path first. Missing accessibility data is not a license to invent a fully accessible route. When the system only knows an accessible entrance and elevator, the honest statement is that those features are shown on the map, not that a complete accessible path has been certified. Legal accessibility duties remain a judgement for qualified counsel and the venue operator; this post describes the data contract.

Three candidate routes are filtered by accessibility, access permission, and current operational status until only the valid route remains.

Physical connectivity is only one eligibility axis. Staff corridors, VIP gates, security zones, ticketed areas, and employee entrances can be walkable in the graph and still forbidden for this visitor. Route eligibility is physical connectivity plus access permission plus operational status. Restricted paths should never reach the conversational layer before access control is applied. The safe sequence is authenticate, determine access, retrieve allowed spaces, calculate an allowed route, then explain. Computing a path across all spaces and hiding restricted steps afterward leaks topology. Map API authentication covers publishable versus server keys for the Kaleidr surfaces that attach conversation to a host map; venue access rules still live in the host’s identity and ticket systems.

Emergency and safety routing is high-stakes. A generative assistant should not invent evacuation paths, emergency procedures, or restricted safety guidance from generic model knowledge. Use venue-approved emergency content, official plans, live staff, and operational alerts. A wayfinding product may surface approved first-aid or exit locations when those records are authoritative. High-stakes routing belongs to the operational system designed for that duty.

When Does Wayfinding Need Positioning, and When Does It Not?

Every route needs an origin. Origins can come from an explicit map selection, a known landmark such as the main entrance, a last stated area (“I am at Hall A”), outdoor device location, or indoor positioning infrastructure. Manual origin must remain available even when automatic positioning exists. Confidence is data. A positioning report that is accurate to a few meters may support corridor-scale guidance. A report that is uncertain by tens of meters indoors can select the wrong corridor or floor. The product should be able to say that indoor location is uncertain and ask the visitor to select the current area. Confident routing from a bad origin is worse than a short clarification.

The W3C Geolocation specification, a Candidate Recommendation Snapshot dated 26 March 2026, provides access to device location only after express permission and states that the API gives no guarantee of the device’s actual location. A browser location fix is not an indoor blue dot. Bluetooth beacons, Wi-Fi positioning, ultra-wideband, visual positioning, and venue-specific systems are infrastructure, not a language-model feature. Orientation is a further requirement for “turn left” instructions. A map can still show a correct route without heading. When heading is unavailable, landmark or map-relative wording should replace compass claims.

Many venues can ship useful wayfinding without continuous indoor tracking. The visitor selects a landmark, the engine returns a route, static steps remain on the map, and the visitor advances manually. Conferences, campuses, resorts, and museums often need that pattern more than a live blue dot. The pattern also reduces privacy and infrastructure cost. Wayfinding can create detailed movement history: current indoor location, route, repeated destinations, workplace, medical department, or event attendance. The NIST Privacy Framework (NIST.CSWP.01162020, 16 January 2020) treats privacy as enterprise risk management: identify what is collected, why, and for how long. Prefer temporary origin, destination, and route context over a persistent movement profile. Private location data for AI map workflows covers the same host-owned boundary.

How Should Conversational Wayfinding Share State With the Map?

Conversation becomes useful after a destination or route is already on the map. Follow-ups such as a restroom along the current path, a request to avoid stairs, or a closer entrance from the selected origin depend on shared state, not a second unofficial result list. Map, list, instructions, and chat should read one wayfinding record: origin, destination, active floor, route identifier, route version, accessibility mode, and position confidence when a positioning system is present. Selecting a destination can show a route. Changing accessibility mode can invalidate the current version and request a recompute. Assistant results should appear on the same map the visitor already uses.

A shared wayfinding state synchronizes conversational requests, route data, floor context, venue information, and validated map actions.

{
  "routeId": "route_north_to_hall_b",
  "originId": "entrance_north",
  "destinationId": "hall_b",
  "mode": "accessible",
  "activeFloorId": "floor_1",
  "routeVersion": 4
}

Semantic actions should stay small: set origin, focus destination, show route, switch floor, highlight a transition, open a destination record, clear route, request re-route. The host validates each payload against current identifiers, access, and network version before the renderer adapter runs. Arbitrary map JavaScript is not a control contract. Permissions for those actions belong to the application and infrastructure, never to the language model. The map-aware assistant guide covers shared map state and validated actions for that handoff.

Operational updates should version both the network and the route. An elevator closure can invalidate route version 4 on network version 18 and require version 5. Versioning makes stale guidance debuggable. Validation before applying a route should confirm that origin, destination, permission, route freshness, closures, and travel mode still match. Wayfinding state changes quickly in live venues. Offline or weak connectivity is also normal indoors. Cache venue geometry, labels, last floor, and a last good route where appropriate. Direct place lookup must survive if the conversational layer fails. Spatial analytics dashboard KPIs belong to product measurement, not to treating chat volume as success.

How Does Kaleidr Fit an Existing Wayfinding Stack?

Kaleidr’s current developer documentation positions Chat as a conversational layer attached to a map the host already runs. The Quickstart shows mounting Chat against a live Mapbox, MapLibre, Google Maps, or Leaflet instance. Chat attach describes the Control Tower as chat-driven navigation, place summaries, and place pins over that host map. Publishable keys are origin-locked for the browser; server keys stay off the page (Auth & Scopes). Snippets should use an obvious placeholder rather than a live-shaped key.

const handle = Kaleidr.mount("#chat", {
  product: "chat",
  publishableKey: "YOUR_PUBLISHABLE_KEY",
  map: myMap,
});

Those surfaces support natural-language destination discovery, map-aware conversation, place answers, live markers, and camera updates. The host continues to own the renderer, venue data, route engine, indoor topology, positioning, and access control. Kaleidr’s public docs describe AI map chat, published maps, designed basemaps, and map editing. Those docs do not currently document a dedicated indoor positioning engine or a specialized turn-by-turn indoor navigation product. A correct architecture is therefore conversational and map-aware interaction on Kaleidr, with specialized indoor routing or positioning remaining in the venue or navigation system when the deployment needs them. Location Intelligence APIs and Map SDK is the current commercial surface for inference APIs, ranking systems, analytics, and deployment support. Ranking and indoor routing are still different products; do not encode a fictional indoor-nav route from marketing language.

Hybrid places still fit that split. Outdoor legs can use a routing provider. Indoor legs can use a venue graph. Event overlays can change booths and sessions without rebuilding walls, as the venue-map article describes. Hospital and airport requests often fail first on destination identity and access, not on path drawing: “imaging” and “the lounge I may use near Gate 42” are eligibility problems before they are geometry problems. The language model can interpret the request. Authorized business data and geospatial services still supply the facts.

How Should Teams Measure an AI Wayfinding Assistant?

Measure the wayfinding job, not chat volume. Destination resolution rate, no-result rate, route success, wrong-floor corrections, reroute rate, access denials, time to a returned route, destination confirmation, and route abandonment describe whether visitors actually get somewhere. If positioning is present, add off-route events, location-confidence failures, and floor-detection failures. Keep discovery separate from navigation: a resolved destination with a failed route is a different defect from a failed lookup. Editorial event names such as destination resolved, route requested, route failed, floor changed, and reroute are product analytics, not documented automatic Kaleidr Analytics events.

Evaluation should include ambiguity, cross-floor paths, closed edges, restricted access, missing accessibility data, and low-connectivity fallback. Test that map, list, and spoken or written steps show the same route version. Latency should be attributed per stage; teams that blame “AI” often find that routing or origin resolution dominates. Task completion outranks interaction count. A visitor who finds Hall B through search without chatting has succeeded. A long conversation that ends on the wrong floor has not.

What Failure Modes Should Wayfinding Products Avoid?

The recurring failure is collapsing three systems into one generated paragraph. A floor-plan image is treated as a router. The language model is treated as a positioning system. Floors disappear. Accessibility becomes a preference weight. Restricted edges leak. Turn-by-turn wording appears without orientation. Conversation becomes mandatory. Movement history persists by default. Each row below is a product defect with a concrete correction.

Mistake Result Better approach
Treat a map image as a navigation network Routes cannot be trusted Model connectivity
Treat the language model as a positioning system Origin becomes unreliable Use an explicit origin source
Ignore floors Wrong-floor guidance Track floor in shared state
Let the model invent a route Unsafe or stale path Use the route engine
Treat accessibility as a preference An inaccessible route can win Use hard constraints
Ignore temporary closures Stale route Update edge status and recompute
Route through restricted areas Access leak Filter the graph before routing
Promise turn-by-turn without orientation Misleading instructions Use landmark or map-relative wording
Make conversation mandatory Basic navigation fails when chat fails Keep deterministic search
Persist movement by default Privacy risk Keep temporary route context

Mobile wayfinding needs large targets, readable steps, and a map that remains usable when the model or an expensive route times out. Cache base geometry. Degrade enrichment in a controlled way. Preserve a path from typed search to highlight even when conversation is unavailable.

Build a Conversational Wayfinding Experience

The reliable architecture is intent, destination resolution, authorized routing, route computation, explanation, and a validated map action. Indoor positioning is an optional later layer, added only when the venue operates a suitable system. Kaleidr can attach conversational spatial AI to the map a host already runs, while venue topology and specialized routers stay authoritative where true indoor navigation is required.

Explore Kaleidr Enterprise for current APIs, SDK surfaces, and deployment support. Review attach patterns and key types in the Kaleidr developer documentation before encoding an integration path.

FAQs

What is an AI wayfinding assistant?

An AI wayfinding assistant interprets natural-language navigation questions, resolves the intended destination from trusted records, and coordinates map or route guidance. Routing and positioning remain separate systems.

Is AI wayfinding the same as indoor navigation?

No. Conversation can interpret a navigation request. Indoor navigation also requires a structured routing network and may require indoor positioning.

Can a floor-plan image be used for turn-by-turn routing?

Not by itself. Reliable routing requires connectivity among spaces, doors, corridors, stairs, elevators, and other transitions.

What is IndoorGML?

IndoorGML is an OGC standard for indoor spatial and navigation data. IndoorGML 2.0 Part 1 is the current conceptual model for spaces, connectivity, and navigation networks (OGC 22-045r5). OGC described IndoorGML 2.0 encoding schemas as forthcoming as of August 2025; IndoorGML 1.1 remains a published encoding-oriented version.

What is IMDF?

The Indoor Mapping Data Format is an OGC Community Standard (OGC 20-094, version 1.0.0) for indoor location archives used for orientation, navigation, and discovery.

Does Kaleidr currently provide indoor positioning?

Kaleidr’s current public documentation describes spatial AI, map chat, custom maps, publishing, and existing-map integration. That documentation does not describe a dedicated indoor positioning system, so indoor positioning should be treated as a separate deployment capability unless the host integrates one.

Can Kaleidr work with an indoor map?

Kaleidr can attach conversational AI to compatible existing map implementations. The host application remains responsible for map data, the route network, and any indoor positioning.

How should accessible wayfinding work?

Accessibility requirements should be encoded as hard route constraints using verified venue data. The assistant should not invent an accessible route from incomplete information.

Can an AI map assistant reroute a visitor?

The assistant can request or explain a new route. The authoritative routing engine should recompute using current network conditions and access rules.

Should wayfinding track a user's location continuously?

Only when the product needs it and the user has appropriate notice or consent. Many wayfinding tasks can work with a selected origin or landmark without persistent tracking.

References

@misc{kaleidr_wayfinding_ai_2026_08_27,
  title  = {AI Map Chat for Customer Discovery},
  author = {{Kaleidr}},
  note   = {Accessed 27 August 2026},
  url    = {https://kaleidr.com/ai}
}

@misc{kaleidr_auth_scopes_2026_08_27,
  title  = {Auth \& Scopes},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/platform-api/auth-and-scopes}
}

@misc{kaleidr_chat_attach_2026_08_27,
  title  = {Chat attach},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/sdk/chat-attach}
}

@misc{kaleidr_docs_intro_2026_08_27,
  title  = {Introduction},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/}
}

@misc{kaleidr_enterprise_wayfinding_2026_08_27,
  title  = {Location Intelligence APIs and Map SDK},
  author = {{Kaleidr}},
  note   = {Accessed 27 August 2026},
  url    = {https://kaleidr.com/enterprise}
}

@misc{kaleidr_quickstart_wayfinding_2026_08_27,
  title  = {Quickstart},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/quickstart}
}

@techreport{nist_privacy_framework_2020,
  title       = {NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0},
  author      = {{National Institute of Standards and Technology}},
  number      = {NIST.CSWP.01162020},
  institution = {National Institute of Standards and Technology},
  year        = {2020},
  month       = jan,
  url         = {https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf}
}

@techreport{ogc_indoorgml_1_1,
  title       = {IndoorGML 1.1},
  author      = {{Open Geospatial Consortium}},
  number      = {OGC 19-011r4},
  institution = {Open Geospatial Consortium},
  year        = {2020},
  month       = nov,
  url         = {https://docs.ogc.org/is/19-011r4/19-011r4.html}
}

@techreport{ogc_imdf_1_0_0,
  title       = {Indoor Mapping Data Format},
  author      = {{Open Geospatial Consortium}},
  number      = {OGC 20-094},
  institution = {Open Geospatial Consortium},
  year        = {2021},
  month       = feb,
  note        = {OGC Community Standard, version 1.0.0},
  url         = {https://docs.ogc.org/cs/20-094/index.html}
}

@techreport{ogc_indoorgml_2_0_part1,
  title       = {OGC IndoorGML 2.0 Part 1 – Conceptual Model},
  author      = {{Open Geospatial Consortium}},
  number      = {OGC 22-045r5},
  institution = {Open Geospatial Consortium},
  year        = {2025},
  month       = jun,
  url         = {https://docs.ogc.org/is/22-045r5/22-045r5.html}
}

@misc{ogc_indoorgml_2_0_announcement_2025_08_28,
  title  = {OGC Publishes IndoorGML 2.0 Part 1 Conceptual Model Standard},
  author = {{Open Geospatial Consortium}},
  year   = {2025},
  month  = aug,
  note   = {Accessed 27 August 2026},
  url    = {https://www.ogc.org/announcement/ogc-publishes-indoorgml-2-0-part-1-conceptual-model-standard/}
}

@misc{owasp_llm01_prompt_injection_2025,
  title  = {LLM01:2025 Prompt Injection},
  author = {{OWASP Gen AI Security Project}},
  note   = {Accessed 27 August 2026},
  url    = {https://genai.owasp.org/llmrisk/llm01-prompt-injection/}
}

@misc{owasp_llm_top10_2025,
  title  = {OWASP Top 10 for LLM Applications 2025},
  author = {{OWASP Gen AI Security Project}},
  note   = {Accessed 27 August 2026},
  url    = {https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf}
}

@misc{w3c_geolocation_2026_03_26,
  title  = {Geolocation},
  author = {{W3C}},
  note   = {W3C Candidate Recommendation Snapshot, 26 March 2026; accessed 27 August 2026},
  url    = {https://www.w3.org/TR/geolocation/}
}

Related content

Turn Your Map Into a Growth Engine