The directives listed below are processed by the SpatialWare reader. The suffixes listed are prefixed by the current <ReaderKeyword> in a mapping file. By default, the <ReaderKeyword> for the SpatialWare reader is SPATIALWARE.
DATASET
Required/Optional: Required
This clause identifies the ODBC Data source connected to the SpatialWare database from which features are retrieved.
|
Parameter |
Contents |
|
<dataset> |
The name of the ODBC data source from which the features are retrieved. In SpatialWare, this data set is referred to as the DATABASE or DATASOURCE. This is required no matter what the underlying RDBMS of SpatialWare. |
Example:
SPATIALWARE_DATASET georgetown
Workbench Parameter: Source MapInfo SpatialWare ODBC Data Source
DEF
Required/Optional
Optional
This clause identifies the queries used to retrieve features from the SpatialWare database.
The syntax of the first form is:
<ReaderKeyword>_DEF <tableName> \ [spatialware_def_where_clause <whereClause>]
The <tableName> must match a table in the database. This will be used as the feature type of all the features read from the table.
If no <whereClause> is specified, all rows in the table will be read and returned as individual features. If a <whereClause> is specified, only those rows that are selected by the clause will be read. The <whereClause> will be included in a constructed SQL statement and passed untouched to the database (and therefore may make use of any of SpatialWare’s SQL/Spatial predicates).
Note that the <whereClause> does not duplicate the word WHERE. Also note that if you already have a <whereClause> in the SQL statement specified at the DEF line against spatialware_def_sql_statement then you don’t have to specify the spatialware_def_where_clause. Doing so will result into an error due to duplicate where clauses.
All attributes from the table will be present on each returned feature.
Example 1:
The example below instructs FME to retrieve features from the database for the table ROADS, and for those rows in which the NUMLANES column has a value of 2 and the SURFACE column has a value of ‘GRAVEL’. Note the use of the continuation characters when building a long WHERE clause.
SPATIALWARE_DEF ROADS \ spatialware_def_where_clause numlanes = 2 and surface \
= GRAVEL
Note: Escaped quotes may be placed around column names that are reserved words. For example, /”FROM/”.
Example 2:
The WHERE clause below illustrates how to select all road features contained in a preset bounding box, defined by (x1, y1, x2, y2). The feature type will be set to ROADS.
SPATIALWARE_DEF ROADS \
spatialware_def_where_clause \
ST_Contains(HG_Box(10,20,60,70),sw_geometry)
The syntax of the second form of the DEF line is:
SPATIALWARE_DEF <tableName> \ [<spatialware_def_sql_statement>]
In this form, an arbitrary complete <sqlStatement>, such as a “SELECT” statement, will be executed. The statement is passed untouched to the database (and therefore may make use of any of SpatialWare’s SQL/Spatial predicates). The results of the statement will be returned, one row at a time, as features to FME. This form allows the results of complex joins to be returned to FME.
All features will be given the feature type <tableName>, even though they may not necessarily have come from that particular table. Indeed, with this form, the <tableName> need not exist as a separate table in the database.
All attributes resulting from the query will be present on each returned feature. When a join operation is being performed, FME features have all of the attributes from the various tables combined into each feature. If more than one table has a column with the same name, then the feature attributes for those columns will be qualified with the table name to ensure that each attribute is unique.
Example 3:
The <spatialware_def_sql_statement> below illustrates how to perform a join on 2 different tables named LAKE, and PRIVBLDG. The query requests the numbers of all lakes and private buildings that are within 150 units from each other. The feature type will be set to complex.
SPATIALWARE_DEF complex \ spatialware_def_sql_statement select a.sw_member, b.sw_member \ from lake a, privbldg b \ where st_overlaps(st_buffer(a.sw_geometry, 150.0, 10.0), \ b.sw_geometry)
DEF_OVERRIDE
Required/Optional: Optional
This clause is of the same form as the DEF clause exactly. It performs the same function as the DEF clause. The use of this clause is generally of little value to users directly except for within auto-generated mapping files.
If there is a DEF line in the mapping file with the same feature type, this clause will override the DEF line and persist. The matching DEF line will be ignored. If there is no DEF line in the mapping file with the same feature type, this clause will simply add another query from which features will be read.
Example:
SPATIALWARE_DEF_OVERRIDE ROADS \ SELECT owner FROM ROADS WHERE numlanes = 2
IDs
Required/Optional: Optional
This clause identifies the names of tables from which to read information.
|
Parameter |
Contents |
|
<table names> |
A list of the names of tables in a SpatialWare database. |
The way these table names are used depends on whether or not there are any DEF lines in the mapping file. Any DEF_OVERRIDE keywords do not count as DEF lines in this situation.
If there are any DEF lines, then only the lines whose feature types are listed on an IDs line are used. All other DEF lines or table names on the IDs line are ignored.
If there are no DEF lines in the mapping file, then all features are read from all table names listed on the IDs lines. The features are read exactly as if the query ‘SELECT * FROM <tablename>’ were used for each table name in the IDs list.
Example:
SPATIALWARE_IDs buildings roads rivers forest
SERVER_TYPE
Required/Optional: Optional
This clause identifies the type of database the SpatialWare server is operating on.
|
Parameter |
Contents |
|
<server type> |
The type of database the SpatialWare server is operating with. This value may contain sqlserver or informix. |
Example:
SPATIALWARE_SERVER_TYPE informix
or
SPATIALWARE_SERVER_TYPE sqlserver
Workbench Parameter: SpatialWare server type
USERID
Required/Optional: May be required
The user name required to access the SpatialWare database. Sine databases such as Informix may not require this.
|
Parameter |
Contents |
|
<userid> |
The ID of the user account given to access the SpatialWare data set. |
Example:
SPATIALWARE_USERID name
Workbench Parameter: User ID
PASSWORD
Required/Optional: May be required
The password associated with the specified user ID. It may not be required by databases such as Informix, but may be required by SQLServer.
|
Parameter |
Contents |
|
<password> |
The password of the user account given to access SpatialWare. |
Example:
SPATIALWARE_Password secretpassword
Workbench Parameter: Password
SEARCH_ENVELOPE
Using the minimum and maximum x and y parameters, define a bounding box that will be used to filter the input features. Only features that interact with the bounding box are returned.
If all four coordinates of the search envelope are specified as 0, the search envelope will be disabled.
Mapping File Syntax
<ReaderKeyword>_SEARCH_ENVELOPE <minX> <minY> <maxX> <maxY>
Note: If all four coordinates of the search envelope are specified as zero, the search envelope will be disabled.
Required/Optional
Optional
Workbench Parameter
Minimum X, Minimum Y, Maximum X, Maximum Y
SEARCH_ENVELOPE_COORDINATE_SYSTEM
This directive specifies the coordinate system of the search envelope if it is different than the coordinate system of the data.
The COORDINATE_SYSTEM directive, which specifies the coordinate system associated with the data to be read, must always be set if the SEARCH_ENVELOPE_COORDINATE_SYSTEM directive is set.
If this directive is set, the minimum and maximum points of the search envelope are reprojected from the SEARCH_ENVELOPE_COORDINATE_SYSTEM to the reader COORDINATE_SYSTEM prior to applying the envelope.
Required/Optional
Optional
Mapping File Syntax
<ReaderKeyword>_SEARCH_ENVELOPE_COORDINATE_SYSTEM <coordinate system>
Workbench Parameter
Search Envelope Coordinate System
RETRIEVE_ALL_SCHEMAS
This parameter is applicable only when generating a mapping file, generating a workspace, or when retrieving schemas in an FME Objects application.
When set to yes, schemas for all of the tables and feature classes in the database are returned.
When set to no (or missing), and if RETRIEVE_ALL_TABLE_NAMES is similarly set to no (or missing), only schemas requested by the IDs parameter are returned.
Required/Optional
Optional
Values
YES | NO (default)
NO: The reader will return the schemas for the feature types specified in the IDs. If no features are specified in IDs, then:
- for Enterprise Geodatabases, FME will not return any schema features;
- for Personal and File Geodatabases, FME returns the schema features for all the tables.
If this value is not specified, then it is assumed to be No.
YES: Indicates to the reader to return all the schemas of the tables in the database.
Mapping File Syntax
Not applicable.
FME Objects applications would include RETRIEVE_ALL_SCHEMAS followed by “YES” in the parameters array passed to IFMEUniversalReader::open().
Workbench Parameter
Not applicable
RETRIEVE_ALL_TABLE_NAMES
This parameter is only applicable when generating a mapping file, generating a workspace or when retrieving schemas in an FME Objects application.
When set to yes, and if RETRIEVE_ALL_SCHEMAS is set to no (or missing), names for all of the tables and feature classes in the database are returned. When set to no (or missing), and if RETRIEVE_ALL_SCHEMAS is similarly set to no (or missing), the schemas requested by the IDs directive are returned.
Note: If RETRIEVE_ALL_SCHEMAS is also set to Yes, then RETRIEVE_ALL_SCHEMAS takes precedence.
Required/Optional
Optional
Values
YES | NO (default)
Mapping File Syntax
Not applicable.
FME Objects applications would include RETRIEVE_ALL_TABLE_NAMES followed by “YES” in the parameters array passed to IFMEUniversalReader::open().
Workbench Parameter
Not applicable (used when you browse a Table List)