Support for DuckDB GEOMETRY type in Airport

[VGSML]

Hi, all!

DuckDB already has a logical GEOMETRY type (used by the spatial extension), and inside DuckDB it supports BBOX filtering, MBR pushdowns and ST_* functions.
However, when a table is passed through Arrow Flight via the Airport extension, GEOMETRY is not supported at all — DuckDB receives it only as binary/blob, losing the logical type and all spatial optimizations.

Current limitation
• Airport passes Arrow schemas as-is.
• DuckDB -> Arrow and Arrow -> DuckDB do not include any mapping for GEOMETRY.
• As a result, Flight servers cannot expose spatial data to DuckDB in a way that preserves the logical geometry type.

Proposal (short-term, realistic)

Add an opt-in mapping in the Airport extension:

If an Arrow field is binary and has specific metadata (e.g. duckdb:geometry_binary), Airport should map it to the DuckDB logical type GEOMETRY when constructing the DuckDB schema.

This would allow:
• using real GEOMETRY columns in DuckDB when scanning via Airport,
• enabling BBOX pushdown,
• running ST_* functions without manual ST_GeomFromWKB(...),
• zero-copy scenarios for DuckDB↔DuckDB Flight connections.

Longer-term direction (within Airport)

Introduce optional support for GeoArrow extension types in Airport, and map them to DuckDB GEOMETRY automatically.
This would enable proper cross-system interoperability while keeping Airport the “geospatial-aware” Arrow layer for DuckDB.

Question

Would you consider adding:
1. An experimental opt-in mapping binary -> GEOMETRY based on metadata?
2. (Later) GeoArrow -> GEOMETRY conversion inside Airport?

[rustyconover]

Hi @VGSML,

I haven't tested the GEOMETRY type like I have with the other DuckDB types.

Have you enabled arrow_lossless_conversion in your DuckDB session? A simple grep of the code in arrow_type_extension.cpp shows that there should be support for the Geometry type both to and from Arrow.

Set the config with:

SET arrow_lossless_conversion = true;

Once you confirm it is not working, can you let me know?

Rusty

[VGSML]

Ah, I see ArrowGeometryType struct, thanks.

I didn't tested yet with airport, but if I use the new arrow C-API (I have just implemented it support in duckdb-go). I got result of query with one geometry field, in that the arrow schema has no metadata (empty) for field and for the schema itself.

It looks like it should work if I create a schema with geo arrow column (with metadata) and pass through the airport to the duckdb.

I will tested it. I try to create golang package that allow developers to make airport compatible service easily.

I will return to discussion in few days with testing results.

[VGSML]

It's looks like the duckdb issue, the new arrow C-API duckdb_to_arrow_schema ignores the Geometry type and converts it to the Binary. Other extensions types like huge int are converted with required metadata.

[VGSML]

It's not working, if I pass the arrow schema with the ARROW:extension:name - geoarrow.wkb, it is defined as BLOB in the catalog! So now we can't define geometry columns in the airport service.

[VGSML]

Maybe it's not fully implemented yet (I see the issue in the duckdb_spatial duckdb/duckdb-spatial#589). I propose to save this discussion open until the 1.5 will be released and I check it