[Developers]

Location Intelligence: Multi-Source Address and Coordinate Resolution

The Location Intelligence module resolves caller-stated location information, in a wide range of formats, into precise geographic coordinates before emergency units are dispatched. Callers describe their location in doze

Category: IntelligenceLast Updated: Jul 16, 2026
intelligenceai

Overview#

The Location Intelligence module resolves caller-stated location information, in a wide range of formats, into precise geographic coordinates before emergency units are dispatched. Callers describe their location in dozens of ways: a street address, a what3words code shown on a sign, a Google Plus Code from a hiking app, a landmark or business name, or simply the name of a place they recognise. The module tries each resolution method in a prioritised waterfall, falling back to the caller's registered address if all other methods fail, and returns a confidence score with every result so dispatchers can immediately assess how precisely the location has been pinned.

A GPS mismatch detection layer cross-checks stated locations against any device-reported coordinates, flagging discrepancies that may indicate a false report or a caller who is in a different location than described.

Key Features#

  • what3words Resolution: Recognises the ///word.word.word format and resolves it to coordinates via the what3words API, delivering 3-metre square precision with a 95% confidence score, particularly valuable for rural incidents, events in open spaces, and locations without conventional postal addresses
  • Google Plus Code Resolution: Detects Plus Code patterns (such as 9C3W9QCJ+2V) and geocodes them via the Google Maps API with regional context for improved accuracy, returning a 90% confidence score
  • Street Address Geocoding: Full postal address text is geocoded against the Google Maps API, with confidence scoring tiered by result type: rooftop matches (95%), interpolated range (85%), geometric centre (75%), and approximate results (60%)
  • POI and Landmark Lookup: Location text that does not match an address or code format is treated as a point-of-interest or business name query, using fuzzy matching against the Google Places API with stopword stripping for improved hit rates; a two-pass approach tries strict matching before falling back to fuzzy
  • Caller-Registered Address Fallback: When all other resolution methods fail, the caller's pre-registered home or work address from their profile is used as a fallback, ensuring dispatch is never completely uninformed about location
  • Confidence-Scored Results: Every resolved location includes a numeric confidence value (0.0 to 1.0) and a source label identifying which method produced the fix (what3words, Plus Code, street address geocoding, point of interest, registered address, or unresolved), giving dispatchers transparent signal quality alongside the coordinate
  • GPS Mismatch Detection: When device GPS coordinates are available alongside a stated address, the module calculates the Haversine distance between the two. Discrepancies exceeding 5 kilometres are flagged as a mismatch and surfaced to the dispatcher
  • Graceful Degradation: If third-party location APIs are unavailable, the module returns a partial result at the deepest level reached rather than blocking dispatch; all external service credentials are optional and the module operates in reduced-accuracy mode without them
  • Verified Location in the Live Call Queue: Dispatchers see verified caller location directly in the call queue: coordinates, the source of the fix, its accuracy radius in metres, a freshness timestamp showing when the position was last updated, and a formatted address once location verification has completed. Location is extracted from live call-session data across multiple device and carrier formats
  • Display-Safe Location Validation: Only operator-safe location fields are exposed to the console; invalid, non-finite, or negative-accuracy values are rejected before display rather than presented as a plausible fix
  • Two-Way Map and Call Sync: Selecting a call in the queue centres the common operating picture on that caller's location, and selecting an incident on the map highlights the linked call. Queued calls retain their location accuracy metadata until answered, so the map reflects the best available caller position from the moment the call is picked

Use Cases#

Rural Emergency with what3words#

A hiker injured on an unmarked trail shares the what3words code visible on a nearby trail marker sign. The system resolves it to a 3-metre square in under a second, giving ambulance crews an exact location they could not have obtained from a verbal description of the surrounding landscape.

Event Location via Plus Code#

A caller at an outdoor festival uses the Plus Code shown on the event programme. The system decodes and geocodes it, pinning the location to within a building footprint even though the caller does not know the full postal address of the venue.

Business Name Incident#

A caller says "I'm outside the Tesco on the Main Road in Kilkenny." POI lookup identifies the specific branch, resolves it to precise coordinates, and returns the address with an 80% confidence score for dispatcher review.

GPS Cross-Verification#

A caller claims to be calling from an address in one part of the city, but their device GPS places them 12 kilometres away in a different neighbourhood. The GPS mismatch flag is raised in the dispatcher interface, prompting a verification question before units are committed.

No Address Available#

An anonymous caller cannot or will not provide a location. All resolution attempts fail. The system falls back to the caller's registered home address if a profile exists, providing the dispatcher with a probable location rather than nothing.

Queue Pick with Instant Map Context#

A dispatcher clicks the next queued call and the common operating picture immediately centres on the caller's verified position, showing where they are relative to responding units. The source label and accuracy radius let the dispatcher judge the trustworthiness of the fix at a glance before committing resources, and a mobile caller who cannot describe their surroundings can still be dispatched to on the strength of their verified device location.

How It Works#

Integration#

Location Intelligence is invoked during call setup in the Voice AI session layer, and its resolved coordinates are passed directly to the Incident Management module for unit dispatch. The confidence score and source type are displayed in the dispatcher's call panel alongside the resolved address, enabling immediate human review of lower-confidence results. what3words and Google Maps service credentials are configured at the organisation level through the administration console. The GPS mismatch flag is surfaced as an advisory event in the incident record and dispatcher interface, not as an automatic block on dispatch. Verified location details also appear directly in the live call queue, and location context is carried into the live call intelligence brief alongside AI and transcript context. Call selection and the common operating picture stay in two-way sync: picking a call focuses the map on the caller's position, and selecting a mapped incident links back to the live call view.

Open Standards#

  • NENA-STA-006.3 (NG9-1-1 GIS Data Model): The module's internal civic-address and boundary layers (PSAP boundary, Emergency Service Boundaries, Road Centreline, Site/Structure Address Points, and administrative A1/A2/A3 boundaries) are implemented using the exact field vocabulary and topology rules defined in the NENA-STA-006.3-2026 standard, enabling interoperability with any NENA-conformant GIS provisioning tool.
  • RFC 5222 (LoST, Location-to-Service Translation): Resolved coordinates are forwarded to a LoST server via the ECRF/LVF layer to obtain the authoritative PSAP service URI; the RouteURI field in each GIS boundary layer carries the RFC 5222 routing URI.
  • RFC 4119 / RFC 5491 (PIDF-LO, Presence Information Data Format Location Object): When routing to an EENA NG112-compliant ESRP, the module constructs a PIDF-LO XML document containing a GML Point in WGS-84, the standard location payload for next-generation emergency call routing.
  • ETSI TS 103 393 (Advanced Mobile Location): The AML receiver parses the semicolon-delimited SMS body pushed by handset operating systems during 999/112 calls, extracting WGS-84 latitude/longitude, radius, and positioning method as defined in the European AML specification.
  • OGC GeoPackage (OGC 12-128r19): GIS boundary and address-point layers can be exported and ingested in GeoPackage format, with the module implementing the mandatory GeoPackage metadata tables for spatial reference systems, contents, and geometry columns, plus the GeoPackage Binary geometry header, per the OGC specification.
  • WGS 84 (EPSG:4326): All resolved coordinates, GIS layers, and exported geometries use WGS 84 as the mandatory coordinate reference system; the validation service rejects any layer containing geometries with a non-4326 SRID.
  • RFC 7852 / NENA-STA-012 (Additional Data Related to an Emergency Call): Subscriber and device information accompanying a location resolution is structured as RFC 7852 Additional Data blocks (SubscriberInfo, DeviceInfo, ProviderInfo, and others), allowing downstream CAD systems to consume caller context in a standards-defined format.
  • ISO 3166-1: Country codes stored in every NENA GIS layer follow the ISO 3166-1 alpha-3 standard, ensuring civic addresses interoperate with national emergency-routing databases across jurisdictions.

Last Reviewed: 2026-07-16 Last Updated: 2026-07-16

Ready to Build?

Get started with our APIs or contact our integration team for support.