2012/4/9 Frank Warmerdam <[email protected]>: > 2012/4/9 Stefan Keller <[email protected]>: >> Private development: That's the current show stopper. That's why I >> proposed it to become an OSGEO project. That's also where the "SQLite >> Provider" comes in but which I found only used (half-hartedly?) in >> FDO. > > Folks, > > For what it's worth at one point the FDO guys, and EvenR and I > on behalf of GDAL/OGR tried to nail down details of how to use > Sqlite as a geodatabase and we hoped in way that was interoperable > with SpatialLite. I'm not exactly clear on the state of things now. > I know that the OGR Sqlite driver will now try and use spatialite > functions including the spatial index if available. I'm not sure if > it still works properly against spatialite databases without actually > having spatiallite linked in. > > My *ambition* was a well specified schema in Sqlite so that > apps could depend on it for interoperability with or without having > spatiallite available. However the spatialite project didn't seem to > want to get tied down to something stable and I lost interest. > > I still like the idea of sqlite as a geodatabase but I haven't the > fortitude to advocate strongly for how I think it ought to work. > > Best regards,
There was some communication outside geowanking so I'm citing partially to summarize: 2012/4/9 Even Rouault <[email protected]> answered: > The state of the OGR Spatialite support is quite good, especially since OGR > 1.9.0. I think Frank's concern is probably the fact that the Spatialite > project is a bit a one-man-show, where the community is more a community of > passive users without much to say in the evolution of the project. Although I > think it has improved a bit, and has attracted at least another active > contributor recently. But I remember a post of Sandro Furieri where he wasn't > very interested into making it a OSGeo project. > > Performance wise, I find it to be one of the best solutions when doing spatial > requests on datasets not requiring something big like the PostgreSQL/PostGIS > pair. And then: > I've never played with the FDO spatial extension, so I cannot comment on that > side. FDO is such a pain to build that I've never managed to do it... > > The key is to have an efficient spatial index. Spatialite does that by using > the > R-Tree capabilities of "recent" Sqlite versions, and by using triggers that > update it consistently. > > As far as the spatialite geometry blob format is concerned, it is documented, > ... So to conclude so far I can state the following about the initial question: * To me, the SQlite 3 format has potential to become the "Shapefile of the future" covering the Shapefiles's use case which I call a "single binary desktop exchange format for geospatial data". * There are two alternatives as spatial extensions, Spatialite and SQlite FDO. * Obviously, there has never been made a comparison between both and it seems that both communities don't know each other. To me, Spatialite obviously is more promising because it simply has more coverage and support. The concerns about the support in OGR and being a one-man show seem to be sorted out. Still, some issues remain to me, namely: 1. There's a recurring argument that Spatialite has it's "built'in" GIS functionality. As a matter of fact, some Spatialite proponents insist that this is the foremost argument. But what's this about here is just a "desktop exchange format" for Simple Features vector data. 2. So far I have'nt heard anything from FDO community. At least OSGeo and Autodesk should have an interest. I'd like to give them another chance in order to get them in the boat. Yours, S. _______________________________________________ Geowanking mailing list [email protected] http://geowanking.org/mailman/listinfo/geowanking_geowanking.org
