INGRES

This driver implements read and write access for spatial data in INGRES database tables. This functionality was introduced in GDAL/OGR 1.6.0.

When opening a database, it's name should be specified in the form "@driver=ingres,[host=host, instance=instance],dbname=[vnode::]dbname [,options]". where the options can include comma seperated items like "host=*ip_address*","instance=*instance*", "username=*userid*", "password=*password*", "effuser=*database_user*", "dbpwd=*database_passwd*", "timeout=*timeout*", "tables=table1/table2". The driver and dbname values are required, while the rest are optional. If username and password are not provided an attempt is made to authenticate as the current OS user.

If the host and instance options are both specified, the username and password *must* be supplied as to componsit the dynamic vnode. The default protocal is Tcp/IP. If any other protocal is expected to be used, a pre-build vnode is preferable. If vnode and these two options are passed at the same time, an error will occur.

The option effuser and dbpwd are mapped to the real user name and password needs to be authorized in dbms, compared to the username and password which are used for OS level authorization.

Examples:

  @driver=ingres,host=192.168.0.1, instance=II, dbname=test,userid=warmerda,password=test,effuser=frank, dbpwd=123, tables=usa/canada
  
  @driver=ingres,host=192.168.0.1, instance=II, dbname=test,userid=warmerda,password=test,tables=usa/canada
  
  @driver=ingres,dbname=test,userid=warmerda,password=test,tables=usa/canada

  @driver=ingres,dbname=test,userid=warmerda,password=test,tables=usa/canada
  
  @driver=ingres,dbname=test,userid=warmerda,password=test,tables=usa/canada
  
  @driver=ingres,dbname=server::mapping
  
  @driver=ingres,dbname=mapping

If the tables list is not provided, an attempt is made to enumerate all non-system tables as layers, otherwise only the listed tables are represented as layers. This option is primarily useful when a database has a lot of tables, and scanning all their schemas would take a significant amount of time.

If an integer field exists in a table that is named "ogr_fid" it will be used as the FID, otherwise FIDs will be assigned sequentially. This can result in different FIDs being assigned to a given record/feature depending on the spatial and attribute query filters in effect at a given time.

By default, SQL statements are passed directly to the INGRES database engine. It's also possible to request the driver to handle SQL commands with OGR SQL engine, by passing "OGRSQL" string to the ExecuteSQL() method, as name of the SQL dialect.

Currently the INGRES driver supports only "old style" INGRES spatial data types such as POLYGON, POINT, LINE, LONG POLYGON, LONG LINE, etc. It is anticipated in the future a newer OGC compliant set of spatial types will also be supported.

Caveats

The spatial types CIRCLE and ICIRCLE are not currently supported for reading.
No fast spatial index is used when reading, so spatial filters are implemented by reading and parsing all records, and then discarding those that do not satisfy the spatial filter.
There is currently no support for coordinate systems.

Creation Issues

The INGRES driver does not support creation of new datasets (a database within INGRES), but it does allow creation of new layers (tables) within an existing database instance.

The INGRES driver makes no allowances for character encodings at this time.
The INGRES driver is not transactional at this time.
The spatial types BOX and IBOX are not supported for creating, and when read are represented as polygons.
The non-LONG types (such as LINE, ILINE, and POLYGON) only support a limited number of vertices. Attempts to create objects with more than the maximum possible vertices for these types will fail.
The old ingres spatial types are very particular about geometry validation, and attempts to insert (create) features with invalid geometries will fail. Reasons for invalidity include self-intersection of linestrings, and self-intersections for polygons.

Layer Creation Options

OVERWRITE: This may be "YES" to force an existing layer of the desired name to be destroyed before creating the requested layer.
LAUNDER: This may be "YES" to force new fields created on this layer to have their field names "laundered" into a form more compatible with MySQL. This converts to lower case and converts some special characters like "-" and "#" to "_". If "NO" exact names are preserved. The default value is "YES".
PRECISION: This may be "TRUE" to attempt to preserve field widths and precisions for the creation and reading of MySQL layers. The default value is "TRUE".
GEOMETRY_NAME: This option specifies the name of the geometry column. The default value is "SHAPE".
INGRES_FID: This option specifies the name of the FID column. The default value is "OGR_FID"
GEOMETRY_TYPE: Specifies the object type for the geometry column. It may be one of POINT, LSEG, LINE, LONG LINE, POLYGON, or LONG POLYGON. By default POINT, LONG LINE or LONG POLYGON are used depending on the layer type.