[fdo-internals] FDO RFC 16 - FDO Provider for SQLite

[Jason Birch]

Mateusz wrote:
 
> 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.

Jason