Chapter 3. Häufige Fragen zu PostGIS

3.1. Wo kann ich Lernprogramme, Anleitungen und Seminare für die Arbeit mit PostGIS finden?
3.2. Meine Anwendungen und Desktop-Tools funktionierten mit PostGIS 1.5, nicht jedoch mit PostGIS 2.0. Wie kann ich dies beheben?
3.3. Wenn ich OpenStreetMap-Daten mit »osm2pgsql« lade, bekomme ich eine Fehlermeldung: »operator class "gist_geometry_ops" does not exist for access method "gist" Error occurred.« In PostGIS 1.5 klappte das gut.
3.4. Ich führe PostgreSQL 9.0 aus und kann Geometrien nicht länger in OpenJump, Safe FME und einigen anderen Werkzeugen lesen/schreiben.
3.5. Ich habe versucht, meine Geometriespalte mit PgAdmin anzusehen, aber sie ist leer. Was ist los?
3.6. Welche Art geometrischer Objekte kann ich speichern?
3.7. Ich bin verwirrt. Welchen Datenspeicher soll ich verwenden, »geometry« oder »geography«?
3.8. Ich habe tiefergehende Fragen über »geography«, wie beispielsweise welche Größe einer geografischen Region kann ich in eine »geography«-Spalte stopfen und trotzdem noch vernünftige Antworten erhalten. Gibt es Beschränkungen wie Pole, etwas im Feld, das in eine Hemisphäre passen muss (wie bei SQL Server 2008), Geschwindigkeit etc.?
3.9. Wie füge ich ein GIS-Objekt in die Datenbank ein?
3.10. Wie erstelle ich eine räumliche Abfrage?
3.11. Wie kann ich räumliche Abfragen auf großen Tabellen beschleunigen?
3.12. Warum werden keine R-Baum-Indizes von PostgreSQL unterstützt?
3.13. Warum soll ich die Funktion AddGeometryColumn() und all das andere OpenGIS-Zeug verwenden?
3.14. Was ist der beste Weg, alle Objekte innerhalb eines Radius eines anderen Objekts zu finden?
3.15. Wie kann ich die Koordinaten-Rückprojektion als Teil einer Abfrage durchführen?
3.16. Ich führte ein ST_AsEWKT und ST_AsText auf meiner eher großen Geometrie aus und erhielt ein leeres Feld zurück. Was ist passiert?
3.17. ST_Intersects ergibt, dass sich meine beiden geometrischen Objekte nicht überschneiden, obwohl ICH WEISS, DASS SIE DIES TUN. Was ist passiert?
3.18. Ich veröffentliche Software, die PostGIS verwendet. Bedeutet das, dass meine Software wie PostGIS unter der GPL lizenziert werden muss? Muss ich all meinen Code veröffentlichen, falls ich PostGIS benutze?

3.1.

Wo kann ich Lernprogramme, Anleitungen und Seminare für die Arbeit mit PostGIS finden?

A step by step tutorial guide workshop Introduction to PostGIS. It includes packaged data as well as intro to working with OpenGeo Suite. It is probably the best tutorial on PostGIS.

Außerdem hat BostonGIS ein PostGIS almost idiot's guide on getting started. Dieser ist eher für Windows-Benutzer gedacht.

3.2.

Meine Anwendungen und Desktop-Tools funktionierten mit PostGIS 1.5, nicht jedoch mit PostGIS 2.0. Wie kann ich dies beheben?

Viele überholte Funktionen wurden aus der Codebasis von PostGIS 2.0 entfernt. Dies betraf Anwendungen sowie Werkzeuge von Drittanbietern wie Geoserver, MapServer, QGIS und OpenJump, um nur ein paar zu nennen. Es gibt mehrere Möglichkeiten dieses Problem zu lösen. Bei Anwendungen von Drittanbietern können Sie versuchen diese auf die neuste Version zu aktualisieren, bei der viele dieser Probleme bereits fixiert wurden. Ihren eigenen Code können Sie so ändern, dass er die überholten Funktionen nicht mehr benutzt. Die meisten dieser Funktionen sind Pseudonyme von ST_Union, ST_Length etc. ohne den Präfix "ST_". Als letzten Ausweg können Sie die gesamte legacy.sql oder die benötigten Teile davon ausführen.

Die Datei legacy.sql liegt im selben Verzeichnis wie »postgis.sql«. Sie können diese Datei nach der Installation von »postgis.sql« und »spatial_ref_sys.sql« installieren, um alle 200 alten Funktionen wieder herzustellen, die entfernt wurden.

3.3.

Wenn ich OpenStreetMap-Daten mit »osm2pgsql« lade, bekomme ich eine Fehlermeldung: »operator class "gist_geometry_ops" does not exist for access method "gist" Error occurred.« In PostGIS 1.5 klappte das gut.

In PostGIS 2 wurde die Standardgeometrieoperatorklasse »gist_geometry_ops« in »gist_geometry_ops_2d« geändert und »gist_geometry_ops« wurde vollständig entfernt. Grund ist, dass PostGIS auch räumliche Nd-Indizes für 3D-Unterstützung einführt und der alte Name als verwirrend und fehlerhaft angesehen wurde.

Einige ältere Anwendungen, die als Teil des Prozesses Tabellen und Indizes erstellen, referenzieren explizit den Operatorklassennamen. Dies ist nicht nötig, wenn Sie den Standard-2D-Index wollten. Falls Sie dies erreichen möchten, ändern Sie die Indexerstellung von:

SCHLECHT:

CREATE INDEX idx_my_table_geom ON my_table USING gist(geom gist_geometry_ops);

in GUT:

CREATE INDEX idx_my_table_geom ON my_table USING gist(geom);

Der einzige Fall, in dem Sie die Operatorklasse angeben müssen, ist, wenn Sie einen räumlichen 3D-Index wie folgt möchten:

CREATE INDEX idx_my_super3d_geom ON my_super3d USING gist(geom gist_geometry_ops_nd);

Falls Sie unglücklicherweise kompilierten Code, den Sie nicht mehr ändern können, am Hals haben und bei dem altes »gist_geometry_ops« hart codiert ist, können Sie die alte Klasse mittels des in PostGIS 2.0.2+ paketierten legacy_gist.sql erstellen. Falls Sie jedoch diese Fehlerbehebung verwenden, wird Ihnen dringend empfohlen, zu einem späteren Zeitpunkt den Index zu löschen und ihn ohne die Operatorklasse neu zu erstellen. Dies wird Ihnen in Zukunft Probleme ersparen, wenn Sie erneut ein Upgrade durchführen müssen.

3.4.

Ich führe PostgreSQL 9.0 aus und kann Geometrien nicht länger in OpenJump, Safe FME und einigen anderen Werkzeugen lesen/schreiben.

In PostgreSQL 9.0+ wurde die Standardcodierung für »bytea«-Daten in hexadezimal geändert und ältere JDBC-Treiber gehen immer noch vom Escape-Format aus. Dies beeinflusste einige Anwendungen wie Java-Programme, die ältere JDBC-Treiber benutzen oder .NET-Anwendungen, die ältere »npgsql«-Treiber verwenden, die das frühere Verhalten von ST_AsBinary erwarten. Es gibt zwei Herangehensweisen, dies wieder zum Laufen zu bringen.

Sie können Ihren JDBC-Treiber auf die neuste PostgreSQL-9.0-Version aktualisieren. Diese erhalten Sie unter http://jdbc.postgresql.org/download.html.

Falls Sie eine .NET-Anwendung ausführen, können Sie Npgsql 2.0.11 oder neuer verwenden. Dies können Sie von http://pgfoundry.org/frs/?group_id=1000140, wie im Blog-Eintrag von Francisco Figueiredo zur Veröffentlichung von NpgSQL 2.0.11 beschrieben, herunterladen.

Falls das Aktualisieren Ihres PostgreSQL-Treibers nicht in Frage kommt, können Sie die Voreinstellung mit der folgenden Änderung auf das vorherige Verhalten zurücksetzen:

ALTER DATABASE mypostgisdb SET bytea_output='escape';

3.5.

Ich habe versucht, meine Geometriespalte mit PgAdmin anzusehen, aber sie ist leer. Was ist los?

PgAdmin zeigt bei großen Geometrien nichts an. Was ist der beste Weg, um zu prüfen, ob sich in Ihren Geometriespalten Daten befinden?

-- Wenn alle Geometriefelder ausgefüllt sind, dann sollte diese Abfrage keine Datensätze zurückgeben 
SELECT somefield FROM mytable WHERE geom IS NULL;
-- Um lediglich die Größe einer Geometrie festzustellen, können Sie eine Abfrage in der folgenden Form ausführen.
-- Sie wird Ihnen die Höchstzahl von Punkten mitteilen, die Sie in Ihren Geometriespalten haben.
SELECT MAX(ST_NPoints(geom)) FROM sometable;

3.6.

Welche Art geometrischer Objekte kann ich speichern?

Sie können Punkte, Linien, Polygone, Objekte aus mehreren Punkten, Linien und Polygonen, sowie Geometriesammlungen speichern. In PostGIS 2.0 und höher können Sie auch TINs und Polyederoberflächen im Basistyp »geometry« speichern. Diese werden im »Well-known Text«-Open-GIS-Textformat (mit XYZ-, XYM- und XYZM-Erweiterungen) angegeben. Derzeit werden drei Datentypen unterstützt: Der Standard-OGC-Datentyp »geometry«, der für die Messung ein flaches Koordinatensystem verwendet, der Datentyp »geography«, der ein geodätisches Koordinatensystem benutzt (nicht OGC, aber Sie finden einen ähnlichen Typ in Microsoft SQL Server 2008+). Nur WGS 84 long lat (SRID:4326) wird vom Datentyp »geography« unterstützt. Das neuste Familienmitglied der räumlichen PostGIS-Typenfamilie ist »raster« zum Speichern und Analysieren von Rasterdaten. »raster« hat seine eigene FAQ. Weitere Einzelheiten finden Sie unter Chapter 10, Häufige Fragen zu PostGIS Raster und Chapter 9, Referenz Raster.

3.7.

Ich bin verwirrt. Welchen Datenspeicher soll ich verwenden, »geometry« oder »geography«?

Kurze Antwort: »geography« ist ein neuer Datentyp, der Distanzmessungen über weite Bereiche hinweg unterstützt; allerdings sind die meisten Berechnungen damit derzeit langsamer als bei »geometry«. Wenn Sie den Datentyp »geography« benutzen, dann müssen Sie nicht viel über ebene Koordinatenreferenzsysteme lernen. Der Datentyp »geography« ist im Allgemeinen dann am besten geeignet, wenn Sie weltweite Daten haben und Sie nur am Messen von Entfernungen und Längen interessiert sind. Der Datentyp »geometry« ist ein alter Datentyp, der von wesentlich mehr Funktionen unterstützt wird, der eine größere Unterstützung von Werkzeugen Dritter genießt und mit dem Transaktionen generell schneller sind; bei einer großen Geometrie manchmal bis zum Zehnfachen schneller. Der Datentyp »geometry« ist die beste Wahl, wenn Sie sich in räumlichen Bezugssystemen sicher fühlen oder Sie mit lokalen Daten arbeiten, bei denen alle Ihre Daten in ein einziges räumliches Bezugssystem (spatial reference system/SRID) passen oder falls Sie eine große Menge räumlicher Daten verarbeiten wollen. Hinweis: Es ist ziemlich einfach, einmalige Umwandlungen zwischen den zwei Typen vorzunehmen, um von den Vorteilen beider zu profitieren. Was derzeit unterstützt wird und was nicht, erfahren Sie unter Section 14.11, “PostGIS Function Support Matrix”.

Lange Antwort: Eine ausführlichere Erörterung finden Sie unter Section 4.2.2, “Wann sollte man den geographischen Datentyp dem geometrischen Datentyp vorziehen” und function type matrix.

3.8.

Ich habe tiefergehende Fragen über »geography«, wie beispielsweise welche Größe einer geografischen Region kann ich in eine »geography«-Spalte stopfen und trotzdem noch vernünftige Antworten erhalten. Gibt es Beschränkungen wie Pole, etwas im Feld, das in eine Hemisphäre passen muss (wie bei SQL Server 2008), Geschwindigkeit etc.?

Ihre Fragen sind zu tiefgehend und komplex, um in diesem Abschnitt angemessen beantwortet werden zu können. Bitte lesen Sie unsere Section 4.2.3, “Fortgeschrittene FAQ's zum geographischen Datentyp”.

3.9.

Wie füge ich ein GIS-Objekt in die Datenbank ein?

Zuerst müssen Sie eine Tabelle mit einer Spalte des Typs »geometry« oder »geography« erstellen, die Ihre GIS-Daten bereithält. Das Speichern des Datentyps »geography« unterscheidet sich etwas vom Speichern des Datentyps »geometry«. Einzelheiten über das Speichern von »geography« finden Sie unter Section 4.2.1, “Grundsätzliches zum geographischen Datentyp”.

Für »geometry«: Verbinden Sie Ihre Datenbank mit psql und probieren Sie folgenden SQL-Befehl:

CREATE TABLE gtest (id serial primary key, name varchar(20), geom geometry(LINESTRING));

Falls die Definition der Spalte »geometry« fehlschlägt, haben Sie wahrscheinlich die PostGIS-Funktionen und -Objekte nicht in Ihre Datenbank geladen oder Sie verwenden eine Version von PostGIS vor 2.0. Siehe Section 2.5, “Kompilierung und Installation des Quellcodes: Detaillierte Beschreibung”.

Dann können Sie mittels eines SQL-INSERT-Befehls eine Geometrie in Ihre Tabelle einfügen. Das GIS-Objekt selbst ist mit dem Format »well-known-text« des OpenGIS-Konsortiums formatiert:

INSERT INTO gtest (ID, NAME, GEOM)
VALUES (
  1,
  'First Geometry',
  ST_GeomFromText('LINESTRING(2 3,4 5,6 5,7 8)')
);

Mehr Informationen über weitere GIS-Objekte finden Sie in der Objektreferenz.

So sehen Sie sich Ihre GIS-Daten in der Tabelle an:

SELECT id, name, ST_AsText(geom) AS geom FROM gtest;

Der Rückgabewert sollte etwa so aussehen:

id | name           | geom
----+----------------+-----------------------------
  1 | First Geometry | LINESTRING(2 3,4 5,6 5,7 8)
(1 row)

3.10.

Wie erstelle ich eine räumliche Abfrage?

Auf die gleiche Weise, wie alle anderen Datenbankabfragen erstellt werden, als Kombination von Rückgabewerten, Funktionen und booleschen Tests.

Es gibt bei räumlichen Abfragen zwei Aspekte, die Sie beim Erstellen Ihrer Abfrage im Hinterkopf behalten sollten: Es gibt einen räumlichen Index, von dem Sie Gebrauch machen können, und führen Sie aufwendige Berechnungen auf einer großen Zahl von Geometrien durch?

Im Allgemeinen werden Sie den »Überschneidungsoperator« (&&) benutzen wollen, der prüft, ob sich die Hüllquader der Objekte überschneiden. Der Hauptnutzen des &&-Operators besteht darin, dass er, falls ein räumlicher Index zum Beschleunigen des Tests verfügbar ist, Gebrauch davon macht. Dies kann Abfragen sehr stark beschleunigen.

Sie werden auch von räumlichen Funktionen wie Distance(), ST_Intersects(), ST_Contains() und ST_Within() Gebrauch machen, um die Ergebnisse Ihrer Suche einzugrenzen. Die meisten räumlichen Abfragen enthalten sowohl einen indizierten als auch einen räumlichen Funktionstest. Der Indextest begrenzt die Auswahl von Tupeln auf nur diejenigen Tupel, die die Bedingung, die von Interesse ist, treffen könnten. Die räumlichen Funktionen werden dann verwendet, um die Bedingung genau zu prüfen.

SELECT id, the_geom
FROM thetable
WHERE
  ST_Contains(the_geom,'POLYGON((0 0, 0 10, 10 10, 10 0, 0 0))');

3.11.

Wie kann ich räumliche Abfragen auf großen Tabellen beschleunigen?

Schnelle Abfragen großer Tabellen sind die Daseinsberechtigung räumlicher Datenbanken (neben der Unterstützung von Transaktionen). Daher ist es wichtig, über einen guten Index zu verfügen.

Um einen räumlichen Index für eine Tablle mit einer geometry-Spalte zu erstellen, benutzen Sie die Funktion »CREATE INDEX« wie folgt:

CREATE INDEX [indexname] ON [tabellenname] USING GIST ( [geometry_spalte] );

Die Option »USING GIST« teilt dem Server mit, dass er einen GiST-Index (Generalized Search Tree/Verallgemeinerter Suchbaum) verwenden soll.

[Note]

Es wird von GiST-Indizes angenommen, dass sie verlustbehaftet sind. Verlustbehaftete Indizes verwenden ein Ersatzobjekt (im Fall räumlicher Objekte einen Hüllquader), um einen Index zu erstellen.

Sie sollten außerdem sicherstellen, dass das PostgreSQL-Abfrageplanungsprogramm ausreichende Informationen über Ihren Index hat, um vernünftige Entscheidungen treffen zu können, wann er benutzt wird. Zu diesem Zweck müssen Sie für Ihre Geometrietabellen »Statistiken erstellen«.

Unter PostgeSQL 8.0.x und neuer führen Sie einfach den Befehl VACUUM ANALYZE aus.

Unter PostgreSQL 7.4.x und älter führen Sie den Befehl SELECT UPDATE_GEOMETRY_STATS() aus.

3.12.

Warum werden keine R-Baum-Indizes von PostgreSQL unterstützt?

Ältere Versionen von PostGIS verwendeten die PostgreSQL-R-Baum-Indizes. PostgreSQL-R-Bäume wurden jedoch seit Version 0.6 komplett ausrangiert und räumliche Indizierung wird mit dem Schema »R-Tree-over-GiST« bereitgestellt.

Unsere Tests haben gezeigt, dass die Suchgeschwindigkeit für native R-Bäume und GiST vergleichbar ist. Native PostgreSQL-R-Bäume haben zwei Einschränkungen, wegen der sie für den Gebrauch mit GIS-Objekten unerwünscht sind (beachten Sie, dass diese Einschränkungen aufgrund der Implementierung nativer PostgreSQL-R-Bäume und nicht wegen des Konzepts der R-Bäume im Allgemeinen bestehen):

  • R-Baum-Indizes können in PostgreSQL nicht mit Objekten umgehen, die größer als 8k sind. GiST-Indizes können dies mittels des »verlustbehafteten« Tricks, das Objekt selbst durch seinen Hüllquader zu ersetzen.

  • R-Baum-Indizes sind in PostgreSQL nicht »nullsicher«, daher wird das Bilden eines Index auf einer »geometry«-Spalte, die Null-Geometrien enthält, scheitern.

3.13.

Warum soll ich die Funktion AddGeometryColumn() und all das andere OpenGIS-Zeug verwenden?

Falls Sie keine OpenGIS-Hilfsfunktionen nutzen möchten, müssen Sie dies nicht. Erstellen Sie einfach Ihre Tabellen in älteren Versionen, indem Sie Ihre »geometry«-Spalten im CREATE-Befehl erstellen. Alle Ihre Geometrien werden SRIDs von -1 haben und die OpenGIS-Metadatentabellen werden nicht ordentlich gefüllt. Dies wird jedoch die meistenAnwendungen, die auf PostGIS basieren, zum Abstürzen bringen und es wird generell empfohlen, dass Sie zum Erstellen von »geometry«-Tabellen AddGeometryColumn() verwenden.

MapServer ist eine dieser Anwendungen, die Gebrauch von geometry_columns-Metadaten machen. Insbesondere kann MapServer die SRID der »geometry«-Spalte nutzen, um direkt eine Rückprojektion von Objekten in die korrekte Abbildungsprojektion vorzunehmen.

3.14.

Was ist der beste Weg, alle Objekte innerhalb eines Radius eines anderen Objekts zu finden?

Um die Datenbank möglichst effizient zu nutzen, ist es am besten Radiusabfragen zu verwenden. Diese kombinieren den Radiustest mit einem Hüllquadertest: Der Hüllquadertest benutzt den räumlichen Index, der schnellen Zugriff auf eine Untermenge von Daten gewährt, auf die dann der Radiustest angewendet wird.

Die Funktion ST_DWithin(geometry, geometry, distance) ist eine praktische Art, eine Entfernungssuche per Index durchzuführen. Dazu wird ein Suchrechteck erstellt, das groß genug ist, um den Entfernungsradius einzuschließen. Dann wird in der indizitierten Untermenge der Ergebnisse die genaue Entfernung gesucht.

Um zum Beispiel alle Objekte mit 100 Metern Entfernung zu POINT(1000 1000) zu finden, wäre die folgende Abfrage gut geeignet:

SELECT * FROM geotable
WHERE ST_DWithin(geocolumn, 'POINT(1000 1000)', 100.0);

3.15.

Wie kann ich die Koordinaten-Rückprojektion als Teil einer Abfrage durchführen?

Um eine Rückprojektion durchzuführen, müssen sowohl die Quell- als auch die Zielkoordinatensysteme in einer SPATIAL_REF_SYS-Tabelle definiert sein und und die SRIDs der Geometrien, die rückprojiziert werden, müssen bereits gesetzt sein. Sobald dies erledigt ist, ist die Rückprojektion so einfach wie Bezug auf die gewünschte Ziel-SRID zu nehmen. Nachfolgend wird eine Geometrie auf »NAD 83 long lat« projiziert. Das Folgende funktioniert nur, falls die SRID der Geometrie nicht -1 ist (keine undefinierte räumliche Referenz).

SELECT ST_Transform(die_geometrie,4269) FROM geometrietabelle;

3.16.

Ich führte ein ST_AsEWKT und ST_AsText auf meiner eher großen Geometrie aus und erhielt ein leeres Feld zurück. Was ist passiert?

Sie verwenden vermutlich PgAdmin oder irgendein anderes Werkzeug, das keine großen Texte ausgibt. Falls Ihre Geometrie groß genug ist, wird sie in diesen Werkzeugen leer erscheinen. Falls Sie sie wirklich sehen oder in WKT ausgeben möchten, verwenden Sie PSQL.

--zum Prüfen, ob die Anzahl der Geometrien wirklich leer ist
                                SELECT count(gid) FROM geotable WHERE the_geom IS NULL;

3.17.

ST_Intersects ergibt, dass sich meine beiden geometrischen Objekte nicht überschneiden, obwohl ICH WEISS, DASS SIE DIES TUN. Was ist passiert?

Im Allgemeinen kommt das in zwei Fällen vor. Ihre Geometrie ist ungültig – prüfen Sie dies mit ST_IsValid oder Sie gehen davon aus, dass sie sich überschneiden, da ST_AsText die Zahlen rundet und Sie viele Dezimalstellen dahinter haben, die Ihnen nicht angezeigt werden.

3.18.

Ich veröffentliche Software, die PostGIS verwendet. Bedeutet das, dass meine Software wie PostGIS unter der GPL lizenziert werden muss? Muss ich all meinen Code veröffentlichen, falls ich PostGIS benutze?

Höchstwahrscheinlich nicht. Oracle-Datenbanken laufen zum Beispiel unter Linux. Linux steht unter der GPL, Oracles Datenbank nicht. Muss Oracles Datenbank, die unter Linux läuft, unter der GPL verteilt werden? Nein. In ähnlicher Weise kann Ihre Software die PostgreSQL/PostGIS Datenbank soviel nutzen wie sie will, und kann unter irgendeiner, von Ihnen gewünschten Lizenz vorliegen.

Die einzige Ausnahme wäre, wenn Sie Veränderungen am PostGIS-Quellcode vorgenommen hätten und die veränderte Version verteilen würden. In diesem Fall müssten Sie den Code Ihres veränderten PostGIS freigeben (aber nicht den Code von Anwendungen, die darauf laufen). Sogar in diesem begrenzten Fall müssten Sie nur den Quellcode an Leute verteilen, denen Sie Binärcode weitergegeben haben. Die GPL verlangt nicht, dass Sie Ihren Quellcode veröffentlichen, nur dass Sie ihn mit Leuten teilen, denen Sie Binärcode geben.

Die oberen Angaben treffen auch zu, wenn Sie PostGIS in Verbindung mit den optionalen CGAL-aktivierten Funktionen nutzen. Teile von CGAL liegen unter GPL vor, so wie bereits das gesamte PostGIS: die Verwendung von CGAL macht PostGIS nicht mehr GPL als es bereits von vornherein ist.