📄 drv_pg.html

📁 gdal库的学习文档
💻 HTML
字号:
<html><head><title>PostgreSQL</title></head><body bgcolor="#ffffff"><h1>PostgreSQL</h1>This driver implements support for access to spatial tables in PostgreSQL extended with the <a href="http://postgis.refractions.net/">PostGIS</a> spatial data support. Some support exists in the driver for use with PostgreSQL without PostGISbut this has not been recently tested and is likely decayed.<p>When opening a database, it's name should be specified in the form"PG:dbname=<databasename>".  We use PQconnectdb() to make the connection, so any other options and defaultsthat would apply to it, apply to the name here.  The PG: prefix is usedto mark the name as a postgres connection string.<p>If the <i>geometry_columns</i> table exists, then all listed tables andnamed views will be treated as OGR layers.  Otherwise all regular user tableswill be treated as layers.<p>Regular (non-spatial) tables can be accessed, and will return features withattributes, but not geometry.  If the table has a "wkb_geometry" field, it willbe treated as a spatial table.  The type of the field is inspected to determine how to read it.  It can be a PostGIS <b>geometry</b> field, whichis assumed to come back in OGC WKT, or type BYTEA or OID in which case itis used as a source of OGC WKB geometry.<p>If there is an "ogc_fid" field, it will be used to set the feature id ofthe features, and not treated as a regular field. <p>The layer name may be of the form "schema.table". The schema must exist, and the user needs to have write permissions for the target and the public schema.<p>The PostgreSQL driver passes SQL statements directly to PostgreSQL ratherthan evaluating them internally when using the ExecuteSQL() call on theOGRDataSource, or the -sql command option to ogr2ogr.  Attribute queryexpressions are also passed through to PostgreSQL.  The PostgreSQLdriver in OGR supports the OGRDataSource::StartTrasaction(), OGRDataSource::CommitTransaction() and OGRDataSource::RollbackTransaction()calls in the normal SQL sense.<p><h2>Caveats</h2><ul><li> The type recognition logic is currently somewhat impoverished.  The types "INT*" and "NUMERIC(width,0)" are mapped to integer, the types"FLOAT*" and "NUMERIC(width,precision>0)" are mapped to real, date, time, timestamp and datetime are handled as date types and all othertypes are just treated as strings. <p><li> A sequence object called <tablename>_ogc_fid_seq is created for newtables (layer)<p><li> Sequential reading is done within a single transaction.  Any attemptsto write to a layer within a sequential read will likely result in a "BEGIN"while already within a transaction type of error message.<p></ul><h2>Creation Issues</h2>The PostgreSQL driver does not support creation of new datasets (a databasewithin PostgreSQL), but it does allow creation of new layers within anexisting database.<P>As mentioned above the type system is impoverished, and many OGR typesare not appropriate mapped into PostgreSQL.<p>If the database has PostGIS types loaded (ie. the geometry type) newlycreated layers will be created with the PostGIS Geometry type.  Otherwisethey will use OID.  By default it is assumed that text being sent to Postgres is in the UTF-8encoding.  This is fine for plain ASCII, but can result in errors forextended characters (ASCII 155+ for instance).  Whle OGR provides no directcontrol over this, you can set the PGCLIENTENCODING environment variable to indicate the format being provided.  For instance, if you text is LATIN1 you could set the environment variable to LATIN1 before using OGRand input would be assumed to be LATIN1 instead of UTF-8. <p><h3>Dataset Creation Options</h3>None<p><h3>Layer Creation Options</h3><ul><li><b>GEOM_TYPE</b>: The GEOM_TYPE layer creation option can be set to one of "Geometry", "BYTEA" or "OID" to force the type of geometry used fora table. <p><li> <b>OVERWRITE</b>: This may be "YES" to force an existing layer of thedesired name to be destroyed before creating the requested layer.<p><li> <b>LAUNDER</b>: This may be "YES" to force new fields created on thislayer to have their field names "laundered" into a form more compatible withPostgreSQL.  This converts to lower case and converts some special characterslike "-" and "#" to "_".  If "NO" exact names are preserved.  The default value is "YES".  If enabled the table (layer) name will also be laundered.<p><li> <b>PRECISION</b>: This may be "YES" to force new fields created on thislayer to try and represent the width and precision information, if availableusing NUMERIC(width,precision) or CHAR(width) types.  If "NO" then the typesFLOAT8, INTEGER and VARCHAR will be used instead.  The default is "YES".<p><li> <b>DIM={2,3}</b>: Control the dimension of the layer.  Defaults to 3. Important to set to 2 for 2D layers with PostGIS 1.0+ as it has constraintson the geometry dimension during loading.<p><li> <b>GEOMETRY_NAME</b>: Set name of geometry column in new table.  If omitted it defaults to wkb_geometry.<p><li> <b>SCHEMA</b>: Set name of schema for new table.Using the same layer name in different schemas ist supported, but not in the public schema and others.<p></ul><h3>Environment variables</h3><ul><li><b>PG_USE_COPY</b>: This may be "YES" for using COPY for inserting data to Postgresql.COPY is less robust than INSERT, but signficantly faster.</li><p><li><b>PGSQL_OGR_FID</b>: Set name of primary key instead of 'ogc_fid'.</li><p></ul><h3>Example</h3>Simple translation of a shapefile into PostgreSQL.  The table 'abc' willbe created with the features from abc.shp and attributes from abc.dbf. The database instance (warmerda) must already exist, and the table abc mustnot already exist. <p><pre>% ogr2ogr -f PostgreSQL PG:dbname=warmerda abc.shp</pre><p>This second example loads a political boundaries layer from VPF (via the<a href="drv_ogdi.html">OGDI driver</a>), and renames the layer from thecryptic OGDI layer name to something more sensible.  If an existing tableof the desired name exists it is overwritten.<p><pre>% ogr2ogr -f PostgreSQL PG:dbname=warmerda \        gltp:/vrf/usr4/mpp1/v0eur/vmaplv0/eurnasia \        -lco OVERWRITE=yes -nln polbndl_bnd 'polbndl@bnd(*)_line'</pre><p>In this example we merge tiger line data from two different directories oftiger files into one table.  Note that the second invocation uses -appendand no OVERWRITE=yes. <p><pre>% ogr2ogr -f PostgreSQL PG:dbname=warmerda tiger_michigan \     -lco OVERWRITE=yes CompleteChain% ogr2ogr -update -append -f PostgreSQL PG:dbname=warmerda tiger_ohio \     CompleteChain</pre><p>This example shows using ogrinfo to evaluate an SQL query statement within PostgreSQL.  More sophisticated PostGIS specific queries may also beused via the -sql commandline switch to ogrinfo.<p><pre>ogrinfo -ro PG:dbname=warmerda -sql "SELECT pop_1994 from canada where province_name = 'Alberta'"</pre><p>This example shows using ogrinfo to list PostgreSQL/PostGIS layers on a different host.<p><pre>ogrinfo -ro PG:'host=myserver.velocet.ca user=postgres dbname=warmerda'</pre><h3>See Also</h3><ul><li> <a href="http://www.postgresql.org/">PostgreSQL Home Page</a><p><li> <a href="http://postgis.refractions.net/">PostGIS</a><p><li> <a href="http://postgis.refractions.net/support/wiki/index.php?OGR%20Examples">PostGIS / OGR Wiki Examples Page</a><p></ul></body></html>
⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -