Chapter 2. Installation

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.

	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.

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

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.

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.8SVN     | 2.0.8SVN
postgis_topology | 2.0.8SVN      | 

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;

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.8SVN, 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;

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.

	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.

	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

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:

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

	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.

First install PostGIS using the prior instructions.

If you don't have an extras folder, download http://download.osgeo.org/postgis/source/postgis-2.0.8SVN.tar.gz

tar xvfz postgis-2.0.8SVN.tar.gz

cd postgis-2.0.8SVN/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
			

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://download.osgeo.org/postgis/source/postgis-2.0.8SVN.tar.gz

tar xvfz postgis-2.0.8SVN.tar.gz

cd postgis-2.0.8SVN/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.

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:

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

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

	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.8SVN";
ALTER EXTENSION postgis_topology UPDATE TO "2.0.8SVN";

If you get an error notice something like:

No migration path defined for ... to 2.0.8SVN

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.

	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. .

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:

Errors may arise in the following cases: