Chapter 2. Installation

Table of Contents

2.1. Short Version
2.2. Requirements
2.3. Getting the Source
2.4. Installation
2.4.1. Configuration
2.4.2. Building
2.4.3. Building PostGIS Extensions and Deploying them
2.4.4. Testing
2.4.5. Installation
2.5. Create a spatially-enabled database on PostgreSQL lower than 9.1
2.6. Creating a spatial database using EXTENSIONS
2.7. Installing, Upgrading Tiger Geocoder and loading data
2.7.1. Tiger Geocoder Enabling your PostGIS database
2.7.2. Upgrading your Tiger Geocoder Install
2.7.3. Loading Tiger Data
2.8. Create a spatially-enabled database from a template
2.9. Upgrading
2.9.1. Soft upgrade
2.9.2. Hard upgrade
2.10. Common Problems
2.11. JDBC
2.12. Loader/Dumper

This chapter details the steps required to install PostGIS.

2.1. Short Version

[Note]

The raster support is currently optional, but installed by default. For installing using the PostgreSQL 9.1+ extensions model it is required. Please refer to Section 2.4.3, “Building PostGIS Extensions and Deploying them” if you are using PostgreSQL 9.1+.

All the .sql files once installed will be installed in share/contrib/postgis-2.0 folder of your PostgreSQL install

The postgis_comments.sql, raster_comments.sql, topology_comments.sql generate quick help tips for each function that can be accessed via pgAdmin III or psql. In psql with a command of the form e.g.\dd ST_SetPoint

tar xvfz postgis-2.0.6SVN.tar.gz
cd postgis-2.0.6SVN
./configure --with-raster --with-topology --with-gui
make
make install
createdb yourdatabase
createlang plpgsql yourdatabase
psql -d yourdatabase -f postgis.sql
psql -d yourdatabase -f postgis_comments.sql
psql -d yourdatabase -f spatial_ref_sys.sql
psql -d yourdatabase -f rtpostgis.sql
psql -d yourdatabase -f raster_comments.sql
psql -d yourdatabase -f topology.sql
psql -d yourdatabase -f topology_comments.sql

[Note]

topology_comments.sql since its an optional feature is not installed by make install or make comments install. However if you do a make comments or make topology_comments.sql, it will be generated in the docs folder

The rest of this chapter goes into detail each of the above installation steps.

2.2. Requirements

PostGIS has the following requirements for building and usage:

Required

  • PostgreSQL 8.4 - 9.2 minor. A complete installation of PostgreSQL (including server headers) is required. PostgreSQL is available from http://www.postgresql.org .

    For a full PostgreSQL / PostGIS support matrix and PostGIS/GEOS support matrix refer to http://trac.osgeo.org/postgis/wiki/UsersWikiPostgreSQLPostGIS

  • GNU C compiler (gcc). Some other ANSI C compilers can be used to compile PostGIS, but we find far fewer problems when compiling with gcc.

  • GNU Make (gmake or make). For many systems, GNU make is the default version of make. Check the version by invoking make -v. Other versions of make may not process the PostGIS Makefile properly.

  • Proj4 reprojection library, version 4.6.0 or greater. The Proj4 library is used to provide coordinate reprojection support within PostGIS. Proj4 is available for download from http://trac.osgeo.org/proj/ .

  • GEOS geometry library, version 3.2.2 or greater, but GEOS 3.3.2+ is recommended. Without GEOS 3.3, you will be missing some major enhancements with handling of topological exceptions and improvements to geometry validation and making geometries valid such as ST_ValidDetail and ST_MakeValid. GEOS 3.3.2+ is also required for topology support. GEOS is available for download from http://trac.osgeo.org/geos/ and 3.3+ is backward-compatible with older versions so fairly safe to upgrade.

  • LibXML2, version 2.5.x or higher. LibXML2 is currently used in some imports functions (ST_GeomFromGML and ST_GeomFromKML). LibXML2 is available for download from http://xmlsoft.org/downloads.html.

  • JSON-C, version 0.9 or higher. JSON-C is currently used to import GeoJSON via the function ST_GeomFromGeoJson. JSON-C is available for download from http://oss.metaparadigm.com/json-c/.

  • GDAL, version 1.6 or higher (1.9 or higher is preferable since some things will not work well with lower versions). This is required for raster support and to be able to install with CREATE EXTENSION postgis so highly recommended for those running 9.1+ even if you don't need raster. http://trac.osgeo.org/gdal/wiki/DownloadSource.

Optional

  • GDAL (pseudo optional) only if you don't want raster and don't care about installing with CREATE EXTENSION postgis can you leave it out. Keep in mind other extensions may have a requires postgis extension which will prevent you from installing them unless you install postgis as an extension. So it is highly recommended you compile with GDAL support.

  • GTK (requires GTK+2.0 (2.8+)) to compile the shp2pgsql-gui shape file loader. http://www.gtk.org/ .

  • CUnit (CUnit). This is needed for regression testing. http://cunit.sourceforge.net/

  • Apache Ant (ant) is required for building any of the drivers under the java directory. Ant is available from http://ant.apache.org .

  • DocBook (xsltproc) is required for building the documentation. Docbook is available from http://www.docbook.org/ .

  • DBLatex (dblatex) is required for building the documentation in PDF format. DBLatex is available from http://dblatex.sourceforge.net/ .

  • ImageMagick (convert) is required to generate the images used in the documentation. ImageMagick is available from http://www.imagemagick.org/ .

2.3. Getting the Source

Retrieve the PostGIS source archive from the downloads website http://postgis.net/stuff/postgis-2.0.6SVN.tar.gz

wget http://postgis.net/stuff/postgis-2.0.6SVN.tar.gz
tar -xvzf postgis-2.0.6SVN.tar.gz

This will create a directory called postgis-2.0.6SVN in the current working directory.

Alternatively, checkout the source from the svn repository http://svn.osgeo.org/postgis/branches/2.0 .

svn checkout http://svn.osgeo.org/postgis/branches/2.0/ postgis-2.0.6SVN

Change into the newly created postgis-2.0.6SVN directory to continue the installation.

2.4. Installation

[Note]

Many OS systems now include pre-built packages for PostgreSQL/PostGIS. In many cases compilation is only necessary if you want the most bleeding edge versions or you are a package maintainer.

This section includes general compilation instructions, if you are compiling for Windows etc or another OS, you may find additional more detailed help at PostGIS User contributed compile/install guides and PostGIS Dev Wiki.

Pre-Built Packages for various OS are listed in PostGIS Pre-built Packages.

If you are a windows user, you can get stable builds via Stackbuilder or PostGIS Windows download site We also have very bleeding-edge windows experimental builds that are built usually once or twice a week or whenever anything exciting happens. You can use these to experiment with the in progress releases of PostGIS

The PostGIS module is an extension to the PostgreSQL backend server. As such, PostGIS 2.0.6SVN requires full PostgreSQL server headers access in order to compile. It can be built against PostgreSQL versions 8.4 or higher. Earlier versions of PostgreSQL are not supported.

Refer to the PostgreSQL installation guides if you haven't already installed PostgreSQL. http://www.postgresql.org .

[Note]

For GEOS functionality, when you install PostgresSQL you may need to explicitly link PostgreSQL against the standard C++ library:

LDFLAGS=-lstdc++ ./configure [YOUR OPTIONS HERE]

This is a workaround for bogus C++ exceptions interaction with older development tools. If you experience weird problems (backend unexpectedly closed or similar things) try this trick. This will require recompiling your PostgreSQL from scratch, of course.

The following steps outline the configuration and compilation of the PostGIS source. They are written for Linux users and will not work on Windows or Mac.

2.4.1. Configuration

As with most linux installations, the first step is to generate the Makefile that will be used to build the source code. This is done by running the shell script

./configure

With no additional parameters, this command will attempt to automatically locate the required components and libraries needed to build the PostGIS source code on your system. Although this is the most common usage of ./configure, the script accepts several parameters for those who have the required libraries and programs in non-standard locations.

The following list shows only the most commonly used parameters. For a complete list, use the --help or --help=short parameters.

--prefix=PREFIX

This is the location the PostGIS libraries and SQL scripts will be installed to. By default, this location is the same as the detected PostgreSQL installation.

[Caution]

This parameter is currently broken, as the package will only install into the PostgreSQL installation directory. Visit http://trac.osgeo.org/postgis/ticket/635 to track this bug.

--with-pgconfig=FILE

PostgreSQL provides a utility called pg_config to enable extensions like PostGIS to locate the PostgreSQL installation directory. Use this parameter (--with-pgconfig=/path/to/pg_config) to manually specify a particular PostgreSQL installation that PostGIS will build against.

--with-gdalconfig=FILE

GDAL, a required library, provides functionality needed for raster support gdal-config to enable software installations to locate the GDAL installation directory. Use this parameter (--with-gdalconfig=/path/to/gdal-config) to manually specify a particular GDAL installation that PostGIS will build against.

--with-geosconfig=FILE

GEOS, a required geometry library, provides a utility called geos-config to enable software installations to locate the GEOS installation directory. Use this parameter (--with-geosconfig=/path/to/geos-config) to manually specify a particular GEOS installation that PostGIS will build against.

--with-xml2config=FILE

LibXML is the library required for doing GeomFromKML/GML processes. It normally is found if you have libxml installed, but if not or you want a specific version used, you'll need to point PostGIS at a specific xml2-config confi file to enable software installations to locate the LibXML installation directory. Use this parameter (>--with-xml2config=/path/to/xml2-config) to manually specify a particular LibXML installation that PostGIS will build against.

--with-projdir=DIR

Proj4 is a reprojection library required by PostGIS. Use this parameter (--with-projdir=/path/to/projdir) to manually specify a particular Proj4 installation directory that PostGIS will build against.

--with-libiconv=DIR

Directory where iconv is installed.

--with-jsondir=DIR

JSON-C is an MIT-licensed JSON library required by PostGIS ST_GeomFromJSON support. Use this parameter (--with-jsondir=/path/to/jsondir) to manually specify a particular JSON-C installation directory that PostGIS will build against.

--with-gui

Compile the data import GUI (requires GTK+2.0). This will create shp2pgsql-gui graphical interface to shp2pgsql.

--with-raster

Compile with raster support. This will build rtpostgis-2.0.6SVN library and rtpostgis.sql file. This may not be required in final release as plan is to build in raster support by default.

--with-topology

Compile with topology support. This will build the topology.sql file. There is no corresponding library as all logic needed for topology is in postgis-2.0.6SVN library.

--with-gettext=no

By default PostGIS will try to detect gettext support and compile with it, however if you run into incompatibility issues that cause breakage of loader, you can disable it entirely with this command. Refer to ticket http://trac.osgeo.org/postgis/ticket/748 for an example issue solved by configuring with this. NOTE: that you aren't missing much by turning this off. This is used for international help/label support for the GUI loader which is not yet documented and still experimental.

[Note]

If you obtained PostGIS from the SVN repository , the first step is really to run the script

./autogen.sh

This script will generate the configure script that in turn is used to customize the installation of PostGIS.

If you instead obtained PostGIS as a tarball, running ./autogen.sh is not necessary as configure has already been generated.

2.4.2. Building

Once the Makefile has been generated, building PostGIS is as simple as running

make

The last line of the output should be "PostGIS was built successfully. Ready to install."

As of PostGIS v1.4.0, all the functions have comments generated from the documentation. If you wish to install these comments into your spatial databases later, run the command which requires docbook. The postgis_comments.sql and other package comments files raster_comments.sql, topology_comments.sql are also packaged in the tar.gz distribution in the doc folder so no need to make comments if installing from the tar ball.

make comments

Introduced in PostGIS 2.0. This generates html cheat sheets suitable for quick reference or for student handouts. This requires xsltproc to build and will generate 4 files in doc folder topology_cheatsheet.html, tiger_geocoder_cheatsheet.html, raster_cheatsheet.html, postgis_cheatsheet.html

You can download some pre-built ones available in html and pdf from PostGIS / PostgreSQL Study Guides

make cheatsheets

2.4.3. Building PostGIS Extensions and Deploying them

The PostGIS extensions are built and installed automatically if you are using PostgreSQL 9.1+.

If you are building from source repository, you need to build the function descriptions first. These get built if you have docbook installed. You can also manually build with the statement:

make comments

Building the comments is not necessary if you are building from a release tar ball since these are packaged pre-built with the tar ball already.

If you are building against PostgreSQL 9.1, the extensions should automatically build as part of the make install process. You can if needed build from the extensions folders or copy files if you need them on a different server.

cd extensions
cd postgis
make clean
make 
make install
cd ..
cd postgis_topology
make clean
make 
make install
	  

The extension files will always be the same for the same version of PostGIS regardless of OS, so it is fine to copy over the extension files from one OS to another as long as you have the PostGIS binaries already installed on your servers.

If you want to install the extensions manually on a separate server different from your development, You need to copy the following files from the extensions folder into the PostgreSQL / share / extension folder of your PostgreSQL install as well as the needed binaries for regular PostGIS if you don't have them already on the server.

  • These are the control files that denote information such as the version of the extension to install if not specified. postgis.control, postgis_topology.control.

  • All the files in the /sql folder of each extension. Note that these need to be copied to the root of the PostgreSQL share/extension folder extensions/postgis/sql/*.sql, extensions/postgis_topology/sql/*.sql

Once you do that, you should see postgis, postgis_topology as available extensions in PgAdmin -> extensions.

If you are using psql, you can verify that the extensions are installed by running this query:

SELECT name, default_version,installed_version 
FROM pg_available_extensions WHERE name LIKE 'postgis%' ;
      name       | default_version | installed_version
-----------------+-----------------+-------------------
postgis          | 2.0.6SVN     | 2.0.6SVN
postgis_topology | 2.0.6SVN      | 

If you have the extension installed in the database you are querying, you'll see mention in the installed_version column. If you get no records back, it means you don't have postgis extensions installed on the server at all. PgAdmin III 1.14+ will also provide this information in the extensions section of the database browser tree and will even allow upgrade or uninstall by right-clicking.

If you have the extensions available, you can install postgis extension in your database of choice by either using pgAdmin extension interface or running these sql commands:

CREATE EXTENSION postgis;
CREATE EXTENSION postgis_topology;
[Warning]

Extension tables spatial_ref_sys, layer, topology can not be explicitly backed up. They can only be backed up when the respective postgis or postgis_topology extension is backed up, which only seems to happen when you backup the whole database. As of PostGIS 2.0.1, only srid records not packaged with PostGIS are backed up when the database is backed up so don't go around changing srids we package and expect your changes to be there. Put in a ticket if you find an issue. The structures of extension tables are never backed up since they are created with CREATE EXTENSION and assumed to be the same for a given version of an extension. These behaviors are built into the current PostgreSQL extension model, so nothing we can do about it.

If you installed 2.0.6SVN, without using our wonderful extension system, you can change it to be extension based by first upgrading to the latest micro version running the upgrade scripts: postgis_upgrade_20_minor.sql,raster_upgrade_20_minor.sql,topology_upgrade_20_minor.sql.

If you installed postgis without raster support, you'll need to install raster support first (using the full rtpostgis.sql

Then you can run teh below commands to package the functions in their respective extension.

CREATE EXTENSION postgis FROM unpackaged;
CREATE EXTENSION postgis_topology FROM unpackaged;

2.4.4. Testing

If you wish to test the PostGIS build, run

make check

The above command will run through various checks and regression tests using the generated library against an actual PostgreSQL database.

[Note]

If you configured PostGIS using non-standard PostgreSQL, GEOS, or Proj4 locations, you may need to add their library locations to the LD_LIBRARY_PATH environment variable.

[Caution]

Currently, the make check relies on the PATH and PGPORT environment variables when performing the checks - it does not use the PostgreSQL version that may have been specified using the configuration parameter --with-pgconfig. So make sure to modify your PATH to match the detected PostgreSQL installation during configuration or be prepared to deal with the impending headaches.

If successful, the output of the test should be similar to the following:

     CUnit - A Unit testing framework for C - Version 2.1-0
	 http://cunit.sourceforge.net/


Suite: print_suite
  Test: test_lwprint_default_format ... passed
  Test: test_lwprint_format_orders ... passed
  Test: test_lwprint_optional_format ... passed
  Test: test_lwprint_oddball_formats ... passed
  Test: test_lwprint_bad_formats ... passed
Suite: Misc Suite
  Test: test_misc_force_2d ... passed
  Test: test_misc_simplify ... passed
  Test: test_misc_count_vertices ... passed
  Test: test_misc_area ... passed
  Test: test_misc_wkb ... passed
Suite: PointArray Suite
  Test: test_ptarray_append_point ... passed
  Test: test_ptarray_append_ptarray ... passed
Suite: PostGIS Computational Geometry Suite
  Test: test_lw_segment_side ... passed
  Test: test_lw_segment_intersects ... passed
  Test: test_lwline_crossing_short_lines ... passed
  Test: test_lwline_crossing_long_lines ... passed
  Test: test_lwline_crossing_bugs ... passed
  Test: test_lwpoint_set_ordinate ... passed
  Test: test_lwpoint_get_ordinate ... passed
  Test: test_point_interpolate ... passed
  Test: test_lwline_clip ... passed
  Test: test_lwline_clip_big ... passed
  Test: test_lwmline_clip ... passed
  Test: test_geohash_point ... passed
  Test: test_geohash_precision ... passed
  Test: test_geohash ... passed
  Test: test_isclosed ... passed
Suite: PostGIS Measures Suite
  Test: test_mindistance2d_tolerance ... passed
  Test: test_rect_tree_contains_point ... passed
  Test: test_rect_tree_intersects_tree ... passed
  Test: test_lwgeom_segmentize2d ... passed
Suite: WKT Out Suite
  Test: test_wkt_out_point ... passed
  Test: test_wkt_out_linestring ... passed
  Test: test_wkt_out_polygon ... passed
  Test: test_wkt_out_multipoint ... passed
  Test: test_wkt_out_multilinestring ... passed
:
:
--Run Summary: Type      Total     Ran  Passed  Failed
               suites       17      17     n/a       0
               tests       143     143     143       0
               asserts    1228    1228    1228       0


Creating spatial db postgis_reg
 Postgis 2.0.0SVN - 2011-01-11 15:33:37
   GEOS: 3.3.0-CAPI-1.7.0
   PROJ: Rel. 4.6.1, 21 August 2008

Running tests

 loader/Point.............. ok
 loader/PointM.............. ok
 loader/PointZ.............. ok
 loader/MultiPoint.............. ok
 loader/MultiPointM.............. ok
 loader/MultiPointZ.............. ok
 loader/Arc.............. ok
 loader/ArcM.............. ok
 loader/ArcZ.......... ok
 loader/Polygon.............. ok
 loader/PolygonM.............. ok
 loader/PolygonZ.............. ok
 regress. ok
 regress_index. ok
 regress_index_nulls. ok
 lwgeom_regress. ok
 regress_lrs. ok
 removepoint. ok
 setpoint. ok
 simplify. ok
 snaptogrid. ok
 affine. ok
 measures. ok
 long_xact. ok
 ctors. ok
 sql-mm-serialize. ok
 sql-mm-circularstring. ok
 sql-mm-compoundcurve. ok
 sql-mm-curvepoly. ok
 sql-mm-general. ok
 sql-mm-multicurve. ok
 sql-mm-multisurface. ok
 polyhedralsurface. ok
 out_geometry. ok
 out_geography. ok
 in_gml. ok
 in_kml. ok
 iscollection. ok
 regress_ogc. ok
 regress_ogc_cover. ok
 regress_ogc_prep. ok
 regress_bdpoly. ok
 regress_proj. ok
 dump. ok
 dumppoints. ok
 wmsservers_new. ok
 tickets. ok
 remove_repeated_points. ok
 split. ok
 relatematch. ok
 regress_buffer_params. ok
 hausdorff. ok
 clean. ok
 sharedpaths. ok
 snap. ok

Run tests: 55
Failed: 0

2.4.5. Installation

To install PostGIS, type

make install

This will copy the PostGIS installation files into their appropriate subdirectory specified by the --prefix configuration parameter. In particular:

  • The loader and dumper binaries are installed in [prefix]/bin.

  • The SQL files, such as postgis.sql, are installed in [prefix]/share/contrib.

  • The PostGIS libraries are installed in [prefix]/lib.

If you previously ran the make comments command to generate the postgis_comments.sql, raster_comments.sql file, install the sql file by running

make comments-install

[Note]

postgis_comments.sql, raster_comments.sql, topology_comments.sql was separated from the typical build and installation targets since with it comes the extra dependency of xsltproc.

2.5. Create a spatially-enabled database on PostgreSQL lower than 9.1

The first step in creating a PostGIS database is to create a simple PostgreSQL database.

createdb [yourdatabase]

Many of the PostGIS functions are written in the PL/pgSQL procedural language. As such, the next step to create a PostGIS database is to enable the PL/pgSQL language in your new database. This is accomplish by the command below command. For PostgreSQL 8.4+, this is generally already installed

createlang plpgsql [yourdatabase]

Now load the PostGIS object and function definitions into your database by loading the postgis.sql definitions file (located in [prefix]/share/contrib as specified during the configuration step).

psql -d [yourdatabase] -f postgis.sql

For a complete set of EPSG coordinate system definition identifiers, you can also load the spatial_ref_sys.sql definitions file and populate the spatial_ref_sys table. This will permit you to perform ST_Transform() operations on geometries.

psql -d [yourdatabase] -f spatial_ref_sys.sql

If you wish to add comments to the PostGIS functions, the final step is to load the postgis_comments.sql into your spatial database. The comments can be viewed by simply typing \dd [function_name] from a psql terminal window.

psql -d [yourdatabase] -f postgis_comments.sql

Install raster support

psql -d [yourdatabase] -f rtpostgis.sql

Install raster support comments. This will provide quick help info for each raster function using psql or PgAdmin or any other PostgreSQL tool that can show function comments

psql -d [yourdatabase] -f raster_comments.sql

Install topology support

psql -d [yourdatabase] -f topology/topology.sql

Install topology support comments. This will provide quick help info for each topology function / type using psql or PgAdmin or any other PostgreSQL tool that can show function comments

psql -d [yourdatabase] -f topology/topology_comments.sql

If you plan to restore an old backup from prior versions in this new db, run:

psql -d [yourdatabase] -f legacy.sql

[Note]

There is an alternative legacy_minimal.sql you can run instead which will install barebones needed to recover tables and work with apps like MapServer and GeoServer. If you have views that use things like distance / length etc, you'll need the full blown legacy.sql

You can later run uninstall_legacy.sql to get rid of the deprecated functions after you are done with restoring and cleanup.

2.6. Creating a spatial database using EXTENSIONS

If you are using PostgreSQL 9.1+ and have compiled and installed the extensions/ postgis modules, you can create a spatial database the new way.

createdb [yourdatabase]

The core postgis extension installs PostGIS geometry, geography, raster, spatial_ref_sys and all the functions and comments with a simple:

CREATE EXTENSION postgis;

command.

psql -d [yourdatabase] -c "CREATE EXTENSION postgis;"

Topology is packaged as a separate extension and installable with command:

psql -d [yourdatabase] -c "CREATE EXTENSION postgis_topology;"

If you plan to restore an old backup from prior versions in this new db, run:

psql -d [yourdatabase] -f legacy.sql

You can later run uninstall_legacy.sql to get rid of the deprecated functions after you are done with restoring and cleanup.

2.7. Installing, Upgrading Tiger Geocoder and loading data

The Tiger geocoder does not get installed / upgraded with the core PostGIS scripts because it is only of regional use. In fact nothing located in the extras folder is installed by default with the regular PostGIS install / upgrade. Extras like Tiger geocoder may also not be packaged in your PostGIS distribution, but will always be available in the postgis-2.0.6SVN.tar.gz file. The instructions provided here are also available in the extras/tiger_geocoder/tiger_2010/README

If you are on Windows and you don't have tar installed, you can use http://www.7-zip.org/ to unzip the PostGIS tarball.

2.7.1. Tiger Geocoder Enabling your PostGIS database

First install PostGIS using the prior instructions.

If you don't have an extras folder, download http://postgis.net/stuff/postgis-2.0.6SVN.tar.gz

tar xvfz postgis-2.0.6SVN.tar.gz

cd postgis-2.0.6SVN/extras/tiger_geocoder/tiger_2010

Edit the tiger_loader.sql to the paths of your executables server etc.

If you are installing Tiger geocoder for the first time edit either the create_geocode.bat script If you are on windows or the create_geocode.sh if you are on Linux/Unix/Mac OSX with your PostgreSQL specific settings and run the corresponding script from the commandline. If you don't edit this file, it will just contain common case locations of items. You can edit the generated script after the fact when you run the Loader_Generate_Script command.

Verify that you now have a tiger schema in your database and that it is part of your database search_path. If it is not, add it with a command something along the line of:

ALTER DATABASE geocoder SET search_path=public, tiger;

The normalizing address functionality works more or less without any data except for tricky addresses. Run this test and verify things look like this:

SELECT pprint_addy(normalize_address('202 East Fremont Street, Las Vegas, Nevada 89101')) As pretty_address;
pretty_address
---------------------------------------
202 E Fremont St, Las Vegas, NV 89101
			

2.7.2. Upgrading your Tiger Geocoder Install

If you have Tiger Geocoder packaged with 2.0 already installed, you can upgrade the functions at any time even from an interim tar ball if there are fixes you badly need.

If you don't have an extras folder, download http://postgis.net/stuff/postgis-2.0.6SVN.tar.gz

tar xvfz postgis-2.0.6SVN.tar.gz

cd postgis-2.0.6SVN/extras/tiger_geocoder/tiger_2010

Locate the upgrade_geocoder.bat script If you are on windows or the upgrade_geocoder.sh if you are on Linux/Unix/Mac OSX. Edit the file to have your postgis database credientials and run then corresponding script from the commandline.

2.7.3. Loading Tiger Data

The instructions for loading data are available in a more detailed form in the extras/tiger_geocoder/tiger_2010/README. This just includes the general steps.

The load process downloads data from the census website for the respective states requested, extracts the files, and then loads each state into its own separate set of state tables. Each state table inherits from the tables defined in tiger schema so that its sufficient to just query those tables to access all the data and drop a set of state tables at any time using the Drop_State_Tables_Generate_Script if you need to reload a state or just don't need a state anymore.

In order to be able to load data you'll need the following tools:

  • A tool to unzip the zip files from census website.

    For Unix like systems: unzip executable which is usually already installed on most Unix like platforms.

    For Windows, 7-zip which is a free compress/uncompress tool you can download from http://www.7-zip.org/

  • shp2pgsql commandline which is installed by default when you install PostGIS.

  • wget which is a web grabber tool usually installed on most Unix/Linux systems.

    If you are on windows, you can get pre-compiled binaries from http://gnuwin32.sourceforge.net/packages/wget.htm

To load data refer to Loader_Generate_Script to generate a data load script for your platform for the states you desire. Note that you can install these piecemeal. You don't have to load all the states you want all at once. You can load them as you need them.

After the states you desire have been loaded, make sure to run the:

SELECT install_missing_indexes();

as described in Install_Missing_Indexes.

To test that things are working as they should, try to run a geocode on an address in your state using Geocode

2.8. Create a spatially-enabled database from a template

Some packaged distributions of PostGIS (in particular the Win32 installers for PostGIS >= 1.1.5) load the PostGIS functions into a template database called template_postgis. If the template_postgis database exists in your PostgreSQL installation then it is possible for users and/or applications to create spatially-enabled databases using a single command. Note that in both cases, the database user must have been granted the privilege to create new databases.

From the shell:

# createdb -T template_postgis my_spatial_db

From SQL:

postgres=# CREATE DATABASE my_spatial_db TEMPLATE=template_postgis

2.9. Upgrading

Upgrading existing spatial databases can be tricky as it requires replacement or introduction of new PostGIS object definitions.

Unfortunately not all definitions can be easily replaced in a live database, so sometimes your best bet is a dump/reload process.

PostGIS provides a SOFT UPGRADE procedure for minor or bugfix releases, and a HARD UPGRADE procedure for major releases.

Before attempting to upgrade PostGIS, it is always worth to backup your data. If you use the -Fc flag to pg_dump you will always be able to restore the dump with a HARD UPGRADE.

2.9.1. Soft upgrade

If you installed your database using extensions, you'll need to upgrade using the extension model as well. If you installed using the old sql script way, then you should upgrade using the sql script way. Please refer to the appropriate.

2.9.1.1. Soft Upgrade Pre 9.1+ or without extensions

This section applies only to those who installed PostGIS not using extensions. If you have extensions and try to upgrade with this approach you'll get messages like:

can't drop ... because postgis extension depends on it

After compiling you should find several postgis_upgrade*.sql files. Install the one for your version of PostGIS. For example postgis_upgrade_13_to_15.sql should be used if you are upgrading from PostGIS 1.3 to 1.5. If you are moving from PostGIS 1.* to PostGIS 2.* or from PostGIS 2.* prior to r7409, you need to do a HARD UPGRADE.

psql -f postgis_upgrade_20_minor.sql -d your_spatial_database

The same procedure applies to raster and topology extensions, with upgrade files named rtpostgis_upgrade*.sql and topology_upgrade*.sql respectively. If you need them:

psql -f rtpostgis_upgrade_20_minor.sql -d your_spatial_database
psql -f topology_upgrade_20_minor.sql -d your_spatial_database
[Note]

If you can't find the postgis_upgrade*.sql specific for upgrading your version you are using a version too early for a soft upgrade and need to do a HARD UPGRADE.

The PostGIS_Full_Version function should inform you about the need to run this kind of upgrade using a "procs need upgrade" message.

2.9.1.2. Soft Upgrade 9.1+ using extensions

If you originally installed PostGIS with extensions, then you need to upgrade using extensions as well. Doing a minor upgrade with extensions, is fairly painless.

ALTER EXTENSION postgis UPDATE TO "2.0.6SVN";
ALTER EXTENSION postgis_topology UPDATE TO "2.0.6SVN";

If you get an error notice something like:

No migration path defined for ... to 2.0.6SVN

Then you'll need to backup your database, create a fresh one as described in Section 2.6, “Creating a spatial database using EXTENSIONS” and then restore your backup on top of this new database. You might get a message that postgis extension already installed which you can safely ignore.

[Note]

If you installed PostGIS originally without a version specified, you can often skip the reinstallation of postgis extension before restoring since the backup just has CREATE EXTENSION postgis and thus picks up the newest latest version during restore. .

2.9.2. Hard upgrade

By HARD UPGRADE we mean full dump/reload of postgis-enabled databases. You need a HARD UPGRADE when PostGIS objects' internal storage changes or when SOFT UPGRADE is not possible. The Release Notes appendix reports for each version whether you need a dump/reload (HARD UPGRADE) to upgrade.

The dump/reload process is assisted by the postgis_restore.pl script which takes care of skipping from the dump all definitions which belong to PostGIS (including old ones), allowing you to restore your schemas and data into a database with PostGIS installed without getting duplicate symbol errors or bringing forward deprecated objects.

Supplementary instructions for windows users are available at Windows Hard upgrade.

The Procedure is as follows:

  1. Create a "custom-format" dump of the database you want to upgrade (let's call it olddb) include binary blobs (-b) and verbose (-v) output. The user can be the owner of the db, need not be postgres super account.

    pg_dump -h localhost -p 5432 -U postgres -Fc -b -v -f "/somepath/olddb.backup" olddb
  2. Do a fresh install of PostGIS in a new database -- we'll refer to this database as newdb. Please refer to Section 2.5, “Create a spatially-enabled database on PostgreSQL lower than 9.1” and Section 2.6, “Creating a spatial database using EXTENSIONS” for instructions on how to do this.

    The spatial_ref_sys entries found in your dump will be restored, but they will not override existing ones in spatial_ref_sys. This is to ensure that fixes in the official set will be properly propagated to restored databases. If for any reason you really want your own overrides of standard entries just don't load the spatial_ref_sys.sql file when creating the new db.

    If your database is really old or you know you've been using long deprecated functions in your views and functions, you might need to load legacy.sql for all your functions and views etc. to properly come back. Only do this if _really_ needed. Consider upgrading your views and functions before dumping instead, if possible. The deprecated functions can be later removed by loading uninstall_legacy.sql.

  3. Restore your backup into your fresh newdb database using postgis_restore.pl. Unexpected errors, if any, will be printed to the standard error stream by psql. Keep a log of those.

    perl utils/postgis_restore.pl "/somepath/olddb.backup" | psql -h localhost -p 5432 -U postgres newdb 2> errors.txt

Errors may arise in the following cases:

  1. Some of your views or functions make use of deprecated PostGIS objects. In order to fix this you may try loading legacy.sql script prior to restore or you'll have to restore to a version of PostGIS which still contains those objects and try a migration again after porting your code. If the legacy.sql way works for you, don't forget to fix your code to stop using deprecated functions and drop them loading uninstall_legacy.sql.

  2. Some custom records of spatial_ref_sys in dump file have an invalid SRID value. Valid SRID values are bigger than 0 and smaller than 999000. Values in the 999000.999999 range are reserved for internal use while values > 999999 can't be used at all. All your custom records with invalid SRIDs will be retained, with those > 999999 moved into the reserved range, but the spatial_ref_sys table would loose a check constraint guarding for that invariant to hold and possibly also its primary key ( when multiple invalid SRIDS get converted to the same reserved SRID value ).

    In order to fix this you should copy your custom SRS to a SRID with a valid value (maybe in the 910000..910999 range), convert all your tables to the new srid (see UpdateGeometrySRID), delete the invalid entry from spatial_ref_sys and re-construct the check(s) with:

    ALTER TABLE spatial_ref_sys ADD CONSTRAINT spatial_ref_sys_srid_check check (srid > 0 AND srid < 999000 );

    ALTER TABLE spatial_ref_sys ADD PRIMARY KEY(srid));

2.10. Common Problems

There are several things to check when your installation or upgrade doesn't go as you expected.

  1. Check that you have installed PostgreSQL 8.4 or newer, and that you are compiling against the same version of the PostgreSQL source as the version of PostgreSQL that is running. Mix-ups can occur when your (Linux) distribution has already installed PostgreSQL, or you have otherwise installed PostgreSQL before and forgotten about it. PostGIS will only work with PostgreSQL 8.4 or newer, and strange, unexpected error messages will result if you use an older version. To check the version of PostgreSQL which is running, connect to the database using psql and run this query:

    SELECT version();

    If you are running an RPM based distribution, you can check for the existence of pre-installed packages using the rpm command as follows: rpm -qa | grep postgresql

  2. If your upgrade fails, make sure you are restoring into a database that already has PostGIS installed.

    SELECT postgis_full_version();

Also check that configure has correctly detected the location and version of PostgreSQL, the Proj4 library and the GEOS library.

  1. The output from configure is used to generate the postgis_config.h file. Check that the POSTGIS_PGSQL_VERSION, POSTGIS_PROJ_VERSION and POSTGIS_GEOS_VERSION variables have been set correctly.

2.11. JDBC

The JDBC extensions provide Java objects corresponding to the internal PostGIS types. These objects can be used to write Java clients which query the PostGIS database and draw or do calculations on the GIS data in PostGIS.

  1. Enter the java/jdbc sub-directory of the PostGIS distribution.

  2. Run the ant command. Copy the postgis.jar file to wherever you keep your java libraries.

The JDBC extensions require a PostgreSQL JDBC driver to be present in the current CLASSPATH during the build process. If the PostgreSQL JDBC driver is located elsewhere, you may pass the location of the JDBC driver JAR separately using the -D parameter like this:

# ant -Dclasspath=/path/to/postgresql-jdbc.jar

PostgreSQL JDBC drivers can be downloaded from http://jdbc.postgresql.org .

2.12. Loader/Dumper

The data loader and dumper are built and installed automatically as part of the PostGIS build. To build and install them manually:

# cd postgis-2.0.6SVN/loader
# make
# make install

The loader is called shp2pgsql and converts ESRI Shape files into SQL suitable for loading in PostGIS/PostgreSQL. The dumper is called pgsql2shp and converts PostGIS tables (or queries) into ESRI Shape files. For more verbose documentation, see the online help, and the manual pages.