SDF faster than dbd: wow! I think the SDF very much solves the issue as Puneet put it, but I will add to the wish list a few things which may be optional but certainly usefull and valuable as time saver:
- optional space for metadata, - optional thumnails (in 2 sizes: thumb and browse) - optional embeded symbols (truetype/svg glyphs) and prefered layout - optional coloring and styles, break values, rendering and scale limits, persistent joins or relates, color ramp, ... - SRS is a must, complete projection parameters. - full set of attibute types (c, int2, int4, int8, float, double, txt (i18l), date and timestamps (with gmt precise offset), blobs, ... - Data range limits, enforced coherence, and presentation format/templates - indexing (unique and non-unique) on key attributes - could use integers or floats for coordinates - uuid (unique id, directory/name independent) I would just love to click open and see something nice, specially if someone has already taken the time to make it beautiful. Think of it as the output of a word processor instead of an editor. Excel vs. VisiCalc; and the list may go on forever. All this is to say: not only the data needs a better container, the maps as well. Manolo. > A little clarification on SDF, since it comes up once or twice in this > thread. Jason's earlier descriptions of it's capabilities are pretty good. > It supports multiple Feature Classes / Tables per file, strongly typed > properties, multiple geometry properties per class, with seperate R-Trees > for each geometry property. All of this is stored in a single file that is > heavily optimized for spatial reads. The SDF FDO Provider suppports a > multiple reader / single writer model. The geometries themselves include > simple features + circular arcs in 2D, 2D with Z, 2D with M, or 2D with Z > & > M. The R-Trees are currently 2D. > > Is it an open format? ABSOLUTELY (we just never wrote a spec, but I am > willing to get it done) > > Another little known fact is that in the process of creating SDF we > (Autodesk) literally wrote the code three times. The first time we built > SDF > on BerkleyDB, a great open source project but it has some fairly > significant > license fees for using it in a proprietary product. The second time we > wrote > it on SQLite, however the performance penalaty of the Relational layer was > significant (read orders of magnitude). The third time we chose to strip > away the SQLite relational layer and built directly on the SQLite Backend > components (B-Tree, Pager, and OS Interface). In the end the third > implementation actually turned out to be faster than BDB and is the one we > use today. > > All this said, I'd really like to understand everyones requirements for > this > new format. If SDF fits thats great, if not thats ok too. We are always > happy to contribute what we can to the community. > > Bob > _______________________________________________ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
