Building Location-Aware Applications

Coordinate Systems and Precision

Coordinates look simple. Latitude and longitude, two numbers. The complexity hides in the details.

WGS84: The Standard

WGS84 (World Geodetic System 1984) is the coordinate reference system used by GPS and most mapping services. Coordinates are expressed as latitude (north/south, -90 to +90) and longitude (east/west, -180 to +180). Store coordinates in this format unless you have a specific reason not to.

Some legacy systems use other coordinate systems. British National Grid (EPSG:27700) is common in UK government data, including Ordnance Survey datasets and local authority planning systems. UTM (Universal Transverse Mercator) appears in surveying data. PostGIS handles conversions between systems using ST_Transform, so you can ingest EPSG:27700 data from OS sources and convert on import: ST_Transform(geom, 4326) converts British National Grid to WGS84.

Precision Matters

Coordinate precision directly affects accuracy. Each decimal place represents roughly:

For most business applications, 6 decimal places is sufficient. Storing more precision wastes space without adding useful accuracy (GPS itself is typically accurate to 3-5 metres under normal conditions).

The Earth Is Not Flat

The Haversine formula calculates the great-circle distance between two points on a sphere. It is computationally cheap and accurate enough for most purposes. For distances under 20km, the error from assuming a perfect sphere is negligible.

For longer distances or when accuracy matters (surveying, precise routing), use the Vincenty formula or PostGIS's geography type, which accounts for the Earth's ellipsoidal shape. The difference between spherical and ellipsoidal calculations can be up to 0.5% over long distances.

Geocoding: Addresses to Coordinates

Converting addresses to coordinates (forward geocoding) and coordinates to addresses (reverse geocoding) is fundamental. It's also where naive implementations become expensive.

The Naive Approach

Call a geocoding API every time you need coordinates. Google Maps Geocoding API, Mapbox, or HERE. Pass the address string, get back latitude and longitude.

This works until:

• You process a bulk import of 10,000 customer addresses and the API bill arrives
• The API rate-limits you mid-import and the job fails
• Users experience latency spikes during address entry
• The same addresses get geocoded repeatedly across different features

The Robust Pattern: Geocode on Write, Cache Aggressively

The principle is simple: geocode addresses at the point of entry (import, user submission, CRM update), store the result, and avoid re-geocoding the same address at read time. Coordinates change when buildings are demolished, not when a user loads a page. Pre-geocoding at write time eliminates per-request API costs and latency entirely. Note: some providers (notably Google) restrict how long you can cache results and require periodic re-validation. Check your provider's terms of service for caching rules before implementing. This requires:

Provider Selection

Geocoding providers vary significantly in accuracy, coverage, and cost.

For UK-focused applications, a hybrid approach works well. Use Postcodes.io for initial postcode-based lookups (free, fast), then fall back to Google or Mapbox for full address resolution when door-level precision is needed.

UK-Specific Data Sources

Global geocoding providers miss nuances in UK address data. Several UK-specific sources fill the gaps:

• Ordnance Survey Data Hub: AddressBase provides authoritative UK address data with UPRN (Unique Property Reference Number), the canonical identifier for every addressable location in Great Britain. OS Maps API and OS Features API offer high-quality UK mapping. Commercial licensing costs apply, but the data quality for UK addresses exceeds any global provider.
• Royal Mail PAF: The Postcode Address File validates UK postal addresses. Useful for address entry validation and normalisation, though it requires a licence.
• what3words: Divides the world into 3m squares, each with a three-word address. Adopted by UK emergency services. Useful for locations without traditional addresses (rural sites, event spaces, construction sites). API costs per lookup.
• UPRN: The Unique Property Reference Number is the gold standard for UK address matching. If your application deals with UK property data, planning, or utilities, storing UPRNs alongside coordinates prevents the duplicate-address problems that plague postcode-only systems.

UK addresses also present specific normalisation challenges. Welsh locality names with diacritics, Scottish address structures that confuse global parsers, rural house names without street numbers, and new-build postcodes that lag behind in provider databases all cause problems. Test your geocoding against these edge cases early.

Address Autocomplete

Address autocomplete provides suggestions as users type, reducing errors and improving data quality. Google Places Autocomplete is the standard, but charges per session (a session covers all keystrokes until selection).

Implementation pattern: debounce input (wait 300ms after typing stops before querying), restrict to relevant countries, bias results toward user location, and validate the final selected address with a geocode call.

Geocoding sits at the boundary between your application and external services. The same patterns that apply to any API integration apply here: rate limiting, retry logic, circuit breakers for provider outages, and fallback chains when a primary provider returns low-confidence results.

Spatial Databases: PostGIS

Storing coordinates as decimal columns works for simple cases. Once you need to answer questions like "find all locations within 10km" or "which delivery zone contains this address", you need a spatial database.

The Naive Approach

Store latitude and longitude as decimals. Calculate distances in application code. For "find nearest", pull all records and sort by calculated distance.

This fails at scale. Calculating distance for 50,000 records takes seconds. The database can't use indexes for distance queries because the calculation happens after retrieval. Memory usage spikes when loading all records for in-application filtering.

The Robust Pattern: PostGIS

PostGIS extends PostgreSQL with spatial types and functions. Coordinates become geometry or geography objects. Spatial indexes enable fast queries against millions of records.

Geometry vs Geography Types

PostGIS offers two spatial types with different calculation methods:

For most business applications, geography is the better default. The performance difference is measurable but rarely significant with proper indexing.

Essential Spatial Queries

PostGIS provides functions for common spatial operations:

Spatial Indexing

Spatial indexes (GiST or SP-GiST) are essential for performance. Without them, every spatial query scans the entire table. With them, PostGIS can eliminate most records before calculation.

CREATE INDEX idx_locations_geom ON locations USING GIST (location);

PostGIS does not create spatial indexes automatically. You must create them explicitly, and verify with EXPLAIN ANALYZE that your queries are using the index. When setting up spatial columns through database migrations, include the GiST index in the same migration as the column creation. Forgetting the index is the single most common PostGIS performance mistake.

GeoJSON: The Interchange Format

GeoJSON (RFC 7946) is the standard format for exchanging spatial data between server and client. PostGIS converts to and from GeoJSON natively with ST_AsGeoJSON and ST_GeomFromGeoJSON. All major map libraries (Mapbox GL JS, Leaflet, MapLibre) consume GeoJSON directly.

For your API endpoints, return GeoJSON FeatureCollections. This keeps your spatial data interoperable: the same endpoint can feed a web map, a mobile app, or a data export. For large datasets, consider streaming GeoJSON or converting to vector tiles with Tippecanoe instead.

ORM Integration

The bridge between PostGIS and application code is where many implementations stall. Raw SQL spatial queries work, but they bypass your ORM's query builder, making code harder to test and maintain.

In Laravel, packages like laravel-postgis add spatial column types to migrations and Eloquent model casts for geography types. Define query scopes for common spatial operations (scopeWithinDistance, scopeInZone) so the rest of your application works with familiar Eloquent syntax. The underlying SQL uses PostGIS functions, but application code reads cleanly. Good data modelling matters here: separate your spatial concerns (a locations table with geography columns and spatial indexes) from your business entities, joined by foreign key.

Map Display and Rendering

Map display seems straightforward: embed a map, add markers. The complexity emerges with scale (thousands of markers), customisation requirements, and mobile performance.

Provider Options

The mapping library you choose affects performance, cost, and how much control you have over styling. Each option sits at a different point on the trade-off between convenience and flexibility.

For internal business applications, Mapbox GL JS or Maplibre typically offer the best balance of capability and cost. For consumer applications where users expect familiar UI, Google Maps may be worth the premium. For applications requiring 3D terrain, globe visualisation, or spatial data overlaid on geography, see our work on geospatial and globe visualisation with Three.js.

Raster vs Vector Tiles

Traditional maps use raster tiles: pre-rendered images at each zoom level. Vector tiles send raw geometry data and render on the client.

Vector tiles are the modern standard. Use raster only when supporting legacy devices or when map styling isn't needed.

Handling Many Markers

Displaying thousands of markers causes performance problems. The browser struggles to render them all, and the map becomes unusable visually.

Marker Clustering

Group nearby markers into clusters that show a count. Expand on zoom or click. Leaflet.markercluster and Mapbox's cluster sources handle this automatically. For 10,000+ points, server-side clustering (PostGIS ST_ClusterKMeans) before sending data to the client improves initial load.

Viewport Loading

Only load markers visible in the current viewport. As the user pans or zooms, fetch new data. Requires a spatial query backend (PostGIS) that can efficiently return points within the current bounding box using ST_MakeEnvelope. Include a buffer around the viewport to prevent flickering during pan.

Vector Tile Data Layers

For very large datasets (100,000+ points), generate vector tiles from your data. Tippecanoe (from Mapbox) converts GeoJSON to vector tiles. Serve from a tile server as static files or generate dynamically on request. The map library handles rendering efficiently using WebGL.

When to Level Up

Most location features start simple and grow. The trick is recognising the breakpoints where your current approach stops working and the next level of infrastructure becomes necessary.

Each upgrade adds complexity but solves a real operational problem. The cost of upgrading too early is wasted engineering. The cost of upgrading too late is a broken production system. Watch your record counts, API bills, and user complaints for the signals.

Routing and Optimisation

Simple directions (A to B) are a solved problem. Multi-stop route optimisation with constraints is computationally hard and remains an active area of development.

Directions APIs

All major providers offer directions APIs: Google Directions, Mapbox Directions, HERE Routing, OSRM (open source). They return distance, duration, and turn-by-turn instructions for a given origin and destination. For multi-stop problems, pre-computing a distance matrix between all pairs of stops avoids redundant API calls during optimisation.

Considerations when choosing:

• Traffic data: Google and HERE have the best real-time traffic. Mapbox and OSRM use historical patterns.
• Vehicle profiles: Truck routing needs height, weight, and hazmat restrictions. Not all providers support this.
• Waypoints: Most APIs support intermediate stops but limit the number (Google: 25 waypoints).
• Terms: Google requires displaying routes on Google Maps. Others are more flexible.

The Route Optimisation Problem

Given a set of stops, find the order that minimises total distance or time. This is the Travelling Salesman Problem (TSP), which is NP-hard. Exact solutions are computationally infeasible beyond about 20 stops.

Practical Approaches

Since exact answers are infeasible at scale, practical routing relies on heuristics and solver libraries that find good-enough routes within time constraints.

Constraints in Real Routing

Real delivery and service routing involves constraints that basic TSP ignores:

• Time windows: Customer available 9am-12pm only. Delivery before 6pm.
• Vehicle capacity: Van holds 50 packages or 500kg.
• Driver hours: Maximum 8 hours driving. Mandatory breaks.
• Priority stops: Some stops must happen first or last.
• Skills: Some deliveries require specific equipment or certification.
• Return to depot: Or end at a different location.

Each constraint narrows the solution space but complicates the optimisation. Commercial APIs and OR-Tools support these constraints; naive implementations don't. For automated dispatch and job assignment, route optimisation often integrates with a workflow engine that handles the business rules around assignment, escalation, and rescheduling.

Offline Maps and Caching

Field applications often operate where connectivity is poor or absent. Offline capability requires caching both map tiles and application data.

Map Tile Caching

Map tiles can be cached locally for offline use. The approach depends on the platform:

Terms of Service

Tile caching terms vary significantly by provider:

• Google Maps: No caching permitted beyond browser/OS cache. Offline requires specific licensing.
• Mapbox: Offline supported in mobile SDKs with active subscription. Pre-rendering for distribution requires custom agreement.
• OpenStreetMap: Free to cache and distribute. Attribution required.

For applications requiring offline maps, OSM-based tiles (self-hosted or via providers like Mapbox with appropriate licensing) are often the most practical choice.

Offline Data Synchronisation

Caching map tiles is only half the problem. Application data (customer locations, job details, route information) also needs offline access with eventual synchronisation. This is where offline-first architecture gets genuinely hard.

Patterns for offline data:

• Download before departure: Sync the day's jobs before leaving. Read-only offline access.
• Queue modifications: Store changes locally, sync when connectivity returns. Handle conflicts (same record modified by different users).
• Optimistic UI: Show success immediately, sync in background. Roll back if sync fails.

Geofencing

Geofencing triggers actions when a device enters or exits a defined geographic area. Common uses: delivery arrival notifications, time tracking for field workers, asset security alerts.

Implementation Approaches

Geofencing can run on the device or on the server. The right choice depends on whether you control the app, how many fences you need, and whether position data is already flowing to a backend.

Fence Definition

Circular fences (centre point plus radius) are simplest. Polygonal fences allow arbitrary shapes (property boundaries, irregular service area boundaries). PostGIS handles both.

For client-side geofencing, circular regions are more battery-efficient. For server-side, polygons add no cost.

Edge Cases and Practical Thresholds

• GPS jitter: Position updates can bounce in and out of a fence boundary. Implement hysteresis (require position to be clearly inside/outside before triggering, typically 20% of fence radius) and debounce events (30 seconds is a sensible default before confirming entry/exit).
• Tunnel/building entry: GPS signal loss can look like an exit. Don't trigger alerts on signal loss alone. Require multiple consecutive position reports outside the fence before confirming exit.
• Minimum fence radius: GPS accuracy (3-5m open sky, 10-30m in urban canyons) limits useful minimum fence size. A 10m fence will generate false triggers. Use 50m minimum for outdoor fences, 200m in dense urban areas.
• iOS region limit: iOS caps monitored regions at 20 per app. For applications with more fences, use server-side geofencing with PostGIS, or dynamically register the nearest fences based on the device's current position.

Geofencing reliability depends on treating GPS as an approximate, noisy signal rather than a precise measurement. Every fence implementation needs a state machine with clear transitions between outside, entering, inside, and exiting states. Each state should have defined thresholds before the transition confirms.

Privacy and Compliance

Location data is personal data under GDPR and similar regulations. Collection, storage, and processing require appropriate legal basis and security measures.

Legal Basis

For employee location tracking, legitimate interest may apply for delivery tracking (customers expect to know where their package is) but consent is typically required for broader monitoring. The ICO's guidance on monitoring workers sets out specific requirements for location tracking of employees. For consumer applications, consent is almost always required.

The legal basis affects what you can do with the data. Purpose limitation is strict: location collected for delivery tracking cannot be repurposed for productivity monitoring without separate consent and a separate legal basis. This distinction matters in practice, because the same GPS data could serve both purposes.

Data Minimisation

Collect only what's needed. Store only what's needed. Delete when no longer needed.

Transparency

Users should know when location is being collected and why. Mobile apps should use location permission prompts that explain the purpose. Employees should have clear policies on what's tracked and how it's used.

Consider providing users access to their own location history. This builds trust and is often required under data subject access rights.

Security

Location data reveals patterns: where people live, work, visit regularly. Protect accordingly:

• Encryption: TLS for transmission, encryption at rest for storage. See security and operations for our standard approach.
• Access control: Limit who can view location data. Log every access with an audit trail, including which user viewed whose location and when.
• Retention: Automatic deletion after retention period. Delivery tracking data can typically be aggregated after 30 days. Field worker tracks after payroll processing. Don't keep data "just in case".
• Anonymisation: For analytics, reduce coordinate precision (3 decimal places gives ~110m accuracy, sufficient for heat maps) or apply k-anonymity techniques. Aggregate rather than store individual tracks long-term.

Common Patterns

Recurring implementation patterns we use across location-aware applications:

Store Locator

The classic "find your nearest" flow. Four steps, each building on the geocoding and spatial query patterns covered above.

Delivery Zone Check

Zone-based pricing and availability checks tie directly into order management workflows. The spatial query runs during checkout, but the zone definitions feed scheduling, pricing tiers, and fulfilment routing.

Field Worker Dispatch

Dispatch combines spatial queries with service delivery workflows. The location layer finds the nearest available worker; the service delivery system handles assignment, SLA tracking, and completion confirmation.

Technology Stack

Our standard stack for location-aware applications, deployed on infrastructure sized for the workload:

What good location-aware architecture delivers

• ✓
  Accurate geocoding Addresses converted to coordinates reliably, with caching to control costs.
• ✓
  Fast spatial queries "Find nearest" and "within area" queries that perform at scale using PostGIS.
• ✓
  Interactive maps Maps that render smoothly with thousands of points and work offline when needed.
• ✓
  Efficient routing Optimised routes that account for real constraints, not just shortest path.
• ✓
  Reliable geofencing Entry/exit detection that handles GPS noise and edge cases.
• ✓
  Privacy compliance Location data handled with appropriate consent, minimisation, and security.

Location capabilities built on solid foundations: PostGIS for spatial queries, proper geocoding strategies, maps that perform, and privacy handled correctly from the start.