2012/4/9 Jaak Laineste <[email protected]>: >> 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.
Ok. Remains some issues like that it's not one file for many tables (and no CRS, no schema description with datatypes). Here, I wasn't aware that QGIS can read several Shapefiles out of a zip? >> 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. Agreed. > 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. No anymore AFAIK. Tom was referring to an earlier version. > 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. I don't see the requirement here to leave the relational table model. And I don't see the requirement of SQL neither since I focussing on a "desktop exchange" like (zipped :->) Shapefiles. > 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. That was argued too by Spatialite members recently. But again: To we should evaluate is just the file format, And of course that it's being supported by ArcGIS and OGR and FDO and whatever GIS tool :-> -S. _______________________________________________ Geowanking mailing list [email protected] http://geowanking.org/mailman/listinfo/geowanking_geowanking.org
