You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice to have a GeoPackage reader that handles full attribute conversion into geozero as well for the table. Or is this out of scope because it would require depending on a specific SQL client instead of leaving that choice for the user? I.e. in geoarrow-rs, I'd probably want a sync API, and would probably want to use rusqlite, but others might prefer sqlx.
The text was updated successfully, but these errors were encountered:
I'm still unsure about GeozeroDatasource trait implementations. It's going into ogr2ogr territory, but because processing with the geozero callback model is very difficult to parametrize, it will never be on par with GDAL/OGR. Therefore I would stick with the geometry impl and let applications implement the datasource part.
but because processing with the geozero callback model is very difficult to parametrize, it will never be on par with GDAL/OGR.
If I understand you correctly, you're saying that supporting, say, a bounding-box filter would be hard to implement because the stream only sees a single coordinate at a time?
To support pushing down queries to the loading stage I was thinking of implementing like a BufferedGeozeroDatasource<T: GeozeroDatasource> which buffers one full feature in memory at a time from the stream and is then able to check if the bounding box of the geometry intersects the query.
It would be nice to have a GeoPackage reader that handles full attribute conversion into geozero as well for the table. Or is this out of scope because it would require depending on a specific SQL client instead of leaving that choice for the user? I.e. in geoarrow-rs, I'd probably want a sync API, and would probably want to use rusqlite, but others might prefer sqlx.
The text was updated successfully, but these errors were encountered: