Skip to content

Postgis mit Daten von Openstreetmap

This content is not available in your language yet.

Postgis

Willkommen bei meinen PostGIS-Notizen! In diesem Text möchte ich Erfahrungen mit dir teilen, die ich beim Durcharbeiten des PostGIS-Workshops1 gesammelt habe. PostGIS ist eine leistungsstarke Erweiterung für PostgreSQL, die es ermöglicht, geografische Objekte und raumbezogene Daten zu speichern, zu verarbeiten und zu analysieren.

Räumliche Datenbanken (Spatial databases)

Eine räumliche Datenbank, wie PostGIS, ist eine besondere Art von Datenbank. Aber was ist so besonders daran?

Einfach ausgedrückt kann eine räumliche Datenbank Informationen über Orte und Formen speichern und bearbeiten. Stell dir vor, du hast eine normale Datenbank, die Namen und Adressen speichert. Eine räumliche Datenbank kann zusätzlich Dinge wie Punkte (zum Beispiel Orte auf einer Karte), Linien (wie Straßen) und Flächen (wie Parks) speichern.

Räumliche Datenbanken sind auch gut darin, diese Informationen schnell zu finden und zu bearbeiten. Sie haben spezielle Werkzeuge, um zu wissen, wo sich Dinge befinden und wie sie miteinander in Beziehung stehen. Das ist besonders nützlich, wenn man herausfinden will, wie weit zwei Orte voneinander entfernt sind oder welche POIs in einem bestimmten Gebiet liegen.

Räumliche Datenbanken erweitern normale Datenbanken, indem sie geografische Datentypen und Funktionen hinzufügen, ähnlich wie GeoJSON das JSON-Format um geografische Felder und Strukturen erweitert.

Installation

Postgresql, PostGis und Pgadmin habe ich beim Erforschen der Vector-Tiles installiert. Auf dieser Installation baue ich hier auf.

Arbeiten mit der Datenbank PostgreSQL

PostgreSQL hat eine Reihe von administrativen Front-Ends. Das wichtigste ist psql, ein Kommandozeilenwerkzeug zur Eingabe von SQL-Abfragen. Ein weiteres beliebtes PostgreSQL-Front-End ist das grafische Tool pgAdmin. Alle Abfragen, die in PgAdmin gemacht werden können, sind ebenfalls mit psql möglich. Zusätzlich beinhaltet Pgadmin einen Geometrie-Viewer, den man für die räumliche Ansicht von PostGIS-Abfragen benutzen kann.

Das Öffnen des Geometrie-Viewers ist über einen Button im Kopf der geom-Spalte möglich.

Link zum PgAdmin Geometrie-Viewer

Der Geometrie-Viewer wird in einem separten Tabulator angezeigt.

Ansicht des PgAdmin Geometrie-Viewers

Daten einlesen

Ich habe habe beim Experimentieren mit Tilekiln und Vector-Tiles Openstreetmap-Daten der spanischen Region Murcia in die Postgres-Datenbank eingelesen. Diese Daten nutze ich, für meine Lernschritte mit PostGis. Wer meinen Schritten folgen mag, kann das Einlesen im Abschnitt Tilekiln nachlesen.

Daten ansehen

Ein erster Überblick zeigt, dass für das Erstellen der Vector-Tiles 24 Tabellen angelegt wurden. Einige davon enthalten lediglich Einstellungen oder Metadaten. Beispielsweise beinhaltet die Tabelle external_data das Datum, an dem die externen Daten eingelesen wurden.

Für die OpenStreetMap-Daten ist jeweils die ID des OpenStreetMap-Objekts gespeichert. Außerdem gibt es Spalten mit den Namen point undgeom. Soweit ich verstanden habe, enthält diese Spalte die Informationen, mit denen PostGIS die Entitäten einem Punkt oder einer Fläche auf der Erde zuordnet.

Ansicht der Daten in PgAdmin

Einfache SQL-Abfragen

SQL, oder “Structured Query Language”, ist eine Sprache, mit der man Datenbanken Fragen stellen und die Daten darin ändern kann.

Allgemeine Abfragen

Ich beginne zur Orientierung mit einfachen SQL-Abfragen. Ich kann beispielsweise die PostGis-Version via SELECT postgis_full_version(); in PgAdmin abfragen. Dazu öffne ich zunächst das Query-Tool.

Pgadmin aufrufen

Wenn ich den SQL-Befehl im Query-Fenster eingegeben habe, kann ich ihn per Klick auf den Button mit dem kleinen Dreieck im oberen Bereich ausführen.

Einen einfachen Befehl ausführen

Das Gleiche ist per psql möglich.

Terminal window
$ sudo -u postgres psql spirit
[sudo] Passwort f\u00fcr astrid:
psql (14.11 (Ubuntu 14.11-0ubuntu0.22.04.1))
Type "help" for help.
postgres=# SELECT postgis_full_version();

Der Befehl SELECT postgis_full_version(); öffnet ein Fenster mit dem nachfolgenden Inhalt, welches man mit q wieder schließt.

Terminal window
postgis_full_version
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
POSTGIS="3.2.0 c3e3cc0" [EXTENSION] PGSQL="140" GEOS="3.10.2-CAPI-1.16.0" PROJ="8.2.1" LIBXML="2.9.12" LIBJSON="0.15" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)"
(1 row)

Daten-Abfragen

Nun frage ich Daten der Tabelle admin via SELECT relation_id, name FROM admin; ab. Ich vermute, dass es in dieser Tabelle um Verwaltungsgrenzen geht.

Als erstes sehe ich mir die Ausgabe in PgAdmin an.

Den Befehl SELECT relation_id, name FROM admin; ausführen

Danach rufe ich den Befehl über psql auf.

$ sudo -u postgres psql spirit
psql (14.11 (Ubuntu 14.11-0ubuntu0.22.04.1))
Type "help" for help.
spirit=# SELECT relation_id, name FROM admin;
relation_id | name
-------------+-----------------------------------------------------
340608 | Puerto Lumbreras
346913 | Lorca
345084 | Aledo
346019 | Totana
5922170 | Valdelentisco
345280 | Fuente \u00c1lamo de Murcia
344992 | Alhama de Murcia
344706 | Librilla
7231356 | La Catedral
4064893 | Pedan\u00eda de Carrascoy - La Murta
3734344 | Pedan\u00eda de Sangonera la Seca
3498276 | Pozo Los Palos
4060975 | Pedan\u00eda de Sangonera la Verde
4114423 | Pedan\u00eda de Puebla de Soto
3480086 | La Gu\u00eda
3729361 | Pedan\u00eda de Ca\u00f1ada Hermosa
4111686 | Pedan\u00eda de San Gin\u00e9s
4114424 | Pedan\u00eda de La Raya
4182783 | Pedan\u00eda de Rinc\u00f3n de Beniscornia
...

Das alles stimmig ist, kann man überprüfen. Ich öffne openstreetmap.org und suche nach Lorca. Ich möchte mich vergewissern, dass die ID der Relation relation_id genau wie in meiner Abfrage mit 346913 angegeben wird.

Per Openstreetmap.org überrüfen, dass alles stimmig ist.

Auf der ersten Seite ist die ID nicht zu finden. Um diese auszulesen, muss ich eine weitere Seite öffnen, die XML-Ansicht.

Die XML Ansicht.

Die kannst auch direkt die URL https://www.openstreetmap.org/relation/346913 öffenen und dich so davon überzeugen, dass die relation_id korrekt ist.

Es sind nicht alle Openstreetmap-Daten in meiner Spirit Datenbank. Wenn man die Daten in der Datenbank-Tabelle und die XML-Daten vergleicht, stellt man fest, dass beispielsweise die Population fehlt. Warum ist das so? Ich habe die Tabelle aus dem Vector-Tiles-Beispiel hier verwendet. In diese wurden die Daten per osm2psql[] eingelesen. Dabei wurden sie für die Erstellung der Vector-Tiles optimiert.

Daten filtern: Eine Where-Abfragen

Der Vollständigkeit halber teste ich eine SQL-Where-Abfrage. Ich sehe mir die Straßen an, die mit dem Tag bicycle = 'yes' versehen sind: Select way_id, name, bicycle from roads where bicycle = 'yes'.

Daten filtern: Eine Where-Abfragen

Außerdem treibt mich eine weitere Frage um. Ich habe weiter oben gesehen, dass die Population nicht in der admin-Tabelle enthalten ist. Wie wird nun die Größe von Städten für die Karte unterschieden? Ich forsche weiter und finde eine Lösung: Hierfür gibt es eine separte Tabelle mit dem Namen settlements. Die Tabelle gehört zum Stil Spirit: places.lua2

$ sudo -u postgres psql spirit
spirit=# Select * from settlements where place = 'city';
spirit=# Select name from settlements where place = 'city';
name
------------------
Lorca
Totana
Alcantarilla
Jumilla
Molina de Segura
Yecla
Murcia
Cartagena
(8 rows)

Spezielle Abfragen

Für das Positionieren der Städtenamen auf einer Karte ist es hilfreich zu wissen, wie viele Buchstaben die Worte enthalten. Wie hoch ist die durchschnittliche Anzahl der Buchstaben und die Standardabweichung der Anzahl der Buchstaben in den Namen aller Städte? Diese Frage beantwortet SELECT avg(char_length(name)), stddev(char_length(name)) FROM settlements WHERE place = 'city';.

$ sudo -u postgres psql spirit
spirit=# SELECT avg(char_length(name)), stddev(char_length(name)) FROM settlements WHERE place = 'city';
avg | stddev
--------------------+--------------------
8.2500000000000000 | 3.9188190640986293
(1 row)

Mit einem Schlag findet man die Werte für aller Orte (town, village, isolated_dwelling, city und hamlet) gruppiert nach Größe über SELECT place, avg(char_length(name)), stddev(char_length(name)) FROM settlements group by place;. Diese Unterscheidung ist relevant, wenn die unterschiedlichen Orte je nach Zoomstufen mit unterschiedlichen Stilen eingeblendet werden.

$ sudo -u postgres psql spirit
spirit=# SELECT place, avg(char_length(name)), stddev(char_length(name)) FROM settlements group by place;
place | avg | stddev
-------------------+---------------------+--------------------
town | 10.2142857142857143 | 5.3979223908431786
village | 9.9166666666666667 | 4.0664129507115095
isolated_dwelling | 13.0285714285714286 | 5.1031550535189519
city | 8.2500000000000000 | 3.9188190640986293
hamlet | 12.5388471177944862 | 4.9806529888320136
(5 rows)

Weitere SQL-Abfragen

In diesem Abschnitt teste ich weiter SQL-Abfragen. Ich wähle die Tabelle vegetation. Diese Tabelle enthält Informationen über verschiedene Vegetationstypen. Während ich diese Abfragen durchführe, rufe ich mir SQL-Funktionen zum

  • Daten filtern,
  • gruppieren und
  • aggregieren in Erinnerung.

Die Abfrage SELECT Count(*) FROM vegetation; zählt die Gesamtanzahl der Einträge (Zeilen) in der Tabelle vegetation.

Terminal window
$ sudo -u postgres psql spirit
spirit=# SELECT Count(*) FROM vegetation;
count
-------
6582
(1 row)
spirit=# exit
$

Die Abfrage SELECT name FROM vegetation WHERE name LIKE 'Parque%'; sucht in der Tabelle vegetation nach allen Einträgen, deren Wert in der Spalte name mit "Parque" beginnt.

Terminal window
$ sudo -u postgres psql spirit
spirit=# SELECT Count(*) FROM vegetation WHERE name LIKE 'Parque%';
count
-------
6
(1 row)
spirit=# SELECT name FROM vegetation WHERE name LIKE 'Parque%';
name
------------------------------------------------
Parque Regional Cabo Cope y Puntas de Calnegre
Parque Duque de Ahumada
Parque del Mar - Reyes de Espa\u00f1a
Parque La Noria
Parque de la Constituci\u00f3n
Parque de la Gimnasia
(6 rows)
spirit=# exit
$

Die nächste SQL-Abfrage berechnet für jede Vegetationsgruppe sowohl die Anzahl der Einträge als auch den entsprechenden Prozentwert der gesamten Einträge in der Tabelle vegetation.

Terminal window
$ sudo -u postgres psql spirit
spirit=# SELECT
vegetation,
COUNT(*) AS Anzahl,
(COUNT(*) * 100.0 / (SELECT COUNT(*) FROM vegetation)) AS Prozent
FROM
vegetation
GROUP BY
vegetation;
vegetation | anzahl | prozent
------------+--------+---------------------
heath | 565 | 8.5840170161045275
wood | 2009 | 30.5226374962017624
scrub | 2316 | 35.1868732907930720
grass | 1444 | 21.9386204800972349
wetland | 248 | 3.7678517168034032
(5 rows)
spirit=# exit
$

Das nächste Beispiel dient lediglich der Vollständigkeit halber. Das Ergebnis ist sinnfrei, da es nur dazu gedacht ist, die SUM-Funktion zu demonstrieren. Die Abfrage SELECT vegetation, SUM(area_id) FROM vegetation GROUP BY vegetation; summiert die Werte in der Spalte area_id für jede Gruppe von vegetation und gibt das Ergebnis zusammen mit der entsprechenden Vegetationsart zurück.

Terminal window
$ sudo -u postgres psql spirit
spirit=# SELECT vegetation,Sum(area_id) FROM vegetation GROUP BY vegetation;
vegetation | sum
------------+---------------
heath | 371415719751
wood | 1157821794024
scrub | 1774700014504
grass | 1024450175716
wetland | 224914669007
(5 rows)
spirit=# exit
$

Nun tauchen ich endlich in die Welt der geometrischen Abfragen ein, in der ich nicht nur Daten analysieren, sondern auch räumliche Beziehungen und Muster erkunde.

Geometrien

Einfache Formen anlegen

Im folgenden Beispiel, welches ich aus dem PostGIS-Workshops[] genommen haben, wird eine Tabelle namens geometries erstellt und anschließend werden fünf verschiedene Geometrien eingefügt: ein Punkt, eine Linie, ein Polygon, ein Polygon mit einem Loch und eine Sammlung/Collection.

Terminal window
$ sudo -u postgres psql spirit
CREATE TABLE geometries (name varchar, geom geometry);
INSERT INTO geometries VALUES
('Point', 'POINT(0 0)'),
('Linestring', 'LINESTRING(0 0, 1 1, 2 1, 2 2)'),
('Polygon', 'POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'),
('PolygonWithHole', 'POLYGON((0 0, 10 0, 10 10, 0 10, 0 0),(1 1, 1 2, 2 2, 2 1, 1 1))'),
('Collection', 'GEOMETRYCOLLECTION(POINT(2 0),POLYGON((0 0, 1 0, 1 1, 0 1, 0 0)))');
SELECT name, ST_AsText(geom) FROM geometries;
spirit=# exit
$

Spezielle Tabellen

Gemäß der Simple Features for SQL (SFSQL) Spezifikation beinhaltet PostGIS zwei spezielle Tabellen, um die verfügbaren Geometrietypen in einer Datenbank zu verfolgen und anzuzeigen.

  1. Die erste Tabelle, spatial_ref_sys, definiert alle räumlichen Bezugssysteme, die der Datenbank bekannt sind.

  2. Die zweite Tabelle geometry_columns, bietet eine Auflistung aller “Features” und die grundlegenden Details dieser Features.

Diese beiden Tabellen sind nützlich, um Informationen über die räumlichen Daten und deren Bezugssysteme in der Datenbank zu erhalten.

Ich sehe mir zuerst den Inhalt an.

SELECT * FROM spatial_ref_sys; zeigt mir:

Terminal window
srid | auth_name | auth_srid | srtext | proj4text
------+-----------+-----------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------
3819 | EPSG | 3819 | GEOGCS["HD1909",DATUM["Hungarian_Datum_1909",SPHEROID["Bessel 1841",6377397.155,299.1528128,AUTHORITY["EPSG","7004"]],TOWGS84[595.48,121.69,515.35,4.115,-2.9383,0.853,-3.408],AUTHORITY["EPSG","1024"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","3819"]] | +proj=longlat +ellps=bessel +towgs84=595.48,121.69,515.35,4.115,-2.9383,0.853,-3.408 +no_defs
3821 | EPSG | 3821 | GEOGCS["TWD67",DATUM["Taiwan_Datum_1967",SPHEROID["GRS 1967 Modified",6378160,298.25,AUTHORITY["EPSG","7050"]],AUTHORITY["EPSG","1025"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","3821"]] | +proj=longlat +ellps=aust_SA +no_defs
3824 | EPSG | 3824 | GEOGCS["TWD97",DATUM["Taiwan_Datum_1997",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","1026"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","3824"]] | +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
.....

SELECT * FROM geometry_columns; zeigt mir:

Terminal window
f_table_catalog | f_table_schema | f_table_name | f_geometry_column | coord_dimension | srid | type
-----------------+----------------+---------------------------+-------------------+-----------------+------+------------
spirit | public | geometries | geom | 2 | 0 | GEOMETRY
spirit | public | simplified_water_polygons | way | 2 | 3857 | POLYGON
spirit | public | water_polygons | way | 2 | 3857 | POLYGON
spirit | public | icesheet_polygons | way | 2 | 3857 | POLYGON
spirit | public | icesheet_outlines | way | 2 | 3857 | LINESTRING
.....

Das erscheint zunächst etwas kryptisch. Der PostGIS-Workshops verspricht später alles ausführlich zu erklären und Licht ins Dunkel zu bringen. Ein wenig verstehe ich schon: Die Tabellen stehen in Verbindung miteinander.

Die Tabellen geometry_columns und spatial_ref_sys ordnen den Tabellen mit den Openstreetmap Daten das korrekte Bezugssystem zu.

Die Tabellen geometry_columns und spatial_ref_sys stehen in der Tat in einer Verbindung zueinander.

Verbindung zwischen geometry_columns und spatial_ref_sys
  • geometry_columns: Diese Tabelle listet alle Geometriespalten auf, die in der Datenbank vorhanden sind. Jede Zeile in dieser Tabelle enthält eine SRID (Spatial Reference System Identifier), die angibt, welches Koordinatensystem für die Geometriespalte verwendet wird.

  • spatial_ref_sys: Diese Tabelle enthält die Definitionen der verschiedenen räumlichen Referenzsysteme. Jedes Referenzsystem hat eine eindeutige SRID, die auch in der geometry_columns-Tabelle verwendet wird.

Ein räumliches Referenzsystem (Spatial Reference System, SRS) ist ein Koordinatensystem, das zur eindeutigen Positionierung von geografischen Objekten auf der Erde verwendet wird. Es definiert, wie die dreidimensionale Erde auf eine zweidimensionale Karte projiziert wird und welche Maßeinheiten und Ursprünge verwendet werden, um geografische Positionen zu bestimmen.

Die SRID in der geometry_columns-Tabelle entspricht der SRID in der spatial_ref_sys-Tabelle. Diese Verbindung ermöglicht es, die genaue Definition des Koordinatensystems einer Geometriespalte zu finden.

Beispiel: In der obigen Abfrage gibt es eine Tabelle namens simplified_water_polygons mit einer Geometriespalte namens geom, die das Koordinatensystem mit der SRID 3857 verwendet.

  • In der Tabelle geometry_columns gibt es einen Eintrag für die Spalte geom von simplified_water_polygons mit der SRID 3857.
  • In der Tabelle spatial_ref_sys gibt es einen Eintrag mit der SRID 3857, der die genaue Definition des Koordinatensystems beschreibt. In unserm Fall WGS 84. Dies kann man überprüfen. Ich nutze den nachfolgenden Befehl.
Terminal window
SELECT * FROM spatial_ref_sys where srid='3857';

Die Ausgabe zeigt mir in der Spalte srtext WGS 84 an.

Terminal window
srid | auth_name | auth_srid | srtext | proj4text
------+-----------+-----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------
3857 | EPSG | 3857 | PROJCS["WGS 84 / Pseudo-Mercator",GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORI:
  • Die geometry_columns-Tabelle beschreibt, welche Tabellen und Spalten Geometrien enthalten und welches Koordinatensystem (SRID) sie verwenden.
  • Die spatial_ref_sys-Tabelle gibt die Details zu den verschiedenen SRIDs, also wie die Koordinatensysteme definiert sind.

Die Verbindung zwischen diesen Tabellen ermöglicht es, die Geometriespalten korrekt zu interpretieren und mit den richtigen Koordinatensystemen zu arbeiten.

Simple Features for SQL (SFSQL)

Die SFSQL-Spezifikation definiert, wie ein Objekt dargestellt wird. Das räumliche Referenzsystem lassen wir zunächst außen vor.

Unsere Beispieltabelle enthält eine Mischung verschiedener Geometrietypen. Wir können allgemeine Informationen über jedes Objekt sammeln, indem wir Funktionen verwenden, die die Geometriemeta-Daten lesen:

  • ST_GeometryType(geometry) gibt den Typ der Geometrie zurück.
  • ST_NDims(geometry) gibt die Anzahl der Dimensionen der Geometrie zurück.
  • ST_SRID(geometry) gibt die räumliche Referenzkennnummer der Geometrie zurück.
Terminal window
$ sudo -u postgres psql spirit
spirit=# SELECT name, ST_GeometryType(geom), ST_NDims(geom), ST_SRID(geom) FROM geometries;
name | st_geometrytype | st_ndims | st_srid
-----------------+-----------------------+----------+---------
Point | ST_Point | 2 | 0
Linestring | ST_LineString | 2 | 0
Polygon | ST_Polygon | 2 | 0
PolygonWithHole | ST_Polygon | 2 | 0
Collection | ST_GeometryCollection | 2 | 0
(5 rows)
spirit=# exit
$

Das nachfolgende Bild zeigt ein Polygon mit einem Loch.

Darstellung eines Polygon mit einem Loch.

Eine vollständige Auflistung aller Geometrien mit den zugehörigen Funktionen befindet sich im PostGIS-Workshops, genau unter geometries.

Geometrien ansehen

ST_Area

Die Funktion ST_Area in PostGIS wird verwendet, um die Fläche einer Geometrie zu berechnen.

Terminal window
spirit=# select ST_Area(geom) from vegetation where name = 'Piscina Municipal';
st_area
--------------------
8203.1115564035
2304.136539456862
4012.3882429022397
7741.811765911987
6237.029539381748
4934.330311485162
5343.122731485377
(7 rows)
Terminal window
spirit=# select sum(ST_Area(geom)) from vegetation where name = 'Piscina Municipal';
sum
-------------------
38775.93068702688
(1 row)
Terminal window
INSERT INTO geometries VALUES
('PolygonWithOutHole', 'POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))');
Terminal window
spirit=# select ST_Area(geom) from geometries where name = 'PolygonWithOutHole';
st_area
---------
100
(1 row)
spirit=# select ST_Area(geom) from geometries where name = 'PolygonWithHole';
st_area
---------
99
(1 row)

Räumliche Joins (Spatial Joins)

Räumliche Joins ermöglichen es, Informationen aus verschiedenen Tabellen zu kombinieren, indem räumliche Beziehungen als Verknüpfungsschlüssel verwendet werden. Vieles, was ich als “Standard-GIS-Analyse” betrachten, kann als räumlicher Join ausgedrückt werden.

Man kann räumliche Beziehungen mit einem zweistufigen Prozess untersucht: Zuerst kann man ein Restaurant extrahiert.

Terminal window
SELECT
ST_AsText(food.geom)
FROM food
WHERE food.name='The Condado Club';

Das Ergebnis ist:

Terminal window
MULTIPOLYGON(((-151095.16936810894 4540633.155692325,-151091.61827635262 4540618.814286588,-151087.77775392027 4540603.656610314,-151072.83867825582 4540607.428434849,-151063.82179950157 4540609.722492974,-151067.673453883 4540624.922400064,-151071.16888589392 4540639.010481889,-151095.16936810894 4540633.155692325)))

Dann kann man diesen Punkt/dieses Polygon verwendet, um weitere Fragen zu beantworten. Beispielsweise: “In welchem Bereich befindet sich das Restaurant?“.

Terminal window
spirit=# SELECT
landuse.name AS landuse_name
FROM landuse
WHERE ST_Intersects(
ST_AsText(landuse.geom),
'MULTIPOLYGON(((-151095.16936810894 4540633.155692325,-151091.61827635262 4540618.814286588,-151087.77775392027 4540603.656610314,-151072.83867825582 4540607.428434849,-151063.82179950157 4540609.722492974,-151067.673453883 4540624.922400064,-151071.16888589392 4540639.010481889,-151095.16936810894 4540633.155692325)))
'
);
landuse_name
-------------------
Condado de Alhama
(1 row)

Mit einem räumlichen Join können wir diese Frage in einem Schritt beantworten und Informationen über das Restaurant und das Stadtviertel, in dem es sich befindet, abrufen.

Terminal window
spirit=# SELECT
landuse.name AS landuse_name,
food.name AS food_name
FROM landuse
JOIN food
ON ST_Contains(landuse.geom, food.geom)
WHERE food.name = 'The Condado Club';
landuse_name | food_name
-------------------+------------------
Condado de Alhama | The Condado Club
(1 row)

Footnotes

  1. postgis.net/workshops/postgis-intro/

  2. github.com/pnorman/spirit/blob/main/themes/spirit/topics/places.lua

Imprint

Astrid Günther
Sonnenhang 23
56729 Kehrig
Germany
E-Mail: info At astrid-guenther.de

I am looking forward to your requests on the topics I describe here and will answer them as soon as possible!

Privacy

I do not collect or store any personal data via this website. In order to make it possible to call up this site, the internet provider stores some data in server log files which a browser automatically forwards: Browser type and browser version, operating system used, referrer URL, host name of the accessing computer, time of the server request, IP address. The basis for the data processing is Art. 6 (1) DSGVO, which allows the processing of data for the fulfilment of a contract or pre-contractual measures.