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. UTM (Universal Transverse Mercator) appears in surveying data. PostGIS handles conversions between systems, but WGS84 should be your storage standard.

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 great-circle distance between two points on a sphere. It's computationally cheap and accurate enough for most purposes. For distances under 20km, the error 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 Once, Cache Forever

Geocode addresses on first encounter, store the result, and never geocode the same address twice. 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.

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.

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);

Index creation is automatic for geography columns in recent PostGIS versions, but verify with EXPLAIN ANALYZE that your queries are using the index.

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

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.

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 this bounding box". 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 as static files or generate dynamically. The map library handles rendering efficiently using WebGL.

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.

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

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.

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.

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

Fence Definition

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

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

Edge Cases

• GPS jitter: Position updates can bounce in and out of a fence boundary. Implement hysteresis (require position to be clearly inside/outside before triggering) or debounce events.
• Tunnel/building entry: GPS signal loss can look like an exit. Don't trigger alerts on signal loss alone.
• Small fences: GPS accuracy (3-5m in good conditions, 10-30m in urban canyons) limits useful minimum fence radius. A 10m fence will generate false triggers.

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. For consumer applications, consent is almost always required.

The legal basis affects what you can do with the data. Location collected for delivery tracking shouldn't be used for productivity monitoring without separate consent.

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.
• Access control: Limit who can view location data. Log access for audit.
• Retention: Automatic deletion after retention period. Don't keep data "just in case".
• Anonymisation: For analytics, consider k-anonymity or differential privacy techniques.

Common Patterns

Recurring implementation patterns we use across location-aware applications:

Store Locator

Delivery Zone Check

Field Worker Dispatch

Technology Stack

Our standard stack for location-aware applications:

What You Get

• ✓
  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.