[OSGeo-Discuss] Re: idea for an OSGeo project -- a new, open data format

[mdragon at ciesas-golfo.edu.mx]

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
>