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 Code Repository bezogen haben, müssen Sie zu allererst das Skript ausführen ./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
export PGUSER=postgres #overwrite psql variables
make check #to test before install
make install
# to test extensions
make check RUNTESTFLAGS=--extension

	make check uses psql to run tests and as such can use psql environment variables. Common ones useful to override are PGUSER,PGPORT, and PGHOST. Refer to psql environment variables

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         | 3.0.0         | 3.0.0
 address_standardizer_data_us | 3.0.0         | 3.0.0
 postgis                      | 3.0.0         | 3.0.0
 postgis_sfcgal               | 3.0.0         |
 postgis_tiger_geocoder       | 3.0.0         | 3.0.0
 postgis_topology             | 3.0.0         |
(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     | 3.0.0
Schema      | public
Description | PostGIS geometry, geography, and raster spat..
-[ RECORD 2 ]-------------------------------------------------
Name        | postgis_raster
Version     | 3.0.0dev
Schema      | public
Description | PostGIS raster types and functions
-[ RECORD 3 ]-------------------------------------------------
Name        | postgis_tiger_geocoder
Version     | 3.0.0
Schema      | tiger
Description | PostGIS tiger geocoder and reverse geocoder
-[ RECORD 4 ]-------------------------------------------------
Name        | postgis_topology
Version     | 3.0.0
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 3.0.0 ohne unser wunderbares Extension System installiert haben, können Sie auf erweiterungsbasiert wechseln, indem Sie folgende Befehle ausführen, welche die Funktionen in ihre entsprechenden Erweiterungen paketieren.

CREATE EXTENSION postgis FROM unpackaged;
CREATE EXTENSION postgis_raster 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://download.osgeo.org/postgis/source/postgis-3.0.0.tar.gz herunterladen

tar xvfz postgis-3.0.0.tar.gz

cd postgis-3.0.0/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.8, “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://download.osgeo.org/postgis/source/postgis-3.0.0.tar.gz herunterladen

tar xvfz postgis-3.0.0.tar.gz

cd postgis-3.0.0/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.9.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.11.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

HINWEIS: Wenn Sie von PostGIS 1. * zu PostGIS 2. * oder von PostGIS 2. * vor r7409 wechseln, können Sie diese Prozedur nicht verwenden, sondern müssen ein schweres Upgrade durchführen.

Nach der Kompilierung und Installation (make install) sollten Sie eine Reihe von *_upgrade.sql-Dateien in den Installationsordnern finden. Y Sie können sie alle auflisten mit:

ls `pg_config --sharedir`/contrib/postgis-3.0.0/*_upgrade.sql
                

Laden Sie sie alle nacheinander, beginnend mit postgis_upgrade.sql.

psql -f postgis_upgrade.sql -d your_spatial_database
                

Dieselbe Vorgangsweise kann auf die Erweiterungen "raster", "topology" und "sfcgal" angewendet werden. Die Dateien für das Upgrade heissen rtpostgis_upgrade.sql, topology_upgrade.sql und sfcgal_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

psql -f sfcgal_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 ??? sollte Sie mit der Meldung "procs need upgrade" darüber informieren, ob Sie diese Art von Upgrade durchführen müssen.

2.11.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 "3.0.0";
ALTER EXTENSION postgis_topology UPDATE TO "3.0.0";

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

No migration path defined for ... to 3.0.0

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

Falls Sie eine ähnliche Meldung wie folgt bekommen:

Version "3.0.0" 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 Entwicklungsversion 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 "3.0.0next";
ALTER EXTENSION postgis_topology UPDATE TO "3.0.0next";

	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.

	Wenn Sie die PostGIS-Erweiterung von einer Version vor 3.0.0 aktualisieren, erhalten Sie eine unverpackte PostGIS Raster-Unterstützung. Sie können die Raster-Unterstützung mit folgendem Befehl neu packen:     CREATE EXTENSION postgis_raster FROM unpackaged;      Danach, falls Sie es nicht brauchen, löschen Sie es mit: DROP EXTENSION postgis_raster;

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');

Das OGC Format unterstützt nur 2D-Geometrien, und die dazugehörige SRID ist *niemals* in den Eingabe/Ausgabe-Darstellungen eingebettet.

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:

Für die Konvertierung zwischen diesen Formaten stehen die folgenden Schnittstellen zur Verfügung:

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' )

Die "kanonische Form" eines PostgreSQL Datentyps ist jene Darstellung die man mit einer einfachen Abfrage (ohne Funktionsaufruf) erhält und bei der sichergestellt ist, dass sie von einem einfachen INSERT, UPDATE oder COPY angenommen wird. Beim geometrischen Datentyp von PostGIS sind dies:

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

Die Definitionen in SQL-MM schließen 3DM-, 3DZ- und 4D-Koordinaten ein, erlauben allerdings nicht das Einbinden von Information über SRID.

Die Erweiterungen zur Well-known-Text-Darstellung werden zur Zeit noch nicht zur Gänze unterstützt. Im Folgenden werden Beispiele für einige einfache gekrümmte Geometrien gezeigt:

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

Der geographische Datentyp unterstützt Geometrien, ausgenommen sind jedoch Kuven, TINS und POLYHEDRALSURFACEs. Daten vom geometrischen Datentyp, welche eine SRID von 4326 aufweisen, werden implizit in den geographischen Datentyp umgewandelt. Sie können Daten auch entsprechend der EWKT- und EWKB-Konvention einfügen.

Die Attribute des geographischen Datentyps werden in dem System View geography_columns registriert.

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

Sie können eine neue Tabelle mit einer geographischen Datentypspalte mit der Syntax von CREATE TABLE erstellen.

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

Beachten Sie bitte, dass die Spalte "location" den geographischen Datentyp verwendet und dieser zwei optionale Modifikatoren unterstützt: Einen Typmodifikator, der die geometrische Form und die Dimension der Geometriespalte festlegt; ein Modifikator für SRID, der den Identifikator für das Koordinatenreferenzsystem auf eine bestimmte Zahl einschränkt.

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.

Wenn Sie keine SRID angeben, dann wird standardmäßig die SRID 4326 WGS84 Länge/Breite verwendet und alle Berechnungen in WGS84 ausgeführt.

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:

-- Ein paar Daten in die Testtabelle einfügen
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.

-- Eine Distanzabfrage; Beachten Sie bitte, dass London ausserhalb der 1000km Toleranz liegt
  SELECT name FROM global_points WHERE ST_DWithin(location, 'SRID=4326;POINT(-110 29)'::geography, 1000000);

Sie können die Mächtigkeit von GEOGRAPHY erfahren, indem Sie berechnen, wie nahe ein Flugzeug, das von Seattle nach London (LINESTRING(-122.33 47.606, 0.0 51.5)) fliegt, an Reykjavik (POINT(-21.96 64.15)) vorbeikommt.

-- Die Entfernung mittels GEOGRAPHY ausrechnen (122.2km)
  SELECT ST_Distance('LINESTRING(-122.33 47.606, 0.0 51.5)'::geography, 'POINT(-21.96 64.15)':: geography);

-- Die Entfernung mittels GEOMETRIE ausrechnen (13.3 "degrees")
  SELECT ST_Distance('LINESTRING(-122.33 47.606, 0.0 51.5)'::geometry, 'POINT(-21.96 64.15)':: geometry);

Ausprobieren von verschiedenen Projektionen in Länge/Breie. Es ist jedes Koordinatenreferenzsystem in Länge und Breite zulässig, das in der Tabelle spatial_ref_sys aufgeführt ist.

-- NAD 83 in Länge und Breite
SELECT 'SRID=4269;POINT(-123 34)'::geography;
                    geography
----------------------------------------------------
 0101000020AD1000000000000000C05EC00000000000004140
(1 row)

-- NAD27  in Länge und Breite
SELECT 'SRID=4267;POINT(-123 34)'::geography;

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

-- NAD83 UTM Zone in Meter, resultiert in einem Fehler, da metrische Projektion
SELECT 'SRID=26910;POINT(-123 34)'::geography;

ERROR:  Nur Koordinatensysteme in Länge und Breite werden vom geographischen Datentyp unterstützt.
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.

Der geographische Datentyp speichert die Koordinaten in Form von Länge und Breite. Er hat allerdings den Nachteil, dass für den Datentyp GEOGRAPHY weniger Funktionen zur Verfügung stehen, als für den Datentyp GEOMETRY und diese auch mehr CPU-Zeit beanspruchen.

Welchen Datentyp Sie wählen, sollte aufgrund der zu erwartenden 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.

Obwohl in der PostGIS Tabelle "spatial_ref_sys" über 3000 der gebräuchlichsten Koordinatenreferenzsysteme definiert sind, die mit der Bibliothek "Proj4" gehandhabt werden können, enthält sie nicht alle bekannten Projektionen. Sie können auch ihre eigenen Projektionen in der Tabelle definieren, falls Sie mit den Konstrukten von "Proj4" vertraut sind. Sie sollten nicht außer Acht lassen, dass die meisten Koordinatenreferenzsysteme regional sind und außerhalb des vorgesehenen Bereichs keinen Sinn haben.

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 ist ein View der den Systemkatalog der Datenbank ausliest. Er hat folgende Struktur:

\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)  |

Die Spalten bedeuten:

Die Erzeugung einer Tabelle mit räumlichen Daten kann in einem Schritt ausgeführt werden. Dies wird im folgenden 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);

Zwei Fälle bei denen Sie dies benötigen könnten sind SQL-Views und Masseninserts. Beim Fall von Masseninserts können Sie die Registrierung in der Tabelle "geometry_columns" korrigieren, indem Sie auf die Spalte einen CONSTRAINT setzen oder ein "ALTER TABLE" durchführen. Falls Ihre Spalte Typmod basiert ist, geschieht die Registrierung beim Erstellungsprozess auf korrekte Weise, so dass Sie hier nichts tun müssen. Auch Views, bei denen keine räumliche Funktion auf die Geometrie angewendet wird, werden auf gleiche Weise wie die Geometrie der zugrunde liegenden Tabelle registriert.

-- Angenommen Sie erstellen folgenden View
CREATE VIEW  public.vwmytablemercator AS
        SELECT gid, ST_Transform(geom,3395) As geom, f_name
        FROM public.mytable;

-- Für eine korrekte Registrierung
-- wird eine Typumwandlung der Geometrie benötigt
--
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;

-- Wenn Sie sicher sind, das es sich bei der Geometrie um ein 2D-Polygon handelt, können Sie folgendes tun
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;

-- Angenommen Sie haben eine abgeleitete Tabelle über ein Masseninsert erzeugt
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);

-- Einen 2D Index auf die neue Tabelle legen
CREATE INDEX idx_myschema_myspecialpois_geom_gist
  ON myschema.my_special_pois USING gist(geom);

-- Falls Ihre Punkte 3D-Punkte oder 3M-Punkte sind,
-- können Sie einen ND-Index anstatt eines 2D-Indexes erstellen
CREATE INDEX my_special_pois_geom_gist_nd
        ON my_special_pois USING gist(geom gist_geometry_ops_nd);

-- Um die Geometriespalte der neuen Tabelle in geometry_columns händisch zu registrieren.
-- Beachten Sie bitte, dass dies auch die zugrundeliegende Struktur der Tabelle ändert,
-- um die Spalte Typmod basiert zu machen.
SELECT populate_geometry_columns('myschema.my_special_pois'::regclass);

-- Wenn Sie PostGIS 2.0 verwenden und aus welchem Grund auch immer
-- das alte Verhalten mit auf CONSTRAINTs basierender Definition benötigen
-- (wie im Fall von vererbten Tabellen bei denen nicht alle Kindtabellen denselben Datentyp und dieselbe SRID aufweisen),
-- setzen Sie das optionale Argument "use_typmod" auf 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 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 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, wenn sich keine zwei Koordinaten (POINTs) decken (keine identischen Koordinatenpaare aufweisen).

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 MULTIPOLYGONs. Hingegen ist (p) valid.

Die meisten von der GEOS Bibliothek implementierten Funktionen beruhen auf der Annahme, dass die verwendete Geometrie - entsprechend der OpenGIS Simple Feature Spezifikation - valide ist. Um die Simplizität und Validität einer Geometrie 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));

Falls Sie irgendwelche seltsamen Fehlermeldungen, wie "GEOS Intersection() threw an error!" erhalten, obwohl sie eine PostGIS Funktion mit validen Eingabegeometrien aufgerufen haben, ist es wahrscheinlich dass Sie einen Fehler in PostGIS oder einer von PostGIS verwendeten Bibliothek gefunden haben. In diesem Fall sollten Sie das PostGIS Entwicklerteam kontaktieren. Dasselbe gilt, wenn eine PostGIS Funktion auf eine valide Eingabegeometrie eine invalide Geometrie zurückgibt.

	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 einen Check-Constraint für die geometrische Dimension hinzu, weshalb es hier ausreicht 2 anzugeben.

Manchmal kommt es vor, dass die typischen räumlichen Aussagen (???, ???, ???, ???, ...) an sich nicht ausreichen, um den verlangten räumlichen Filter auf geeignete Weise zu liefern.

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 einer Unternehmensvorschrift widerspricht. In diesem Fall liefert ??? 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 (???) 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 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: ???(lake, wharf) = TRUE ???(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

Gemäß der OpenGIS Simple Features Implementation Specification for SQL, ist der grundlegende Ansatz für einen Lagevergleich von zwei geometrischen Objekten, die paarweise Überprüfung der Verschneidung des Inneren, der Begrenzung und des Äusseren der beiden geometrischen Objekte und der Einstufung der Beziehung zwischen den beiden geometrischen Objekten an Hand der Einträge in die resultierende 'Verschneidungs'-Matrix.

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

Wenn Sie Ihre Daten in eine Textdarstellung konvertieren können, dann ist möglicherweise die Verwendung von formatiertem SQL der leichteste Weg um die 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 zahlreiche 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. Für viele Anwender, die mit der Befehlszeile nicht versiert sind, oder mit PostGIS erst beginnen, ist die GUI möglicherweise einfacher zu bedienen. Sie kann auch in PgAdminIII als Plugin konfiguriert werden.

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

Die direkteste Methode, um Daten aus der Datenbank abzurufen, ist eine SQL Select-Anfrage. Dadurch kann die Anzahl der resultierenden Datensätze und Attribute reduziert und in eine lesbare Textdatei überspielt werden:

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 dieselbe SQL-Syntax verwenden wie bei jeder anderen Nicht-Geometrietabelle. Für räumliche Beschränkungen sind folgende Operatoren verfügbar/nützlich:

Außerdem können Sie diese Operatoren in Anfragen verwenden. Beachten Sie bitte, wenn Sie eine Geometrie oder eine Box auf der SQL-Befehlszeile eingeben, dass Sie die Zeichensatzdarstellung explizit in eine Geometrie umwandeln müssen. 312 ist ein fiktives Koordinatenreferenzsystem das zu unseren Daten passt. Also, zum Beispiel:

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.

Überprüfung ob einige der Strassen in die Polygonfläche hineinreichen:

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

Die häufigsten räumlichen Abfragen werden vermutlich in einem bestimmten Ausschnitt ausgeführt. Insbesondere von Client-Software, wie Datenbrowsern und Kartendiensten, die auf diese Weise die Daten für die Darstellung eines "Kartenausschnitts" erfassen.

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.

Die Abfrage zur Verwendung des "BOX3D" Objekts für einen solchen Ausschnitt sieht folgendermaßen aus:

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) ist eine generische Datenstruktur. Zusätzlich zur Indizierung von Geodaten wird GIST auch zur Beschleunigung von Abfragen auf unregelmäßige Datenstrukturen (Ganzzahl-Felder, Spektraldaten, etc.) verwendet, welche über gewöhnlicher B-Baum Indizierung nicht zugänglich sind.

Sobald eine Geodatentabelle einige 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 gelegt wird, lautet:

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

Die obere Syntax erzeugt immer einen 2D-Index. Um einen n-dimensionalen Index für den geometrischen Datentyp zu erhalten, können Sie die folgende Syntax verwenden:

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

Die Erstellung eines räumlichen Indizes ist eine rechenintensive Aufgabe. Während der Erstellung wird auch der Schreibzugriff auf die Tabelle blockiert. Bei produktiven Systemen empfiehlt sich daher die langsamere Option CONCURRENTLY:

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

Nachdem ein Index aufgebaut wurde sollte PostgreSQL gezwungen werden die Tabellenstatistik zu sammeln, da diese zur Optmierung der Auswertungspläne verwendet wird:

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] ); 

Die obere Syntax erzeugt einen 2D-Index. Um einen 3-dimensionalen Index zu erhalten, können Sie die folgende Syntax verwenden:

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

Sie können auch einen 4-dimensionalen Index über die 4D-Operatorklasse erstellen

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] ); 

Die obere Syntax erzeugt den 2D-Index für Geoobjekte 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 steht als Abkürzung für "Space-Partitioned Generalized Search Tree", ein generischer Indextyp der partitionierte Baumstrukturen, wie Quadtree, k-d Baum und Radix-Trie unterstützt. Diese Datenstrukturen haben die gemeinsame Eigenschaft, dass sie den Suchraum in mehrere Partitionen unterteilen, die unterschiedlich groß sein können. Zusätzlich zur Indizierung von Geodaten wird der SP-GIST Index zur Beschleunigung der Suche von vielen Datentypen verwendet, wie bei Telefon Routing, IP Routing, String-Matching-Algorithmen, etc.

So wie der GiST Index, ist auch der SP-GiST Index insofern nicht verlustfrei, da nur die umschreibenden Rechtecke der Geoobjekte gespeichert werden. Der SP-GiST Index kann als Alternative zum GiST Index gesehen werden. Die Performanztests zeigten, dass der SP-GiST Index insbesondere bei vielen überlappenden Objekten Vorteile haben, wie dies bei sogenannten "Spaghettidaten" der Fall ist.

Sobald eine Geodatentabelle einige tausend Zeilen überschreitet, kann es sinnvoll sein einen SP-GIST Index zu erzeugen, um die räumlichen Abfragen auf die Daten zu beschleunigen. Die Syntax zur Erstellung eines SP-GIST Index auf eine "Geometriespalte" lautet:

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

Die obere Syntax erzeugt einen 2D-Index. Ein 3-dimensionaler Index für den geometrischen Datentyp können Sie mit der 3D Operatorklasse erstellen:

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

Die Erstellung eines räumlichen Indizes ist eine rechenintensive Aufgabe. Während der Erstellung wird auch der Schreibzugriff auf die Tabelle blockiert. Bei produktiven Systemen empfiehlt sich daher die langsamere Option CONCURRENTLY:

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

Nachdem ein Index aufgebaut wurde sollte PostgreSQL gezwungen werden die Tabellenstatistik zu sammeln, da diese zur Optmierung der Auswertungspläne verwendet wird:

VACUUM ANALYZE [table_name] [(column_name)];

Ein SP-GiST Index kann Abfragen mit folgenden Operatoren beschleunigen:

kNN Suche wird zurzeit nicht unterstützt.

Üblicherweise beschleunigen Indizes den Datenzugriff: Sobald der Index aufgebaut ist, entscheidet der Anfrageoptimierer, ob der Index den Auswertungsplan bescheunigt. Unglücklicherweise optimiert der Anfrageoptimierer von PostgreSQL die Verwendung von GIST Indizes nicht sehr gut, so dass manchmal eine Suche, welche die Verwendung eines räumlichen Index bedingen sollte, über einen Full Table Scan ausgeführt wird.

Wenn Sie bemerken, dass Ihre räumlichen Indizes (oder Ihre Attributindizes) nicht verwendet werden, gibt es mehrere Möglichkeiten:

Wenn Sie eine Abfrage erstellen, müssen Sie beachten, dass nur die auf den umschreibenden Rechtecken 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

Diese Abfrage wählt die geometrischen Objekte der Tabelle "geom_table" aus, die weniger als 100 Einheiten von dem Punkt (100000, 200000) entfernt liegen. Sie ist sehr langsam, da die Entfernung zwischen jedem Punkt in der Tabelle und dem gegebenen Punkt berechnet werden muss, d.h. eine ST_Distance() Berechnung pro Tabellenzeile. Wir können dies vermeiden, indem wir die indexbeschleunigte Einstufenfunktion ST_DWithin verwenden und so die Anzahl der benötigten Entfernungsberechnungen verringern:

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

Diese Anfrage wählt dieselben geometrischen Objekte aus, allerdings auf effizientere Weise. Angenommen es existiert ein GIST Index auf der Spalte "the_geom" und der Anfrageoptimierer erkennt, dass der Index angewendet werden kann, um die Zeilenanzahl zu verringern, bevor das Ergebnis durch die Funktion ST_Distance() errechnet wird. Anmerkung: die Geometrie ST_MakeEnvelope, die vom Operator "&&" verwendet wird, ist ein Quadrat mit einer Seitenlänge von 200 Einheiten, dessen Mittelpunkt auf dem ursprünglichen Punkt liegt - dies ist unsere "Abfrage Box". Der Operator "&&" verwendet diesen Index, um die Ergebnismenge rasch auf die Geometrie zu reduzieren, deren Umgebungsrechtecke die "Abfrage Box" überlagern. Falls Unsere "Abfrage Box" wesentlich kleiner als die Gesamtausdehnung der gesamten Geometrietabelle ist, wird dadurch die Anzahl der Entfernungsberechnungen drastisch verringert- dies ist genau das, was wir wollen.

Die Beispiele in diesem Abschnitt verwenden zwei Tabellen, eine Tabelle mit linearen Straßen, 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 lautet:

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

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.