Interesting! Thanks for pointing me to that. Appreciate knowing the history. Your explanation for it becoming optional makes sense.
Partly I was just curious that the SQLite driver is not built in by default, since today GDAL build requires PROJ, PROJ requires libsqlite3, and so the dependency is always there since SQLite driver can be be built with or without libspatialite. (I'm not advocating necessarily that SQLite driver *should* be built in by default.) The practical motivation for asking is that SQLite driver supports multiple geometry columns on a layer which GPKG does not. It's simple to test for availability of SQLite and SpatiaLite before attempting to use them of course, but wondered if there's any general sense of potential for SQLite driver tending to be unavailable in some cases. It's not uncommon that SpatiaLite is unavailable to GDAL on some platforms I encounter, even though it seems mostly available in general. Chris On Sun, Mar 9, 2025 at 2:29 PM Rahkonen Jukka < jukka.rahko...@maanmittauslaitos.fi> wrote: > Hi, > > > > The SQLite driver has a long history, I guess it was originally made to > support FDO > https://web.archive.org/web/20240811210751/https://trac.osgeo.org/fdo/wiki/FDORfc16 > <https://web.archive.org/web/20240811210751/https:/trac.osgeo.org/fdo/wiki/FDORfc16> > . > > By that time there was no other use for SQLite so making it optional was > probably natural. > > > > -Jukka Rahkonen- > > > > *Lähettäjä:* Chris Toney <jcto...@gmail.com> > *Lähetetty:* sunnuntai 9. maaliskuuta 2025 21.37 > *Vastaanottaja:* Rahkonen Jukka <jukka.rahko...@maanmittauslaitos.fi> > *Kopio:* gdal dev <gdal-dev@lists.osgeo.org> > *Aihe:* Re: [gdal-dev] SQLite / Spatialite RDBMS > > > > Right, libsqlite3 is definitely ubiquitous, and I always want > libspatialite too. But that is different from whether the GDAL vector > driver "SQLite / Spatialite RDBMS" is compiled in, which it is not by > default. That would depend more on whether various package management > systems choose to enable it in their distributions, for example. Or if > there are reasons that custom builds would tend to exclude it sometimes. My > sense is that the driver is generally available even though it's optional > at build time. Just wondering if there are known exceptions to be aware of, > or if my assumptions above are wrong? Why is it an optionally compiled in > driver given ubiquity of SQLite? Just because GPKG mostly fulfills that > need and is standard? > > > > Chris > > > > On Sun, Mar 9, 2025 at 1:02 PM Rahkonen Jukka < > jukka.rahko...@maanmittauslaitos.fi> wrote: > > Hi, > > > > Proj requires SQLite anyway and you may want to do coordinate > transformations with GDAL. Without SpatiaLite you’ll miss only the > SpatiaLite SQL functions, and of course support for SpatiaLite databases. > > > > -Jukka Rahkonen- > > > > *Lähettäjä:* gdal-dev <gdal-dev-boun...@lists.osgeo.org> *Puolesta *Chris > Toney via gdal-dev > *Lähetetty:* sunnuntai 9. maaliskuuta 2025 20.31 > *Vastaanottaja:* gdal dev <gdal-dev@lists.osgeo.org> > *Aihe:* [gdal-dev] SQLite / Spatialite RDBMS > > > > Hi, > > The SQLite / Spatialite RDBMS driver says "SQLite is an optionally > compiled in driver. It is not compiled in by default." It seems fairly > ubiquitous though. Is that a safe assumption (more or less), or are there > important caveats to know about? I know that SQLite could be present > without SpatiaLite support, but I'm wondering about the SQLite driver for > "regular" SQLite databases, with or without SpatiaLite. > > > > Thanks! > > > > Chris Toney > > > >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
