- BigQuery supports the GEOGRAPHY type and GoogleSQL geography functions; coordinate order and spherical semantics require explicit checks
- Dataproc with Sedona: distributed spatial processing on managed Spark. Serverless Dataproc for one-off jobs, persistent clusters for heavy raster and vector workloads. GCP's answer to AWS Glue Spark ETL
- Cloud Composer (managed Airflow): orchestrates multi-step GIS pipelines across BigQuery, Dataproc, and Cloud Run. Replaces cron-based scheduling and manual coordination
- Keep the execution boundary visible: a query that should run in BigQuery can be pulled into local Python. Record the job location, bytes processed, output check, and failure path
This retained note maps a possible GCP geospatial workflow across BigQuery, Earth Engine, Dataproc, Cloud Run, and Cloud Storage. The services solve different problems, so the correct boundary depends on the data, operation, and operating model.
The original article included workload timings and cost illustrations. They are not current measurements. Re-run the target workflow with the data location, query, account terms, execution boundary, output check, and failure path recorded.
Geospatial in Cloud Series
This is Part 3 of our Geospatial in Cloud series. Each post is self-contained. Part 1 covers Databricks. Part 2 covers AWS. Part 4 covers Snowflake. Read the one that matches your stack.
GCP Geospatial Services Map
GCP's geospatial capabilities are spread across six services. Understanding which one to use for what is the first decision you need to make.
| SERVICE | GEOSPATIAL USE | WHEN TO USE |
|---|---|---|
| BigQuery GIS | Spatial SQL on massive datasets | Billions of rows, ad-hoc spatial analysis |
| Dataproc | Distributed Spark with Sedona | Heavy spatial processing, large rasters, millions of features |
| Cloud Composer | Managed Apache Airflow | Multi-step pipeline orchestration across all GCP services |
| Earth Engine | Satellite imagery analysis | Multi-temporal raster analysis, change detection |
| Cloud Run | Containerised geospatial APIs | Processing services, tile servers, APIs |
| Cloud Storage (GCS) | COG/GeoParquet storage | Primary data lake (like S3) |
| Vertex AI | ML on geospatial data | Classification, prediction models |
| Dataflow (Beam) | Streaming geospatial processing | Real-time sensor data, IoT |
Most geospatial teams on GCP use four of these: BigQuery GIS for analysis, Dataproc for heavy spatial processing, GCS for storage, and Cloud Run for serving. Cloud Composer ties multi-step pipelines together. Earth Engine is the specialist tool you bring in when satellite imagery is involved.
BigQuery GIS in Detail
BigQuery GIS operates on a native GEOGRAPHY type. No extensions, no plugins, no PostGIS-style setup. Spatial functions work directly on petabyte-scale tables with the same SQL your analysts already write.
A spatial join can use standard GoogleSQL geography functions such as ST_CONTAINS, ST_DISTANCE, and ST_INTERSECTION. Query plan, data layout, location, billing model, and output validation affect the result. Treat any timing or scale result as a run-specific record, not a portable promise.
COORDINATE ORDER: THE NUMBER ONE MISTAKE
BigQuery GIS uses longitude first, latitude second for ST_GEOGPOINT. This is the opposite of what most GIS practitioners expect. ST_GEOGPOINT(13.4, 52.5) means longitude 13.4, latitude 52.5 (Berlin). Get this wrong and your points land in the ocean. Every team hits this. Use SAFE.ST_GEOGPOINT() which returns NULL instead of an error for out-of-range coordinates - but be warned: SAFE only catches values outside valid ranges (e.g., longitude 200). A swapped pair like (52.5, 13.4) when you meant (13.4, 52.5) is still within valid ranges and SAFE will happily return the wrong point. Visual spot-checks on a map are the only reliable way to catch axis swaps.
Check the current GEOGRAPHY coordinate and measurement semantics before loading data. If the source uses a projected coordinate system, reproject and validate the result before spatial operations. Buffer and distance units, coordinate order, and invalid input handling must be part of the test record.
Public datasets can reduce ingestion work when the required dataset, licence, location, freshness, and access terms fit. Query the intended public table with the intended predicate and record bytes processed, job location, timing, cost model, and output checks.
THE LOCAL FALLBACK TRAP
A common execution-boundary failure is silent: a workflow that should run spatial operations in BigQuery moves data into local pandas or GeoPandas processing. Verify the BigQuery job, bytes processed, client-side work, output, and failure path instead of assuming that a successful pipeline used the intended engine.
KEY INSIGHT: S2 vs H3 INDEXING
BigQuery GIS uses S2 cell indexing internally - spatial operations are not scan-based, they use a spatial index automatically. No EXPLAIN ANALYZE, no manual index creation, no tuning. This is the single biggest difference from PostGIS, where spatial index creation and maintenance is a constant overhead.
S2 is the internal query index you cannot control. For application-level hexagonal aggregations - heatmaps, density analysis, catchment areas - you compute H3 indices yourself via BigQuery UDFs. H3 gives you consistent hexagonal cells at defined resolutions (resolution 9 for urban, 7 for regional - same as Databricks Mosaic). S2 optimises your queries; H3 structures your analytical output.
NAMING TRAP: BIGQUERY vs GCS
BigQuery dataset names only allow underscores (no hyphens). GCS bucket names allow hyphens but not underscores. These are opposite rules. Teams that name everything consistently with hyphens discover this when BigQuery rejects their dataset name. Adopt a naming convention early: underscores for BigQuery resources, hyphens for GCS buckets.
For detail on the file formats that power this, see our guide on cloud-native geospatial formats (GeoParquet, COG, STAC). GeoParquet and COG work natively with BigQuery and GCS.
Dataproc for Heavy Processing
BigQuery handles SQL-based spatial analysis. Dataproc handles everything else. When you need Python GIS libraries (rasterio, GDAL, fiona) or distributed Spark processing with Apache Sedona, Dataproc is GCP's answer. It is the equivalent of AWS EMR or Glue Spark ETL - a managed Spark cluster you can provision with geospatial libraries pre-installed.
Two modes: Serverless Dataproc for one-off jobs (no cluster to manage, you submit a PySpark script and it runs), and persistent clusters for interactive exploration or recurring workloads. Serverless has cold start but eliminates cluster management entirely. For persistent clusters, initialisation actions install GIS libraries - geopandas, rasterio, fiona, shapely, apache-sedona - which adds 2-5 minutes to cluster startup.
| USE CASE | MACHINE TYPE | MEMORY | NOTES |
|---|---|---|---|
| Small vector | n2-standard-4 | 16 GB | Basic spatial joins, format conversion |
| Large vector | n2-highmem-8 | 64 GB | Millions of features, complex spatial joins |
| Raster | n2-highmem-16 | 128 GB | Windowed raster processing, large COGs |
| ML + spatial | a2-highgpu-1g | 85 GB + GPU | GPU-accelerated ML inference on spatial data |
Sedona integration: pass Sedona JAR coordinates via the --properties flag when submitting Dataproc jobs. Sedona gives you distributed spatial SQL (ST_Intersects, ST_Buffer, ST_Union_Aggr) across the Spark cluster. Read GeoParquet from GCS, run spatial operations, and write results back to GCS or directly load into BigQuery via the BigQuery connector. This is the pattern for heavy spatial ETL that BigQuery SQL alone cannot handle - dissolves, complex unions, raster zonal statistics.
The GCS write limitation is identical to S3 and Databricks Volumes: GCS is object storage with no filesystem semantics. GeoTIFF and GeoPackage writes that require seek operations fail silently. Write to /tmp on the Dataproc node first, then upload the finished file to GCS. This is the same two-stage write pattern that every cloud platform requires for GDAL-based formats.
A related trap: os.path.exists() and Path(...).exists() do not work on GCS paths. They silently return False even when the file exists. Use the google.cloud.storage client with blob.exists() instead. This catches teams who port local file-checking patterns to the cloud without adapting the existence checks.
Cloud Composer (managed Airflow) orchestrates multi-step pipelines that span BigQuery, Dataproc, and Cloud Run. A typical GIS migration pipeline: load raw data into BigQuery (BigQueryInsertJobOperator), run spatial analysis in SQL, then hand off heavy raster processing to Dataproc (DataprocSubmitPySparkJobOperator). Composer manages dependencies, retries, and scheduling - replacing the cron-based scripts and manual coordination that most GIS teams rely on today. Environment creation takes 15-25 minutes, but once running, it handles the orchestration that Step Functions does on AWS.
WHEN TO USE WHAT
BigQuery GIS for SQL-based spatial analysis (joins, distance queries, aggregations). Dataproc + Sedona for heavy spatial ETL that requires Python libraries or distributed processing beyond SQL (dissolves, complex geometry operations, raster processing). Cloud Composer to wire them together in automated pipelines. Do not try to do everything in BigQuery - complex geometry operations belong in Dataproc. Do not try to do everything in Dataproc - compare simple SQL analysis in BigQuery with the same data, query, and verifier.
Earth Engine: What Works and What Does Not
Earth Engine is designed for particular imagery and remote-sensing workflows. This note records useful fit questions and boundaries; it does not rank Earth Engine or make a universal platform recommendation.
Where Earth Engine May Fit
Managed imagery collections
Current collections, access terms, processing levels, and export limits must be checked against the intended account and use case.
Multi-temporal analysis
A time-series workflow can avoid some local ingestion work. Measure the target region, collection, reducer, scale, export, and account terms.
Built-in change detection and classification
Deforestation tracking, urban expansion monitoring, crop classification - algorithms are built in with the data co-located. No data movement.
Where Earth Engine Is Overkill or Wrong
1. Vector analysis
Earth Engine is raster-first. If the target is vector SQL, compare BigQuery GIS, PostGIS, or another spatial engine with the same data, predicate, and verifier.
2. Custom processing pipelines
Earth Engine has a managed execution model. For a multi-step workflow that needs explicit control over packaging, memory, retries, or execution order, compare a separately managed container boundary such as Cloud Run.
3. Integration with non-Google tools
Exports are part of the workflow boundary. Record their format, destination, queueing, duration, failure handling, and downstream integration before selecting Earth Engine for a larger pipeline.
4. Reproducibility
Reproducibility depends on the script, collection version, parameters, account, export, and evidence retained. Regulated workflows need an explicit audit record and a review of the current service terms.
5. Cost predictability
Access and commercial terms can vary by programme, account, and usage. Check the current terms and pricing for the intended use, then compare with the target BigQuery and Cloud Run cost model.
RECOMMENDATION
Use Earth Engine when the imagery collection, processing model, export path, terms, and validation record fit the workflow. Use BigQuery GIS or Cloud Run when their data and execution boundaries better match the target operation. Recheck the choice with a small representative run.
Cloud Run for Processing
Cloud Run can provide a managed container boundary for a geospatial API or job. Scaling, request handling, memory, concurrency, region, and billing behaviour still require a check for the target service.
It may fit tile serving, geocoding APIs, on-demand raster processing, or another service that benefits from a container boundary. Test request size, cold and warm behaviour, retries, output validation, and operational ownership.
The pattern is straightforward: a FastAPI application with GeoPandas and rasterio that reads GeoParquet from GCS, performs a spatial operation (intersection, buffer, distance query), and returns GeoJSON. Deployment is a single gcloud command - point it at your source directory, specify the region and memory, and Cloud Run builds, deploys, and serves it with HTTPS, autoscaling, and zero-downtime deployments.
Cloud Run can reduce some infrastructure configuration, but it does not remove the need for an image, IAM, observability, capacity, and failure plan. GDAL and rasterio memory, startup, concurrency, and request behaviour are workload-specific. Record those values before comparing Cloud Run with Lambda or another runtime.
Public Datasets as a Workflow Input
GCP public datasets can be a useful workflow input when the catalogue, licence, schema, freshness, location, and access terms fit. The data still needs a source record, query check, output verifier, and current cost model.
| DATASET | SIZE | UPDATES | COST |
|---|---|---|---|
| OpenStreetMap (planet) | Current catalogue | Check current | Terms check |
| US Census | Current catalogue | Check current | Terms check |
| NOAA Weather | Current catalogue | Check current | Terms check |
| EPA Facilities | Current catalogue | Check current | Terms check |
| TIGER (US boundaries) | Current catalogue | Check current | Terms check |
The practical impact can be lower ingestion effort when a public dataset fits the required geography, licence, freshness, and schema. It is still a data dependency: record the source, terms, update behaviour, query bytes, billing model, and output validation.
Retained Benchmark Illustration
The original article retained workload numbers from a named region and setup. They are historical illustrations, not current measurements. A new run record must include the data, query, location, billing model, runtime, export, and verifier.
GCP GEOSPATIAL - RETAINED ILLUSTRATION
pricing check required
pricing check required
terms and pricing check required
pricing check required
pricing check required
Historical illustration; record the location, data, terms, and verifier.
Cost Analysis
A cost model must use the target users, data volume, locations, query pattern, account terms, support, and operating labour. The old side-by-side figures are retained only as a layout illustration.
| WORKLOAD | GCP | ESRI ENTERPRISE | POSTGIS (SELF-MANAGED) |
|---|---|---|---|
| Store 1TB vectors | Model required | Source check required | Source check required |
| Spatial queries (1TB/mo) | Model required | Licence check required | Compute model required |
| Raster analysis | Terms check required | Source check required | Engineering model required |
| API serving | Model required | Source check required | Source check required |
CAVEAT: QUERY-BASED PRICING BITES
Query-based pricing can make an unbounded scan expensive. Use the current GCP pricing and reservation terms, then record bytes processed, partitioning, clustering, selected columns, location, and query frequency. Compare the same scope with any licence or self-managed option.
When NOT to Use GCP for Geospatial
Review these boundaries before selecting GCP for the target workflow:
1. Your organisation is AWS or Azure first
Multi-cloud complexity rarely justifies the benefits. If your data team, IAM policies, and billing are on AWS, adding GCP for geospatial alone introduces operational overhead that outweighs BigQuery's advantages. Use your primary cloud's spatial capabilities first. Our AWS guide covers the alternatives.
2. You need real-time spatial queries (sub-10ms)
BigQuery is an analytics boundary, not automatically a low-latency application database. Measure the target latency and compare a warm service such as PostGIS or another indexed runtime when the API requires it.
3. You need full control over processing
Earth Engine is a black box. BigQuery abstracts away execution. Cloud Run abstracts away infrastructure. If you need to control every aspect of execution - parallelism, memory allocation, scheduling granularity - consider AWS ECS or bare Kubernetes where you manage the entire stack.
4. You are processing sensitive data
Earth Engine processes data on Google's infrastructure with limited control over data residency. For highly sensitive geospatial data (defence, classified assets, certain financial data), a self-hosted solution with full audit control may be required. BigQuery offers more control here, but Earth Engine does not.
5. Your geospatial workload is small
If the data and query volume are small, a simpler database or local workflow may have a lower operating burden. Compare the target data, latency, support, and total cost rather than using a fixed row or byte threshold.
Reference Architecture
An illustrative GCP geospatial stack for mixed vector and raster workloads. Validate each service, permission, retry path, data movement boundary, and output check before treating it as a deployment design.
1. DATA LAKE
2. SPATIAL ETL
3. ANALYTICS
4. ORCHESTRATION
5. SERVING
The key principle: each service does one thing well. BigQuery for SQL analysis, Dataproc for heavy spatial ETL, Earth Engine for raster imagery, Cloud Run for APIs, Cloud Composer for orchestration, GCS for storage. Resist the temptation to route everything through Earth Engine or build everything as BigQuery stored procedures.
For teams comparing this with other platforms, Part 1 covers Databricks (stronger for lakehouse architectures) and Part 2 covers AWS (more flexible, DIY approach).
Frequently Asked Questions
Can BigQuery handle geospatial data?
BigQuery documents a native GEOGRAPHY type and GoogleSQL geography functions such as ST_CONTAINS, ST_DISTANCE, and ST_INTERSECTION. Check the current limits, location, data layout, billing model, and output validation for the target workload.
Is Google Earth Engine free?
Access and commercial terms depend on the current Google programme and account. Check the official terms and pricing for the intended use. Do not infer a cost or platform recommendation from this retained note.
What is the best GCP service for geospatial analysis?
It depends on the data, operation, region, access pattern, team, and operating model. BigQuery, Earth Engine, Dataproc, and Cloud Run solve different parts of a workflow; compare the target output, limits, cost, and validation method.
GCP offers several geospatial building blocks. The useful decision is the boundary between the data, operation, execution, and validation requirements.
BigQuery GIS may fit SQL geography analysis. Earth Engine may fit a supported imagery workflow. Dataproc may fit distributed processing, and Cloud Run may fit a container service. Confirm the fit with a representative run and current terms.
That is the consistent pattern across this entire series. Match the tool to the problem. Not the other way around.
Get Workflow Automation Insights
Monthly tips on automating GIS workflows, open-source tools, and lessons from enterprise deployments. No spam.