Category: Spatial Lakehouse

Mobility data is the continuous stream of GPS location records capturing how people, vehicles, and assets move through the world. Processing it at scale is fundamentally different from standard spatial data work because it carries temporal dependencies: the order and timing of observations define movement, not just position. Most organizations have discovered, often painfully, that the tools they already use were not designed with that in mind. In Part 2, we walk through the technical implementation: a three-notebook medallion architecture built on Wherobots and Apache Sedona that takes raw GPS pings and transforms them into analysis-ready, GeoParquet-backed analytical views.

Why Mobility Data Is Harder to Process Than It Looks

Every second, billions of GPS-equipped devices generate spatiotemporal data capturing how people, goods, and vehicles move through the physical world. The market reflects how seriously organizations are treating this: the global fleet management market is valued at approximately $27 billion in 2025 and projected to exceed $122 billion by 2035. Mobility data analytics platforms are on a similar trajectory, from $2.5 billion to over $11 billion by 2034. But collecting this data and actually extracting reliable intelligence from it are two very different things.

Most organizations have discovered, often painfully, that the tools they already use were not designed with GPS mobility data in mind. The result is brittle pipelines, inconsistent methodologies, and analyses that quietly produce misleading conclusions. Researchers at ACM have characterized the field as requiring its own dedicated science because general-purpose data science pipelines consistently produce suboptimal results when applied to movement data. Understanding why requires looking at the specific properties that make mobility data uniquely difficult to process correctly.

What Makes Mobility Data Different From Standard Spatial Data

Mobility data is not just spatial data with timestamps attached. It is a distinct category of data that violates assumptions built into most data processing systems. Researchers at ACM have characterized the field as requiring its own dedicated science—Mobility Data Science—because general-purpose data science pipelines consistently produce suboptimal results when applied to movement data. Understanding why requires examining the specific properties that make trajectory data uniquely challenging.

Why GPS Data Volume Overwhelms Traditional Databases

The volume and velocity problem is the recognition that GPS data generation at fleet scale is not a batch analytics challenge, it is a continuous, high-throughput data engineering problem that demands distributed processing from the start. A single connected vehicle generating GPS pings at one-second intervals produces roughly 86,400 records per day. A fleet of 10,000 vehicles generates over 860 million data points daily. Multiply this across the millions of connected vehicles, delivery drones, rideshare fleets, and maritime vessels operating globally, and the scale becomes staggering. 

Traditional spatial databases like PostGIS, which excel at transactional workloads and moderate-scale analytics, were not designed for this volume. Loading hundreds of millions of GPS points into PostgreSQL, constructing geometries, and running spatial joins or trajectory reconstruction queries can take hours or days on a single node. Adding more hardware does not solve the fundamental problem: PostGIS was not built for distributed, parallel spatial computation.

How GPS Signal Noise Corrupts Downstream Analysis

GPS noise is error in raw location readings caused by signal reflection, satellite loss in tunnels and urban canyons, and atmospheric interference and it cascades through every downstream analysis built on top of it. Signals bounce off buildings, lose satellites in tunnels and urban canyons, and suffer from atmospheric interference. Studies have documented median GPS errors of 7 meters with standard deviations exceeding 23 meters in urban environments. Points can appear on the wrong side of a street, inside buildings, or kilometers from the actual position when signal quality degrades.

Speed calculations between consecutive points can spike to physically impossible values. Distance measurements accumulate systematic errors. Clustering algorithms identify phantom stop locations. Without rigorous cleaning and validation at the earliest stages of the pipeline, every subsequent insight is built on a compromised foundation.

Researchers at the University of Pennsylvania’s Computational Social Science Lab studied exactly this problem in the context of COVID-19 epidemic modeling. Using the same GPS mobility dataset, they found that different but individually reasonable preprocessing choices led to substantially different conclusions. a methodological “garden of forking paths” where reproducibility became nearly impossible. The root causes: data sparsity, sampling bias, and inconsistent algorithmic choices at the preprocessing stage.

Why Temporal Ordering Is Critical in Mobility Data Processing

Trip segmentation is the process of splitting a continuous GPS stream into discrete trips by detecting temporal gaps, periods where no data was recorded or the device was stationary. Mobility data is not simply geospatial—it is spatiotemporal. Every GPS point has a position and a timestamp, and the relationship between consecutive observations is what defines movement. This trip segmentation step alone introduces significant methodological complexity, because the threshold you choose (5 minutes? 20 minutes? 60 minutes?) fundamentally changes the structure of your resulting trajectories and all metrics derived from them.

Beyond segmentation, ordering matters. Trajectories are sequences, not sets. Every analytical operation—speed calculation, direction changes, stop detection, map matching—depends on correct chronological ordering within each trip. Systems that do not preserve or guarantee ordering (a common challenge in distributed frameworks) can produce geometries that appear valid but contain scrambled temporal information.

Why 2D Spatial Systems Fail for Mobility Analytics

The dimensionality problem is the gap between how most spatial systems model location, latitude and longitude only and what mobility analysis increasingly requires: 3D and 4D geometry that encodes elevation and time directly into the geometry itself. Most spatial systems treat location as a 2D construct: latitude and longitude. But mobility analysis increasingly demands 3D and 4D processing. Elevation matters for fuel consumption modeling, route optimization in mountainous terrain, aviation and drone trajectories, and any analysis where the difference between 2D and 3D distance is materially significant. Adding a temporal measure dimension (the “M” in XYZM geometries) enables encoding timestamps directly into the geometry itself, supporting trajectory validation and interpolation operations that are impossible with 2D points.

Yet 4D geometry support—constructing XYZM points, building trajectories from them, and performing analytical operations that respect all four dimensions—is rare. Most spatial SQL implementations either lack these functions entirely or implement them inconsistently. This forces practitioners to maintain separate columns for elevation and time, losing the computational advantages of integrated 4D geometry processing.

Where Traditional Spatial Systems Fail for Mobility Data

Desktop GIS: The Single-Machine Ceiling

Tools like QGIS and ArcGIS Pro are extraordinarily capable for visualization, manual analysis, and working with datasets that fit in memory. But they hit a hard wall with mobility data at scale. Loading millions of GPS trajectories, performing trip segmentation with window functions, running DBSCAN clustering on stop points, and executing map matching against a road network are not operations that desktop GIS was designed to handle. Analysts working with fleet-scale data routinely encounter out-of-memory errors, multi-hour processing times, and the inability to iterate quickly on analytical parameters.

Spatial Databases: Scale Without Spatial Intelligence

PostGIS remains the gold standard for spatial SQL and is an excellent choice for many use cases. However, it is fundamentally a single-node system. Scaling PostGIS to handle hundreds of millions of GPS points requires expensive vertical scaling, and even then, operations like trajectory construction across thousands of users, spatial indexing with H3 or GeoHash, and DBSCAN clustering at urban scale can exhaust available resources.

Cloud data warehouses like Snowflake, BigQuery, and Redshift have added spatial capabilities, but these tend to be shallow implementations optimized for simple point-in-polygon or distance queries. Constructing XYZM trajectories from ordered GPS points, performing spatial clustering, computing 3D distances, or running map matching against a road network are either unsupported or require convoluted workarounds that sacrifice performance and maintainability.

General-Purpose Distributed Frameworks: Power Without Spatial Awareness

Apache Spark provides the distributed computing muscle needed for mobility-scale data, but vanilla Spark has no concept of spatial data types, spatial indexing, or geometric operations. Running a spatial join in pure Spark requires broadcasting datasets or implementing custom partitioning strategies—both of which are error-prone and perform poorly at scale compared to purpose-built spatial engines.

This is precisely the gap that Apache Sedona and Wherobots were designed to fill. Sedona extends Spark (and other distributed frameworks) with native spatial data types, over 290 spatial SQL functions, spatial indexing, and optimized query planning that understands geometric predicates. Wherobots builds on Sedona to provide a fully managed, cloud-native spatial intelligence platform where teams can process GPS-scale data without managing infrastructure, configuring clusters, or bolting together fragmented toolchains.

Map Matching: The Unsolved Infrastructure Problem

Map matching—the process of snapping noisy GPS traces to the actual road network—is one of the most computationally demanding and methodologically complex steps in any mobility pipeline. It requires loading a complete road network graph, computing probabilistic alignments between GPS observations and candidate road segments, and resolving ambiguities at intersections, parallel roads, and complex interchanges.

Most map matching solutions are either commercial APIs with strict rate limits and per-request pricing that make batch processing of historical data prohibitively expensive, or open-source tools that require significant infrastructure setup and do not scale to city-wide or fleet-wide datasets. Researchers have consistently identified scalability as the primary bottleneck: algorithms that produce accurate matches on small datasets fail to perform when confronted with millions of trajectories.

Having map matching available as an integrated capability within the same distributed environment where you are already processing and analyzing your trajectory data—rather than as an external API call or a separate system—eliminates an entire category of infrastructure complexity and data movement overhead.

The Real Cost of a Fragmented Mobility Data Pipeline

In practice, most organizations processing mobility data have assembled a patchwork of tools: Python scripts for data cleaning, PostGIS for spatial operations, custom code for trip segmentation, an external API for map matching, a separate clustering library, and a visualization tool at the end. Each transition between tools introduces data serialization overhead, potential for schema drift, and opportunities for subtle bugs.

This fragmentation carries real costs beyond engineering time. When a researcher needs to change the trip segmentation threshold from 20 minutes to 30 minutes, the entire pipeline must be re-executed across multiple systems. When a new data source arrives with a slightly different schema, adapters must be updated at each integration point. When results need to be reproduced for regulatory or academic review, reconstructing the exact sequence of operations across disparate tools is often impractical.

The ideal mobility data pipeline processes GPS pings through ingestion, cleaning, enrichment, trajectory construction, map matching, spatial indexing, clustering, and analytical aggregation—all within a single, distributed, spatially-aware environment where every step is expressed in SQL or Python, every intermediate result is inspectable, and the entire pipeline can be reproduced with a single execution.

What a Modern Mobility Data Architecture Looks Like

The medallion architecture—Bronze, Silver, Gold—has become the standard pattern for progressive data refinement in the data lakehouse world. But applying it to mobility data requires rethinking what each layer does, because spatial data introduces transformations and enrichment steps that have no analog in conventional data engineering.

Bronze is not just ingestion—it is spatial profiling. You are not only loading CSV or Parquet files; you are constructing point geometries, validating coordinate bounds, assessing data quality metrics like altitude validity and temporal coverage, and establishing the spatial extent of your dataset.

Silver is where the heavy lifting happens. This is trip segmentation, 4D geometry construction, trajectory building, movement metric derivation, spatial indexing, and map matching. Each of these operations is computationally intensive, order-dependent, and requires spatial functions that most data platforms simply do not have.

Gold produces the analytical views that power downstream consumption: H3 hexbin density heatmaps, temporal activity patterns, stop detection via spatial clustering, trajectory anomaly flagging, and road segment speed analysis. These views are written as GeoParquet files—compatible with Kepler.gl, QGIS, Felt, Foursquare Studio, and DuckDB Spatial—ensuring that the output of the pipeline is immediately consumable by any modern geospatial visualization or analytics tool.

How Wherobots Handles Mobility Data Processing: What We Built

To demonstrate this architecture in practice, we built a three-notebook Wherobots Mobility Solution Accelerator using the Microsoft Research GeoLife GPS Trajectories dataset—one of the few open mobility datasets that includes elevation data, enabling full 4D geometry processing. The dataset contains 17,621 trajectories from 182 users in Beijing, with latitude, longitude, altitude, and timestamps spanning 2007–2012.

In Part 2, we walk through every notebook in detail: the Bronze layer’s ingestion and profiling pipeline, the Silver layer’s 4D trajectory construction and map matching workflow, and the Gold layer’s analytical and exploratory views. We cover the specific Apache Sedona spatial SQL functions used at each step, the PySpark window function patterns for trip segmentation and movement metrics, and the real-world challenges we encountered and solved—from Spark’s schema inference corrupting timestamp values, to COLLECT_LIST not preserving order in trajectory construction, to DBSCAN requiring physical column references.

If you are building mobility analytics pipelines and hitting the limitations of your current toolchain, Part 2 will give you a concrete, reproducible blueprint for how to do it on Wherobots.

When building a geospatial platform, technical decisions are never just technical, they are financial. Choosing the wrong architecture for your spatial data doesn’t just frustrate your data team; it directly impacts your bottom line through large cloud infrastructure bills and, perhaps more dangerously, delayed business insights.

For decision-makers, the choice between a traditional spatial database (like PostGIS, an open-source extension of PostgreSQL that adds support for storing and querying location data) and a cloud-native geospatial analytics platform (like Wherobots, built with distributed computing including Apache Spark to process massive spatial datasets in parallel across compute clusters) comes down to two fundamental metrics: Time to Insight and Total Cost of Ownership (TCO).

To understand where to invest your budget, we need to look beyond the software labels and understand the economics of how these systems handle data.

If you are new to the PostGIS vs Wherobots discussion, start with [Part 1: PostGIS, Wherobots, and the Spatial Data Lakehouse: A Strategic Guide for Leaders]. This post assumes you understand the architectural difference and focuses on what it actually costs you to choose wrong.

Key Takeaways:

1. PostGIS is optimized for low-latency lookups. Wherobots is optimized for high-throughput analytics and data processing. Using the wrong one for the wrong job costs you both time and money.
2. A PostGIS server must be provisioned for peak load, so you pay for maximum capacity even when usage is low. Wherobots is designed to charge primarily for active compute time, so you are not paying for idle capacity.
3. For industries like insurance, logistics, and urban planning, the right architecture choice can dramatically reduce query time for large-scale spatial analysis — in some cases from hours or days down to minutes. 
4. PostGIS and Wherobots are not mutually exclusive. Many enterprises use Wherobots to process data at scale, then serve results through PostGIS for live application access. 
5. Use the checklist in this post as a fast diagnostic: if you are waiting hours for spatial queries or your cloud bill is outpacing your revenue growth, you have a strong case for cloud-native spatial compute.

Why Slow Spatial Queries Cost More Than You Think

In the modern enterprise, the value of data decays over time. An answer delivered in 5 seconds is actionable; an answer delivered in 5 days is a post-mortem. The architecture you choose dictates how fast you can answer complex questions.

Low Latency vs High Throughput: What Speed Actually Means for Each Tool

It is crucial to understand the difference between “speed” for an app and “speed” for analytics.

• Low Latency (PostGIS): This is the speed of retrieval. When a customer opens your delivery app and asks, “Where is my driver?”, they need an answer in milliseconds. PostGIS is optimized for this. It uses heavy indexing to find a single “needle in a haystack” instantly.
• High Throughput (Wherobots): This is the speed of processing. When your risk analyst asks, “Which of our 50,000 retail locations are at risk of flooding based on the new 100-year climate models?”, they are not looking for a needle; they are looking for patterns across the whole haystack.

The Bottleneck: If you try to run that massive climate model analysis in PostGIS, the database has to check every single location against every single flood zone, even with optimizations for search like spatial indexing. Because PostGIS typically runs on a single server, running that analysis forces your app and your analytics to compete for the same resources. The query might take 24 hours, and your customer-facing app slows down the whole time.

The Solution: Wherobots breaks that same job into parallel tasks across a cluster of worker nodes, each handling a partitioned geographic slice. Because the work happens simultaneously, the job finishes in minutes instead of hours. 

Business Impact: Your analysts get answers before lunch, not next week. Your operational apps remain fast for customers because the heavy lifting happened elsewhere.

PostGIS vs Wherobots: Why the Pricing Models Are Fundamentally Different

The second major factor is how you pay for these capabilities. Query speed is only half the cost story. The other half is how each system charges you. The pricing models for databases and cloud-native engines are fundamentally different.

Why PostGIS Forces You to Pay for Peak Capacity Around the Clock

A high-performance database like PostGIS requires expensive hardware specifically, high-speed RAM and fast CPUs, to keep your data accessible.

• The Lease Model: PostGIS requires provisioning a server for peak load, which means you pay for maximum capacity even when usage is low. Think of it like leasing a Ferrari just to drive to the grocery store on Sundays. You have to provision this server for your peak usage. If you need to run a heavy report once a week that requires 64 cores of CPU, you must pay for a 64-core server 24 hours a day, 7 days a week. 
• The Waste: For the other 6 days and 23 hours, that expensive server sits idle, burning budget. It is analogous to leasing a Ferrari just to drive to the grocery store on Sundays.

How Wherobots Charges Only for Active Compute Time

Wherobots uses an elastic, on-demand pricing model: you consume compute while an operation is actively running, then billing stops when it finishes. Storage and compute are decoupled, meaning your data sits in low-cost object storage and you rent processing power only when you need it.

• Storage is Cheap: You keep your massive datasets in low-cost Object Storage (like Amazon S3), which costs pennies per gigabyte.
• Compute is On-Demand: When you need to run that heavy climate model, you rent the 1,000 computers for exactly 15 minutes. The moment the job is done, the machines turn off, and the billing stops.
• The Savings: You convert a massive fixed Capital Expenditure (CapEx) into a lean, manageable Operational Expenditure (OpEx).

PostGIS vs Wherobots: Which One Is Right for Your Use Case?

To make this concrete, let’s look at three distinct industry examples and which tool provides the best ROI for each.

1. Logistics and Delivery: Why Real-Time Tracking Needs PostGIS

Scenario: You need to route drivers in real-time and show customers where their package is.

• The Choice: PostGIS.
• Why: You need transactional guarantees. If a driver marks a package as “Delivered,” that data must be instantly saved and visible. You are doing millions of tiny, fast lookups.

2. Insurance and Real Estate: Why Portfolio-Scale Risk Analysis Needs Wherobots

Scenario: You need to calculate risk premiums for 10 million homes based on historical wildfire data, distance to fire stations, and vegetation density indices.

• The Choice: Wherobots.
• Why: This is a “Global Join.” You are comparing massive datasets against each other. PostGIS would take weeks to process this at a national scale. Wherobots can recalculate the entire portfolio every night, allowing you to adjust pricing dynamically.

3. Urban Planning: Why Time-Series Sensor Data Overwhelms a Standard Database

Scenario: You are ingesting telemetry data from 50,000 connected traffic lights and sensors to analyze traffic congestion trends over the last 5 years.

• The Choice: Wherobots.
• Why: The volume of data (Time-Series) is too large for a standard database. A database would bloat, slow down, and become expensive to back up. Wherobots can read this data directly from cheap storage, aggregate it into trends, and output the results.

PostGIS vs Wherobots: Decision Checklist

PostGIS is a good choice when your primary use case is powering a user-facing application that needs fast, transactional lookups on a relatively stable dataset. Wherobots is the better choice when you are running analytical queries across complex datasets, processing historical data at scale, or need compute costs that flex with actual usage rather than peak capacity.

If you are currently evaluating your data stack, use this simple checklist to guide your architecture decision.

Stick with PostGIS if:

• [ ] Your primary goal is powering a user-facing application.
• [ ] You need to edit data manually (e.g., fixing property boundaries).
• [ ] Your dataset is relatively stable and fits comfortably on one large server.
• [ ] You require strict “ACID” transactions (meaning every write is confirmed and visible before the next read — no partial updates, no stale reads)

Move to Wherobots if:

• [ ] You are waiting hours or days for analytical queries to finish.
• [ ] Your cloud database bill is growing faster than your revenue.
• [ ] You need to join two massive datasets (e.g., “All Buildings” + “All Parcels”).
• [ ] You are building AI/Machine Learning models that need to “learn” from all your historical data.

The most competitive organizations today realize they don’t have to choose just one. They use Wherobots to crunch the data cheaply and efficiently, and then move the polished results into PostGIS for instant access—a strategy we will cover in our next post on the “Medallion Architecture”, a data design pattern where raw, refined, and production-ready data are stored in separate layers, each optimized for different workloads

Ready to see what this looks like for your workload? Contact us and get a cost comparison built around your actual data volume.