alamb commented on code in PR #156: URL: https://github.com/apache/parquet-site/pull/156#discussion_r2768730792
########## content/en/blog/features/geospatial.md: ########## @@ -0,0 +1,152 @@ +--- +title: "Native Geospatial Types in Apache Parquet" +date: 2026-02-04 +description: "Native Geospatial Types in Apache Parquet" +author: "[Jia Yu](https://github.com/jiayuasu), [Dewey Dunnington](https://github.com/paleolimbot), [Kristin Cowalcijk](https://github.com/Kontinuation), [Feng Zhang](https://github.com/zhangfengcdt)" +categories: ["features"] +--- + +Geospatial data has become a core input for modern analytics across logistics, climate science, urban planning, mobility, and location intelligence. Yet for a long time, spatial data lived outside the mainstream analytics ecosystem. In primarily non-spatial data engineering workflows, spatial data was common but required workarounds to handle efficiently at scale. Formats such as Shapefile, GeoJSON, or proprietary spatial databases worked well for visualization and GIS workflows, but they did not integrate cleanly with large scale analytical engines. + +The introduction of native geospatial types in Apache Parquet marks a major shift. Geometry and geography are no longer opaque blobs stored alongside tabular data. They are now first class citizens in the columnar storage layer that underpins modern data lakes and lakehouses. + +This post explains why native geospatial support in Parquet matters and gives a technical overview of how these types are represented and stored. + +## Why Geospatial Types Matter in Analytical Storage + +Spatial data storage presents unique challenges: a single geometry may represent a point, a road segment, or a complex polygon with thousands of vertices. Queries are also different: instead of simple equality or range filters, users ask spatial questions such as containment, intersection, distance, and proximity in two (XY) or even three (XYZ) dimensions. + +Historically, geospatial columns in Parquet were stored as generic binary or string values, with spatial meaning encoded in external metadata. This approach had several limitations. + +1. Query engines could not detect a column was GEOMETRY or GEOGRAPHY without an explicit function call by the user (even if the engine supported GEOMETRY or GEOGRAPHY types natively) +2. Query engines could not apply statistics-based pruning: full Parquet files were required to be read even for spatial queries that returned a small number of rows. + +Native geospatial types address these issues directly. By making geometry and geography part of the Parquet logical type system, spatial columns become visible to query planners, execution engines, and storage optimizers. + +A key benefit is the ability to attach spatial statistics such as bounding boxes to column chunks and row groups. With bounding boxes available in Parquet statistics, engines can skip entire row groups that fall completely outside a query window. This dramatically reduces IO for spatial filters and joins, especially on large datasets. + +In practice, this means that spatial analytics can finally benefit from the same performance techniques that made Parquet dominant for non-spatial workloads. + + + +**Figure 1:** Visualization of bounding boxes for 130 million buildings stored in a Parquet file from the contiguous U.S. (Microsoft Buildings, file from [geoarrow.org/data](http://geoarrow.org/data), visualization [code](https://gist.github.com/paleolimbot/06303283b42161b57ffc37a8fed60890) here) + +## From GeoParquet Metadata to Native Types + +Before Parquet adopted GEOMETRY and GEOGRAPHY types in 2025, the [GeoParquet](https://geoparquet.org/) community [1] had already standardized how geometries should be stored in Parquet as early as 2022, using well known binary encoding plus a set of metadata keys. This was an important step because it enabled interoperability across tools. Review Comment: Given you already have the link to Geoparquet here, I am not sure the `[1]` adds much -- it is also not a hyperlink in the rendered text. I suggest you remove the `[1]` link here and the end of the document and instead just use inline markdown links instead <img width="1165" height="447" alt="Image" src="https://github.com/user-attachments/assets/d01f2892-bb17-4460-8f86-3b8e2862ec40"; /> That being said, I think it is also fine to leave the links here ########## content/en/blog/features/_index.md: ########## @@ -0,0 +1,6 @@ + Review Comment: We can probably remove this random blank like (I think that is left over from the template) ```suggestion ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
