paleolimbot commented on issue #546: URL: https://github.com/apache/arrow-adbc/issues/546#issuecomment-1707530057
It's a good point...going from value-level SRID to column-level SRID is hard and would require either: - collecting a certain number of rows or batches when a user calls `AdbcStatementExecuteQuery()` and using the first values to query the SRID table and add it to the type before populating the result `ArrowArrayStream`. This is what the SQLite driver does. - in the common case where the query is returning a field in a table, the `PQresult` would know what table and what column index (via `PQftable()` and `PQftablecol()`). In theory one could construct a query in `AdbcStatementExecuteQuery()` before populating the `ArrowArrayStream` result that fills in the CRS. SQLite similarly has options for this ( https://www.sqlite.org/c3ref/column_database_name.html ). The first option could be done in a wrapper driver...the second one would have to be passed on via field metadata to be used in a wrapper driver (and wouldn't work for queries with PostGIS or the various spatial SQLite function calls). Collecting some rows from the start might be helpful when attempting to convert a geometry column to geoarrow, too (it could try to guess a single geometry type, for example). Probably the first "geoadbc" driver should be a thin wrapper around OGR's ArrowArrayStream export? That may help establish some conventions (e.g., option names). Worth chatting about in the geoarrow org somewhere too, but also worth considering which pieces of metadata we would need from the upstream driver to make geospatial wrappers since those changes would have to happen here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
