GH-45522: [Parquet][C++] Parquet GEOMETRY and GEOGRAPHY logical type implementations

[paleolimbot]

Rationale for this change

The GEOMETRY and GEOGRAPHY logical types are being proposed as an addition to the Parquet format.

What changes are included in this PR?

This is a continuation of @Kontinuation 's initial PR (#43977) implementing apache/parquet-format#240 , which included:

• Added geometry logical types (printing, serialization, deserialization)
• Added geometry column statistics (serialization, deserialization, writing)
• Support reading/writing parquet files containing geometry columns

Changes after this were:

• Rebasing on the latest apache/arrow
• Split geography/geometry types
• Synchronize the final parameter names (e.g., no more "encoding", "edges" -> "algorithm")
• Simplify geometry_util_internal.h and use Status instead of exceptions according to suggestions from the previous PR

In order to write test files, I also:

• Implemented conversion to/from the GeoArrow extension type
• Wired the requisite options to pyarrow so that the files could be written from Python

Those last two are probably a bit much for this particular PR, and I'm happy to move them.

Some things that aren't in this PR (but should be in this one or a future PR):

• Update the bounding box logic to implement the "wraparound" bounding boxes where max > min (and generally make sure the stats for geography are written for trivial cases)
• Test more invalid WKB cases

Are these changes tested?

Yes!

Are there any user-facing changes?

Yes!

Example from the included Python bindings:

import pyarrow as pa
from pyarrow import parquet
import geoarrow.pyarrow as ga  # For registering the extension type
import geopandas

path = "/Users/dewey/gh/parquet-testing/data/geospatial/example-crs_vermont-4326.parquet"
file = parquet.ParquetFile(path, arrow_extensions_enabled=True)
file.schema
#> <pyarrow._parquet.ParquetSchema object at 0x1136ee600>
#> required group field_id=-1 schema {
#>   optional binary field_id=-1 geometry (Geometry(crs=));
#> }
file.metadata.metadata
#> (eventually should contain any CRSes that were dumped there)
geometry_index = len(file.schema.names) - 1
file.metadata.row_group(0).column(geometry_index).geospatial_statistics
#> <pyarrow._parquet.GeospatialStatistics object at 0x117b07f40>
#>   geospatial_types: [3]
#>   xmin: -73.4296726142165
#>   xmax: -71.50351111518535
#>   ymin: 42.72708222103286
#>   ymax: 45.00831248634144
#>   zmin: None
#>   zmax: None
#>   mmin: None
#>   mmax: None

# Type and CRS should propagate through
file.schema_arrow.field("geometry").type
#> WkbType(geoarrow.wkb <OGC:CRS84>)

# GeoPandas should be able to take the result of this and ensure
# the CRS is not lost (and that the geometry column is picked up)
table = file.read()
df = geopandas.GeoDataFrame.from_arrow(table)
df.geometry.crs.name
#> 'WGS 84 (CRS84)'
df.geometry.head(5)
#> 0    POLYGON ((-72.45707 42.72708, -73.28203 42.743...
#> Name: geometry, dtype: geometry
parquet.write_table(table, "foofy.parquet", write_geospatial_logical_types=True)
parquet.read_table("foofy.parquet", arrow_extensions_enabled=True).schema
#> geometry: extension<geoarrow.wkb<WkbType>>

• GitHub Issue: [Parquet][C++] Implement Geography and Geometry types in the C++ Parquet implementation #45522

[emkornfield]

One separate thing that would be nice to do as a follow up is adding a fuzzing test for the new parsers.

[paleolimbot]

@emkornfield @pitrou @wgtmac Thank you for your reviews! I think I managed to get the spirit of all of your comments throughout the diff, although I am sure I missed something and obviously feel free to let me know what it was! I think the outstanding issues are:

• I merged the changes in from the branch I had been using to write the test files, so as is, this PR is fully functional for arbitrary cases of write_parquet(geopandas_data_frame.to_arrow()) or write_parquet(duckdb_rel.to_arrow_table()) or write_parquet(sedona.spark.dataframe_arrow(spark_df)) with the extension type registered. I made the JSON dependency optional and separated the code so that it's easy to remove if that's not something we want. I'm totally game to remove that...we can do enough without parsing JSON that all of the reading/writing code is tested and we can solve the full utility later on (e.g., through a canonical extension type).
• I re-read the "crs" section of the final spec and remembered very late that the projjson:some_file_metadata_field is a recommendation and not a requirement. It's obviously much easier to just dump GeoArrow's "crs": ... to Parquet's crs and vice versa and it would be very easy to convince me not to implement the recommendation (which would allow the removal of the GeoCrsContext from the ArrowWriterProperties and the KeyValueMetadata reference from the node context thing in the other direction). Alternatively, I'm happy to remove all non-lon/lat CRS handling (which still allows all of the read/write code to be tested) and figure that out later.
• I am wondering if the R CI failures are because I added a shared_ptr to the ArrowWriterProperties. Happy to work through that if we decide we still want it there!

(Or feel free to add something to this list!)