Properties at top level vs. nested

[gadomski]

Note

This issue should be copied to https://github.com/radiantearth/stac-geoparquet-spec as a part of #114

Discussed in #110

^{Originally posted by jcondit June 16, 2025}
Hi!

I'm an engineer at Google working on Earth Engine and BigQuery. We're publishing some tables to BigQuery that contain raster metadata with a STAC-inspired schema. So far we've based the table schema on STAC itself, but we were considering adopting stac-geoparquet in order to be more consistent with external formats aimed at analytical databases. In particular, it'd be nice to be able to import/export easily between BigQuery image tables and stac-geoparquet files.

My main concern is that stac-geoparquet puts the properties at top level, which creates some awkward conflicts; for example, we've already encountered an asset with an "id" property that would be disallowed (at least with its current name) due to a conflict with the main "id" field. And for BigQuery at least, there's no benefit in putting the properties at top level vs. nested within the "properties" field -- they're easily queryable in both schema locations.

Can you tell me a bit more about why you chose to move the properties at top level? Is it necessary for some query engines? Is there any possibility that a future version of stac-geoparquet might move them back inside a "properties" object, or is stac-geoparquet fully committed to keeping them at top level?

Thanks!
Jeremy