Changes between Version 8 and Version 9 of FDORfc16

Timestamp:

Mar 21, 2008, 1:09:53 PM (16 years ago)

Author:

traianstanev

Comment:

--

FDORfc16

@@ -29 +29 @@
 A SQLite format for storing spatial data would make a good interchange format, similar to, but more flexible than Shapefiles.
 
-== Proposed Solution ==
+== What makes a valid spatial SQLite database? ==
+
+The goal of this provider is to allow access to SQLite databases in as open and standard way as possible.
+Here is the minimum set of characteristics the provider will expect in SQLite database:
+
+ * geometry_columns table, as per SF spec, Part 2, SQL Option, section 6.2.1;
+ * spatial_ref_sys table as per SF spec;
+ * g_geometry_format column in geometry_columns table. If not present, WKB will be assumed as geometry format
+
+
+== Proposed FDO Provider ==
 
 The proposed SQLite provider will have the following features:
 
  * Data stored and consumed in native SQLite format, and therefore accessible to other SQLite-based applications;
- * Geometry will be serialized as BLOBs in FDO geometry format (FGF), WKB , or WKT 1.2 format. The type of geometry encoding will be specified in the geometry_columns table (see below) in a column called g_geometry_format. In addition, the provider may support point geometry with coordinates stored in non-geometric columns, via a connection string setting.
+ * Geometry will be serialized as BLOBs in FDO geometry format (FGF), WKB , or WKT 1.2 format. The type of geometry encoding will be specified in the geometry_columns table (see below) in a column named g_geometry_format. In addition, the provider may support point geometry with coordinates stored in non-geometric columns, via a connection string setting.
  * A non-persistent, spatial index usable for BBOX queries built on the fly and valid for the duration of the FDO connection;
  * Execution of arbitrary SQL commands;