On Mon, Apr 09, 2012 at 06:41:51PM +0300, Jaak Laineste wrote: > > On 09.04.2012, at 18:22, Reed Underwood wrote: > > > I began tinkering recently with a non-relational self-contained binary > > format for feature data and indices. The toolkit includes Spidermonkey for > > querying and view generation using Javascript. It's written in C and uses > > tokyocabinet for storage and libgeos for topology/geometry. The idea was to > > build a manager on top of this for distributed, eventually-consistent > > geospatial data storage. > > > > I'd be very interested in talking about alternatives to shapefiles, > > including the very cursory work I did. The project, called "Grist" is on > > github: > > > > https://github.com/runderwood/grist > > This is interesting. Reminds me UnQLite [1] which seems to be the direction > to go. SQL-based things with fixed structures is so jurassic. But you need to > keep it very light and portable, using set of heavy dependencies can break > your neck easily. > > 1 - http://www.infoq.com/news/2011/08/UnQL > > Jaak
I've considered this, for sure. The only real dependency is TokyoCabinet, which is near ubiquitous in package repositories for major Linux distros. I'm not sure what Windows support looks like, though I think it's decent. LibGEOS worries me a little, but it too isn't really a requirement, as the geometries are stored as WKB. As for Spidermonkey, that's only in the toolkit as a querying/mapping tool. The format itself requires only TokyoCabinet, which, as a descendent of dbm, etc. seems reasonable. Shapefiles have survived while depending on dBaseIV, etc. Relying on a decent k/v store ought to be okay. Clearly, it doesn't have to be TokyoCabinet. I chose it, honestly, because it's absolutely beautiful (C) code. -R. _______________________________________________ Geowanking mailing list [email protected] http://geowanking.org/mailman/listinfo/geowanking_geowanking.org
