Relative paths behave differently with spatial extension than with others

jaanli commented 6 months ago

Example:

GDB data:

wget https://s-media.nyc.gov/agencies/dcp/assets/files/zip/data-tools/bytes/nyc_mappluto_24v1_fgdb.zip -O /tmp/nyc_mappluto_24v1_fgdb.zip
unzip -o /tmp/nyc_mappluto_24v1_fgdb.zip -d ~/data/nyc_mappluto_24v1_fgdb

DuckDB usage:

SELECT * FROM ST_READ('/Users/me/data/nyc_mappluto_24v1_fgdb/MapPLUTO24v1.gdb')

The above works, but with read_csv and others, relative paths are accepted. (Was getting uninformative errors when using SELECT * FROM ST_READ('~/data/nyc_mappluto_24v1_fgdb/MapPLUTO24v1.gdb') as I am more used to DuckDB vs spatial duckdb syntax)

Thank you for an awesome extension!! It's leading to this: https://jaanli.github.io/new-york-real-estate/

Maxxen commented 6 months ago

Hi! Thanks for reporting this issue. I can't reproduce this on macOS, are you sure the relative path is correct? What OS are you on?

jaanli commented 6 months ago

Weird!! Might be on my end then.

I'm on MacOS indeed, latest version.

I installed the latest duckdb via homebrew, and ran:

D INSTALL spatial;
D LOAD spatial;
D SELECT * FROM ST_READ('~/data/nyc_mappluto_24v1_fgdb/MapPLUTO24v1.gdb');
IO Error: GDAL Error (4): `~/data/nyc_mappluto_24v1_fgdb/MapPLUTO24v1.gdb' not recognized as a supported file format.
D SELECT * FROM ST_READ('/Users/me/data/nyc_mappluto_24v1_fgdb/MapPLUTO24v1.gdb')
  ;
100% ▕████████████████████████████████████████████████████████████▏
┌─────────┬───────┬───┬────────────┬─────────────────┬──────────────────────┐
│ Borough │ Block │ … │ Shape_Leng │   Shape_Area    │        Shape         │
│ varchar │ int32 │   │   double   │     double      │       geometry       │
├─────────┼───────┼───┼────────────┼─────────────────┼──────────────────────┤

duckdb / duckdb_spatial

Relative paths behave differently with spatial extension than with others #308