docs(readme): clarify DuckDB version alignment for GeoArrow 1.1 / GeoParquet 1.1#183
Open
estebanzimanyi wants to merge 1 commit into
Open
Conversation
…Parquet 1.1 The README already states v1.4.4 is the supported DuckDB version, but adopters reading the codebase have repeatedly asked whether the v1.5.x line is supported and what to do about the reduced bundled spatial surface on v1.5.2. Add a small subsection (3.2.1) that: - States that v1.4.4 LTS is also the ecosystem alignment target for GeoArrow 1.1 / GeoParquet 1.1 (the full bundled spatial extension surface — ST_Intersects, ST_MakeEnvelope, ST_Point, ST_Within, ST_Contains — exposes the spec features). - Acknowledges that DuckDB v1.5.x's bundled spatial extension ships a reduced surface and points to duckdb/duckdb-spatial's in-progress v1.5-variegata port as the eventual restoration path. - Documents the scalar-AND-chain bbox-pruning recipe that works on DuckDB v1.5.x today without the spatial extension — same row-group pruning as the spatial-aware path, no per-row geometry construction. Pure docs change; CI is path-ignored for **/README.md and doc/** so no build runs on this PR.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The README already states that MobilityDuck is built with DuckDB v1.4.4 (long-term support). This adds a small subsection clarifying what that version target means for GeoArrow 1.1 / GeoParquet 1.1 consumers — a question that has come up repeatedly when adopters are weighing v1.4.4 vs v1.5.x.
What the new subsection 3.2.1 covers
The v1.4.4 LTS target is the ecosystem alignment target for GeoArrow 1.1 / GeoParquet 1.1. DuckDB v1.4.4's bundled
spatialextension exposes the full set of spatial functions (ST_Intersects,ST_MakeEnvelope,ST_Point,ST_Within,ST_Contains, …) needed to exploit GeoParquet'scovering.bboxand GeoArrow's native-coordinate encodings.DuckDB v1.5.x adopters get a reduced bundled spatial surface today. The v1.5.2 bundled spatial extension is missing the spatial functions above. The eventual restoration path is
duckdb/duckdb-spatial's in-progressv1.5-variegataport shipping into the bundled extension.Concrete fall-back recipe for v1.5.x today. The scalar-AND-chain on the
covering.bboxstruct fields prunes row-groups identically to the spatial-aware path, no spatial extension required:Why this is a docs-only PR
Pure README change (29 lines added, 0 removed, 0 existing lines touched). The repository's CI workflow declares
paths-ignore: ['**/README.md', 'doc/**']so no build runs on this PR — landing it has zero CI cost.Adjacent observation (not addressed in this PR)
While preparing this clarification I noticed that the
duckdb-spatialgit submodule HEAD onmaincurrently points to av1.5-variegata-era commit, which is a different series from the README's v1.4.4 target. If that's intentional (e.g. pre-staging the v1.5 migration), no action is needed. If it's drift, an explicit re-pin to a v1.4.x SHA matching CI would close the inconsistency. Flagging here rather than fixing because submodule SHA changes can interact with in-flight build work; happy to follow up in a separate PR if desired.