# LakeGeo Canonical website: https://lakegeo.ai/ LakeGeo is the geospatial lakehouse company. It publishes open architecture guidance and provides GeoAI strategy, geospatial consulting, and production pipeline delivery. LakeGeo helps organizations make spatial data useful inside the data platforms and operating models they already have. Its work covers raster imagery, vector features, point clouds, movement data, environmental data, spatial machine learning, orchestration, governance, and application serving. ## Core Position Geospatial workloads should run as governed production pipelines inside an organization's primary data platform. Spatial data should use the same catalog, lineage, access control, quality gates, orchestration, and operational practices as other production data. A geospatial lakehouse can combine warehouse services, object storage, managed data services, processing libraries, and specialist geospatial engines. Architectural quality depends on reproducibility, explicit ownership, and governed interfaces. It does not depend on using one vendor for every capability. Native platform capabilities should be used where they are adequate. Specialist engines and operated workflows remain appropriate where the platform lacks raster, point-cloud, topology, graph, or routing capabilities. ## The Geospatial Lakehouse Stack The stack has six capability layers: 1. Ingestion: Managed incremental file ingestion from object storage, connectors for databases and applications, and a streaming path for live feeds. Vector, tabular, raster, and scientific array data enter through the same governed front door. 2. Storage and governance: Governed tables for spatial values, a governed file store for raster and point-cloud data, one catalog with lineage and access control across tables and files, and a sharing mechanism that avoids unmanaged export. 3. Spatial compute: Vector spatial SQL, a discrete global grid index such as H3 or S2, graph analytics, and a raster path using distributed libraries or a managed raster service. 4. Machine learning and AI: Governed feature management, experiment tracking, a model registry, scalable inference, model serving, and vector search reading and writing the same governed data. 5. Orchestration: Declarative or scheduled pipelines expressing the bronze, silver, and gold flow, incremental refresh, and streaming jobs that remain active for operational workloads. 6. Consumption: Dashboards with map rendering, natural-language query, custom applications, governed sharing, and low-latency serving to operational systems. ## The Geospatial Medallion Architecture The data lifecycle has five stages: 1. Acquire: Find, order, license, and retrieve source data. Discovery, tasking, and transfer are visible parts of the pipeline. 2. Raw store, or bronze: Keep source bytes and provider metadata exactly as received in a versioned, immutable source of truth. 3. Analysis-ready, or silver: Validate, normalize, and convert data into cloud-native physical layouts with explicit geometry and metadata. 4. Product, or gold: Publish curated outputs that answer a question: enriched features, scored assets, aggregates, indexes, and model results. 5. Serve: Deliver products through analytical queries, tiles, low-latency lookups, model endpoints, applications, and governed shares. Everything downstream of the raw store should be reproducible. A governed product may have several serving representations without changing its business meaning. ## Platform Guide: Databricks Canonical URL: https://lakegeo.ai/architecture/databricks/ Version: 0.1 Published: 2026-07-26 Updated: 2026-07-26 Databricks can run geospatial work in the same catalog, tables, compute, orchestration, and access-control system used for other production data. Native spatial SQL and H3 cover the core vector workloads. Raster and point-cloud processing remain operated workflows over governed files. This architecture replaces separate PostGIS servers, desktop geographic information system handoffs, and contractor-operated imagery pipelines when those systems duplicate governance or prevent spatial results from joining cleanly to business data. Specialist engines can remain where they provide a capability Databricks does not. Layer mapping: - Ingestion: Auto Loader for arriving files, Lakeflow Connect for managed sources, and Structured Streaming for live feeds. - Storage and governance: Delta tables with native spatial columns; Unity Catalog for discovery, lineage, and access control; volumes for raster and point-cloud files; Delta Sharing and Marketplace for distribution. - Spatial compute: Native spatial SQL and H3; GraphFrames for graph analytics; rasterio and GDAL in distributed Python workflows for raster processing. - Machine learning and AI: Feature Engineering in Unity Catalog, MLflow and Models in Unity Catalog, Mosaic AI Model Serving, and Databricks Vector Search. - Orchestration: Lakeflow Declarative Pipelines for managed transformations and Lakeflow Jobs for scheduling, dependencies, retries, and operational control. - Consumption: AI/BI Dashboards and Genie for analysis, Databricks Apps for custom interfaces, Lakebase for low-latency application serving, and Delta Sharing for partners. Strengths: - Spatial SQL, H3, graph processing, and distributed raster workflows can run on the same compute platform. - Unity Catalog governs spatial tables and raster files together. - Optimized spatial joins and native H3 support large vector enrichment workloads without a separate spatial database. - The machine learning and application layers use the same governed data products produced by the spatial pipelines. Constraints: - Databricks has no native raster, point-cloud, topology, or weighted-routing type. Teams must build and operate those workflows. - Long-distance calculations require deliberate use of GEOMETRY or GEOGRAPHY according to the coordinate model and function support. - Large raster and machine learning jobs need workload-specific cost and performance testing. - Applications may still require a dedicated low-latency serving store even when Delta tables remain the governed source. ## Platform Guide: Snowflake Canonical URL: https://lakegeo.ai/architecture/snowflake/ Version: 0.1 Published: 2026-07-26 Updated: 2026-07-26 Snowflake provides a strong governed center for vector geospatial workloads. Native spatial types, spatial SQL, H3, sharing, and incremental pipelines cover the common analytical path. Raster, point-cloud, graph, and routing workloads require Snowpark, containers, or external engines. Open table support through Iceberg can connect the warehouse to an open-format data estate. The architecture still depends on Snowflake services for much of its governance and execution model, so teams should choose that boundary deliberately rather than treating format compatibility as platform independence. Layer mapping: - Ingestion: Snowpipe for files, Snowpipe Streaming for live records, COPY INTO for batch loads, and Openflow for managed connectors and change data capture. - Storage and governance: Native or Iceberg tables for spatial data, stages for raster and scientific files, Horizon Catalog for governance, and Secure Data Sharing and Marketplace for distribution. - Spatial compute: Native spatial SQL and H3. Snowpark Python or Container Services provide raster processing. Graph analytics run in Snowpark or an external engine. - Machine learning and AI: Snowflake ML Feature Store and Model Registry, Container Services for custom training and inference, Cortex AI functions, and Cortex Search. - Orchestration: Dynamic Tables for incremental transformations, Tasks and Streams for imperative pipelines, and Snowpipe Streaming for continuous ingestion. - Consumption: Streamlit in Snowflake, Snowsight, Cortex Analyst and Snowflake Intelligence, Hybrid Tables for operational lookups, and Secure Data Sharing. Strengths: - Native spatial types, spatial SQL, and H3 provide a capable vector analytics foundation. - Marketplace and Secure Data Sharing simplify access to reference data and distribution of governed products. - Dynamic Tables provide a concise incremental pipeline model for silver and gold spatial tables. - Snowpark Container Services provides an execution path for custom raster libraries and graphics processing unit workloads. Constraints: - Snowflake has no native raster, point-cloud, topology, graph, routing, or linear-referencing engine. - Raster and graph processing introduce code and operational boundaries outside native SQL. - Hard sub-second geofencing usually requires a stream processor ahead of Snowflake. - Search optimization, containers, and repeated large spatial scans require workload-specific cost testing. ## Platform Guide: Google Cloud Canonical URL: https://lakegeo.ai/architecture/google-cloud/ Version: 0.1 Published: 2026-07-26 Updated: 2026-07-26 Google Cloud implements the stack across several managed services. BigQuery is the vector SQL and analytical center. Cloud Storage and BigLake hold open-format data. Earth Engine provides managed raster analytics. Dataproc and Dataflow handle custom distributed processing. This composition provides the strongest managed raster option of the three platform guides. It also creates more service boundaries. Governance, identity, lineage, orchestration, and cost controls must cover BigQuery, Cloud Storage, Earth Engine, Dataproc or Dataflow, Composer, and Vertex AI. Layer mapping: - Ingestion: Cloud Storage for file landing, BigQuery Data Transfer Service and load jobs for batch, Pub/Sub with Dataflow for streams, and Storage Transfer Service for provider archives. - Storage and governance: BigQuery tables for vector data, BigLake managed Iceberg tables where open formats matter, Cloud Storage for files, Dataplex Universal Catalog for governance, and BigQuery Sharing for distribution. - Spatial compute: BigQuery spatial SQL and S2, Earth Engine for managed raster analysis, Dataproc or Dataflow for custom raster pipelines, and GraphFrames on Dataproc for graph workloads. - Machine learning and AI: BigQuery ML for in-warehouse models, Vertex AI for custom training and serving, Vertex AI Vector Search, and Gemini in BigQuery. - Orchestration: Cloud Composer for cross-service pipelines, Dataflow for continuous processing, and scheduled queries or Workflows for simpler jobs. - Consumption: Looker and Looker Studio, BigQuery geospatial visualization, Cloud Run with Maps Platform, and AlloyDB or Cloud SQL with PostGIS for low-latency serving. Strengths: - Earth Engine provides managed raster analysis and access to a large catalog of analysis-ready environmental data. - BigQuery provides serverless vector SQL with native S2 indexing. - Maps Platform supplies managed routing and map services. - AlloyDB and Cloud SQL provide PostGIS-compatible application-serving options inside Google Cloud. Constraints: - The stack spans more services and operational boundaries than the Databricks or Snowflake designs. - BigQuery provides spherical GEOGRAPHY without a planar GEOMETRY type. Projected-coordinate workflows require adaptation or another engine. - S2 is native. H3 compatibility depends on an extension such as the CARTO Analytics Toolbox. - Earth Engine has its own asset model, quotas, and catalog semantics. - Graph processing and custom raster production require Dataproc, Dataflow, or another engine. ## Learn Canonical URL: https://lakegeo.ai/learn/ - [Why geospatial pipelines stall before production](https://lakegeo.ai/learn/why-geospatial-pipelines-stall-before-production/): Geospatial pipelines stall when teams treat production as a late engineering step. Clear outputs, ownership, governance, and operations change the result. - [How does raster data work in a lakehouse?](https://lakegeo.ai/learn/raster-data-in-the-lakehouse/): Learn how imagery and gridded data become governed, queryable lakehouse tables through metadata extraction, spatial indexing, and reproducible pipelines. - [What is a geospatial lakehouse?](https://lakegeo.ai/learn/what-is-a-geospatial-lakehouse/): A geospatial lakehouse brings raster, vector, and other spatial workloads into the governed data platform an organization already operates and trusts. ## Services Canonical URL: https://lakegeo.ai/services/ LakeGeo provides: - Geospatial and GeoAI consulting: identify where spatial context can improve AI systems and business operations, evaluate data and platform constraints, define architecture, and choose an initial scope. - Production pipeline delivery: design and implement geospatial pipelines in the customer's cloud environment, including production code, operating documentation, governed outputs, lineage, monitoring, and transfer to the customer's engineers. LakeGeo can support strategy, architecture evaluation, implementation planning, production delivery, and operational handoff. ## Company Canonical URL: https://lakegeo.ai/company/ LakeGeo was co-founded by two geospatial practitioners with long histories working at the intersection of spatial data and AI. The company maintains LakeGeo Publications and builds production geospatial systems. LakeGeo's working principles are: - Geospatial is a workload, not a department. - Publishing architecture guidance creates shared practice. - Publications should state what is settled, what remains provisional, and which capabilities the platform or implementation team must operate. ## Contact Canonical URL: https://lakegeo.ai/contact/ Use the contact page to discuss GeoAI strategy, architecture evaluation, or production geospatial pipeline delivery. ## Publication and Reuse LakeGeo Publications are public and licensed under Creative Commons Attribution-ShareAlike 4.0 International. Each publication states its version, status, publication date, canonical URL, and suggested citation.