Felix Kunde

Every year, there's a new Postgres major release that improves on performance in certain areas and could provide new hooks for extensions like PostGIS to take advantage from them. If not planned well, upgrading your production databases can become a pain. Sooner than you think you'll be running on EOL (End-of-Life) versions because the upgrade has been postponed too many times. Don't! Did you know Postgres upgrades can be greatly automatized these days with downtimes of only a few seconds? This talk will show you how and will also present some essential features from recent Postgres and PostGIS versions to get you excited for the new upgrade.

None

Indexing OSM data in your PostGIS database for fast spatial queires is not as straight foreward as one migth hope. And with each release of PostgreSQL / PostGIS there are more options to try out. This talk will explain different spatial indexing concepts and best practices in PostGIS and present some benchmarking results.

When working with OpenStreetMap data in a database you learn pretty soon that you need to index the columns (and rows) which you use for filtering in order to have fast running queries. PostgreSQL offers a variety of these [table access methods](https://youtu.be/W6B8-srOsrs) but when it comes to its spatial extension PostGIS, developers could only use one for the geometry fields for years: The GiST index - an implementation of the [R-tree](https://en.wikipedia.org/wiki/R-tree) search tree concept. But during the last releases new methods were made available, namely BRIN and sp-GiST. Not many resources are yet available to figure out which index strategy to apply for which data processing or analytical workflows. Therefore, I created a simple [benchmark](https://github.com/FxKu/postgis_indexing) to find it out. So far, only for artifical data, but for this years StoM it is planned to extend the experiments to OSM datasets. This talk will explain the different characteristics of each spatial index and present some performance comparisons in terms of query speed, overhead on writes, index building time and index size. It will also cover general indexing best practices such as subdividing geometries, [partial indexing](https://wiki.openstreetmap.org/wiki/User:Species/PostGIS_Tuning#Indices) and introduce new concepts such as [covering indexes](https://info.crunchydata.com/blog/why-covering-indexes-are-incredibly-helpful).

Der Workshop richtet sich an alle, die ihre SQL-Kenntnisse erweitern wollen, um komplexe Analysen innerhalb der Datenbank durchzuführen.

Der Workshop wird mit PostreSQL 11 und PostGIS 2.5 durchgeführt. Es wird eine breits aufgesetzte Datenbank mit verschiedenen Testdaten geben (sollte OSGeo Live nicht ausreichen), anhand derer verschiedene SQL-Rezepte erklärt werden. Dazu zählen u.a.: - DISTINCT ON - Aggregate mit FILTER - Window Functions - Rekursive Abfrage - PL/pgSQL Programmierung Hier und da wird es auch Tipps zu folgenden Themen geben: - Indizierung - Performancefallen bei SQL - Abfrage Ausführungspläne - PostgreSQL-Konfiguration - Partitionierung

GIST, sp-GIST, BRIN oder BTREE - in PostgreSQL gibt es verschiedene Indextypen, die mittlerweile auch für PostGIS-Geometriespalten unterstützt werden. Der Vortrag wird kurz die wesentlichen Unterschiede vorstellen und anhand von einfachen Regressionstests mit künstlichen Geodaten aufzeigen, wann welcher Typ am Besten verwendet werden sollte.

Mittlerweile bietet PostGIS verschiedene Indexarten für Geometriespalten an: Den klassischen R-Baum, der auf dem GIST-Framework von PostgreSQL implementiert ist, den leichtgewichtigen Block-Range Index, kurz BRIN und seit PostGIS 2.5 den Kd-baum auf Basis des sp-GIST Framework. Selbst B-Baum-Indizierung ist möglich, aber wenig nützlich. Nun ist die Frage, welcher Indextyp am besten zu den eigenen Daten bzw. Use Case passt? Verschiedene Quellen bestehend aus der Doku, Vortragsfolien oder StackOverflow-Fragen geben mal mehr, mal weniger konkrete Hinweise. Dabei sollten eine paar einfache Regressionstests mit künstlich generierten Geodaten die Antwort liefern. Der Vortrag wird die Ergebnisse der Tests vorstellen und die Funktionsweise der Indizes kurz (mit bunten Bildern!) erläutern.

Was sind GPU-Datenbanken? Wie viel Geo steckt schon drin? Eine kurze Live-Demo mit OmniSci wirds euch zeigen.

GPU Datenbanken sind der neuste Schrei, da ihre Abfragegeschwindigkeiten die der andere Systeme deutlich schlagen (https://github.com/szilard/benchm-databases#results). Geometrische Algorithmen scheinen wie gemacht für diese Systeme und erste interaktive Dashboards begeistern durch ein neues Interaktionsgefühl zwischen Karte und Infografiken. Die momentanen Abfrage- und Darstellungsmöglichkeiten sind zwar noch stark begrenzt, aber eine kurze Live-Präsentation soll vermitteln, welches Potenzial GPU-unterstützte Datenbanken haben.

Es gibt so viele tolle Open-Source-Projekte im FOSS4G-Umfeld, von denen man als FOSSGIS-Besucher eventuell nichts mitbekommt. Entweder kommen die Kernentwickler nicht aus Deutschland oder sie setzen mal ein Jahr aus oder sie mögen einfach nicht vortragen etc.

GDAL, PDAL, PROJ, JTS, JSTS, GEOS, Shapely, GeoTools, OTB, Cesium, Leaflet, OpenLayers, Mapnik, OSMBuilding, Tangram, GeoPandas, Rasterio, pySAL, sf, stars, GRASS GIS, QGIS, gvSIG, OpenJump, SAGA, GeoDa, HALE, PostGIS, SpatiaLite, GeoPackage, RasDaMan, GeoRocket, Tile38, rbush, kdbush, flatbush, entwine, MapServer, GeoServer, deegree, QGIS Server, Greyhound, MapCache, GeoWebCache, OpenMapTiles, Tegola, T-Rex, MapBender, Oskari, GeoNode, GeoExt, GeoMoose, LizMap, QGIS Web Client, iTowns, VTS, Potree, Plas.io, Mago 3D, BIM Surfer, GeoNetwork, pyCSW, GeoMesa, GeoWave, GeoTrellis, GeoSpark OmniSci