[fdo-internals] FDO RFC 16 - FDO Provider for SQLite
Jason.Birch at nanaimo.ca
Tue Mar 18 22:42:36 EDT 2008
> IOW, the native format is defined per a database instance.
No, per table. A single database can store multiple tables, each of which could (but probably shouldn't in most cases) have their own geometry type stored.
Actually, I would guess that a table could have multiple geometry columns, each of different type, as long as there were multiple rows in geometry_columns. But I don't think I'd want to encourage or advertise that :)
> I don't understand what does the "would have to support these formats" mean?
In order for this to be a truly portable solution (just send someone the .db file and they get spatial data), then each implementation (FDO, GDAL, GeoTools) would have to implement support for all geometry types. I want this to be a strong data access format, but also a powerful interchange format.
> There is possible situation in which B database is unusable with OGR
> driver, but the FDO Provider for SQLite can use both, and in A case can
> switch to WKB.
Or, better yet, OGR and FDO both support both data types, but with translation performance penalty for WKB under FDO.
> IOW, databases are not really portable.
I think that they can be, with proper implementation support in OGR and FDO and with use of the additional geometry type column in the geometry_columns table.
The use of custom functions in SQLite is certainly an option, but I'd really like to see the output-centric version of this "format" that Traian has outlined first. I'd prefer to see a persisted, native, spatial index in SQLite also, but that seems like a fairly large-scope item, and would probably require coordination with the SQLite project to implement.
More information about the fdo-internals