Changes between Version 24 and Version 25 of FDORfc16
- Timestamp:
- 04/20/08 21:44:29 (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TabularUnified FDORfc16
v24 v25 19 19 ||-0|||| 20 20 ||-1|||| 21 22 == Updates == 23 24 * April 20, 2008 (jbirch) - Modified to explicitly specify the contents of the spatial_ref_sys table. Changed VARCHAR references to TEXT because VARCHAR is only a [http://www.sqlite.org/datatype3.html valid SQLite type] through inference. 21 25 22 26 == Overview == … … 36 40 37 41 * well-defined subset of the geometry_columns table (as per SF spec, section 7.1.3.2, 7.1.3.3); see below for specific column requirements, 38 * spatial_ref_sys table (as per SF spec, section 7.1.2.2, 7.1.2.3). Valid WKT spatial reference systems mustbe defined for each unique coordinate system used in the database.42 * spatial_ref_sys table (as per SF spec, section 7.1.2.2, 7.1.2.3). The unique SRID and valid WKT spatial reference text MUST be defined for each unique coordinate system used in the database. 39 43 * geometry_format column extending the geometry_columns table, set to one of WKB, WKT, WKB12, WKT12 or FGF. If not present, WKB will be assumed. 40 44 * one or more tables to store the geometry and associated features. Although in general [http://www.sqlite.org/datatype3.html type does not matter in SQLite], BLOB type is recommended at least for WKB and FGF formats as it does not perform character translation on the data. … … 47 51 48 52 || Column Name || Type || Notes || 49 || f_table_name || VARCHAR|| name of a feature table with a geometry column. ||50 || f_geometry_column || VARCHAR|| name of a geometry column in the feature table ||53 || f_table_name || TEXT || name of a feature table with a geometry column. || 54 || f_geometry_column || TEXT || name of a geometry column in the feature table || 51 55 || geometry_type || INTEGER || integer value representing the form of geometry (1=POINT, 2=LINESTRING, etc). See Table 4 on Page 29-31 of the SFSQL [http://www.opengeospatial.org/standards/sfs 06-104r3] spec for a full list. || 52 56 || coord_dimension || INTEGER || dimensionality of the geometric features: 2, 3 or 4 || 53 57 || srid || INTEGER || foreign key into the spatial_ref_sys table || 54 || geometry_format || VARCHAR|| One of "WKB", "WKT", "WKB12", "WKT12", "FGF" ||58 || geometry_format || TEXT || One of "WKB", "WKT", "WKB12", "WKT12", "FGF" || 55 59 56 60 The suggested definition is: … … 58 62 {{{ 59 63 CREATE TABLE geometry_columns ( 60 f_table_name VARCHAR,61 f_geometry_column VARCHAR,64 f_table_name TEXT, 65 f_geometry_column TEXT, 62 66 geometry_type INTEGER, 63 67 coord_dimension INTEGER, 64 68 srid INTEGER, 65 geometry_format VARCHAR ) 69 geometry_format TEXT ) 70 }}} 71 72 == spatial_ref_sys == 73 74 SQLite databases require the following fields in their spatial_ref_sys table. The SRID and SRTEXT columns must be populated with a unique identifier and a valid WKT spatial reference string respectively. AUTH_NAME and AUTH_SRID may be populated where known, but are not critical to functionality and may be left null when unknown. 75 76 || Column Name || Type || Notes || 77 || srid || INTEGER || an integer value that uniquely identifies each Spatial Reference System within a database || 78 || auth_name || TEXT || the name of the standard or standards body that is being cited for this reference system. EPSG would be an example of a valid AUTH_NAME. If unknown, leave as null. || 79 || auth_srid || INTEGER || the ID of the Spatial Reference System as defined by the Authority cited in AUTH_NAME. {http://spatialreference.org/ref/epsg/26910 26910] would be an example of a valid EPSG srid (UTM Zone 10 NAD830). If unknown, leave as null. || 80 || srtext || TEXT || The Well-known Text Representation of the Spatial Reference System || 81 82 The suggested definition is: 83 84 {{{ 85 CREATE TABLE spatial_ref_sys ( 86 srid INTEGER UNIQUE, 87 auth_name TEXT, 88 auth_srid INTEGER, 89 srtext TEXT ) 66 90 }}} 67 91
