GeoParquet 1.1 support

[cholmes]

It'd be great to more broadly support GeoParquet 1.1. There's a range of what could be done with GPQ, in rough order of importance / effort:

• Validate the new 1.1 features - recognize the new encodings, and check for the bbox (perhaps recommend adding if it's not there)
• Write support for bounding box column - writing without trying to sort would be a good first step, and just assume/hope the file has a decent sort order
• Option to sort by r-tree or some other nice spatial option when writing bounding box column
• Read a subset of data leveraging the bbox column. Reading with bbox is less important right now as GPQ doesn't have a notion of filtering by bounds / getting a subset, but if it added it then it could efficiently grab overture data and other large datasets.
• native encoding / geoarrow support, for both read and write. Perhaps would not be a huge amount of work as there's likely good arrow support in the underlying parquet/arrow libraries?

[felix-schott]

For the record, point 4 is covered by #264.

Re point 2 - "Write support for bounding box column": I can see this having an effect on 2 areas of the API.
To start with, we would probably want to compute row-level boxes as part of gpq convert input.geojson output.parquet and gpq convert non-geo.parquet geo.parquet. I'm wondering if there is any need to make this optional or whether a bbox column should be added by default when converting.
Secondly, we might want an explicit gpq add-bbox input.parquet output.parquet command. As an alternative API, I also like the idea of a subcommand gpq add bbox (another subcommand to gpq add could be gpq add metadata cf. #48). Any suggestions on the API? add(-)bbox could potentially be ambiguous as there is also column-level bbox metadata, so maybe more explicitly add-bbox-column?

[cholmes]

+1 to adding a bbox column by default, at least if it's 1.1 output. Could potentially have an option to turn off the bbox, but I lean towards doing it by default. Ideally we also order it - just having the bbox on unsorted data won't help performance much. But I don't know what the options are in the go geospatial ecosystem, if there is a hilbert curve implementation or anything. If there's not I probably wouldn't add the bbox column by default. DuckDB can do it, and I know we don't want to pull that in as a dependency, but it could be a separate library and if it's there then could do the sort (and add the bbox column by default).

+1 on a add-bbox-column command, and I think that's also ok even if there's not a spatial sort, as the user can sort it with other tools.