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
Is there any interest in such kind of functionality support, or that was intentionally not implemented? Could be nice to establish / contribute into some sort of a standard for the R-tree serialization format (if there is no such yet).
// definitely a feature request / enhancement / help wanted issue
The text was updated successfully, but these errors were encountered:
The use case is in building an index for the parquet file of geometries and persisting it, so we are not rebuilding it every time. The leafs of a tree will contain file block id(s) which later on can be used to perform reads.
I don’t need serialization immediately (it was resolved in a bit different fashion, I can tell you more but it seems like the out of scope conversation) and also don’t have any capacity to work on it.
But conceptually the idea of an efficient persistent index is of a significant interest to me: I have a feeling that such index may work way faster than the inbuilt parquet reader predicates api; I could also be wrong since that’s unclear what benefits we really get with it until we try, the cons are obvious though.
R-tree
serialization could be a pretty nice extra feature to support as a part of this fantastic tiny library.R-tree
serialization implementations to inspireIs there any interest in such kind of functionality support, or that was intentionally not implemented? Could be nice to establish / contribute into some sort of a standard for the
R-tree
serialization format (if there is no such yet).// definitely a feature request / enhancement / help wanted issue
The text was updated successfully, but these errors were encountered: