PostGIS
Chapter 2. PostGIS Installation
Table of Contents
This chapter details the steps required to install PostGIS.
2.1. Short Version
To compile assuming you have all the dependencies in your search path:
tar -xvzf postgis-3.4.3dev.tar.gz
cd postgis-3.4.3dev
./configure
make
make installOnce PostGIS is installed, it needs to be enabled (Section 3.3, “Creating spatial databases”) or upgraded (Section 3.4, “Upgrading spatial databases”) in each individual database you want to use it in.
2.2. Compiling and Install from Source
|
The PostGIS module is an extension to the PostgreSQL backend server. As such, PostGIS 3.4.3dev requires full PostgreSQL server headers access in order to compile. It can be built against PostgreSQL versions 12 - 16. Earlier versions of PostgreSQL are not supported.
Refer to the PostgreSQL installation guides if you haven’t already installed PostgreSQL. https://www.postgresql.org .
|
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.2.1. Getting the Source
Retrieve the PostGIS source archive from the downloads website https://postgis.net/stuff/postgis-3.4.3dev.tar.gz
wget https://postgis.net/stuff/postgis-3.4.3dev.tar.gz
tar -xvzf postgis-3.4.3dev.tar.gz
cd postgis-3.4.3devThis will create a directory called postgis-3.4.3dev in the current
working directory.
Alternatively, checkout the source from the git repository https://git.osgeo.org/gitea/postgis/postgis/ .
git clone https://git.osgeo.org/gitea/postgis/postgis.git postgis
cd postgis
sh autogen.shChange into the newly created postgis directory to continue the
installation.
./configure2.2.2. Install Requirements
PostGIS has the following requirements for building and usage:
Required
-
PostgreSQL 12 - 16. A complete installation of PostgreSQL (including server headers) is required. PostgreSQL is available from https://www.postgresql.org .
For a full PostgreSQL / PostGIS support matrix and PostGIS/GEOS support matrix refer to https://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 withgcc. -
GNU Make (
gmakeormake). For many systems, GNUmakeis the default version of make. Check the version by invokingmake -v. Other versions ofmakemay not process the PostGISMakefileproperly. -
Proj reprojection library. Proj 6.1 or above is required. The Proj library is used to provide coordinate reprojection support within PostGIS. Proj is available for download from https://proj.org/ .
-
GEOS geometry library, version 3.6 or greater, but GEOS 3.12+ is required to take full advantage of all the new functions and features. GEOS is available for download from https://libgeos.org .
-
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 https://gitlab.gnome.org/GNOME/libxml2/-/releases.
-
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 https://github.com/json-c/json-c/releases/.
-
GDAL, version 2+ is required 3+ is preferred. This is required for raster support. https://gdal.org/download.html.
-
If compiling with PostgreSQL+JIT, LLVM version >=6 is required https://trac.osgeo.org/postgis/ticket/4125.
Optional
-
GDAL (pseudo optional) only if you don’t want raster you can leave it out. Also make sure to enable the drivers you want to use as described in Section 3.2, “Configuring raster support”.
-
GTK (requires GTK+2.0, 2.8+) to compile the shp2pgsql-gui shape file loader. http://www.gtk.org/ .
-
SFCGAL, version 1.3.1 (or higher), 1.4.1 or higher is recommended and required to be able to use all functionality. SFCGAL can be used to provide additional 2D and 3D advanced analysis functions to PostGIS cf Section 7.21, “SFCGAL Functions”. And also allow to use SFCGAL rather than GEOS for some 2D functions provided by both backends (like ST_Intersection or ST_Area, for instance). A PostgreSQL configuration variable
postgis.backendallow end user to control which backend he want to use if SFCGAL is installed (GEOS by default). Nota: SFCGAL 1.2 require at least CGAL 4.3 and Boost 1.54 (cf: https://sfcgal.org) https://gitlab.com/sfcgal/SFCGAL/. -
In order to build the Section 11.1, “Address Standardizer” you will also need PCRE http://www.pcre.org (which generally is already installed on nix systems). Section 11.1, “Address Standardizer” will automatically be built if it detects a PCRE library, or you pass in a valid
--with-pcre-dir=/path/to/pcreduring configure. -
To enable ST_AsMVT protobuf-c library 1.1.0 or higher (for usage) and the protoc-c compiler (for building) are required. Also, pkg-config is required to verify the correct minimum version of protobuf-c. See protobuf-c. By default, Postgis will use Wagyu to validate MVT polygons faster which requires a c+11 compiler. It will use CXXFLAGS and the same compiler as the PostgreSQL installation. To disable this and use GEOS instead use the `--without-wagyu+` during the configure step.
-
CUnit (
CUnit). This is needed for regression testing. http://cunit.sourceforge.net/ -
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.2.3. Build 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.
- [.command]--with-library-minor-version
-
Starting with PostGIS 3.0, the library files generated by default will no longer have the minor version as part of the file name. This means all PostGIS 3 libs will end in
postgis-3. This was done to make pg_upgrade easier, with downside that you can only install one version PostGIS 3 series in your server. To get the old behavior of file including the minor version: e.g.postgis-3.0add this switch to your configure statement. - [.command]--prefix=PREFIX
-
This is the location the PostGIS loader executables and shared libs will be installed. By default, this location is the same as the detected PostgreSQL installation. +
|
- [.command]--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.
- [.command]--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.
- [.command]--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.
- [.command]--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-configconfi 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. - [.command]--with-projdir=DIR
-
Proj is a reprojection library required by PostGIS. Use this parameter (--with-projdir=/path/to/projdir) to manually specify a particular Proj installation directory that PostGIS will build against.
- [.command]--with-libiconv=DIR
-
Directory where iconv is installed.
- [.command]--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.
- [.command]--with-pcredir=DIR
-
PCRE is an BSD-licensed Perl Compatible Regular Expression library required by address_standardizer extension. Use this parameter (--with-pcredir=/path/to/pcredir) to manually specify a particular PCRE installation directory that PostGIS will build against.
- [.command]--with-gui
-
Compile the data import GUI (requires GTK+2.0). This will create shp2pgsql-gui graphical interface to shp2pgsql.
- [.command]--without-raster
-
Compile without raster support.
- [.command]--without-topology
-
Disable topology support. There is no corresponding library as all logic needed for topology is in postgis-3.4.3dev library.
- [.command]--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.
- [.command]--with-sfcgal=PATH
-
By default PostGIS will not install with sfcgal support without this switch.
PATHis an optional argument that allows to specify an alternate PATH to sfcgal-config. - [.command]--without-phony-revision
-
Disable updating postgis_revision.h to match current HEAD of the git repository.
|
2.2.4. 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. Comments are also included as part of the CREATE EXTENSION install.
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.2.5. 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.
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
export PGUSER=postgres #overwrite psql variables
make check #to test before install
make install
# to test extensions
make check RUNTESTFLAGS=--extension
|
The extension files will always be the same for the same version of PostGIS and PostgreSQL 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%' or name LIKE 'address%';
name | default_version | installed_version
------------------------------+-----------------+-------------------
address_standardizer | 3.4.3dev | 3.4.3dev
address_standardizer_data_us | 3.4.3dev | 3.4.3dev
postgis | 3.4.3dev | 3.4.3dev
postgis_raster | 3.4.3dev | 3.4.3dev
postgis_sfcgal | 3.4.3dev |
postgis_tiger_geocoder | 3.4.3dev | 3.4.3dev
postgis_topology | 3.4.3dev |
(6 rows)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_raster;
CREATE EXTENSION postgis_sfcgal;
CREATE EXTENSION fuzzystrmatch; --needed for postgis_tiger_geocoder
--optional used by postgis_tiger_geocoder, or can be used standalone
CREATE EXTENSION address_standardizer;
CREATE EXTENSION address_standardizer_data_us;
CREATE EXTENSION postgis_tiger_geocoder;
CREATE EXTENSION postgis_topology;In psql you can use to see what versions you have installed and also what schema they are installed.
\connect mygisdb
\x
\dx postgis*List of installed extensions
-[ RECORD 1 ]-------------------------------------------------
Name | postgis
Version | 3.4.3dev
Schema | public
Description | PostGIS geometry, geography, and raster spat..
-[ RECORD 2 ]-------------------------------------------------
Name | postgis_raster
Version | 3.0.0dev
Schema | public
Description | PostGIS raster types and functions
-[ RECORD 3 ]-------------------------------------------------
Name | postgis_tiger_geocoder
Version | 3.4.3dev
Schema | tiger
Description | PostGIS tiger geocoder and reverse geocoder
-[ RECORD 4 ]-------------------------------------------------
Name | postgis_topology
Version | 3.4.3dev
Schema | topology
Description | PostGIS topology spatial types and functions
|
If you installed 3.4.3dev, without using our wonderful extension system,
you can change it to be extension based by running the below commands to
package the functions in their respective extension. Installing using
unpackaged was removed in PostgreSQL 13, so you are advised to switch
to an extension build before upgrading to PostgreSQL 13.
CREATE EXTENSION postgis FROM unpackaged;
CREATE EXTENSION postgis_raster FROM unpackaged;
CREATE EXTENSION postgis_topology FROM unpackaged;
CREATE EXTENSION postgis_tiger_geocoder FROM unpackaged;2.2.6. 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.
|
|
If successful, make check will produce the output of almost 500 tests. The results will look similar to the following (numerous lines omitted below):
CUnit - A unit testing framework for C - Version 2.1-3
http://cunit.sourceforge.net/
.
.
.
Run Summary: Type Total Ran Passed Failed Inactive
suites 44 44 n/a 0 0
tests 300 300 300 0 0
asserts 4215 4215 4215 0 n/a
Elapsed time = 0.229 seconds
.
.
.
Running tests
.
.
.
Run tests: 134
Failed: 0
-- if you build with SFCGAL
.
.
.
Running tests
.
.
.
Run tests: 13
Failed: 0
-- if you built with raster support
.
.
.
Run Summary: Type Total Ran Passed Failed Inactive
suites 12 12 n/a 0 0
tests 65 65 65 0 0
asserts 45896 45896 45896 0 n/a
.
.
.
Running tests
.
.
.
Run tests: 101
Failed: 0
-- topology regress
.
.
.
Running tests
.
.
.
Run tests: 51
Failed: 0
-- if you built --with-gui, you should see this too
CUnit - A unit testing framework for C - Version 2.1-2
http://cunit.sourceforge.net/
.
.
.
Run Summary: Type Total Ran Passed Failed Inactive
suites 2 2 n/a 0 0
tests 4 4 4 0 0
asserts 4 4 4 0 n/aThe postgis_tiger_geocoder and address_standardizer extensions,
currently only support the standard PostgreSQL installcheck. To test
these use the below. Note: the make install is not necessary if you
already did make install at root of PostGIS code folder.
For address_standardizer:
cd extensions/address_standardizer
make install
make installcheckOutput should look like:
============== dropping database "contrib_regression" ==============
DROP DATABASE
============== creating database "contrib_regression" ==============
CREATE DATABASE
ALTER DATABASE
============== running regression test queries ==============
test test-init-extensions ... ok
test test-parseaddress ... ok
test test-standardize_address_1 ... ok
test test-standardize_address_2 ... ok
=====================
All 4 tests passed.
=====================For tiger geocoder, make sure you have postgis and fuzzystrmatch extensions available in your PostgreSQL instance. The address_standardizer tests will also kick in if you built postgis with address_standardizer support:
cd extensions/postgis_tiger_geocoder
make install
make installcheckoutput should look like:
============== dropping database "contrib_regression" ==============
DROP DATABASE
============== creating database "contrib_regression" ==============
CREATE DATABASE
ALTER DATABASE
============== installing fuzzystrmatch ==============
CREATE EXTENSION
============== installing postgis ==============
CREATE EXTENSION
============== installing postgis_tiger_geocoder ==============
CREATE EXTENSION
============== installing address_standardizer ==============
CREATE EXTENSION
============== running regression test queries ==============
test test-normalize_address ... ok
test test-pagc_normalize_address ... ok
=====================
All 2 tests passed.
=====================2.2.7. 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
|
2.3. Installing and Using the address standardizer
The address_standardizer extension used to be a separate package
that required separate download. From PostGIS 2.2 on, it is now bundled
in. For more information about the address_standardize, what it does,
and how to configure it for your needs, refer to
Section 11.1, “Address
Standardizer”.
This standardizer can be used in conjunction with the PostGIS packaged tiger geocoder extension as a replacement for the Normalize_Address discussed. To use as replacement refer to Section 2.4.2, “Using Address Standardizer Extension with Tiger geocoder”. You can also use it as a building block for your own geocoder or use it to standardize your addresses for easier compare of addresses.
The address standardizer relies on PCRE which is usually already
installed on many Nix systems, but you can download the latest at:
http://www.pcre.org. If during
Section 2.2.3,
“Build configuration”, PCRE is found, then the address standardizer
extension will automatically be built. If you have a custom pcre install
you want to use instead, pass to configure
--with-pcredir=/path/to/pcre where /path/to/pcre is the root
folder for your pcre include and lib directories.
For Windows users, the PostGIS 2.1+ bundle is packaged with the
address_standardizer already so no need to compile and can move straight
to CREATE EXTENSION step.
Once you have installed, you can connect to your database and run the SQL:
CREATE EXTENSION address_standardizer;The following test requires no rules, gaz, or lex tables
SELECT num, street, city, state, zip
FROM parse_address('1 Devonshire Place PH301, Boston, MA 02109');Output should be
num | street | city | state | zip
-----+------------------------+--------+-------+-------
1 | Devonshire Place PH301 | Boston | MA | 021092.4. Installing, Upgrading Tiger Geocoder, and loading data
Extras like Tiger geocoder may not be packaged in your PostGIS
distribution. If you are missing the tiger geocoder extension or want a
newer version than what your install comes with, then use the
share/extension/postgis_tiger_geocoder.* files from the packages in
Windows Unreleased Versions
section for your version of PostgreSQL. Although these packages are for
windows, the postgis_tiger_geocoder extension files will work on any OS
since the extension is an SQL/plpgsql only extension.
2.4.1. Tiger Geocoder Enabling your PostGIS database
-
These directions assume your PostgreSQL installation already has the postgis_tiger_geocoder extension installed.
-
Connect to your database via psql or pgAdmin or some other tool and run the following SQL commands. Note that if you are installing in a database that already has postgis, you don’t need to do the first step. If you have
fuzzystrmatchextension already installed, you don’t need to do the second step either.CREATE EXTENSION postgis; CREATE EXTENSION fuzzystrmatch; CREATE EXTENSION postgis_tiger_geocoder; --this one is optional if you want to use the rules based standardizer (pagc_normalize_address) CREATE EXTENSION address_standardizer;If you already have postgis_tiger_geocoder extension installed, and just want to update to the latest run:
ALTER EXTENSION postgis UPDATE; ALTER EXTENSION postgis_tiger_geocoder UPDATE;If you made custom entries or changes to
tiger.loader_platformandtiger.loader_variablesyou may need to update these. -
To confirm your install is working correctly, run this sql in your database:
SELECT na.address, na.streetname,na.streettypeabbrev, na.zip FROM normalize_address('1 Devonshire Place, Boston, MA 02109') AS na;Which should output
address | streetname | streettypeabbrev | zip ---------+------------+------------------+------- 1 | Devonshire | Pl | 02109 -
Create a new record in
tiger.loader_platformtable with the paths of your executables and server.So for example to create a profile called debbie that follows
shconvention. You would do:INSERT INTO tiger.loader_platform(os, declare_sect, pgbin, wget, unzip_command, psql, path_sep, loader, environ_set_command, county_process_command) SELECT 'debbie', declare_sect, pgbin, wget, unzip_command, psql, path_sep, loader, environ_set_command, county_process_command FROM tiger.loader_platform WHERE os = 'sh';And then edit the paths in the declare_sect column to those that fit Debbie’s pg, unzip,shp2pgsql, psql, etc path locations.
If you don’t edit this
loader_platformtable, it will just contain common case locations of items and you’ll have to edit the generated script after the script is generated. -
As of PostGIS 2.4.1 the Zip code-5 digit tabulation area
zcta5load step was revised to load current zcta5 data and is part of the Loader_Generate_Nation_Script when enabled. It is turned off by default because it takes quite a bit of time to load (20 to 60 minutes), takes up quite a bit of disk space, and is not used that often.To enable it, do the following:
UPDATE tiger.loader_lookuptables SET load = true WHERE table_name = 'zcta520';If present the Geocode function can use it if a boundary filter is added to limit to just zips in that boundary. The Reverse_Geocode function uses it if the returned address is missing a zip, which often happens with highway reverse geocoding.
-
Create a folder called
gisdataon root of server or your local pc if you have a fast network connection to the server. This folder is where the tiger files will be downloaded to and processed. If you are not happy with having the folder on the root of the server, or simply want to change to a different folder for staging, then edit the fieldstaging_foldin thetiger.loader_variablestable. -
Create a folder called temp in the
gisdatafolder or wherever you designated thestaging_foldto be. This will be the folder where the loader extracts the downloaded tiger data. -
Then run the Loader_Generate_Nation_Script SQL function make sure to use the name of your custom profile and copy the script to a .sh or .bat file. So for example to build the nation load:
psql -c "SELECT Loader_Generate_Nation_Script('debbie')" -d geocoder -tA > /gisdata/nation_script_load.sh -
Run the generated nation load commandline scripts.
cd /gisdata sh nation_script_load.sh -
After you are done running the nation script, you should have three tables in your
tiger_dataschema and they should be filled with data. Confirm you do by doing the following queries from psql or pgAdminSELECT count(*) FROM tiger_data.county_all;count ------- 3234 (1 row)SELECT count(*) FROM tiger_data.state_all;count ------- 56 (1 row)This will only have data if you marked zcta520 to be loaded
SELECT count(*) FROM tiger_data.zcta5_all;count ------- 37371 (1 row) -
By default the tables corresponding to
bg,tract,tabblock20are not loaded. These tables are not used by the geocoder but are used by folks for population statistics. If you wish to load them as part of your state loads, run the following statement to enable them.UPDATE tiger.loader_lookuptables SET load = true WHERE load = false AND lookup_name IN('tract', 'bg', 'tabblock20');Alternatively you can load just these tables after loading state data using the Loader_Generate_Census_Script
-
For each state you want to load data for, generate a state script Loader_Generate_Script.
DO NOT Generate the state script until you have already loaded the nation data, because the state script utilizes county list loaded by nation script.
-
psql -c "SELECT Loader_Generate_Script(ARRAY['MA'], 'debbie')" -d geocoder -tA > /gisdata/ma_load.sh -
Run the generated commandline scripts.
cd /gisdata sh ma_load.sh -
After you are done loading all data or at a stopping point, it’s a good idea to analyze all the tiger tables to update the stats (include inherited stats)
SELECT install_missing_indexes(); vacuum (analyze, verbose) tiger.addr; vacuum (analyze, verbose) tiger.edges; vacuum (analyze, verbose) tiger.faces; vacuum (analyze, verbose) tiger.featnames; vacuum (analyze, verbose) tiger.place; vacuum (analyze, verbose) tiger.cousub; vacuum (analyze, verbose) tiger.county; vacuum (analyze, verbose) tiger.state; vacuum (analyze, verbose) tiger.zip_lookup_base; vacuum (analyze, verbose) tiger.zip_state; vacuum (analyze, verbose) tiger.zip_state_loc;
2.4.2. Using Address Standardizer Extension with Tiger geocoder
One of the many complaints of folks is the address normalizer function Normalize_Address function that normalizes an address for prepping before geocoding. The normalizer is far from perfect and trying to patch its imperfectness takes a vast amount of resources. As such we have integrated with another project that has a much better address standardizer engine. To use this new address_standardizer, you compile the extension as described in Section 2.3, “Installing and Using the address standardizer” and install as an extension in your database.
Once you install this extension in the same database as you have
installed postgis_tiger_geocoder, then the
Pagc_Normalize_Address can be used
instead of Normalize_Address. This
extension is tiger agnostic, so can be used with other data sources such
as international addresses. The tiger geocoder extension does come
packaged with its own custom versions of rules table
( tiger.pagc_rules) , gaz table
(tiger.pagc_gaz), and lex table
(tiger.pagc_lex). These you can add and update to improve your
standardizing experience for your own needs.
2.4.3. Required tools for tiger data loading
The load process downloads data from the census website for the
respective nation files, 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:
unzipexecutable 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/
-
shp2pgsqlcommandline which is installed by default when you install PostGIS. -
wgetwhich 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
If you are upgrading from tiger_2010, you’ll need to first generate and run Drop_Nation_Tables_Generate_Script. Before you load any state data, you need to load the nation wide data which you do with Loader_Generate_Nation_Script. Which will generate a loader script for you. Loader_Generate_Nation_Script is a one-time step that should be done for upgrading (from a prior year tiger census data) and for new installs.
To load state 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.4.4. Upgrading your Tiger Geocoder Install and Data
First upgrade your postgis_tiger_geocoder extension as follows:
ALTER EXTENSION postgis_tiger_geocoder UPDATE;Next drop all nation tables and load up the new ones. Generate a drop script with this SQL statement as detailed in Drop_Nation_Tables_Generate_Script
SELECT drop_nation_tables_generate_script();Run the generated drop SQL statements.
Generate a nation load script with this SELECT statement as detailed in Loader_Generate_Nation_Script
For windows
SELECT loader_generate_nation_script('windows');For unix/linux
SELECT loader_generate_nation_script('sh');Refer to Section 2.4.1, “Tiger Geocoder Enabling your PostGIS database” for instructions on how to run the generate script. This only needs to be done once.
|
2.5. Common Problems during installation
There are several things to check when your installation or upgrade doesn’t go as you expected.
-
Check that you have installed PostgreSQL 12 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 12 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
-
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 Proj library and the GEOS library.
-
The output from configure is used to generate the
postgis_config.hfile. Check that thePOSTGIS_PGSQL_VERSION,POSTGIS_PROJ_VERSIONandPOSTGIS_GEOS_VERSIONvariables have been set correctly.
Chapter 1. Introduction |
Chapter 3. PostGIS Administration |