lib-spatialite is under the MPL tri-license, Spatialite itself is under GPLv3. Quite a bit of functionality is contained in Spatialite (the library) and would need reimplementation.
Google Groups has apparently eaten the thread, but here's Sandro's response to my query about using .loadshp outside of Spatialite: https://gist.github.com/79b3b89c8900df57f67d I don't think that killing SQL is a priority here. It certainly isn't something I consider to be a problem in everyday geo work. And if the killer feature of Spatialite is all the extra features and assumptions, that'll kill the file format. Baby steps are needed. On Mon, Apr 9, 2012 at 3:31 PM, Jaak Laineste <[email protected]> wrote: > > Andrew Turner wrote: > >> The best format I've seen anywhere that > >> every tool uses and is easy and powerful? CSV > > > > Did you mean CSV + WKT (to stick on the geospatial topic)? > > Actually I've used exactly this recently a lot. This is what QGIS gives > from copy-paste, very easy to read and write with one-code-liners. > > > Tom wrote: > >> SQLite by itself has a ton of potential... > >> Spatialite, while nice, is problematic to talking about SQLite because > its > >> GEOS dependency, restrictive licensing, and private development strategy > > > > GEOS dependency: I would ignore the fact that there are libraries > > involved. I'm concentrating on a single binary format just the sake of > > this use case. > > Spatialite means two things: specific postgis-inspired table structure in > sqlite file format and a SQL library with set of geofunctions to make > read/write easier. File format is SQLite3, so you can just read it without > GEOS or even without Spatialite. If you want to have BBOX-based quick > queries, then you need Spatialite and for more advanced functions like > buffers you need GEOS, and possibly also Proj4. So strictly there is no > GEOS dependency. > > Where are license restrictions here, SQLite is Public Domain; Spatialite > has tri-license system which is essentially also PD? Development strategy > is tricky question still, Spatialite is more or less one-man show with all > the risks involved. > > The only principal technical key restriction is that it is SQL-table > based, with all the inflexibility. However, also most of the legacy data is > in similar tables (Shapefiles, Geodatabases, PostGIS), but it is problem > for newer stuff like KML and OSM data. So, something as lite as Spatialite, > but with flexible collections instead of tables, and I would suggest UnQL > compatibility for it. > > But remember: the killer feature of Spatialite is that it is not just a > file standard, but it is bundled with essential compact and stand-alone > enough library to use it in very nice and easy way. Same for Shapefile - > ArcGIS and other apps have made it successful, not standardization or some > technical innovation. So you would need to have good plan for the whole > stack: file format, drivers, tools (cli, gui), ogr driver, qgis adapter etc. > > Jaak > _______________________________________________ > Geowanking mailing list > [email protected] > http://geowanking.org/mailman/listinfo/geowanking_geowanking.org >
_______________________________________________ Geowanking mailing list [email protected] http://geowanking.org/mailman/listinfo/geowanking_geowanking.org
