Earth Engine in BigQuery: A New Geospatial SQL Analytics
BigQuery Earth Engine
With Earth Engine directly integrated into BigQuery, Google Cloud has expanded its geographic analytics capabilities. Incorporating powerful raster analytics into BigQuery, this new solution from Google Cloud Next ‘25 lets SQL users analyse satellite imagery-derived geographical data.
Google Cloud customers prefer BigQuery for storing and accessing vector data, which represents buildings and boundaries as points, lines, or polygons. Earth Engine in BigQuery is suggested for processing and storing raster data like satellite imagery, which encodes geographic information as a grid of pixels with temperature, height, and land cover values.
“Earth Engine in BigQuery” mixes vector and raster analytics. This integration could improve access to advanced raster analysis and help solve real-world business problems.
Key features driving this integration:
- BigQuery’s new geography function is ST_RegionStats. This program extracts statistics from raster data inside geographic borders, similar to Earth Engine’s reduceRegion function. Use an Earth Engine-accessible raster picture and a geographic region (vector data) to calculate mean, min, max, total, or count for pixels that traverse the geography.
- BigQuery Sharing, formerly Analytics Hub, now offers Earth Engine in BigQuery datasets. This makes it easy to find data and access more datasets, many of which are ready for processing to obtain statistics for a region of interest. These datasets may include risk prediction, elevation, or emissions.
Raster analytics with this new feature usually has five steps:
- Find vector data representing interest areas in a BigQuery table.
- Find an Earth Engine raster dataset in BigQuery image assets, Cloud GeoTiff, or BigQuery Sharing.
- Use ST_RegionStats() with the raster ID, vector geometries, and optional band name to aggregate intersecting data.
- To understand, look at ST_RegionStats() output.
- Use BigQuery Geo Viz to map analysis results.
This integration enables data-driven decision-making in sustainability and geographic application cases:
Climate, physical risk, and disaster response: Using drought, wildfire, and flood data in transportation, infrastructure, and urban design. For instance, using the Wildfire hazard to Communities dataset to assess wildfire risk or the Global River Flood Hazard dataset to estimate flood risk.
Assessing land-use, elevation, and cover for agricultural evaluations and supply chain management. This includes using JRC Global Forest Cover datasets or Forest Data Partnership maps to determine if commodities are grown in non-deforested areas.
Methane emissions monitoring: MethaneSAT L4 Area Sources data can identify methane emission hotspots from minor, distributed sources in oil and gas basins to enhance mitigation efforts.
Custom use cases: Supporting Earth Engine raster dataset imports into BigQuery image assets or Cloud Storage GeoTiffs.
BigQuery Sharing contains ST_RegionStats()’s raster data sources, where the assets.image.href column normally holds the raster ID for each image table. Cloud Storage GeoTIFFs in the US or US-central1 regions can be used with URIs. Earth Engine image asset locations like ‘ee://IMAGE_PATH’ are supported in BigQuery.
ST_RegionStats()’s include option lets users adjust computations by assigning pixel weights (0–1), with 0 representing missing data. If no weight is given, pixels are weighted by geometry position. Raster pixel size, or scale, affects calculation and output. Changing scale (e.g., using options => JSON ‘{“scale”: 1000}’) can reduce query runtime and cost for prototyping, but it may impact results and should not be used for production analysis.
ST_RegionStats() is charged individually under BigQuery Services since Earth Engine calculates. Costs depend on input rows, raster picture quality, input geography size and complexity, crossing pixels, image projection, and formula usage. Earth Engine quotas in BigQuery slot time utilisation can be changed to control expenses.
Currently, ST_RegionStats() queries must be run in the US, us-central1, or us-central2.
This big improvement in Google Cloud’s geospatial analytics provides advanced raster capabilities and improves sustainability and other data-driven decision-making.
