Wie bei den meisten Installationen auf Linux besteht der erste Schritt in der Erstellung eines Makefiles, welches dann zur Kompilation des Quellcodes verwendet wird. Dies wird durch einen Aufruf des Shell Scripts erreicht.

./configure

Ohne zusätzliche Parameter legt dieser Befehl die Komponenten und Bibliotheken fest, welche für die Kompilation des PostGIS Quellcodes auf Ihrem System benötigt werden. Obwohl dies der häufigste Anwendungsfall von ./configure ist, akzeptiert das Skript eine Reihe von Parametern, falls sich die benötigten Bibliotheken und Programme nicht in den Standardverzeichnissen befinden.

Die folgende Liste weist nur die am häufigsten verwendeten Parameter auf. Für eine vollständige Liste benutzen Sie bitte --help oder --help=short .

	Wenn Sie PostGIS vom SVN Repository heruntergeladen haben, dann ist die Ausführung des Skripts der erste Schritt. ./autogen.sh Dieses Skript erzeugt das configure Skript, welches seinerseits zur Anpassung der Installation von PostGIS eingesetzt wird. Falls Sie stattdessen PostGIS als Tarball vorliegen haben, dann ist es nicht notwendig ./autogen.sh auszuführen, da configure bereits erzeugt wurde.

Sobald das Makefile erzeugt wurde, ist der Build-Prozess für PostGIS so einfach wie

make

Die letzte Zeile der Ausgabe sollte "PostGIS was built successfully. Ready to install." enthalten

Seit PostGIS v1.4.0 haben alle Funktionen Kommentare, welche aus der Dokumentation erstellt werden. Wenn Sie diese Kommentare später in die räumliche Datenbank importieren wollen, können Sie den Befehl ausführen der "docbook" benötigt. Die Dateien "postgis_comments.sql", "raster_comments.sql" und "topology_comments.sql" sind im Ordner "doc" der "tar.gz"-Distribution mit paketiert, weshalb Sie bei einer Installation vom "tar ball" her, die Kommentare nicht selbst erstellen müssen. Die Kommentare werden auch als Teil der Installation "CREATE EXTENSION" angelegt.

make comments

Eingeführt in PostGIS 2.0. Erzeugt HTML-Spickzettel, die als schnelle Referenz oder als Handzettel für Studenten geeignet sind. Dies benötigt xsltproc zur Kompilation und erzeugt 4 Dateien in dem Ordner "doc": topology_cheatsheet.html,tiger_geocoder_cheatsheet.html, raster_cheatsheet.html, postgis_cheatsheet.html

Einige bereits Vorgefertigte können von PostGIS / PostgreSQL Study Guides als HTML oder PDF heruntergeladen werden

make cheatsheets

Die PostGIS Erweiterungen/Extensions werden ab PostgreSQL 9.1+ automatisch kompiliert und installiert.

Wenn Sie aus dem Quell-Repository kompilieren, müssen Sie zuerst die Beschreibung der Funktionen kompilieren. Diese lassen sich kompilieren, wenn Sie docbook installiert haben. Sie können sie aber auch händisch mit folgender Anweisung kompilieren:

make comments

Sie müssen die Kommentare nicht kompilieren, wenn sie von einem Format "tar" weg kompilieren, da diese in der tar-Datei bereits vorkompilierten sind.

Wenn Sie gegen PostgreSQL 9.1 kompilieren, sollten die Erweiterungen automatisch als Teil des Prozesses "make install" kompilieren. Falls notwendig, können Sie auch vom Ordner mit den Erweiterungen aus kompilieren, oder die Dateien auf einen anderen Server kopieren.

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

cd ..
cd address_standardizer
make clean
make
make install
make installcheck

cd ..
cd postgis_tiger_geocoder
make clean
make
make install
make installcheck
          

Die Erweiterungsdateien sind für dieselbe Version von PostGIS immer ident, unabhängig vom Betriebssystem. Somit ist es in Ordnung, die Erweiterungsdateien von einem Betriebssystem auf ein anderes zu kopieren, solange die Binärdateien von PostGIS bereits installiert sind.

Falls Sie die Erweiterungen händisch auf einen anderen Server installieren wollen, müssen sie folgende Dateien aus dem Erweiterungsordner in den Ordner PostgreSQL / share / extension Ihrer PostgreSQL Installation kopieren. Ebenso die benötigten Binärdateien für das reguläre PostGIS, falls sich PostGIS noch nicht auf dem Server befindet.

Sobald Sie dies ausgeführt haben, sollten Sie postgis, postgis_topology als verfügbare Erweiterungen in PgAdmin -> extensions sehen.

Falls Sie psql verwenden, können Sie die installierten Erweiterungen folgendermaßen abfragen:

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         | 2.5.3dev         | 2.5.3dev
 address_standardizer_data_us | 2.5.3dev         | 2.5.3dev
 postgis                      | 2.5.3dev         | 2.5.3dev
 postgis_sfcgal               | 2.5.3dev         |
 postgis_tiger_geocoder       | 2.5.3dev         | 2.5.3dev
 postgis_topology             | 2.5.3dev         |
(6 rows)

Wenn Sie in der Datenbank, die Sie abfragen, eine Erweiterung installiert haben, dann sehen Sie einen Hinweis in der Spalte installed_version. Wenn Sie keine Datensätze zurückbekommen bedeutet dies, dass Sie überhaupt keine PostGIS Erweiterung auf dem Server installiert haben. PgAdmin III 1.14+ bietet diese Information ebenfalls in der Sparte extensions im Navigationsbaum der Datenbankinstanz an und ermöglicht sogar ein Upgrade oder eine Deinstallation über einen Rechtsklick.

Wenn die Erweiterungen vorhanden sind, können Sie die PostGIS-Extension sowohl mit der erweiterten pgAdmin Oberfläche als auch mittels folgender SQL-Befehle in einer beliebigen Datenbank installieren:

CREATE EXTENSION postgis;
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;

Sie können psql verwenden, um sich die installierten Versionen und die Datenbankschemen in denen sie installiert sind, anzeigen zu lassen.

\connect mygisdb
\x
\dx postgis*

List of installed extensions
-[ RECORD 1 ]-------------------------------------------------
-
Name        | postgis
Version     | 2.5.3dev
Schema      | public
Description | PostGIS geometry, geography, and raster spat..
-[ RECORD 2 ]-------------------------------------------------
-
Name        | postgis_tiger_geocoder
Version     | 2.5.3dev
Schema      | tiger
Description | PostGIS tiger geocoder and reverse geocoder
-[ RECORD 3 ]-------------------------------------------------
-
Name        | postgis_topology
Version     | 2.5.3dev
Schema      | topology
Description | PostGIS topology spatial types and functions

Die Erweiterungstabellen spatial_ref_sys. layer und topology können nicht explizit gesichert werden. Sie können nur mit der entsprechenden postgis oder postgis_topology Erweiterung gesichert werden, was nur geschieht, wenn Sie die ganze Datenbank sichern. Ab PostGIS 2.0.2 werden nur diejenigen Datensätze von SRID beim Backup der Datenbank gesichert, die nicht mit PostGIS paketiert sind. Sie sollten daher keine paketierte SRID ändern und Sie können erwarten, dass Ihre Änderungen gesichert werden. Wenn Sie irgendein Problem finden, reichen Sie bitte ein Ticket ein. Die Struktur der Erweiterungstabellen wird niemals gesichert, da diese mit CREATE EXTENSION erstellt wurde und angenommen wird, dass sie für eine bestimmten Version einer Erweiterung gleich ist. Dieses Verhalten ist in dem aktuellen PostgreSQL Extension Model eingebaut, weshalb wir daran nichts ändern können.

Wenn Sie 2.5.3dev ohne das wunderbare Extension System installiert haben, können Sie auf Extension basiert wechseln, indem Sie zuerst auf die neueste Microversion aktualisieren indem Sie die Upgradeskripts: postgis_upgrade_22_minor.sql,raster_upgrade_22_minor.sql und topology_upgrade_22_minor.sql ausführen.

Wenn Sie PostGIS ohne Rasterunterstützung installiert haben, so müssen Sie zuerst die Rasterunterstützung mittels rtpostgis.sql installieren

Anschließend können Sie die nachfolgenden Befehle ausführen, um die Funktionen in den entsprechenden Erweiterungen zu paketieren.

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

Wenn Sie die Kompilation von PostGIS überprüfen wollen:

make check

Obiger Befehl durchläuft mehere Überprüfungen und Regressionstests, indem er die angelegte Bibliothek in einer aktuellen PostgreSQL Datenbank ausführt.

	Falls Sie PostGIS so konfiguriert haben, dass nicht die Standardverzeichnisse für PostgreSQL, GEOS oder Proj4 verwendet werden, kann es sein, dass Sie die Speicherstellen dieser Bibliotheken in der Umgebungsvariablen "LD_LIBRARY_PATH" eintragen müssen.

Zurzeit beruht make check auf die Umgebungsvariablen PATH undPGPORT beim Ausführen der Überprüfungen - es wird nicht die Version von PostgreSQL verwendet, die mit dem Konfigurationsparameter --with-pgconfig angegeben wurde. Daher stellen Sie sicher, dass die Variable PATH mit der während der Konfiguration dedektierten Installation von PostgreSQL übereinstimmt, oder seien Sie auf drohende Kopfschmerzen vorbereitet.

Wenn der Test erfolgreich war, sollte die Ausgabe etwa so aussehen:

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


Suite: computational_geometry
  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_geohash_point_as_int ...passed
  Test: test_isclosed ...passed
  Test: test_lwgeom_simplify ...passed
Suite: buildarea
  Test: buildarea1 ...passed
  Test: buildarea2 ...passed
  Test: buildarea3 ...passed
  Test: buildarea4 ...passed
  Test: buildarea4b ...passed
  Test: buildarea5 ...passed
  Test: buildarea6 ...passed
  Test: buildarea7 ...passed
Suite: geometry_clean
  Test: test_lwgeom_make_valid ...passed
Suite: clip_by_rectangle
  Test: test_lwgeom_clip_by_rect ...passed
Suite: force_sfs
  Test: test_sfs_11 ...passed
  Test: test_sfs_12 ...passed
  Test: test_sqlmm ...passed
Suite: geodetic
  Test: test_sphere_direction ...passed
  Test: test_sphere_project ...passed
  Test: test_lwgeom_area_sphere ...passed
  Test: test_signum ...passed
  Test: test_gbox_from_spherical_coordinates ...passed
  Test: test_gserialized_get_gbox_geocentric ...passed
  Test: test_clairaut ...passed
  Test: test_edge_intersection ...passed
  Test: test_edge_intersects ...passed
  Test: test_edge_distance_to_point ...passed
  Test: test_edge_distance_to_edge ...passed
  Test: test_lwgeom_distance_sphere ...passed
  Test: test_lwgeom_check_geodetic ...passed
  Test: test_gserialized_from_lwgeom ...passed
  Test: test_spheroid_distance ...passed
  Test: test_spheroid_area ...passed
  Test: test_lwpoly_covers_point2d ...passed
  Test: test_gbox_utils ...passed
  Test: test_vector_angle ...passed
  Test: test_vector_rotate ...passed
  Test: test_lwgeom_segmentize_sphere ...passed
  Test: test_ptarray_contains_point_sphere ...passed
  Test: test_ptarray_contains_point_sphere_iowa ...passed
Suite: GEOS
  Test: test_geos_noop ...passed
  Test: test_geos_subdivide ...passed
  Test: test_geos_linemerge ...passed
Suite: Clustering
  Test: basic_test ...passed
  Test: nonsequential_test ...passed
  Test: basic_distance_test ...passed
  Test: single_input_test ...passed
  Test: empty_inputs_test ...passed
Suite: Clustering Union-Find
  Test: test_unionfind_create ...passed
  Test: test_unionfind_union ...passed
  Test: test_unionfind_ordered_by_cluster ...passed
Suite: homogenize
  Test: test_coll_point ...passed
  Test: test_coll_line ...passed
  Test: test_coll_poly ...passed
  Test: test_coll_coll ...passed
  Test: test_geom ...passed
  Test: test_coll_curve ...passed
Suite: encoded_polyline_input
  Test: in_encoded_polyline_test_geoms ...passed
  Test: in_encoded_polyline_test_precision ...passed
Suite: geojson_input
  Test: in_geojson_test_srid ...passed
  Test: in_geojson_test_bbox ...passed
  Test: in_geojson_test_geoms ...passed
Suite: twkb_input
  Test: test_twkb_in_point ...passed
  Test: test_twkb_in_linestring ...passed
  Test: test_twkb_in_polygon ...passed
  Test: test_twkb_in_multipoint ...passed
  Test: test_twkb_in_multilinestring ...passed
  Test: test_twkb_in_multipolygon ...passed
  Test: test_twkb_in_collection ...passed
  Test: test_twkb_in_precision ...passed
Suite: serialization/deserialization
  Test: test_typmod_macros ...passed
  Test: test_flags_macros ...passed
  Test: test_serialized_srid ...passed
  Test: test_gserialized_from_lwgeom_size ...passed
  Test: test_gbox_serialized_size ...passed
  Test: test_lwgeom_from_gserialized ...passed
  Test: test_lwgeom_count_vertices ...passed
  Test: test_on_gser_lwgeom_count_vertices ...passed
  Test: test_geometry_type_from_string ...passed
  Test: test_lwcollection_extract ...passed
  Test: test_lwgeom_free ...passed
  Test: test_lwgeom_flip_coordinates ...passed
  Test: test_f2d ...passed
  Test: test_lwgeom_clone ...passed
  Test: test_lwgeom_force_clockwise ...passed
  Test: test_lwgeom_calculate_gbox ...passed
  Test: test_lwgeom_is_empty ...passed
  Test: test_lwgeom_same ...passed
  Test: test_lwline_from_lwmpoint ...passed
  Test: test_lwgeom_as_curve ...passed
  Test: test_lwgeom_scale ...passed
  Test: test_gserialized_is_empty ...passed
  Test: test_gbox_same_2d ...passed
Suite: measures
  Test: test_mindistance2d_tolerance ...passed
  Test: test_rect_tree_contains_point ...passed
  Test: test_rect_tree_intersects_tree ...passed
  Test: test_lwgeom_segmentize2d ...passed
  Test: test_lwgeom_locate_along ...passed
  Test: test_lw_dist2d_pt_arc ...passed
  Test: test_lw_dist2d_seg_arc ...passed
  Test: test_lw_dist2d_arc_arc ...passed
  Test: test_lw_arc_length ...passed
  Test: test_lw_dist2d_pt_ptarrayarc ...passed
  Test: test_lw_dist2d_ptarray_ptarrayarc ...passed
  Test: test_lwgeom_tcpa ...passed
  Test: test_lwgeom_is_trajectory ...passed
Suite: effectivearea
  Test: do_test_lwgeom_effectivearea_lines ...passed
  Test: do_test_lwgeom_effectivearea_polys ...passed
Suite: miscellaneous
  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
  Test: test_grid ...passed
Suite: noding
  Test: test_lwgeom_node ...passed
Suite: encoded_polyline_output
  Test: out_encoded_polyline_test_geoms ...passed
  Test: out_encoded_polyline_test_srid ...passed
  Test: out_encoded_polyline_test_precision ...passed
Suite: geojson_output
  Test: out_geojson_test_precision ...passed
  Test: out_geojson_test_dims ...passed
  Test: out_geojson_test_srid ...passed
  Test: out_geojson_test_bbox ...passed
  Test: out_geojson_test_geoms ...passed
Suite: gml_output
  Test: out_gml_test_precision ...passed
  Test: out_gml_test_srid ...passed
  Test: out_gml_test_dims ...passed
  Test: out_gml_test_geodetic ...passed
  Test: out_gml_test_geoms ...passed
  Test: out_gml_test_geoms_prefix ...passed
  Test: out_gml_test_geoms_nodims ...passed
  Test: out_gml2_extent ...passed
  Test: out_gml3_extent ...passed
Suite: kml_output
  Test: out_kml_test_precision ...passed
  Test: out_kml_test_dims ...passed
  Test: out_kml_test_geoms ...passed
  Test: out_kml_test_prefix ...passed
Suite: svg_output
  Test: out_svg_test_precision ...passed
  Test: out_svg_test_dims ...passed
  Test: out_svg_test_relative ...passed
  Test: out_svg_test_geoms ...passed
  Test: out_svg_test_srid ...passed
Suite: x3d_output
  Test: out_x3d3_test_precision ...passed
  Test: out_x3d3_test_geoms ...passed
  Test: out_x3d3_test_option ...passed
Suite: ptarray
  Test: test_ptarray_append_point ...passed
  Test: test_ptarray_append_ptarray ...passed
  Test: test_ptarray_locate_point ...passed
  Test: test_ptarray_isccw ...passed
  Test: test_ptarray_signed_area ...passed
  Test: test_ptarray_unstroke ...passed
  Test: test_ptarray_insert_point ...passed
  Test: test_ptarray_contains_point ...passed
  Test: test_ptarrayarc_contains_point ...passed
  Test: test_ptarray_scale ...passed
Suite: printing
  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: SFCGAL
  Test: test_sfcgal_noop ...passed
Suite: split
  Test: test_lwline_split_by_point_to ...passed
  Test: test_lwgeom_split ...passed
Suite: stringbuffer
  Test: test_stringbuffer_append ...passed
  Test: test_stringbuffer_aprintf ...passed
Suite: surface
  Test: triangle_parse ...passed
  Test: tin_parse ...passed
  Test: polyhedralsurface_parse ...passed
  Test: surface_dimension ...passed
Suite: Internal Spatial Trees
  Test: test_tree_circ_create ...passed
  Test: test_tree_circ_pip ...passed
  Test: test_tree_circ_pip2 ...passed
  Test: test_tree_circ_distance ...passed
  Test: test_tree_circ_distance_threshold ...passed
Suite: triangulate
  Test: test_lwgeom_delaunay_triangulation ...passed
Suite: twkb_output
  Test: test_twkb_out_point ...passed
  Test: test_twkb_out_linestring ...passed
  Test: test_twkb_out_polygon ...passed
  Test: test_twkb_out_multipoint ...passed
  Test: test_twkb_out_multilinestring ...passed
  Test: test_twkb_out_multipolygon ...passed
  Test: test_twkb_out_collection ...passed
  Test: test_twkb_out_idlist ...passed
Suite: varint
  Test: test_zigzag ...passed
  Test: test_varint ...passed
  Test: test_varint_roundtrip ...passed
Suite: wkb_input
  Test: test_wkb_in_point ...passed
  Test: test_wkb_in_linestring ...passed
  Test: test_wkb_in_polygon ...passed
  Test: test_wkb_in_multipoint ...passed
  Test: test_wkb_in_multilinestring ...passed
  Test: test_wkb_in_multipolygon ...passed
  Test: test_wkb_in_collection ...passed
  Test: test_wkb_in_circularstring ...passed
  Test: test_wkb_in_compoundcurve ...passed
  Test: test_wkb_in_curvpolygon ...passed
  Test: test_wkb_in_multicurve ...passed
  Test: test_wkb_in_multisurface ...passed
  Test: test_wkb_in_malformed ...passed
Suite: wkb_output
  Test: test_wkb_out_point ...passed
  Test: test_wkb_out_linestring ...passed
  Test: test_wkb_out_polygon ...passed
  Test: test_wkb_out_multipoint ...passed
  Test: test_wkb_out_multilinestring ...passed
  Test: test_wkb_out_multipolygon ...passed
  Test: test_wkb_out_collection ...passed
  Test: test_wkb_out_circularstring ...passed
  Test: test_wkb_out_compoundcurve ...passed
  Test: test_wkb_out_curvpolygon ...passed
  Test: test_wkb_out_multicurve ...passed
  Test: test_wkb_out_multisurface ...passed
  Test: test_wkb_out_polyhedralsurface ...passed
Suite: wkt_input
  Test: test_wkt_in_point ...passed
  Test: test_wkt_in_linestring ...passed
  Test: test_wkt_in_polygon ...passed
  Test: test_wkt_in_multipoint ...passed
  Test: test_wkt_in_multilinestring ...passed
  Test: test_wkt_in_multipolygon ...passed
  Test: test_wkt_in_collection ...passed
  Test: test_wkt_in_circularstring ...passed
  Test: test_wkt_in_compoundcurve ...passed
  Test: test_wkt_in_curvpolygon ...passed
  Test: test_wkt_in_multicurve ...passed
  Test: test_wkt_in_multisurface ...passed
  Test: test_wkt_in_tin ...passed
  Test: test_wkt_in_polyhedralsurface ...passed
  Test: test_wkt_in_errlocation ...passed
Suite: wkt_output
  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
  Test: test_wkt_out_multipolygon ...passed
  Test: test_wkt_out_collection ...passed
  Test: test_wkt_out_circularstring ...passed
  Test: test_wkt_out_compoundcurve ...passed
  Test: test_wkt_out_curvpolygon ...passed
  Test: test_wkt_out_multicurve ...passed
  Test: test_wkt_out_multisurface ...passed

Run Summary:    Type  Total    Ran Passed Failed Inactive
              suites     38     38    n/a      0        0
               tests    251    251    251      0        0
             asserts   2468   2468   2468      0      n/a

Elapsed time =    0.298 seconds

Creating database 'postgis_reg'
Loading PostGIS into 'postgis_reg'
  /projects/postgis/branches/2.2/regress/00-regress-install/share/contrib/postgis/postgis.sql
  /projects/postgis/branches/2.2/regress/00-regress-install/share/contrib/postgis/postgis_comments.sql
Loading SFCGAL into 'postgis_reg'
  /projects/postgis/branches/2.2/regress/00-regress-install/share/contrib/postgis/sfcgal.sql
  /projects/postgis/branches/2.2/regress/00-regress-install/share/contrib/postgis/sfcgal_comments.sql
PostgreSQL 9.4.4, compiled by Visual C++ build 1800, 32-bit
  Postgis 2.2.0dev - r13980 - 2015-08-23 06:13:07
  scripts 2.2.0dev r13980
  GEOS: 3.5.0-CAPI-1.9.0 r4088
  PROJ: Rel. 4.9.1, 04 March 2015
  SFCGAL: 1.1.0

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
 loader/TSTPolygon ......... ok
 loader/TSIPolygon ......... ok
 loader/TSTIPolygon ......... ok
 loader/PointWithSchema ..... ok
 loader/NoTransPoint ......... ok
 loader/NotReallyMultiPoint ......... ok
 loader/MultiToSinglePoint ......... ok
 loader/ReprojectPts ........ ok
 loader/ReprojectPtsGeog ........ ok
 loader/Latin1 .... ok
 loader/Latin1-implicit .... ok
 loader/mfile .... ok
 dumper/literalsrid ....... ok
 dumper/realtable ....... ok
 affine .. ok
 bestsrid .. ok
 binary .. ok
 boundary .. ok
 cluster .. ok
 concave_hull .. ok
 ctors .. ok
 dump .. ok
 dumppoints .. ok
 empty .. ok
 forcecurve .. ok
 geography .. ok
 in_geohash .. ok
 in_gml .. ok
 in_kml .. ok
 in_encodedpolyline .. ok
 iscollection .. ok
 legacy .. ok
 long_xact .. ok
 lwgeom_regress .. ok
 measures .. ok
 operators .. ok
 out_geometry .. ok
 out_geography .. ok
 polygonize .. ok
 polyhedralsurface .. ok
 postgis_type_name .. ok
 regress .. ok
 regress_bdpoly .. ok
 regress_index .. ok
 regress_index_nulls .. ok
 regress_management .. ok
 regress_selectivity .. ok
 regress_lrs .. ok
 regress_ogc .. ok
 regress_ogc_cover .. ok
 regress_ogc_prep .. ok
 regress_proj .. ok
 relate .. ok
 remove_repeated_points .. ok
 removepoint .. ok
 setpoint .. ok
 simplify .. ok
 simplifyvw .. ok
 size .. ok
 snaptogrid .. ok
 split .. 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
 swapordinates .. ok
 summary .. ok
 temporal .. ok
 tickets .. ok
 twkb .. ok
 typmod .. ok
 wkb .. ok
 wkt .. ok
 wmsservers .. ok
 knn .. ok
 hausdorff .. ok
 regress_buffer_params .. ok
 offsetcurve .. ok
 relatematch .. ok
 isvaliddetail .. ok
 sharedpaths .. ok
 snap .. ok
 node .. ok
 unaryunion .. ok
 clean .. ok
 relate_bnr .. ok
 delaunaytriangles .. ok
 clipbybox2d .. ok
 subdivide .. ok
 in_geojson .. ok
 regress_sfcgal .. ok
 sfcgal/empty .. ok
 sfcgal/geography .. ok
 sfcgal/legacy .. ok
 sfcgal/measures .. ok
 sfcgal/regress_ogc_prep .. ok
 sfcgal/regress_ogc .. ok
 sfcgal/regress .. ok
 sfcgal/tickets .. ok
 sfcgal/concave_hull .. ok
 sfcgal/wmsservers .. ok
 sfcgal/approximatemedialaxis .. ok
 uninstall .  /projects/postgis/branches/2.2/regress/00-regress-install/share/contrib/postgis/uninstall_sfcgal.sql
  /projects/postgis/branches/2.2/regress/00-regress-install/share/contrib/postgis/uninstall_postgis.sql
. ok (4336)

Run tests: 118
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/


Suite: Shapefile Loader File shp2pgsql Test
  Test: test_ShpLoaderCreate() ...passed
  Test: test_ShpLoaderDestroy() ...passed
Suite: Shapefile Loader File pgsql2shp Test
  Test: test_ShpDumperCreate() ...passed
  Test: test_ShpDumperDestroy() ...passed

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/a

Die Erweiterungen postgis_tiger_geocoder und address_standardizer unterstützen zurzeit nur die standardmäßige Installationsüberprüfung von PostgreSQL. Um diese zu überprüfen siehe unterhalb. Anmerkung: "make install" ist nicht notwendig, wenn Sie bereits ein "make install" im Root des Ordners mit dem PostGIS Quellcode durchgeführt haben.

Für den address_standardizer:

cd extensions/address_standardizer
make install
make installcheck
          

Die Ausgabe sollte folgendermaßen aussehen:

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

Für den Tiger Geokodierer müssen Sie die Erweiterungen "postgis" und "fuzzystrmatch" in Ihrer PostgreSQL Instanz haben. Die Überprüfungen des "address_standardizer" laufen ebenfalls an, wenn Sie postgis mit "address_standardizer" Unterstützung kompiliert haben:

cd extensions/postgis_tiger_geocoder
make install
make installcheck
          

Die Ausgabe sollte folgendermaßen aussehen:

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

Um PostGIS zu installieren geben Sie bitte folgendes ein

make install

Dies kopiert die Installationsdateien von PostGIS in das entsprechende Unterverzeichnis, welches durch den Konfigurationsparameter --prefix bestimmt wird. Insbesondere:

Falls Sie zuvor den Befehl make comments ausgeführt haben, um die Dateien postgis_comments.sql und raster_comments.sql anzulegen, können Sie die SQL-Dateien folgendermaßen installieren:

make comments-install

	postgis_comments.sql, raster_comments.sql und topology_comments.sql wurden vom klassischen Build- und Installationsprozess getrennt, da diese mit xsltproc eine zusätzliche Abhängigkeit haben.

Perl Regex:Assemble wird nicht länger für die Kompiation der Erweiterung "address_standardizer" benötigt, da die generierten Dateien jetzt Teil des Quellcodes sind. Wenn Sie allerdings usps-st-city-orig.txt oder usps-st-city-orig.txt usps-st-city-adds.tx editieren müssen, dann müssen Sie parseaddress-stcities.h neu kompilieren, wozu Regex:Assemble benötigt wird.

cpan Regexp::Assemble

oder wenn Sie auf einer Ubuntu / Debian Distribution arbeiten, müssen Sie möglicherweise folgendes ausführen:

sudo perl -MCPAN -e "install Regexp::Assemble"

Falls Sie PostgreSQL 9.1+ und PostGIS 2.1+ verwenden, können Sie Vorteil aus dem Extension-Modell ziehen, um den Tiger Geokodierer zu installieren. Um dies zu tun:

Zuerst installieren Sie PostGIS entsprechend den vorherigen Anweisungen.

Wenn Sie keinen Ordner "extras" haben, können Sie http://postgis.net/stuff/postgis-2.5.3dev.tar.gz herunterladen

tar xvfz postgis-2.5.3dev.tar.gz

cd postgis-2.5.3dev/extras/tiger_geocoder

Editieren Sie die Datei tiger_loader_2015.sql (oder die aktuellste Loader Datei die Sie finden, außer Sie wollen ein anderes Jahr laden) um die Pfade zu den ausführbaren Dateien, dem Server etc. richtigzustellen. Alternativ können Sie auch die Tabelle loader_platform nach der Installation editieren. Wenn Sie diese Datei oder die Tabelle loader_platform nicht editieren, dann enthält diese nur die üblichen Ortsangaben und Sie müssen das erzeugte Skript nachträglich bearbeiten, wenn Sie die SQL Funktionen Loader_Generate_Nation_Script und Loader_Generate_Script ausgeführt haben.

Wenn Sie den Tiger Geokodierer zum ersten Mal installieren, dann editierren Sie entweder das Skript create_geocode.bat auf Windows oder create_geocode.sh auf Linux/Unix/Mac OSX entsprechend Ihren spezifischen Einstellungen von PostgreSQL und führen das entsprechende Skript auf der Befehlszeile aus.

Überprüfen sie, ob Sie ein Schema tiger in Ihrer Datenbank haben und sich das Schema in dem "search_path" Ihrer Datenbank befindet. Falls nicht, können Sie das Schema mit folgendem Befehl hinzufügen:

ALTER DATABASE geocoder SET search_path=public, tiger;

Die Funktionalität zur Standardisierung von Adressen funktioniert mehr oder weniger auch ohne Daten, mit Ausnahme von komplizierten Adressen. Führen Sie diese Tests durch und überprüfen Sie, ob das Ergebnis ähnlich wie dieses aussieht:

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
                        

Eine von vielen Beschwerden betrifft die Funktion Normalize_Address des Adressennormierers, die eine Adresse vor der Geokodierung vorbereitend standardisiert. Der Normierer ist bei weitem nicht perfekt und der Versuch seine Unvollkommenheit auszubessern nimmt viele Ressourcen in Anspruch. Daher haben wir ein anderes Projekt integriert, welches eine wesentlich bessere Funktionseinheit für den Adressennormierer besitzt. Um diesen neuen Adressennormierer zu nutzen, können Sie die Erweiterung so wie unter Section 2.7, “Installation und Verwendung des Adressennormierers” beschrieben kompilieren und als Extension in Ihrer Datenbank installieren.

Sobald Sie diese Extension in der gleichen Datenbank installieren, in der Sie auch postgis_tiger_geocoder installiert haben, dann können Sie Pagc_Normalize_Address anstatt Normalize_Address verwenden. Diese Erweiterung ist nicht auf Tiger beschränkt, wodurch sie auch mit anderen Datenquellen, wie internationalen Adressen, genutzt werden kann. Die Tiger Geokodierer Extension enthält eine eigenen Versionen von rules Tabelle (tiger.pagc_rules), gaz Tabelle (tiger.pagc_gaz) und lex Tabelle (tiger.pagc_lex). Diese können Sie hinzufügen und aktualisieren, um die Normierung an die eigenen Bedürfnisse anzupassen.

Die Anweisungen zum Laden von Daten sind unter extras/tiger_geocoder/tiger_2011/README detailliert beschrieben. Hier sind nur die allgemeinen Schritte berücksichtigt.

Der Ladeprozess lädt Daten von der Census Webseite für die jeweiligen Nationsdateien und die angeforderten Bundesstaaten herunter, extrahiert die Dateien und lädt anschließlich jeden Bundesstaat in einen eigenen Satz von Bundesstaattabellen. Jede Bundesstaattabelle erbt von den Tabellen im Schema tiger, wodurch es ausreicht nur diese Tabellen abzufragen um auf alle Daten zugreifen zu können. Sie können auch jederzeit Bundesstaattabellen mit Drop_State_Tables_Generate_Script löschen, wenn Sie einen Bundesstaat neu laden müssen oder den Bundesstaat nicht mehr benötigen.

Um Daten laden zu können benötigen Sie folgende Werkzeuge:

Wenn Sie von tiger_2010 her upgraden, müssen Sie zuerst das Skript Drop_Nation_Tables_Generate_Script generieren und ausführen. Bevor Sie irgendwelche Bundesstaatdaten laden, müssen Sie die nationsweiten Daten mit Loader_Generate_Nation_Script laden. Dies erstellt ein Skript zum Laden. Loader_Generate_Nation_Script ist ein einmaliger Schritt, der vor dem Upgrade (von 2010) und vor neuen Installationen aufsgeführt werden sollte.

Wie ein Skript zum Laden der Daten für Ihre Plattform und für die gewünschten Bundesstaaten generiert werden kann siehe Loader_Generate_Script. Sie können diese stückchenweise installieren. Sie müssen nicht alle benötigten Staaten auf einmal laden. Sie können sie laden wenn Sie diese benötigen.

Nachdem die gewünschten Bundesstaaten geladen wurden, führen Sie so wie unter Install_Missing_Indexes beschrieben

SELECT install_missing_indexes();

aus.

Um zu überprüfen, dass alles funktioniert wie es sollte, können Sie eine Geokodierung über eine Adresse Ihres Staates laufen lassen, indem Sie Geocode verwenden

Wenn Sie den Tiger Geokodierer der mit 2.0+ paketiert ist bereits installiert haben, können Sie die Funktionen jederzeit sogar mit einem vorläufigen Tarball aktualisieren, wenn Bugs fixiert wurden oder Sie es unbedingt benötigen. Dies funktioniert nur für einen Tiger Geokodierer, der nicht als Extension installiert wurde.

Wenn Sie keinen Ordner "extras" haben, können Sie http://postgis.net/stuff/postgis-2.5.3dev.tar.gz herunterladen

tar xvfz postgis-2.5.3dev.tar.gz

cd postgis-2.5.3dev/extras/tiger_geocoder/tiger_2011

Finden Sie das Skript upgrade_geocoder.bat auf Windows, oder upgrade_geocoder.sh unter Linux/Unix/Mac OSX. Editieren Sie die Datei um die Berechtigungsnachweise für Ihre PostGIS Datenbank zu erhalten.

Wenn Sie von 2010 oder 2011 her upgraden, sollten Sie die Loader-Skriptzeile auskommentieren, um das neueste Skript zum Laden der Daten von 2012 zu erhalten.

Dann führen Sie das dazugehörige Skript von der Befehlszeile aus.

Anschließend löschen Sie alle "nation"-Tabellen und laden die Neuen. Erstellen Sie ein "drop"-Skript mit den unter Drop_Nation_Tables_Generate_Script beschriebenen SQL-Anweisungen

SELECT drop_nation_tables_generate_script();

Führen Sie die erstellten SQL "drop"-Anweisungen aus.

Die untere SELECT Anweisung erstellt ein Skript zum Laden eines Staates. Details dazu finden Sie unter Loader_Generate_Nation_Script.

Auf Windows:

SELECT loader_generate_nation_script('windows'); 

Auf Unix/Linux:

SELECT loader_generate_nation_script('sh');

Siehe Section 2.8.4, “Tiger-Daten laden” für Anleitungen wie das "generate"-Skript auszuführen ist. Dies muss nur einmal ausgeführt werden.

	Sie können eine Mischung aus Bundesstaattabellen von 2010/2011 haben und jeden Bundesstaat getrennt aktualisieren. Bevor Sie einen Bundesstaat auf 2011 aktualisieren, müssen Sie zuerst die Tabellen von 2010 für diesen Bundesstaat mit Drop_State_Tables_Generate_Script entfernen.

Wenn Sie Ihre Datenbank mittels Extensions installiert haben, müssen Sie auch mit dem Extension Modell upgraden. Wenn Sie auf die alte Art mit dem SQL-Skript installiert haben, dann sollten Sie auch mit dem SQL-Skript upgraden. Beziehen Sie sich bitte auf das Richtige.

2.10.1.1. Soft Upgrade Pre 9.1+ oder ohne Extensions/Erweiterungen

Dieser Abschnitt bezieht sich lediglich auf die Installation von PostGIS ohne Extensions. Wenn Sie Extensions haben und ein Upgrade auf diese Weise versuchen, dann erhalten Sie Meldungen wie:

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

Nach dem Kompilieren und der Installation (make install) sollten sich die Dateien postgis_upgrade.sql und rtpostgis_upgrade.sql in den Installationsordnern befinden. Zum Beispiel /usr/share/postgresql/9.3/contrib/postgis_upgrade.sql. Installieren Sie postgis_upgrade.sql. Wenn Sie die Rasterfunktionalität installiert haben, dann müssen Sie auch /usr/share/postgresql/9.3/contrib/postgis_upgrade.sql installieren. Wenn Sie von PostGiS 1.*, oder von PostGIS 2.* älter als r7409, auf PostGIS 2.* wechseln, dann müssen Sie ein HARD UPGRADE ausführen.

psql -f postgis_upgrade.sql -d your_spatial_database

Dieselbe Vorgangsweise kann auf die Erweiterungen "raster" und "topology" angewendet werden. Die Dateien für das Upgrade heissen rtpostgis_upgrade*.sql beziehungsweise topology_upgrade*.sql. Wenn Sie diese benötigen:

psql -f rtpostgis_upgrade.sql -d your_spatial_database

psql -f topology_upgrade.sql -d your_spatial_database

	Wenn Sie die Datei postgis_upgrade*.sql für das Upgrade Ihrer spezifischen Version nicht finden können, dann verwenden Sie eine Version, die zu zu alt für ein SOFT UPGRADE ist und müssen ein HARD UPGRADE durchführen.

Die Funktion PostGIS_Full_Version sollte Sie mit der Meldung "procs need upgrade" darüber informieren, ob Sie diese Art von Upgrade durchführen müssen.

2.10.1.2. Soft Upgrade von PostGIS 9.1+ mittels EXTENSIONS

Wenn Sie PostGIS urspünglich mittels Extensions installiert haben, dan müssen Sie beim Upgrade ebenfalls Extensions verwenden. Ein minor Upgrade mit Extensions ist einigermaßen schmerzlos.

ALTER EXTENSION postgis UPDATE TO "2.5.3dev";
ALTER EXTENSION postgis_topology UPDATE TO "2.5.3dev";

Falls eine Fehlermeldung angezeigt wird, unternehemen Sie bitte etwas ähnliches wie:

No migration path defined for ... to 2.5.3dev

Dann müssen Sie ein Backup Ihrer Datenbank erstellen, eine neue so wie unter Section 2.5, “Eine Geodatenbank mit EXTENSIONS anlegen” beschrieben erstellen und das Backup in dieser neuen Datenbank wiederherstellen.

Falls Sie eine ähnliche Meldung wie folgt bekommen:

Version "2.5.3dev" of extension "postgis" is already installed

Dann ist alles bereits auf dem letzten Stand und Sie können das bedenkenlos ignorieren. SOFERN NICHT versucht wird, von einer SVN Version auf die nächste (welche keine neue Versionsnummer bekommt) upzugraden; In diesem Fall können Sie "next" an die Versionszeichenkette anhängen und das nächste Mal das Suffix "next" wieder entfernen:

ALTER EXTENSION postgis UPDATE TO "2.5.3devnext";
ALTER EXTENSION postgis_topology UPDATE TO "2.5.3devnext";

	Wenn Sie PostGIS ursprünglich ohne festgelegte Version installiert haben, dann können Sie die erneute Installation der PostGIS Erweiterungen - vor der Wiederherstellung - überspringen, da im Backup bereits CREATE EXTENSION postgis steht und so die neueste und letzte Version bei der Wiederherstellung aufgegriffen wird.

Unter einem HARD UPGRADE verstehen wir einen vollen Dump/Reload von PostGIS-Datenbanken. Sie benötigen ein HARD UPGRADE, wenn sich die interne Speicherung von PostGIS Objekten geändert hat, oder wenn ein SOFT UPGRADE nicht möglich ist. Der Anhang Release Notes zeigt für jede Version an, ob ein dump/reload (HARD UPGRADE) notwendig ist.

Der Prozess "Dump/Reload" wird von dem Skript "postgis_restore.pl" unterstützt, welches aufpasst dass alle Definitionen, die zu PostGIS gehören (inklusive der alten) beim Dump übersprungen werden. Dies ermöglicht es Ihnen, Ihre Schemata und Daten in einer Datenbank mit PostGIS Erweiterung wiederherzustellen, ohne dass Fehler aufgrund duplizierter Symbole oder überholter Objekte auftreten.

Zusätzliche Anweisungen für Windows Benutzer sind unter Windows Hard upgrade verfügbar.

Die Vorgehensweise ist wie folgt:

In folgenden Fällen können Fehler auftreten:

Die OpenGIS Spezifikation standardisiert zwei Möglichkeiten um Geoobjekte darzustellen: die Well-known-Text (WKT) und die Well-Known-Binary (WKB) Darstellung. Sowohl WKT als auch WKB enthalten Information über den Objekttyp und die Koordinaten, die das Objekt bilden.

Beispiele für die Textdarstellung (WKT) von Geoobjekten:

Die OpenGIS Spezifikation verlangt auch, dass das der Identifikator des Koordinatenreferenzsystem (SRID) im internen Format der Geoobjekte mit abgespeichert ist.

Für die Ein- und Ausgabe dieser Formate stehen die folgenden Schnittstellen zur Verfügung

bytea WKB = ST_AsBinary(geometry);
text WKT = ST_AsText(geometry);
geometry = ST_GeomFromWKB(bytea WKB, SRID);
geometry = ST_GeometryFromText(text WKT, SRID);

Eine gültige Einfügeanweisung, um ein räumliches OGC-Objekt zu erzeugen und einzufügen, wäre:

INSERT INTO geotable ( the_geom, the_name )
  VALUES ( ST_GeomFromText('POINT(-126.4 45.32)', 312), 'A Place');

OGC formats only support 2D geometries, and the associated SRID is *never* embedded in the input/output representations.

Zur Zeit sind die erweiterten Formate von PostGIS eine Obermenge von den OGC-Formaten (jeder gültige WKT/WKB ist auch ein gültiger EWKT/EWKB). Dies kann sich in der Zukunft allerdings ändern, insbesondere dann, wenn OGC ein neues Format einführt, welches mit diesen Erweiterungen im Widerspruch steht. Daher sollten SIE sich BITTE NICHT auf diese Eigenschaft verlassen!

PostGIS EWKB/EWKT add 3DM, 3DZ, 4D coordinates support and embedded SRID information.

Beispiele für die Textdarstellung (EWKT) von erweiterten Geoobjekten:

Conversion between these formats is available using the following interfaces:

bytea EWKB = ST_AsEWKB(geometry);
text EWKT = ST_AsEWKT(geometry);
geometry = ST_GeomFromEWKB(bytea EWKB);
geometry = ST_GeomFromEWKT(text EWKT);

Zum Beispiel würde eine gültige Eingabeanweisung, um räumliche PostGIS Objekte zu erzeugen und einzufügen, wie folgt lauten:

INSERT INTO geotable ( the_geom, the_name )
  VALUES ( ST_GeomFromEWKT('SRID=312;POINTM(-126.4 45.32 15)'), 'A Place' )

The "canonical forms" of a PostgreSQL type are the representations you get with a simple query (without any function call) and the one which is guaranteed to be accepted with a simple insert, update or copy. For the PostGIS 'geometry' type these are:

- Ausgabe
  - binary: EWKB
        ascii: HEXEWKB (EWKB in hex form)
- Eingabe
  - binary: EWKB
        ascii: HEXEWKB|EWKT 

Zum Beispiel liest die folgende Anweisung EWKT ein und gibt HEXEWKB in Normalform aus:

=# SELECT 'SRID=4;POINT(0 0)'::geometry;

geometry
----------------------------------------------------
01010000200400000000000000000000000000000000000000
(1 row)

Die "SQL Multimedia Applications Spatial" Spezifikation erweitert die SQL Spezifikation für Simple Features indem es eine Reihe von kreisförmig interpolierten Kurven definiert.

The SQL-MM definitions include 3DM, 3DZ and 4D coordinates, but do not allow the embedding of SRID information.

The Well-Known Text extensions are not yet fully supported. Examples of some simple curved geometries are shown below:

	Alle Gleitpunkt Vergleiche der SQL-MM Implementierung werden mit einer bestimmten Toleranz ausgeführt, zurzeit 1E-8.

The geography type does not support curves, TINS, or POLYHEDRALSURFACEs, but other geometry types are supported. Standard geometry type data will autocast to geography if it is of SRID 4326. You can also use the EWKT and EWKB conventions to insert data.

The geography fields get registered in the geography_columns system view.

Nun überprüfen Sie bitte ob Ihre Tabelle in der gespeicherten Abfrage "geography_columns" aufscheint.

You can create a new table with a GEOGRAPHY column using the CREATE TABLE syntax.

CREATE TABLE global_points (
    id SERIAL PRIMARY KEY,
    name VARCHAR(64),
    location GEOGRAPHY(POINT,4326)
  );

Note that the location column has type GEOGRAPHY and that geography type supports two optional modifiers: a type modifier that restricts the kind of shapes and dimensions allowed in the column; an SRID modifier that restricts the coordinate reference identifier to a particular number.

Für den Typmodifikator sind folgende Werte erlaubt: POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON. Der Modifikator unterstützt auch Einschränkungen der Dimensionalität durch Nachsilben: Z, M und ZM. So erlaubt zum Beispiel ein Modifikator mit dem Wert 'LINESTRINGM' nur die Eingabe von Linienzügen mit drei Dimensionen, wobei die dritte Dimension als Kilometrierung/measure behandelt wird. Ebenso verlangt 'POINTZM' die Eingabe von vierdimensionalen Daten.

If you do not specify an SRID, the SRID will default to 4326 WGS 84 long/lat will be used, and all calculations will proceed using WGS84.

Sobald Sie Ihre Tabelle erstellt haben, können Sie diese in der Tabelle "geography_columns" sehen:

-- Metadaten abfragen
SELECT * FROM geography_columns;

Sie können Daten auf dieselbe Art und Weise in die Tabelle einfügen wie Sie dies bei einer Geometriespalte tun würden:

-- Add some data into the test table
INSERT INTO global_points (name, location) VALUES ('Town', 'SRID=4326;POINT(-110 30)');
INSERT INTO global_points (name, location) VALUES ('Forest', 'SRID=4326;POINT(-109 29)');
INSERT INTO global_points (name, location) VALUES ('London', 'SRID=4326;POINT(0 49)');

Die Erstellung eines Index funktioniert gleich wie beim Datentyp GEOMETRY. PostGIS erkennt, dass es sich um den Datentyp GEOGRAPHY handelt und erzeugt einen entsprechenden, auf einer Kugeloberfläche basierenden Index anstelle des üblichen planaren Index, der für den Datentyp GEOMETRY verwendet wird.

-- Einen sphärischen Index auf die Testtabelle legen
  CREATE INDEX global_points_gix ON global_points USING GIST ( location );

Anfrage und Messfunktionen verwenden die Einheit Meter. Daher sollten Entfernungsparameter in Metern ausgedrückt werden und die Rückgabewerte sollten ebenfalls in Meter (oder Quadratmeter für Flächen) erwartet werden.

-- Show a distance query and note, London is outside the 1000km tolerance
  SELECT name FROM global_points WHERE ST_DWithin(location, 'SRID=4326;POINT(-110 29)'::geography, 1000000);

You can see the power of GEOGRAPHY in action by calculating how close a plane flying from Seattle to London (LINESTRING(-122.33 47.606, 0.0 51.5)) comes to Reykjavik (POINT(-21.96 64.15)).

-- Distance calculation using GEOGRAPHY (122.2km)
  SELECT ST_Distance('LINESTRING(-122.33 47.606, 0.0 51.5)'::geography, 'POINT(-21.96 64.15)'::geography);

-- Distance calculation using GEOMETRY (13.3 "degrees")
  SELECT ST_Distance('LINESTRING(-122.33 47.606, 0.0 51.5)'::geometry, 'POINT(-21.96 64.15)'::geometry);

Testing different lon/lat projects. Any long lat spatial reference system listed in spatial_ref_sys table is allowed.

-- NAD 83 lon/lat
SELECT 'SRID=4269;POINT(-123 34)'::geography;
                    geography
----------------------------------------------------
 0101000020AD1000000000000000C05EC00000000000004140
(1 row)

-- NAD27 lon/lat
SELECT 'SRID=4267;POINT(-123 34)'::geography;

                    geography
----------------------------------------------------
 0101000020AB1000000000000000C05EC00000000000004140
(1 row)

-- NAD83 UTM zone meters, yields error since its a meter based projection
SELECT 'SRID=26910;POINT(-123 34)'::geography;

ERROR:  Only lon/lat coordinate systems are supported in geography.
LINE 1: SELECT 'SRID=26910;POINT(-123 34)'::geography;

Mit dem Datentyp GEOGRAPHY wird die wahre, kürzeste Entfernung auf der Kugeloberfläche zwischen Reykjavik und der Flugstrecke entlang des Großkreises von Seattle nach London errechnet.

Great Circle mapper Beim geometrischen Datentyp wird die Entfernung sinnloserweise in einem kartesischen Koordinatensystem zwischen Reykjavik und einer Geraden von Seattle nach London errechnet und auf einer ebenen Weltkarte angezeigt. Dem Namen nach mag das Ergebnis in der Einheit "Grad" angegeben sein, da es aber in keiner Weise irgendeinem wahren Winkel zwischen den Punkten entspricht, ist sogar die Verwendung der Bezeichnung "Grad" falsch.

The geography type allows you to store data in longitude/latitude coordinates, but at a cost: there are fewer functions defined on GEOGRAPHY than there are on GEOMETRY; those functions that are defined take more CPU time to execute.

Welchen Datentyp Sie wählen sollte aufgrund der zu erwartene Flächenausdehnung ihrer Anwendung festgelegt werden. Erstrecken sich Ihre Daten über den gesamten Globus oder über eine große kontinentale Fläche, oder sind sie auf einen Staat, ein Land oder eine Gemeinde beschränkt.

Für einen Vergleich, welche Funktionalität von Geography vs. Geometry unterstützt wird, siehe Section 14.11, “PostGIS Function Support Matrix”. Für eine kurze Liste mit der Beschreibung der geographischen Funktionen, siehe Section 14.4, “PostGIS Geography Support Functions”

Die Tabelle "spatial_ref_sys" ist eine mit PostGIS kommende und OGC-konforme Datenbanktabelle, die über 3000 bekannte Koordinatenreferenzsysteme enthält, sowie Details zur Koordinatentransformation zwischen diesen.

Although the PostGIS spatial_ref_sys table contains over 3000 of the more commonly used spatial reference system definitions that can be handled by the proj library, it does not contain all known to man and you can define your own custom projection if you are familiar with proj4 constructs. Keep in mind that most spatial reference systems are regional and have no meaning when used outside of the bounds they were intended for.

Eine hervorragende Quelle zum Auffinden von Koordinatenreferenzsystemen, welche nicht in der Grundmenge enthalten sind, ist http://spatialreference.org/

Einige der häufiger eingesetzten Koordinatenreferenzsysteme sind: 4326 - WGS 84 Long Lat, 4269 - NAD 83 Long Lat, 3395 - WGS 84 World Mercator, 2163 - US National Atlas Equal Area, Koordinatenreferenzsysteme für jede NAD 83, WGS 84 und UTM Zone - UTM Zonen sind ideal für Messungen, decken aber nur 6 Grad breite, vertikale Zonen ab.

Verschiedenste Koordinatenreferenzsysteme "US State Plane" (auf Meter und Fuß basierend) - üblicherweise 2 pro US Staat. Die meisten auf Meter basierten befinden sich in der Grundmenge, aber viele der auf Fuß basierten, oder von ESRI erzeugten müssen von spatialreference.org heruntergeladen werden.

Genauere Angaben zur Ermittlung der UTM Zone für ein bestimmtes Gebiet finden Sie unter utmzone PostGIS plpgsql helper function.

Die SPATIAL_REF_SYS Tabelle ist folgendermaßen definiert:

CREATE TABLE spatial_ref_sys (
  srid       INTEGER NOT NULL PRIMARY KEY,
  auth_name  VARCHAR(256),
  auth_srid  INTEGER,
  srtext     VARCHAR(2048),
  proj4text  VARCHAR(2048)
)

Die SPATIAL_REF_SYS Spalten folgendermaßen:

GEOMETRY_COLUMNS is a view reading from database system catalogs. Its structure is as follows:

\d geometry_columns

View "public.geometry_columns"
      Column       |          Type          | Modifiers
-------------------+------------------------+-----------
 f_table_catalog   | character varying(256) |
 f_table_schema    | character varying(256) |
 f_table_name      | character varying(256) |
 f_geometry_column | character varying(256) |
 coord_dimension   | integer                |
 srid              | integer                |
 type              | character varying(30)  |

The column meanings are:

Die Erzeugung einer Tabelle mit spatialen Daten kann in einem Schritt ausgeführt werden. Dies wird im folgende Beispiel demonstriert, welches eine Straßentabelle mit einer geometrischen Spalte für 2D Linienzüge in WGS84 Länge/Breite erzeugt

CREATE TABLE ROADS (ID serial, ROAD_NAME text, geom geometry(LINESTRING,4326) );

Wir können zusätzliche Spalten hinzufügen, indem wir den normalen ALTER TABLE Befehl verwenden. Wir zeigen dies im nächsten Beispiel, wo wir einen 3D-Linienzug hinzufügen.

ALTER TABLE roads ADD COLUMN geom2 geometry(LINESTRINGZ,4326);

Two of the cases where you may need this are the case of SQL Views and bulk inserts. For bulk insert case, you can correct the registration in the geometry_columns table by constraining the column or doing an alter table. For views, you could expose using a CAST operation. Note, if your column is typmod based, the creation process would register it correctly, so no need to do anything. Also views that have no spatial function applied to the geometry will register the same as the underlying table geometry column.

-- Lets say you have a view created like this
CREATE VIEW public.vwmytablemercator AS
        SELECT gid, ST_Transform(geom, 3395) As geom, f_name
        FROM public.mytable;

-- For it to register correctly
-- You need to cast the geometry
--
DROP VIEW public.vwmytablemercator;
CREATE VIEW  public.vwmytablemercator AS
        SELECT gid, ST_Transform(geom, 3395)::geometry(Geometry, 3395) As geom, f_name
        FROM public.mytable;

-- If you know the geometry type for sure is a 2D POLYGON then you could do
DROP VIEW public.vwmytablemercator;
CREATE VIEW  public.vwmytablemercator AS
        SELECT gid, ST_Transform(geom,3395)::geometry(Polygon, 3395) As geom, f_name
        FROM public.mytable;

--Lets say you created a derivative table by doing a bulk insert
SELECT poi.gid, poi.geom, citybounds.city_name
INTO myschema.my_special_pois
FROM poi INNER JOIN citybounds ON ST_Intersects(citybounds.geom, poi.geom);

-- Create 2D index on new table
CREATE INDEX idx_myschema_myspecialpois_geom_gist
  ON myschema.my_special_pois USING gist(geom);

-- If your points are 3D points or 3M points,
-- then you might want to create an nd index instead of a 2D index
CREATE INDEX my_special_pois_geom_gist_nd
        ON my_special_pois USING gist(geom gist_geometry_ops_nd);

-- To manually register this new table's geometry column in geometry_columns.
-- Note it will also change the underlying structure of the table to
-- to make the column typmod based.
SELECT populate_geometry_columns('myschema.my_special_pois'::regclass);

-- If you are using PostGIS 2.0 and for whatever reason, you
-- you need the constraint based definition behavior
-- (such as case of inherited tables where all children do not have the same type and srid)
-- set optional use_typmod argument to false
SELECT populate_geometry_columns('myschema.my_special_pois'::regclass, false); 

Obwohl die alte auf CONSTRAINTs basierte Methode immer noch unterstützt wird, wird eine auf Constraints basierende Geometriespalte, die direkt in einem View verwendet wird, nicht korrekt in geometry_columns registriert. Eine Typmod basierte wird korrekt registriert. Im folgenden Beispiel definieren wir eine Spalte mit Typmod und eine andere mit Constraints.

CREATE TABLE pois_ny(gid SERIAL PRIMARY KEY, poi_name text, cat text, geom geometry(POINT,4326));
SELECT AddGeometryColumn('pois_ny', 'geom_2160', 2160, 'POINT', 2, false);

In psql:

\d pois_ny;

Wir sehen, das diese Spalten unterschiedlich definiert sind -- eine mittels Typmodifizierer, eine nutzt einen Constraint

Table "public.pois_ny"
  Column   |         Type          |                       Modifiers

-----------+-----------------------+------------------------------------------------------
 gid       | integer               | not null default nextval('pois_ny_gid_seq'::regclass)
 poi_name  | text                  |
 cat       | character varying(20) |
 geom      | geometry(Point,4326)  |
 geom_2160 | geometry              |
Indexes:
    "pois_ny_pkey" PRIMARY KEY, btree (gid)
Check constraints:
    "enforce_dims_geom_2160" CHECK (st_ndims(geom_2160) = 2)
    "enforce_geotype_geom_2160" CHECK (geometrytype(geom_2160) = 'POINT'::text
        OR geom_2160 IS NULL)
    "enforce_srid_geom_2160" CHECK (st_srid(geom_2160) = 2160)

Beide registrieren sich korrekt in "geometry_columns"

SELECT f_table_name, f_geometry_column, srid, type
        FROM geometry_columns
        WHERE f_table_name = 'pois_ny';

f_table_name | f_geometry_column | srid | type
-------------+-------------------+------+-------
pois_ny      | geom              | 4326 | POINT
pois_ny      | geom_2160         | 2160 | POINT

Jedoch -- wenn wir einen View auf die folgende Weise erstellen

CREATE VIEW vw_pois_ny_parks AS
SELECT *
  FROM pois_ny
  WHERE cat='park';

SELECT f_table_name, f_geometry_column, srid, type
        FROM geometry_columns
        WHERE f_table_name = 'vw_pois_ny_parks';

Die Typmod basierte geometrische Spalte eines View registriert sich korrekt, die auf Constraint basierende nicht.

f_table_name   | f_geometry_column | srid |   type
------------------+-------------------+------+----------
 vw_pois_ny_parks | geom              | 4326 | POINT
 vw_pois_ny_parks | geom_2160         |    0 | GEOMETRY

Dies kann sich bei zukünftigen Versionen von PostGIS ändern, vorerst müssen Sie aber folgendes ausführen, um die auf Constraint basierende Spalte eines View korrekt zu registrieren:

DROP VIEW vw_pois_ny_parks;
CREATE VIEW vw_pois_ny_parks AS
SELECT gid, poi_name, cat,
  geom,
  geom_2160::geometry(POINT,2160) As geom_2160
  FROM pois_ny
  WHERE cat = 'park';
SELECT f_table_name, f_geometry_column, srid, type
        FROM geometry_columns
        WHERE f_table_name = 'vw_pois_ny_parks';

f_table_name   | f_geometry_column | srid | type
------------------+-------------------+------+-------
 vw_pois_ny_parks | geom              | 4326 | POINT
 vw_pois_ny_parks | geom_2160         | 2160 | POINT

PostGIS ist mit den Open Geospatial Consortium (OGC) OpenGIS Spezifikationen konform. Daher setzen viele PostGIS Methoden voraus, dass die Geometrien mit denen sie rechnen sowohl "Simple" als auch "Valid" sind . Zum Beispiel hat es keinen Sinn, die Fläche eines Polygons zu berechnen, das eine Insel aufweist die ausserhalb des Polygons festgelegt ist, oder ein Polygon aus einer Begrenzungslinie zu konstruieren, welche nicht "simple" ist.

Entsprechend der OGC Spezifikationen ist eine simple/einfache Geometrie eine solche, die sich nicht selbst überschneidet oder berührt und bezieht sich in erster Linie auf 0- und 1-dimensionale Geometrien (insbesondere [MULTI]POINT, [MULTI]LINESTRING). Andererseits bezieht sich die Validität/Gültigkeit einer Geometrie hauptsächlich auf 2-dimensionale Geometrien (insbesondere [MULTI]POLYGON) und definiert die Menge an Aussagen, welche ein valides/gültiges Polygon auszeichnen. Die Beschreibung einer jeden geometrischen Klasse schließt bestimmte Bedingungen mit ein, welche die Simplizität und Validität von Geometrien näher beschreiben.

Da ein POINT ein 0-dimensionales geometrisches Objekt ist, ist er von vornherein simple.

MULTIPOINTs sind simple, if no two coordinates wenn sich nicht zwei Koordinate (POINTs) decken (identische Koordinatenpaare).

Ein LINESTRING ist simple, wenn er nicht zweimal durch denselben POINT geht (ausgenommen bei Endpunkten, wo dieser als linearer Ring benannt wird und zusätzlich als geschlossen angesehen wird).

(a)	(b)
(c)	(d)

(a) und (c) sind simple LINESTRINGs, (b) und (d) nicht.

Ein MULTILINESTRING ist nur dann simple, wenn alle seine Elemente "simple" sind und die einzigen Überschneidungen zwischen zwei Elementen nur an jenen POINTs auftreten, die an den Begrenzungen der beiden Elemente liegen.

(e)

(f)

(g)

(e) und (f) sind simple MULTILINESTRINGs, (g) nicht.

Definitionsgemäß ist ein POLYGON immer simple. Es ist valid, wenn sich keine zwei Ringe an der Begrenzung (bestehend aus einem äußeren Ring und inneren Ringen) kreuzen. Die Begrenzung eines POLYGONs darf an einem POINT schneiden, allerdings nur als Tangente (insbesondere nicht an einer Linie). Ein POLYGON darf keine Schnittlinien oder "Spikes" aufweisen und die inneren Ringe müssen zur Gänze im äußeren Ring enthalten sein.

(h)	(i)	(j)
(k)	(l)	(m)

(h) und (i) sind valide POLYGONe, (j-m) können nicht als einzelne POLYGONe dargestellt werden, aber (j) und (m) können als ein valides MULTIPOLYGON dargestellt werden.

Ein MULTIPOLYGON ist dann und nur dann valide, wenn alle seine Elemente valide sind und sich das Innere zweier Elemente nicht überschneidet. Die Begrenzungen zweier Elemente können sich berühren, allerdings nur an einer endlichen Anzahl von POINTs.

(n)

(o)

(p)

(n) und (o) sind keine validen MULTIPOLYGONe. Hingegen ist (p) valid.

Die meisten der von der GEOS Bibliothek implementierten Funktionen beruhen auf der Annahme, dass Ihre Geometrien entsprechend der OpenGIS Simple Feature Spezifikation, valide sind. Um die Simplizität und Validität von Geometrien festzustellen, können Sie ST_IsSimple() und ST_IsValid() verwenden.

-- Üblicherweise hat es keinen Sinn lineare Geometrien
-- auf Validität zu überprüfen, da immer TRUE zurückgegeben wird.
-- Aber in diesem Beispiel erweitert PostGIS die OGC Definition von IsValid
-- indem es FALSE zurückgibt, wenn ein LineString weniger als 2 *eindeutige* Stützpunkte aufweist.
gisdb=# SELECT
   ST_IsValid('LINESTRING(0 0, 1 1)'),
   ST_IsValid('LINESTRING(0 0, 0 0, 0 0)');

 st_isvalid | st_isvalid
------------+-----------
      t     |     f

Standardmäßig überprüft PostGIS eine Geometrieeingabe nicht auf Validität, da Validitätstests von komplexen Geometrien, insbesondere Polygonen, viel CPU Zeit beanspruchen. Fall Sie Ihren Datenquellen nicht trauen, können Sie eine Überprüfung Ihrer Tabellen durch eine "Check Constraint"/Prüfbeschränkung erzwingen:

ALTER TABLE mytable
  ADD CONSTRAINT geometry_valid_check
        CHECK (ST_IsValid(the_geom));

If you encounter any strange error messages such as "GEOS Intersection() threw an error!" when calling PostGIS functions with valid input geometries, you likely found an error in either PostGIS or one of the libraries it uses, and you should contact the PostGIS developers. The same is true if a PostGIS function returns an invalid geometry for valid input.

	Eine streng konforme OGC-Geometrie hat keine Z- oder M-Werte. Die Funktion ST_IsValid() betrachtet höhere geometrische Dimensionen nicht als invalide! Aufrufe von AddGeometryColumn() fügen eine Check-Constraint für die geometrische Dimension hinzu, weshalb es hier ausreicht 2 anzugeben.

It is sometimes the case that the typical spatial predicates (ST_Intersects, ST_Contains, ST_Crosses, ST_Touches, ...) are insufficient in and of themselves to adequately provide that desired spatial filter.

Betrachten Sie zum Beispiel einen linearen Datensatz, der ein Straßennetz darstellt. Es kann sein, dass ein GIS-Analyst die Aufgabe hat, alle Straßenabschnitte herauszufinden, die sich gegenseitig nicht an einem Punkt sondern entlang einer Linie kreuzen, da dies möglicherweise irgendeiner Unternehmensvorschrift wiederspricht. In diesem Fall liefert ST_Crosses nicht den passenden räumlichen Filter, da bei linearen Geoobjekten nur dann TRUE zurückgeben wird wenn sie sich an einem Punkt kreuzen. Eine zweistufige Lösung kann sein, dass man zuerst die eigentliche Verschneidung (ST_Intersection) von Straßenabschnittspaaren die sich räumlich überschneiden (ST_Intersects) ausführt, und anschließend den ST_GeometryType der Verschneidung mit 'LINESTRING' vergleicht (vermutlich muss man sich mit Fällen auseinandersetzen die GEOMETRYCOLLECTIONs von [MULTI]POINTs, [MULTI]LINESTRINGs, etc. zurückgeben). Eine elegantere/schnellere Lösung wäre sicherlich wünschenswert.

Ein zweites [theoretisches] Beispiel wäre, dass ein GIS-Analyst versucht alle Anlegestellen oder Kais welche die Begrenzung eines Sees entlang einer Linie überschneiden und bei denen nur ein Ende der Anlegestelle an der Küste liegt. Anders ausgedrückt, wo ein Kai im, aber nicht zur Gänze im See liegt, da er den See entlang einer Linie schneidet und seine Endpunkte sowohl zur Gänze in und auf der Begrenzung des Sees liegen. Dazu kann es nötig sein, dass der Analyst eine Kombination von Aussagen ausführen muss, um die gesuchten Geoobjekte herauszufiltern: ST_Contains(lake, wharf) = TRUE ST_ContainsProperly(lake, wharf) = FALSE ST_GeometryType(ST_Intersection(wharf, lake)) = 'LINESTRING' ST_NumGeometries(ST_Multi(ST_Intersection(ST_Boundary(wharf), ST_Boundary(lake)))) = 1 ... (überflüssig zu erwähnen, das dies ziemlich kompliziert werden kann)

Somit stürzen wir uns auf die DE-9IM-Matrix, oder kurz DE-9IM

4.3.6.1. Theorie

Entsprechend der OpenGIS Simple Features Implementation Specification for SQL, "Der grundlegende Ansatz um zwei Geometrien zu vergleichen, besteht in einer paarweisen Überprüfung des Inneren, der Begrenzung und des Äusseren zweier Geometrien und der Einstufung der Beziehung zwischen den zwei Geometrien an Hand den Einträgen in die resultierende 'Verschneidungs'-Matrix." [frei übersetzt]

Boundary

Die Begrenzung einer Geometrie ist die geometrische Grundmenge der nächst kleineren Dimension. Bei POINTs, die die Dimension 0 haben ist die Begrenzung die leere Menge. Die Begrenzung eines LINESTRINGs sind die zwei Endpunkte. Bei POLYGONen entspricht die Begrenzung jenen Linien, die die äußeren und inneren Ringe zusammensetzen.

Interior

Die Innenseite/interior einer Geometrie besteht aus jenen Punkten einer Geometrie, die zurückbleiben, wenn die Außenbegrenzung/boundary entfernt wird. Bei POINTs ist die Innenseite der POINT selbst. Die Innenseite eines LINESTRINGs ist die Menge der echten Punkte zwischen den Endpunkten. Bei POLYGONen entspricht die Innenseite der Fläche innerhalb des Polygons.

Exterior

Die Außenseite/exterior einer Geometrie ist durch die Grundgesamtheit gegeben. Das ist jene Fläche, die nicht auf der Innenseite/interior oder auf der Begrenzung der Geometrie liegt.

Gegeben sei die Geometrie a, wobei I(a), B(a), und E(a) das Innere/Interior, die Begrenzung/Boundary und dasÄussere/Exterior von a sind; die mathematische Formulierung der Matrix lautet:

	Interior	Boundary	Exterior
Interior	dim( I(a) ∩ I(b) )	dim( I(a) ∩ B(b) )	dim( I(a) ∩ E(b) )
Boundary	dim( B(a) ∩ I(b) )	dim( B(a) ∩ B(b) )	dim( B(a) ∩ E(b) )
Exterior	dim( E(a) ∩ I(b) )	dim( E(a) ∩ B(b) )	dim( E(a) ∩ E(b) )

Wobei dim(a), so wie von ST_Dimension festgelegt, die Dimension von a ist, aber zu der Domäne von {0,1,2,T,F,*} gehört.

• 0 => point

• 1 => line

• 2 => area

• T => {0,1,2}

• F => Leere Menge

• * => braucht nicht zu kümmern

Bildlich schaut dies für zwei überlappende Polygongeometrien folgendermaßen aus:

	Interior Boundary Exterior Interior dim(...) = 2 dim(...) = 1 dim(...) = 2 Boundary dim(...) = 1 dim(...) = 0 dim(...) = 1 Exterior dim(...) = 2 dim(...) = 1 dim(...) = 2

Von links nach rechts und von oben nach unten gelesen wird die Dimensionsmatrix durch '212101212' dargestellt.

Eine Beziehungsmatrix, welche das erste Beispiel von zwei Linien, die sich auf einer Linie schneiden, abbildet, würde '102101FF2' entsprechen.

-- Identifizierung der Strassenabschnitte, die eine Linie kreuzen
SELECT a.id
FROM roads a, roads b
WHERE a.id != b.id
AND a.geom && b.geom
AND ST_Relate(a.geom, b.geom, '1*1***1**');

Eine Beziehungsmatrix, welche das zweite Beispiel mit den Kais, die teilweise an der Uferlinie des Sees liegen, abbildet, würde '102101FF2' entsprechen.

-- Ermittlung von Dämmen, die teilweise an der Uferlinie eines Sees liegen
SELECT a.lake_id, b.wharf_id
FROM lakes a, wharfs b
WHERE a.geom && b.geom
AND ST_Relate(a.geom, b.geom, '102101FF2');

Für weiterführende Information siehe:

• OpenGIS Simple Features Implementation Specification for SQL (Version 1.1, Abschnitt 2.1.13.2)

• DE-9IM-Matrix (DE-9IM)

• Geotools: Mengentheoretische Topologie und die DE-9IM-Matrix

• Encyclopedia of GIS By Hui Xiong

Falls Sie Ihre Daten in eine Textdarstellung konvertieren können, dann ist möglicherweise die Verwendung von formatiertem SQL der leichteste Weg um Ihre Daten in PostGIS zu importieren. Wie bei Oracle und anderen Datenbanken, können die Daten über Masseninserts geladen werden, indem eine große Textdatei, in der sich lauter SQL "INSERT" Anweisungen befinden, an die SQL-Konsole weitergeleitet wird.

Eine Importdatei (z.B. roads.sql) könnte folgendermaßen aussehen:

BEGIN;
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (1,'LINESTRING(191232 243118,191108 243242)','Jeff Rd');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (2,'LINESTRING(189141 244158,189265 244817)','Geordie Rd');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (3,'LINESTRING(192783 228138,192612 229814)','Paul St');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (4,'LINESTRING(189412 252431,189631 259122)','Graeme Ave');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (5,'LINESTRING(190131 224148,190871 228134)','Phil Tce');
INSERT INTO roads (road_id, roads_geom, road_name)
  VALUES (6,'LINESTRING(198231 263418,198213 268322)','Dave Cres');
COMMIT;

Diese Datei kann dann über die "psql" SQL-Konsole sehr leicht nach PostgreSQL weitergeleitet werden:

psql -d [database] -f roads.sql

Der shp2pgsql Datenlader wandelt ESRI Shapefiles in eine SQL-Datei um, die für das Einfügen in eine PostGIS/PostgreSQL Datenbank mit der "psql"-Konsole, sowohl im Geometrie- als auch im Geographie-Format, geeignet ist. Der Loader besitzt eine Reihe von Betriebsmodi, die durch Flags auf der Befehlszeile ausgewählt werden:

Zusätzlich zu dem befehlszeilenorientierten Lader "shp2pgsql" gibt es auch die graphische Schnittstelle shp2pgssql-gui, welche fast ebensoviele Optionen wie der befehlszeilenorientierte Lader zur Verfügung stellt und für viele nicht so Befehlszeilenversierte bzw. PostGIS-Neuankömmlinge vielleicht einfacher zu bedienen ist. Es gibt auch ein Plugin davon für PgAdminIII.

Eine beispielhafte Sitzung, in welcher der Loader verwendet wird, um eine Eingabedatei zu erzeugen und anschließend hochzuladen, könnte folgendermaßen aussehen:

# shp2pgsql -c -D -s 4269 -i -I shaperoads.shp myschema.roadstable > roads.sql
# psql -d roadsdb -f roads.sql

Konvertierung und Import können über UNIX-Pipes in einem Schritt erfolgen:

# shp2pgsql shaperoads.shp myschema.roadstable | psql -d roadsdb

Das geradlinigste Mittel um Daten aus der Datenbank zu holen, besteht in der Anwendung einer SQL Select-Anfrage. Dadurch kann man die Anzahl der zurückgegebenen Datensätze und Spalten reduzieren und die resultierenden Datenbankspalten in eine lesbare Textdatei überspielen:

db=# SELECT road_id, ST_AsText(road_geom) AS geom, road_name FROM roads;

road_id | geom                                    | road_name
--------+-----------------------------------------+-----------
          1 | LINESTRING(191232 243118,191108 243242) | Jeff Rd
          2 | LINESTRING(189141 244158,189265 244817) | Geordie Rd
          3 | LINESTRING(192783 228138,192612 229814) | Paul St
          4 | LINESTRING(189412 252431,189631 259122) | Graeme Ave
          5 | LINESTRING(190131 224148,190871 228134) | Phil Tce
          6 | LINESTRING(198231 263418,198213 268322) | Dave Cres
          7 | LINESTRING(218421 284121,224123 241231) | Chris Way
(6 rows)

Wie auch immer, manchmal wird eine Einschränkung notwendig sein, um die Anzahl der zurückgegebenen Werte zu reduzieren. Falls es sich um eine Beschränkung auf ein Attribut handelt, können Sie die selbe SQL-Syntax verwenden wie bei jeder anderen Nicht-Geometrietabelle. Für räumliche Beschränkungen sind folgende Operatoren verfügbar/nützlich:

Next, you can use these operators in queries. Note that when specifying geometries and boxes on the SQL command line, you must explicitly turn the string representations into geometries function. The 312 is a fictitious spatial reference system that matches our data. So, for example:

SELECT road_id, road_name
  FROM roads
  WHERE roads_geom='SRID=312;LINESTRING(191232 243118,191108 243242)'::geometry;

Die obere Abfrage würde einen einzelnen Datensatz aus der Tabelle "ROADS_GEOM" zurückgeben, in dem die Geometrie gleich dem angegebenen Wert ist.

To check whether some of the roads passes in the area defined by a polygon:

SELECT road_id, road_name
FROM roads
WHERE ST_Intersects(roads_geom, 'SRID=312;POLYGON((...))');

The most common spatial query will probably be a "frame-based" query, used by client software, like data browsers and web mappers, to grab a "map frame" worth of data for display.

Der Operator "&&" kann entweder mit einer BOX3D oder mit einer Geometrie verwendet werden. Allerdings wird auch bei einer Geometrie nur das Umgebungsrechteck für den Vergleich herangezogen.

Using a "BOX3D" object for the frame, such a query looks like this:

SELECT ST_AsText(roads_geom) AS geom
FROM roads
WHERE
  roads_geom && ST_MakeEnvelope(191232, 243117,191232, 243119,312);

Achten Sie auf die Verwendung von SRID=312, welche die Projektion Einhüllenden/Enveloppe bestimmt.

Der Tabellendumper pgsql2shp verbindet sich direkt mit der Datenbank und konvertiert eine Tabelle (evtl. durch eine Abfrage festgelegt) in eine Shapedatei. Die grundlegende Syntax lautet:

pgsql2shp [<options>] <database> [<schema>.]<table>

pgsql2shp [<options>] <database> <query>

Optionen auf der Befehlszeile:

GIST, "Generalized Search Tree", steht für eine generische Datenstruktur. Zusätzlich zu der indizierung von GIS-Daten, wird GIST zur schnelleren Abfrage aller möglichen unregelmäßigen Datenstrukturen (Ganzzahl-Felder, Spektraldaten, etc.), welche über gewöhnlicher B-Baum Indizierung nicht zugänglich sind.

Sobald eine Geodatentabelle ein paar tausend Zeilen überschreitet, werden Sie einen Index erzeugen wollen, um die räumlichen Abfragen auf die Daten zu beschleunigen (außer Ihre Suche basiert lediglich auf Attributen, in diesem Fall werden Sie einen gewöhnlichen Index auf die Attribute setzen).

Die Syntax, mit der ein GIST-Index auf eine Geometriespalte angelegt wird, lautet wie folgt:

CREATE INDEX [indexname] ON [tablename] USING GIST ( [geometryfield] ); 

The above syntax will always build a 2D-index. To get the an n-dimensional index for the geometry type, you can create one using this syntax:

CREATE INDEX [indexname] ON [tablename] USING GIST ([geometryfield] gist_geometry_ops_nd);

Building a spatial index is a computationally intensive exercise. It also blocks write access to your table for the time it creates, so on a production system you may want to do in in a slower CONCURRENTLY-aware way:

CREATE INDEX CONCURRENTLY [indexname] ON [tablename] USING GIST ( [geometryfield] ); 

After building an index, it is sometimes helpful to force PostgreSQL to collect table statistics, which are used to optimize query plans:

VACUUM ANALYZE [table_name] [(column_name)];

Die Bezeichnung BRIN steht für "Block Range Index", eine generische Form des Indizierens und wurde mit PostgreSQL 9.5 eingeführt. BRIN ist ein verlustbehafteter Index, dessen Hauptzweck ist, einen Kompromiss sowohl bei der Lese- als auch bei der Schreibgeschwindigkeit anzubieten. Der Hauptverwendungszweck liegt bei sehr großen Tabellen, in denen einige Spalten einen natürlichen Bezug zu dem physischen Speicherplatz innerhalb der Tabelle haben. Zusätzlich zur Indizierung von GIS-Daten, werden BRIN-Indizes zur Beschleunigung von Suchabfragen auf unterschiedliche regelmäßige und unregelmäßige Datenstrukturen (Ganzzahlen, Felder etc.) verwendet.

Sobald eine Geodatentabelle ein paar tausend Zeilen überschreitet, werden Sie einen Index erzeugen wollen, um die räumlichen Abfragen auf die Daten zu beschleunigen (außer Ihre Suche basiert lediglich auf Attributen, in diesem Fall werden Sie einen gewöhnlichen Index auf die Attribute setzen). GIST Indizes sind sehr performant, solange ihre Dateigröße den verfügbaren Arbeitsspeicher der Datenbank nicht überschreitet, genügend Festplattenspeicher vorhanden ist und die Systembelastung durch Schreibvorgänge akzeptiert werden kann. Andernfalls bietet der BRIN Index eine Alternative.

Die Idee hinter einem BRIN-Index ist, dass nur das Umgebungsrechteck abgespeichert wird, dass die gesamte Geometrie eines oder mehrerer Tabellenblöcke umschließt; dies wird als "Range" bezeichnet. Es ist klar, dass diese Indizierungsmethode nur dann effizient sein kann, wenn die Daten physikalisch so angeordnet sind, dass sich die resultierenden Umgebungsrechtecke der "Block Ranges" gegenseitig ausschließen. Der resultierende Index ist zwar sehr klein, in vielen Fällen allerdings weniger effizient als ein GIST Index.

Die Erstellung eines BRIN-Index benötigt wesentlich weniger Zeit, als die Erstellung eines GIST-Index. Es ist durchaus üblich, dass die Erstellung des BRIN Index mehr als zehnmal so schnell ist, als die eines GIST Index. Da ein BRIN Index nur ein Umgebungsrechteck für einen oder mehrere Tabellenblöcke speichert, benötigt dieser oft bis zu tausendmal weniger Festplattenspeicher.

Sie können die Anzahl der Blöcke festlegen, die zu einen "Range" aufsummiert werden sollen. Wenn Sie die Anzahl verringern, wird der Index zwar größer, höchstwahrscheinlich aber zu einer besseren Performanz verhelfen.

Der Syntax zur Erstellung eines BRIN-Indizes auf eine geometrische Spalte lautet wie folgt:

CREATE INDEX [indexname] ON [tablename] USING BRIN ( [geometryfield] ); 

The above syntax will always build a 2D-index. To get a 3D-dimensional index, you can create one using this syntax

CREATE INDEX [indexname] ON [tablename] USING BRIN ([geometryfield] brin_geometry_inclusion_ops_3d);

You can also get a 4D-dimensional index using the 4D operator class

CREATE INDEX [indexname] ON [tablename] USING BRIN ([geometryfield] brin_geometry_inclusion_ops_4d);

Die oberen Syntaxen verwenden die Standardeinstellung für die Anzahl der Blöcke in einem "Range", nämlich 128. Wenn Sie die Anzahl der Blöcke, die in einem Range zusammengefasst werden sollen, selbst festlegen wollen, verwenden Sie bitte die folgende Syntax

CREATE INDEX [indexname] ON [tablename] USING BRIN ( [geometryfield] ) WITH (pages_per_range = [number]); 

Beachten Sie bitte auch, dass ein BRIN Index nur einen Indexwert für eine große Anzahl von Zeilen speichert. Wenn Ihre Tabelle eine Geometrie mit unterschiedlichen Dimensionen speichert, dann ist es wahrscheinlich dass der Index eine schlechte Performanz aufweist. Sie können diesen Performanzrückgang vermeiden, indem Sie die Operatorklasse mit der niedrigsten Dimension der gespeicherten Geometrie wählen.

Der BRIN-Index wird auch vom geographischen Datentyp unterstützt. Die Syntax zur Erstellung eines BRIN-Index auf eine "geographische" Spalte lautet wie folgt:

CREATE INDEX [indexname] ON [tablename] USING BRIN ( [geographyfield] ); 

Der obere Syntax erzeugt den 2D-Index für Geoobjekte immer auf dem Referenzellipsoid.

Aktuell wird hierbei nur die "Inklusionsunterstützung" betrachtet; d.h. dass nur die Operatoren &&, ~ und @ für 2D (sowohl für den "geometrischen", als auch für den "geographischen" Datentyp), und nur der Operator &&& für 3D-Geometrie verwendet werden kann. Die kNN-Suche wird zur Zeit nicht unterstützt.

SP-GiST stands for "Space-Partitioned Generalized Search Tree" and is a generic form of indexing that supports partitioned search trees, such as quad-trees, k-d trees, and radix trees (tries). The common feature of these data structures is that they repeatedly divide the search space into partitions that need not be of equal size. In addition to GIS indexing, SP-GiST is used to speed up searches on many kinds of data, such as phone routing, ip routing, substring search, etc.

As it is the case for GiST indexes, SP-GiST indexes are lossy, in the sense that they store the bounding box englobing the spatial objects. SP-GiST indexes can be considered as an alternative to GiST indexes. The performance tests reveal that SP-GiST indexes are especially beneficial when there are many overlapping objects, that is, with so-called “spaghetti data”.

Once a GIS data table exceeds a few thousand rows, an SP-GiST index may be used to speed up spatial searches of the data. The syntax for building an SP-GiST index on a "geometry" column is as follows:

CREATE INDEX [indexname] ON [tablename] USING SPGIST ( [geometryfield] ); 

The above syntax will build a 2-dimensional index. A 3-dimensional index for the geometry type can be created using the 3D operator class:

CREATE INDEX [indexname] ON [tablename] USING SPGIST ([geometryfield] spgist_geometry_ops_3d);

Building a spatial index is a computationally intensive operation. It also blocks write access to your table for the time it creates, so on a production system you may want to do in in a slower CONCURRENTLY-aware way:

CREATE INDEX CONCURRENTLY [indexname] ON [tablename] USING SPGIST ( [geometryfield] ); 

After building an index, it is sometimes helpful to force PostgreSQL to collect table statistics, which are used to optimize query plans:

VACUUM ANALYZE [table_name] [(column_name)];

An SP-GiST index can accelerate queries involving the following operators:

There is no support for kNN searches at the moment.

Ordinarily, indexes invisibly speed up data access: once the index is built, the query planner transparently decides when to use index information to speed up a query plan. Unfortunately, the PostgreSQL query planner sometimes does not optimize the use of GiST indexes well, so sometimes searches which should use a spatial index instead may perform a sequential scan of the whole table.

Wenn Sie bemerken, dass Ihre räumlichen Indizes (oder Ihre Attributindizes) nicht verwendet werden, können Sie eine Reihe von Dingen unternehmen:

Wenn Sie eine Abfrage erstellen müssen Sie beachten, dass nur die auf den Umgebungsrechtecken basierenden Operatoren wie && die Vorteile eines räumlichen GIST Index ausnutzen können. Funktionen wie ST_Distance() können den Index nicht zur Optimierung heranziehen. Zum Beispiel würde die folgende Abfrage auf eine große Tabelle ziemlich langsam ablaufen:

SELECT the_geom
FROM geom_table
WHERE ST_Distance(the_geom, 'SRID=312;POINT(100000 200000)') < 100

This query is selecting all the geometries in geom_table which are within 100 units of the point (100000, 200000). It will be slow because it is calculating the distance between each point in the table and our specified point, ie. one ST_Distance() calculation for each row in the table. We can avoid this by using the single step index accelerated function ST_DWithin to reduce the number of distance calculations required:

SELECT the_geom
FROM geom_table
WHERE ST_DWithin(the_geom, 'SRID=312;POINT(100000 200000)', 100)

This query selects the same geometries, but it does it in a more efficient way. Assuming there is a GiST index on the_geom, the query planner will recognize that it can use the index to reduce the number of rows before calculating the result of the ST_Distance() function. Notice that the ST_MakeEnvelope geometry which is used in the && operation is a 200 unit square box centered on the original point - this is our "query box". The && operator uses the index to quickly reduce the result set down to only those geometries which have bounding boxes that overlap the "query box". Assuming that our query box is much smaller than the extents of the entire geometry table, this will drastically reduce the number of distance calculations that need to be done.

Die Beispiele in diesem Abschnitt verwenden zwei Tabellen, eine Tabelle mit linearen Strassen, und eine Tabelle mit polygonalen Verwaltungsgrenzen. Die Tabellendefinition der Tabelle bc_roads lautet:

Column      | Type              | Description
------------+-------------------+-------------------
gid         | integer           | Unique ID
name        | character varying | Road Name
the_geom    | geometry          | Location Geometry (Linestring)

Die Tabellendefinition für die Tabelle bc_municipality:

Column     | Type              | Description
-----------+-------------------+-------------------
gid        | integer           | Unique ID
code       | integer           | Unique ID
name       | character varying | City / Town Name
the_geom   | geometry          | Location Geometry (Polygon)

SELECT sum(ST_Length(the_geom))/1000 AS km_roads FROM bc_roads;

km_roads
------------------
70842.1243039643
(1 row)

SELECT
  ST_Area(the_geom)/10000 AS hectares
FROM bc_municipality
WHERE name = 'PRINCE GEORGE';

hectares
------------------
32657.9103824927
(1 row)

SELECT
  name,
  ST_Area(the_geom)/10000 AS hectares
FROM
  bc_municipality
ORDER BY hectares DESC
LIMIT 1;

name           | hectares
---------------+-----------------
TUMBLER RIDGE  | 155020.02556131
(1 row)

SELECT
  m.name,
  sum(ST_Length(r.the_geom))/1000 as roads_km
FROM
  bc_roads AS r,
  bc_municipality AS m
WHERE
  ST_Contains(m.the_geom, r.the_geom)
GROUP BY m.name
ORDER BY roads_km;

name                        | roads_km
----------------------------+------------------
SURREY                      | 1539.47553551242
VANCOUVER                   | 1450.33093486576
LANGLEY DISTRICT            | 833.793392535662
BURNABY                     | 773.769091404338
PRINCE GEORGE               | 694.37554369147
...

CREATE TABLE pg_roads as
SELECT
  ST_Intersection(r.the_geom, m.the_geom) AS intersection_geom,
  ST_Length(r.the_geom) AS rd_orig_length,
  r.*
FROM
  bc_roads AS r,
  bc_municipality AS m
WHERE
  m.name = 'PRINCE GEORGE'
        AND ST_Intersects(r.the_geom, m.the_geom);

SELECT
  sum(ST_Length(r.the_geom))/1000 AS kilometers
FROM
  bc_roads r,
  bc_municipality m
WHERE
        r.name = 'Douglas St'
        AND m.name = 'VICTORIA'
        AND ST_Intersects(m.the_geom, r.the_geom);

kilometers
------------------
4.89151904172838
(1 row)

SELECT gid, name, ST_Area(the_geom) AS area
FROM bc_municipality
WHERE ST_NRings(the_geom) > 1
ORDER BY area DESC LIMIT 1;

gid  | name         | area
-----+--------------+------------------
12   | SPALLUMCHEEN | 257374619.430216
(1 row)

raster2pgsql ist ein ausführbarer Rasterlader, der die von GDAL unterstützten Rasterformate in SQL umwandelt um sie anschließend in eine PostGIS Rastertabelle zu laden. Er kann sowohl ganze Verzeichnisse mit Rasterdateien laden, als auch Rasterübersichten erzeugen.

Da "raster2pgsql" meistens als Teil von PostGIS kompiliert ist (solange Sie nicht Ihre eigene GDAL Bibliothek kompilieren), sind die von "raster2pgsql" unterstützten Rastertypen die selben wie in der GDAL Bibliothek. Um eine Liste der Rastertypen, die von Ihrem jeweiligen "raster2pgsql"unterstützt werden, zu erhalten, benutzen Sie bitte den -G Switch. Falls Sie dieselbe GDAL Bibliothek für beide verwenden, sollte diese Liste mit der Ihrer PostGIS Installation, die durch ST_GDALDrivers bereitgestellt wird, ident sein.

	Die frühere Version dieses Tools war ein Python Skript. Die lauffähige Version hat das Python Skript ersetzt. Sollten Sie weiterhin das Python Skript benötigen, können Sie unter GDAL PostGIS Raster Driver Usage Beispiele für Python finden. Beachten Sie bitte, dass zukünftige Versionen von PostGIS Raster das "raster2pgsql" Pythonskript nicht mehr unterstützen.

	Bei einem bestimmten Faktor kann es vorkommen, dass die Raster in der Übersicht/Overview nicht bündig angeordnet sind, obwohl sie die Raster selbst dies sind. Siehe http://trac.osgeo.org/postgis/ticket/1764 für ein solches Beispiel.

ANWENDUNGSBEISPIEL:

raster2pgsql raster_options_go_here raster_file someschema.sometable > out.sql

Eine Beispielssitzung, wo mit dem Lader eine Eingabedatei erstellt und stückchenweise als 100x100 Kacheln hochgeladen wird, könnte so aussehen:

	Sie können den Schemanamen weglassen z.B. demelevation anstatt public.demelevation , wodurch die Rastertabelle im Standardschema der Datenbank oder des Anwenders angelegt wird.

raster2pgsql -s 4326 -I -C -M *.tif -F -t 100x100 public.demelevation 
> elev.sql
psql -d gisdb -f elev.sql

Durch die Verwendung von UNIX-Pipes kann die Konvertierung und der Upload in einem Schritt vollzogen werden:

raster2pgsql -s 4326 -I -C -M *.tif -F -t 100x100 public.demelevation | psql -d gisdb

Luftbildkacheln in "Massachusetts State Plane Meters" in das Schema aerial laden. Einen vollständigen View und Übersichtstabellen mit Faktor 2 und 4 erstellen. Verwendet den Modus "copy" für das Insert (keine dazwischengeschaltete Datei, sondern direkt in die Datenbank). Die Option -e bedingt, dass nicht alles innerhalb einer Transaktion abläuft (nützlich, wenn Sie sofort Daten sehen wollen, ohne zu warten). Die Raster werden in 128x128 Pixel große Kacheln zerlegt und Constraints auf die Raster gesetzt. Verwendet den Modus "copy" anstelle eines Tabellen-Inserts. (-F) Erzeugt das Attribut "filename", welches die Bezeichnung der Ausgangsdateien enthält, aus denen die Rasterkacheln ausgeschnitten wurden.

raster2pgsql -I -C -e -Y -F -s 26986 -t 128x128  -l 2,4 bostonaerials2008/*.jpg aerials.boston | psql -U postgres -d gisdb -h localhost -p 5432

--gibt eine Liste der unterstützten Rasterformate aus:
raster2pgsql -G

Der -G Befehl gibt eine ähnliche Liste wie die Folgende aus

Available GDAL raster formats:
  Virtual Raster
  GeoTIFF
  National Imagery Transmission Format
  Raster Product Format TOC format
  ECRG TOC format
  Erdas Imagine Images (.img)
  CEOS SAR Image
  CEOS Image
  JAXA PALSAR Product Reader (Level 1.1/1.5)
  Ground-based SAR Applications Testbed File Format (.gff)
  ELAS
  Arc/Info Binary Grid
  Arc/Info ASCII Grid
  GRASS ASCII Grid
  SDTS Raster
  DTED Elevation Raster
  Portable Network Graphics
  JPEG JFIF
  In Memory Raster
  Japanese DEM (.mem)
  Graphics Interchange Format (.gif)
  Graphics Interchange Format (.gif)
  Envisat Image Format
  Maptech BSB Nautical Charts
  X11 PixMap Format
  MS Windows Device Independent Bitmap
  SPOT DIMAP
  AirSAR Polarimetric Image
  RadarSat 2 XML Product
  PCIDSK Database File
  PCRaster Raster File
  ILWIS Raster Map
  SGI Image File Format 1.0
  SRTMHGT File Format
  Leveller heightfield
  Terragen heightfield
  USGS Astrogeology ISIS cube (Version 3)
  USGS Astrogeology ISIS cube (Version 2)
  NASA Planetary Data System
  EarthWatch .TIL
  ERMapper .ers Labelled
  NOAA Polar Orbiter Level 1b Data Set
  FIT Image
  GRIdded Binary (.grb)
  Raster Matrix Format
  EUMETSAT Archive native (.nat)
  Idrisi Raster A.1
  Intergraph Raster
  Golden Software ASCII Grid (.grd)
  Golden Software Binary Grid (.grd)
  Golden Software 7 Binary Grid (.grd)
  COSAR Annotated Binary Matrix (TerraSAR-X)
  TerraSAR-X Product
  DRDC COASP SAR Processor Raster
  R Object Data Store
  Portable Pixmap Format (netpbm)
  USGS DOQ (Old Style)
  USGS DOQ (New Style)
  ENVI .hdr Labelled
  ESRI .hdr Labelled
  Generic Binary (.hdr Labelled)
  PCI .aux Labelled
  Vexcel MFF Raster
  Vexcel MFF2 (HKV) Raster
  Fuji BAS Scanner Image
  GSC Geogrid
  EOSAT FAST Format
  VTP .bt (Binary Terrain) 1.3 Format
  Erdas .LAN/.GIS
  Convair PolGASP
  Image Data and Analysis
  NLAPS Data Format
  Erdas Imagine Raw
  DIPEx
  FARSITE v.4 Landscape File (.lcp)
  NOAA Vertical Datum .GTX
  NADCON .los/.las Datum Grid Shift
  NTv2 Datum Grid Shift
  ACE2
  Snow Data Assimilation System
  Swedish Grid RIK (.rik)
  USGS Optional ASCII DEM (and CDED)
  GeoSoft Grid Exchange Format
  Northwood Numeric Grid Format .grd/.tab
  Northwood Classified Grid Format .grc/.tab
  ARC Digitized Raster Graphics
  Standard Raster Product (ASRP/USRP)
  Magellan topo (.blx)
  SAGA GIS Binary Grid (.sdat)
  Kml Super Overlay
  ASCII Gridded XYZ
  HF2/HFZ heightfield raster
  OziExplorer Image File
  USGS LULC Composite Theme Grid
  Arc/Info Export E00 GRID
  ZMap Plus Grid
  NOAA NGS Geoid Height Grids

Oftmals werden Sie die Raster und die Rastertabellen direkt in der Datenbank erzeugen wollen. Dafür existieren eine Unmenge an Funktionen. Dies verlangt im Allgemeinen die folgende Schritte.

raster_columns ist ein Katalog mit allen Rasterspalten Ihrer Datenbanktabellen. Es handelt sich dabei um einen View, der die Constraints auf die Tabellen ausnutzt, um so immer konsistent mit dem aktuellen Stand der Datenbank zu bleiben; sogar dann, wenn Sie den Raster aus einem Backup oder einer anderen Datenbank wiederherstellen. Der raster_columns Katalog beinhaltet die folgenden Spalten.

Falls Sie Ihre Tabellen nicht mit dem Loader erstellt haben, oder vergessen haben, die -C Option während des Ladens anzugeben, können Sie die Constraints auch anschließend erzwingen, indem Sie AddRasterConstraints verwenden, wodurch der raster_columns Katalog die Information über Ihre Rasterkacheln, wie üblich abspeichert.

raster_overviews Katalogisiert Information über die Rastertabellenspalten die für die Übersichten/Overviews herangezogen wurden, sowie weitere zusätzliche Information bezüglich Overviews. Die Übersichtstabellen werden sowohl in raster_columns als auch in raster_overviews registriert, da sie sowohl eigene Raster darstellen, als auch, als niedriger aufgelöstes Zerrbild einer höher aufgelösten Tabelle, einem bestimmten Zweck dienen. Wenn Sie den -l Switch beim Laden des Rasters angeben, werden diese gemeinsam mit der Rasterhaupttabelle erstellt; sie können aber auch händisch über AddOverviewConstraints erstellt werden.

Übersichtstabellen enthalten dieselben Constraints wie andere Rastertabellen und zusätzliche informative Constraints, spezifisch für die Übersichten.

	Die Information in raster_overviews befindet sich nicht in raster_columns. Falls Sie die Information der Übersichtstabelle und der raster_columns zusammen benötigen, können Sie einen Join auf raster_overviews und raster_columns ausführen, um die gesamte Information zu erhalten.

Die zwei Hauptgründe für Übersichtsraster sind:

Der raster_overviews Katalog enthält folgende Attribute an Information.

In diesem Abschnitt zeigen wir die Anwendung des PHP PostgreSQL Treibers und der Funktion ST_AsGDALRaster, um die Bänder 1,2,3 eines Rasters an einen PHP Request-Stream zu übergeben. Dieser kann dann in einen "img src" HTML Tag eingebunden werden.

Dieses Beispiel zeigt, wie Sie ein ganzes Bündel von Rasterfunktionen kombinieren können, um jene Kacheln zu erhalten, die ein bestimmtes WGS84 Umgebungsrechteck schneiden. Anschließend werden alle Bänder dieser Kacheln mit ST_Union vereinigt, mit ST_Transform in die vom Benutzer vorgegebene Projektion transformiert und das Ergebnis mit ST_AsPNG als PNG ausgegeben.

Sie können das unten angeführte Programm über

http://mywebserver/test_raster.php?srid=2249

aufrufen, um den Raster in "Massachusetts State Plane Feet" zu erhalten.

<?php
/** Inahlt von test_raster.php **/
$conn_str ='dbname=mydb host=localhost port=5432 user=myuser password=mypwd';
$dbconn = pg_connect($conn_str);
header('Content-Type: image/png');
/**Wenn eine bestimmte Projektion angefragt ist, wird diese verwendet, ansonsten wird "Mass State Plane Meters" verwendet **/
if (!empty( $_REQUEST['srid'] ) && is_numeric( $_REQUEST['srid']) ){
                $input_srid = intval($_REQUEST['srid']);
}
else { $input_srid = 26986; }
/**  "set bytea_output" für PostgreSQL 9.0+, wird für 8.4 nicht benötigt**/
$sql = "set bytea_output='escape';
SELECT ST_AsPNG(ST_Transform(
                        ST_AddBand(ST_Union(rast,1), ARRAY[ST_Union(rast,2),ST_Union(rast,3)])
                                ,$input_srid) ) As new_rast
 FROM aerials.boston
        WHERE
         ST_Intersects(rast, ST_Transform(ST_MakeEnvelope(-71.1217, 42.227, -71.1210, 42.218,4326),26986) )";
$result = pg_query($sql);
$row = pg_fetch_row($result);
pg_free_result($result);
if ($row === false) return;
echo pg_unescape_bytea($row[0]);
?>

In diesem Abschnitt zeigen wir die Anwendung des Npgsql PostgreSQL .NET Treibers und der Funktion ST_AsGDALRaster, um die Bänder 1,2,3 eines Rasters an einen PHP Request-Stream zu übergeben. Dieser kann dann in einen "img src" HTML Tag eingebunden werden.

Für dieses Beispiel benötigen Sie den npgsql .NET PostgreSQL Treiber. Um loslegen zu können, reicht es aus, dass Sie die neueste Version von http://npgsql.projects.postgresql.org/ in Ihren ASP.NET Ordner laden.

Dieses Beispiel zeigt, wie Sie ein ganzes Bündel von Rasterfunktionen kombinieren können, um jene Kacheln zu erhalten, die ein bestimmtes WGS84 Umgebungsrechteck schneiden. Anschließend werden alle Bänder dieser Kacheln mit ST_Union vereinigt, mit ST_Transform in die vom Benutzer vorgegebene Projektion transformiert und das Ergebnis mit ST_AsPNG als PNG ausgegeben.

Dasselbe Beispiel wie Section 5.3.1, “PHP Beispiel: Ausgabe mittels ST_AsPNG in Verbindung mit anderen Rasterfunktionen” nur in C# implementiert.

Sie können das unten angeführte Programm über

http://mywebserver/TestRaster.ashx?srid=2249

aufrufen, um den Raster in "Massachusetts State Plane Feet" zu bekommen.

-- web.config Verbindungsaufbau --
<connectionStrings>
    <add name="DSN"
        connectionString="server=localhost;database=mydb;Port=5432;User Id=myuser;password=mypwd"/>
</connectionStrings
>

// Code für TestRaster.ashx
<%@ WebHandler Language="C#" Class="TestRaster" %>
using System;
using System.Data;
using System.Web;
using Npgsql;

public class TestRaster : IHttpHandler
{
        public void ProcessRequest(HttpContext context)
        {

                context.Response.ContentType = "image/png";
                context.Response.BinaryWrite(GetResults(context));

        }

        public bool IsReusable {
                get { return false; }
        }

        public byte[] GetResults(HttpContext context)
        {
                byte[] result = null;
                NpgsqlCommand command;
                string sql = null;
                int input_srid = 26986;
        try {
                    using (NpgsqlConnection conn = new NpgsqlConnection(System.Configuration.ConfigurationManager.ConnectionStrings["DSN"].ConnectionString)) {
                            conn.Open();

                if (context.Request["srid"] != null)
                {
                    input_srid = Convert.ToInt32(context.Request["srid"]);
                }
                sql = @"SELECT ST_AsPNG(
                            ST_Transform(
                                        ST_AddBand(
                                ST_Union(rast,1), ARRAY[ST_Union(rast,2),ST_Union(rast,3)])
                                                    ,:input_srid) ) As new_rast
                        FROM aerials.boston
                                WHERE
                                    ST_Intersects(rast,
                                    ST_Transform(ST_MakeEnvelope(-71.1217, 42.227, -71.1210, 42.218,4326),26986) )";
                            command = new NpgsqlCommand(sql, conn);
                command.Parameters.Add(new NpgsqlParameter("input_srid", input_srid));


                            result = (byte[]) command.ExecuteScalar();
                conn.Close();
                        }

                }
        catch (Exception ex)
        {
            result = null;
            context.Response.Write(ex.Message.Trim());
        }
                return result;
        }
}

Eine einfache Java Applikation, die eine Abfrage entgegennimmt, ein Bild erzeugt und in eine bestimmte Datei ausgibt.

Sie können die neuesten PostgreSQL JDBC Treiber unter http://jdbc.postgresql.org/download.html herunterladen.

Sie können den unten angegebenen Code mit einem Befehl wie folgt kompilieren:

set env CLASSPATH .:..\postgresql-9.0-801.jdbc4.jar
javac SaveQueryImage.java
jar cfm SaveQueryImage.jar Manifest.txt *.class

Und ihn von der Befehlszeile wie folgt aufrufen:

java -jar SaveQueryImage.jar "SELECT ST_AsPNG(ST_AsRaster(ST_Buffer(ST_Point(1,5),10, 'quad_segs=2'),150, 150, '8BUI',100));" "test.png" 

-- Manifest.txt --
Class-Path: postgresql-9.0-801.jdbc4.jar
Main-Class: SaveQueryImage

// Code für SaveQueryImage.java
import java.sql.Connection;
import java.sql.SQLException;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.io.*;

public class SaveQueryImage {
  public static void main(String[] argv) {
      System.out.println("Checking if Driver is registered with DriverManager.");

      try {
        //java.sql.DriverManager.registerDriver (new org.postgresql.Driver());
        Class.forName("org.postgresql.Driver");
      }
      catch (ClassNotFoundException cnfe) {
        System.out.println("Couldn't find the driver!");
        cnfe.printStackTrace();
        System.exit(1);
      }

      Connection conn = null;

      try {
        conn = DriverManager.getConnection("jdbc:postgresql://localhost:5432/mydb","myuser", "mypwd");
        conn.setAutoCommit(false);

        PreparedStatement sGetImg = conn.prepareStatement(argv[0]);

        ResultSet rs = sGetImg.executeQuery();

                FileOutputStream fout;
                try
                {
                        rs.next();
                        /** Output to file name requested by user **/
                        fout = new FileOutputStream(new File(argv[1]) );
                        fout.write(rs.getBytes(1));
                        fout.close();
                }
                catch(Exception e)
                {
                        System.out.println("Can't create file");
                        e.printStackTrace();
                }

        rs.close();
                sGetImg.close();
        conn.close();
      }
      catch (SQLException se) {
        System.out.println("Couldn't connect: print out a stack trace and exit.");
        se.printStackTrace();
        System.exit(1);
      }
  }
}

Diese als plpython gespeicherte Prozedur erzeugt eine Datei pro Datensatz im Serververzeichnis. Benötigt die Installation von plpython. Funktioniert sowohl mit plpythonu als auch mit plpython3u.

CREATE OR REPLACE FUNCTION write_file (param_bytes bytea, param_filepath text)
RETURNS text
AS $$
f = open(param_filepath, 'wb+')
f.write(param_bytes)
return param_filepath
$$ LANGUAGE plpythonu;

-- 5 Bilder in verschiedenen Größen nach PostgreSQL schreiben
-- der Account des PostgreSQL Daemons benötigt Schreibrechte auf den Ordner
-- die Namen der erzeugten Dateien werden ausgegeben;
 SELECT write_file(ST_AsPNG(
        ST_AsRaster(ST_Buffer(ST_Point(1,5),j*5, 'quad_segs=2'),150*j, 150*j, '8BUI',100)),
         'C:/temp/slices'|| j || '.png')
         FROM generate_series(1,5) As j;

     write_file
---------------------
 C:/temp/slices1.png
 C:/temp/slices2.png
 C:/temp/slices3.png
 C:/temp/slices4.png
 C:/temp/slices5.png

Leider hat PSQL keine einfach zu benützende Funktion für die Ausgabe von Binärdateien eingebaut. Dieser Hack baut auf der etwas veralteten "Large Object" Unterstützung von PostgreSQL auf. Um ihn anzuwenden verbinden Sie sich bitte zuerst über die Befehlszeile "psql" mit Ihrer Datenbank.

Anders als beim Ansatz mit Python, wird die Datei bei diesem Ansatz auf Ihrem lokalen Rechner erzeugt.

SELECT oid, lowrite(lo_open(oid, 131072), png) As num_bytes
 FROM
 ( VALUES (lo_create(0),
   ST_AsPNG( (SELECT rast FROM aerials.boston WHERE rid=1) )
  ) ) As v(oid,png);
-- die Ausgabe sieht ungefähr so aus --
   oid   | num_bytes
---------+-----------
 2630819 |     74860

-- beachten Sie die OID und ersetzen Sie c:/test.png mit dem tatsächlichen Pfad
-- auf Ihrem Rechner
 \lo_export 2630819 'C:/temp/aerial_samp.png'

-- löscht die Datei aus dem "large object" Speicher der Datenbank
SELECT lo_unlink(2630819);
                        

Um PostGIS mit MapServer zu verwenden müssen Sie wissen, wie Sie MapServer konfigurieren, da dies den Rahmens dieser Dokumentation sprengen würde. Dieser Abschnitt deckt PostGIS-spezifische Themen und Konfigurationsdetails ab.

Um PostGIS mit MapServer zu verwenden, benötigen Sie:

MapServer greift auf die PostGIS/PostgreSQL-Daten, so wie jeder andere PostgreSQL-Client, über die libpq Schnittstelle zu. Dies bedeutet, dass MapServer auf jedem Server, der Netzwerkzugriff auf den PostgreSQL Server hat, installiert werden kann und PostGIS als Datenquelle nutzen kann. Je schneller die Verbindung zwischen den beiden Systemen, desto besser.

Die SQL-Pseudoklausel USING wird verwendet, um MapServer zusätzliche Information über komplexere Abfragen zukommen zu lassen. Genauer gesagt, wenn entweder ein View oder ein Subselect als Ursprungstabelle verwendet wird (der Ausdruck rechts von "FROM" bei einer DATA Definition) ist es für MapServer schwieriger einen eindeutigen Identifikator für jede Zeile und die SRID der Tabelle automatisch zu bestimmen. Die USINGKlausel kann MapServer die Information über diese beiden Teile wie folgt zukommen lassen:

DATA "geom FROM (
  SELECT
    table1.geom AS geom,
    table1.gid AS gid,
    table2.data AS data
  FROM table1
  LEFT JOIN table2
  ON table1.id = table2.id
) AS new_table USING UNIQUE gid USING SRID=4326"

Beginnen wir mit einem einfachen Beispiel und arbeiten uns dann langsam vor. Betrachten Sie die nachfolgende MapServer Layerdefinition:

LAYER
  CONNECTIONTYPE postgis
  NAME "roads"
  CONNECTION "user=theuser password=thepass dbname=thedb host=theserver"
  DATA "geom from roads"
  STATUS ON
  TYPE LINE
  CLASS
    STYLE
      COLOR 0 0 0
    END
  END
END

Dieser Layer stellt alle Straßengeometrien der "roads"-Tabelle schwarz dar.

Angenommen, wir wollen bis zu einem Maßstab von 1:100000 nur die Autobahnen anzeigen - die nächsten zwei Layer erreichen diesen Effekt:

LAYER
  CONNECTIONTYPE postgis
  CONNECTION "user=theuser password=thepass dbname=thedb host=theserver"
  PROCESSING "CLOSE_CONNECTION=DEFER"
  DATA "geom from roads"
  MINSCALE 100000
  STATUS ON
  TYPE LINE
  FILTER "road_type = 'highway'"
  CLASS
    COLOR 0 0 0
  END
END
LAYER
  CONNECTIONTYPE postgis
  CONNECTION "user=theuser password=thepass dbname=thedb host=theserver"
  PROCESSING "CLOSE_CONNECTION=DEFER"
  DATA "geom from roads"
  MAXSCALE 100000
  STATUS ON
  TYPE LINE
  CLASSITEM road_type
  CLASS
    EXPRESSION "highway"
    STYLE
      WIDTH 2
      COLOR 255 0 0
    END
  END
  CLASS
    STYLE
      COLOR 0 0 0
    END
  END
END

Der erste Layer wird verwendet, wenn der Maßstab größer als 1:100000 ist und es werden nur die Straßen vom Typ "highway"/Autobahn als schwarze Linien dargestellt. Die Option FILTER bedingt, dass nur Straßen vom Typ "highway" angezeigt werden.

Der zweite Layer wird angezeigt, wenn der Maßstab kleiner als 1:100000 ist. Er zeigt die Autobahnen als doppelt so dicke rote Linien an, die anderen Straßen als normale schwarze Linien.

Wir haben eine Reihe von interessanten Aufgaben lediglich mit der von MapServer zur Verfügung gestellten Funktionalität durchgeführt, und unsere SQL-Anweisung unter DATA ist trotzdem einfach geblieben. Angenommen, die Namen der Straßen sind in einer anderen Tabelle gespeichert (wieso auch immer) und wir müssen einen Join ausführen, um sie für die Straßenbeschriftung verwenden zu können.

LAYER
  CONNECTIONTYPE postgis
  CONNECTION "user=theuser password=thepass dbname=thedb host=theserver"
  DATA "geom FROM (SELECT roads.gid AS gid, roads.geom AS geom,
        road_names.name as name FROM roads LEFT JOIN road_names ON
        roads.road_name_id = road_names.road_name_id)
        AS named_roads USING UNIQUE gid USING SRID=4326"
  MAXSCALE 20000
  STATUS ON
  TYPE ANNOTATION
  LABELITEM name
  CLASS
    LABEL
      ANGLE auto
      SIZE 8
      COLOR 0 192 0
      TYPE truetype
      FONT arial
    END
  END
END

Dieser Beschriftungslayer fügt grüne Beschriftungen zu allen Straßen hinzu, wenn der Maßstab 1:20000 oder weniger wird. Es zeigt auch wie man einen SQL-Join in einer DATA Definition verwenden kann.

...

...

Aktuelle PostgreSQL Versionen (inklusive 9.6) haben eine Schwäche des Optimizers in Bezug auf TOAST Tabellen. TOAST Tabellen bieten eine Art "Erweiterungsraum", der benutzt wird um große Werte (im Sinne der Datengröße), welche nicht in die üblichen Datenspeicherseiten passen (wie lange Texte, Bilder oder eine komplexe Geometrie mit vielen Stützpunkten) auszulagern, siehe the PostgreSQL Documentation for TOAST für mehr Information).

Das Problem tritt bei Tabellen mit relativ großen Geometrien, aber wenigen Zeilen auf (z.B. eine Tabelle welche die europäischen Ländergrenzen in hoher Auflösung beinhaltet). Dann ist die Tabelle selbst klein, aber sie benützt eine Menge an TOAST Speicherplatz. In unserem Beispiel hat die Tabelle um die 80 Zeilen und nutzt dafür nur 3 Speicherseiten, während die TOAST Tabelle 8225 Speicherseiten benützt.

Stellen Sie sich nun eine Abfrage vor, die den geometrischen Operator && verwendet, um ein Umgebungsrechteck mit nur wenigen Zeilen zu ermitteln. Der Abfrageoptimierer stellt fest, dass die Tabelle nur 3 Speicherseiten und 80 Zeilen aufweist. Er nimmt an, das ein sequentieller Scan bei einer derart kleinen Tabelle wesentlich schneller abläuft als die Verwendung eines Indizes. Und so entscheidet er den GIST Index zu ignorieren. Normalerweise stimmt diese Annahme. Aber in unserem Fall, muss der && Operator die gesamte Geometrie von der Festplatte lesen um den BoundingBox-Vergleich durchführen zu können, wodurch auch alle TOAST-Speicherseiten gelesen werden.

Um zu sehen, ob dieses Problem auftritt, können Sie den "EXPLAIN ANALYZE" Befehl von PostgreSQL anwenden. Mehr Information und die technischen Feinheiten entnehmen Sie bitte dem Thread auf der Postgres Performance Mailing List: http://archives.postgresql.org/pgsql-performance/2005-02/msg00030.php

und einem neueren Thread über PostGIS https://lists.osgeo.org/pipermail/postgis-devel/2017-June/026209.html

Die PostgreSQL Entwickler versuchen das Problem zu lösen, indem sie die Abschätzung der Abfragen TOAST-gewahr machen. Zur Überbrückung zwei Workarounds:

Der erste Workaround besteht darin den Query Planer zu zwingen, den Index zu nutzen. Setzen Sie "SET enable_seqscan TO off;" am Server bevor Sie die Abfrage ausführen. Dies zwingt den Query Planer grundsätzlich dazu sequentielle Scans, wann immer möglich, zu vermeiden. Womit der GIST Index wie üblich verwendet wird. Aber dieser Parameter muss bei jeder Verbindung neu gesetzt werden, und er verursacht das der Query Planer Fehleinschätzungen in anderen Fällen macht. Daher sollte "SET enable_seqscan TO on;" nach der Abfrage ausgeführt werden.

Der zweite Workaround besteht darin, den sequentiellen Scan so schnell zu machen wie der Query Planer annimmt. Dies kann durch eine zusätzliche Spalte, welche die BBOX "zwischenspeichert" und über die abgefragt wird, erreicht werden. In Unserem Beispiel sehen die Befehle dazu folgendermaßen aus:

SELECT AddGeometryColumn('myschema','mytable','bbox','4326','GEOMETRY','2');
UPDATE mytable SET bbox = ST_Envelope(ST_Force2D(the_geom));

Nun ändern Sie bitte Ihre Abfrage so, das der && Operator gegen die bbox anstelle der geom_column benutzt wird:

SELECT geom_column
FROM mytable
WHERE bbox && ST_SetSRID('BOX3D(0 0,1 1)'::box3d,4326);

Selbstverständlich muss man die BBOX synchron halten. Die transparenteste Möglichkeit dies zu erreichen wäre über Trigger. Sie können Ihre Anwendung derart abändern, das die BBOX Spalte aktuell bleibt oder ein UPDATE nach jeder Änderung durchführen.

Folgende Einstellungen werden in der postgresql.conf konfiguriert:

constraint_exclusion

shared_buffers

max_worker_processes Diese Einstellung ist erst ab PostgreSQL 9.4+ verfügbar. Ab PostgreSQL 9.6+ hat diese Einstellung eine zusätzliche Bedeutung, da sie die maximale Anzahl von Prozessen bestimmt, die bei parallel ablaufenden Abfragen verwendet werden können.

work_mem (jener Arbeitsspeicher der für Sortieroperationen und komplexe Abfragen benutzt wird)

maintenance_work_mem (wird für VACUUM, CREATE INDEX, etc. genutzt)

max_parallel_workers_per_gather Diese Enstellung ist erst ab PostgreSQL 9.6+ verfügbar und wirkt sich erst ab PostGIS 2.3+ aus, da nur PostGIS 2.3+ parallel laufende Abfragen unterstützt. Wenn der Parameter auf einen höheren Wert als 0 gestellt wird können manche Abfragen, wie jene die Relationsfunktionen wie ST_Intersects verwenden, mehrere Prozesse benutzen und mehr als doppelt so schnell ablaufen. Falls Sie eine große Anzahl an Prozessoren zur Verfügung haben, sollten Sie diesen Wert auf die Anzahl der Prozessoren setzen. Stellen Sie bitte auch sicher die max_worker_processes auf zumindest die gleiche Anzahl zu erhöhen.