-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OGRLayer::WriteArrowBatch type fallback implementation breaks if OGRLayer::GetDataset is not overridden #9568
Comments
Help welcome :-)
Unfortunately there's none when you have just the layer object. You need to browser through layer -> dataset -> driver
done per #9570 |
Global pass done in #9572 |
What is the bug?
#8517 added a generic type fallback mechanism for writing non-native field types as strings/JSON. The Arrow-based writing API with this fallback is very useful for all layer types when the data is already present in the Arrow format in a driver-agnostic application (for example, through the new WIP Arrow writing path in pyogrio). Unfortunately, the fallback implementation currently relies on the
OGRLayer::GetDataset
being overridden by a specific layer to fetch the list of field data types supported by its driver, and starts silently creating fields with non-supported data types and passing through such data intoCreateFeature
if this method is not implemented or returnsnullptr
.The documentation on this method seems to be a bit outdated, and states the following:
I would argue that at least the type fallback mechanism needs either to be able to rely on this method, in which case it needs to be implemented in all layers, or there should be some other reliable way to access the driver metadata. I stumbled on this issue when trying to write some data with a StringList field into FlatGeoBuf, and it was very confusing to see it fail when the Shapefile write succeeded, while they should be using the same generic implementation.
It seems that indeed only a few drivers implement this method currently, with FlatGeoBuf added in master (#8860, not in 3.8). Maybe it would be possible to at least backport the
OGRFlatGeobufLayer::GetDataset
implementation from there into 3.8?Steps to reproduce the issue
Autotest
test_ogr_shape_write_arrow_fallback_types
should work for all drivers without native datetime/list support.Versions and provenance
Issue reproduced on GDAL 3.8.3 built into the pyogrio wheels on Linux x86_64.
Additional context
No response
The text was updated successfully, but these errors were encountered: