Why GeoParquet Is Not A Cloud Native Format

(Geo)Parquet is an extremely useful column oriented data format. When working with local, massive data sets having many millions of features, the performance of this format is second to none. When working with data over the internet, it has no advantage what-so-ever. In fact, it's useless in the context of cloud native.

Range requests or streaming is what makes a cloud native format, cloud native.

Range requests are only available using out-of-the-box http(s) protocol. This means only @cogeotiff for raster and @flatgeobuf for vector can be efficiently requested in a cloud native format.

To do range requests on the poorly named #geoparquet you need a protocol that adheres to fsspec. Further, both end points must support that protocol. Meaning the browser must have additional code as well as the server. Apache or other web servers do not natively support it.

To make matters worse, you can't grab a bounding box from "Geo" parquet. Which is the whole point.

Further, geoparquet allows geometry SRS to be different in every feature. It does not have a 'table' level SRS. Think about that for a moment.

Lastly, and most importantly, the benefits of a columnar format are only realized with huge data sets. When visualizing or doing analyses in browser you wouldn't move that quantity of data across the internet. The browser probably couldn't handle it and the user wouldn't wait for it.

Note, the term cloud native refers to processing cloud data with a app/web client without intermediate backend servers/services.