# GeoParquet vs Cloud Optimized GeoTIFF for Mesh Distribution

Choosing the wire format for a spatial data product is a contract decision, not a storage convenience: it fixes how consumers read, filter, and reproject the data across every domain boundary. This page compares GeoParquet against Cloud Optimized GeoTIFF (COG) as the two canonical distribution formats in a mesh, and belongs to Metadata Cataloging for Raster/Vector under Geospatial Data Mesh Fundamentals. The short rule: distribute discrete features and attribute tables as GeoParquet with columnar predicate pushdown, and distribute continuous raster surfaces as COG with HTTP range reads and internal overviews. The catalog entry that advertises either format follows the same discipline set out in Best Practices for Spatial Metadata Catalogs.

Both formats are cloud-native and support partial reads over object storage, so the decision turns on the data model, not on whether a file “opens in the cloud.” The matrix below draws the line dimension by dimension.

Figure — A six-dimension comparison matrix contrasting GeoParquet and Cloud Optimized GeoTIFF for mesh distribution.

# Prerequisites

# Step-by-Step Implementation

# 1. Inspect a GeoParquet product before advertising it

Confirm the geometry column, feature count, CRS, and that the file carries the geo metadata GeoParquet requires. ogrinfo reads the columnar structure without materializing every row:

ogrinfo -so -al roads_v1.2.0.parquet
# Layer name: roads
# Geometry: Line String
# Feature Count: 184203
# Extent: (-122.52, 37.70) - (-122.34, 37.83)
# SRS WKT: GEOGCRS["WGS 84", ... ID["EPSG",4326]]

Verify the columnar metadata and row-group count with pyarrow so you know predicate pushdown will actually prune:

python3 -c "import pyarrow.parquet as pq; f=pq.ParquetFile('roads_v1.2.0.parquet'); \
print('row_groups=', f.num_row_groups); \
print('has_geo=', b'geo' in f.metadata.metadata)"
# expect: row_groups= 12
# expect: has_geo= True

# 2. Inspect and validate a COG product

For raster, confirm the file is a valid COG — internal tiling plus overviews — because a plain GeoTIFF served over HTTP forces whole-file reads. gdalinfo reports the block layout and overview levels:

gdalinfo dem_v1.2.0.tif | grep -E "Block|Overviews|EPSG"
# Band 1 Block=512x512 Type=Float32
# Overviews: 4096x4096, 2048x2048, 1024x1024, 512x512

Then run the conformance check that the format actually mandates:

rio cogeo validate dem_v1.2.0.tif
# dem_v1.2.0.tif is a valid cloud optimized GeoTIFF

# 3. Prove the range-read access pattern for COG

The property that makes COG mesh-ready is the HTTP range read: a consumer fetches the header and a single tile without downloading the file. Fetch just the leading bytes that hold the IFD and tile index:

curl -s -r 0-16383 \
  https://cdn.geo-mesh.example/dem_v1.2.0.tif -o cog_header.bin
# Server must answer 206 Partial Content, not 200 OK
curl -s -o /dev/null -w "%{http_code} %{size_download}\n" \
  -r 0-16383 https://cdn.geo-mesh.example/dem_v1.2.0.tif
# expect: 206 16384

Confirm GDAL can then read a window remotely over /vsicurl/ without pulling the whole raster:

gdalinfo /vsicurl/https://cdn.geo-mesh.example/dem_v1.2.0.tif | grep "Size is"
# Size is 8192, 8192   (read from the header alone, no full download)

# 4. Apply the decision and record the format in the catalog

Use the table below to pick the format, then declare it in the STAC asset type so consumers negotiate the right reader. This is the same catalog envelope described in Best Practices for Spatial Metadata Catalogs.

Because CRS travels differently in each format — PROJJSON for GeoParquet, embedded SRS tags for COG — pin the projection at the product boundary rather than reprojecting on read, as covered in Standardizing on EPSG:4326 Across Domains.

# Configuration Reference

# Common Failure Modes & Fixes

Symptom: curl -r against the COG returns 200 OK and the full file size, not 206. Root cause: the object store or CDN in front of it does not honor Range headers, so every “windowed” read downloads the whole raster. Fix: enable range support on the bucket/CDN and re-test with the step 3 command; confirm the response is 206 Partial Content before advertising the asset.

Symptom: rio cogeo validate reports “not a valid cloud optimized GeoTIFF.” Root cause: the file has no internal tiling or no overviews — it is a striped GeoTIFF that happens to sit in object storage. Fix: rewrite it with rio cogeo create -p deflate --overview-resampling average in.tif out.tif and re-validate.

Symptom: GeoParquet reads scan every row group despite a bbox filter. Root cause: the writer produced a single giant row group, or geometry bbox statistics were not written, so there is nothing to prune on. Fix: rewrite with a bounded ROW_GROUP_SIZE and a spatially sorted order (e.g. Hilbert curve) so row-group bboxes are tight, then confirm num_row_groups > 1.

Symptom: consumers report the vector product is in the wrong projection. Root cause: the geo PROJJSON metadata was stripped during a copy, so readers fall back to assuming EPSG:4326. Fix: rewrite with ogr2ogr -f Parquet -a_srs EPSG:4326 out.parquet in.parquet and verify ogrinfo -so reports the SRS WKT.

# FAQ

# Related

• Metadata Cataloging for Raster/Vector — the parent concern that advertises whichever format you choose.
• Best Practices for Spatial Metadata Catalogs — the catalog envelope that carries the asset type.
• Standardizing on EPSG:4326 Across Domains — how CRS is pinned regardless of format carrier.
• Implementing Product Thinking for Satellite Imagery Datasets — a COG-centric raster product pipeline end to end.
• Data Mesh vs Traditional GIS Architecture — why format choice is a consumer contract, not a storage detail.