Summary
GeoLibre reads Parquet/GeoParquet client-side with @duckdb/duckdb-wasm (currently pinned 1.33.1-dev45.0). On that build, read_parquet throws Invalid Error: stoi: no conversion while parsing GeoParquet metadata. The same files load fine in the DuckDB CLI, so this is a WASM-specific regression tracked upstream at duckdb/duckdb-wasm#2199.
Where it bites in GeoLibre
- Drag-and-drop / Add Data of a
.parquet/.geoparquet file (both web and desktop, since desktop also parses in the webview via DuckDB-WASM).
- SQL workspace remote reads, e.g.
read_parquet('https://…').
Local finding beyond the upstream report
Upstream #2199 states extension load order is "not a factor." In our case it clearly is for the local registered-buffer path: a connection that runs LOAD spatial before its first read_parquet triggers the crash on DESCRIBE/SELECT. Reading the file once before LOAD spatial primes the connection and avoids it.
Current workarounds in the code (what this issue tracks)
apps/geolibre-desktop/src/lib/duckdb-vector-loader.ts
parquetWarmUp() (~L238) — pre-LOAD read SELECT 1 FROM read_parquet(...) LIMIT 0.ensureSpatialExtension() (~L92) runs the warm-up before LOAD spatial.createDatabase() (~L160) calls db.open({}) so remote HTTP reads don't stoi-crash.
apps/geolibre-desktop/src/lib/sql-workspace.ts — pre-spatial remote read_parquet warm-up + HTTPS-arg rewriting (~L124–L140, L739).
These are best-effort hacks. The warm-up can still fail for genuinely large or remote files, and it adds an extra read per first-load.
Ask
Tracking issue so we can remove the warm-up hacks and the db.open({}) shim once upstream duckdb-wasm#2199 is fixed and we bump the pin. Related: the native-desktop proposal would sidestep this entirely on desktop.
Summary
GeoLibre reads Parquet/GeoParquet client-side with
@duckdb/duckdb-wasm(currently pinned1.33.1-dev45.0). On that build,read_parquetthrowsInvalid Error: stoi: no conversionwhile parsing GeoParquet metadata. The same files load fine in the DuckDB CLI, so this is a WASM-specific regression tracked upstream at duckdb/duckdb-wasm#2199.Where it bites in GeoLibre
.parquet/.geoparquetfile (both web and desktop, since desktop also parses in the webview via DuckDB-WASM).read_parquet('https://…').Local finding beyond the upstream report
Upstream #2199 states extension load order is "not a factor." In our case it clearly is for the local registered-buffer path: a connection that runs
LOAD spatialbefore its firstread_parquettriggers the crash onDESCRIBE/SELECT. Reading the file once beforeLOAD spatialprimes the connection and avoids it.Current workarounds in the code (what this issue tracks)
apps/geolibre-desktop/src/lib/duckdb-vector-loader.tsparquetWarmUp()(~L238) — pre-LOADreadSELECT 1 FROM read_parquet(...) LIMIT 0.ensureSpatialExtension()(~L92) runs the warm-up beforeLOAD spatial.createDatabase()(~L160) callsdb.open({})so remote HTTP reads don'tstoi-crash.apps/geolibre-desktop/src/lib/sql-workspace.ts— pre-spatial remoteread_parquetwarm-up + HTTPS-arg rewriting (~L124–L140, L739).These are best-effort hacks. The warm-up can still fail for genuinely large or remote files, and it adds an extra read per first-load.
Ask
Tracking issue so we can remove the warm-up hacks and the
db.open({})shim once upstream duckdb-wasm#2199 is fixed and we bump the pin. Related: the native-desktop proposal would sidestep this entirely on desktop.