Etienne Trimaille (@etrimaille) von 3Liz hat auf der diesjährigen FOSS4G 2021 in Buenos Aires einen interessanten Beitrag “How to use OSM data in QGIS?” [2] zur Nutzung von OSM-Daten im QGIS gehalten. Die ganze Palette wird abgedeckt, Datenmodell, Plugins, HStore, Quellen, Abfragen, Vektor, Raster, Datenbank, Docker, Overpass, Tiles, Geocoding, Routing, … Eine wunderbare Zusammenfassung des aktuellen Status, das Lesen lohnt sich unbedingt, die Folien sind unter [2] verfügbar

[1] … https://twitter.com/etrimaille
[2] … https://docs.3liz.org/presentations/2021-09-foss4g-osm-in-qgis.html
[3] … https://twitter.com/cartocalypse/status/1448376965866704903?s=20

Vor genau fünf Jahren und zwei Tagen habe ich hier das Visual vocabulary der Financial Times thematisiert [1]. Ja, fünf Jahre, Grund genug, mal wieder nach einem Update zu schauen. Und wie erwartet, vieles ist natürlich gleich geblieben und weiterhin genauso aktuell, aber einige Änderungen gab es schon, zuletzt 2019. Es lohnt sich, mal wieder die Datenvisualisierung (#DataViz) für sich selbst zu entdecken oder ein eigenes Update zu machen.

Der Tipp kam von Albrecht Elstermann, Danke!

[1] … https://geoobserver.de/2016/10/11/dataviz-visual-vocabulary/
[2] … https://github.com/Financial-Times/chart-doctor/blob/main/visual-vocabulary/Visual-vocabulary.pdf

Christian Reinboth (alias @reinboth) hat gestern auf Twitter [1] mitgeteilt, dass die erste Version seiner offenen Dorf- und Hofladenkarte für Sachsen-Anhalt basierend auf den freien OSM-Geodaten in einer umap-Karte zur Verfügung steht. Ich habe es gleich mal ausprobiert, klappt prima! Die Daten (siehe auch [3]) könnt Ihr Euch für das eigene (Q)GIS auch aus der umap-Anwendung downloaden, ich hab’s gemacht, als GeoJSON-Datei und im QGIS eingelesen. Die Daten sind natürlich offen und frei verwendbar und können gern aktualisiert werden.
Danke Christian!

[1] … https://twitter.com/reinboth/status/1447560385654136835?s=20
[2] … https://umap.openstreetmap.de/de/map/dorf-und-hofladen-in-sachsen-anhalt_18372#7/52.009/14.414
[3] … https://twitter.com/reinboth/status/1444984010988560387?s=20

Neulich am Helpdesk: “Wir wollen Blattschnitte als Polygone anzeigen, haben aber nur Punktkoordinaten (Linke untere Ecke oder den Mittelpunkt). Früher haben wir uns da ein GeoJSON generiert und ins QGIS importiert, geht’s vielleicht auch einfacher?” Ja, geht. Da hatte ich doch kürzlich einen Tweet von Ujaval Gandhi [1] gelesen, dort ging es um die Funktion ‘Geometry by Expression’, in der deutschen Version ‘Geometrie nach Ausdruck’ in der QGIS Processing Toolbox. Gesucht, gefunden und ausprobiert. Funktioniert, Danke, guter Tipp!

Mein adaptierter Test-Code: X/Y-Koordinaten aus der aktuellen Punktgeometrie (z. B. x($geometry) geholt und damit die Rechtecke als Polygon mit 50m Breite und 50m Höhe berechnet:

make_polygon(
   make_line(
      make_point(x($geometry), y($geometry)),
      make_point(x($geometry)+50, y($geometry)),
      make_point(x($geometry)+50, y($geometry)+50),
      make_point(x($geometry), y($geometry)+50),
      make_point(x($geometry), y($geometry))
   )
)

[1] … https://twitter.com/spatialthoughts/status/1442905558521053184?s=20

Wer schon immer mal die eigene PostgreSQL-Datenbank mit QGIS verwalten wollte, sollte sich mal in Ryan Hansons Beitrag “Managing a PostgreSQL Database with QGIS” [1] einlesen. Einige Basics und Tools wie der QGIS-eigene DB-Manager sowie pgAdmin werden vorgestellt. Die grundlegenden Einführung umfasst neben Schemas und Tabellen natürlich auch Authentifizierung und Verbindungsoptionen. Lesenswert für Einsteiger.. Danke Ryan!

[1] … https://www.hansongis.com/blog/managing-a-postgresql-database-with-qgis
[2] … https://twitter.com/GeoNe_ws/status/1445051847492915205?s=20

Eines der Top-Probleme der Klimakrise ist die Überhitzung der Städte. Wo heizen sich deutsche Städte besonders auf, wo bleibt es relativ kühl? Einen bemerkenswerten Beitrag dazu fand ich im Tweet von Steffen Kühne (alias @stekhn) [1], welcher auf den Artikel “In der Hitze der Stadt” von BR24 [2] verweist. Interessante Fakten und Erklärungen, am Ende eine interaktive Karte für ganz Deutschland.

[1] … https://twitter.com/stekhn/status/1439995135480287244?s=20
[2] … https://interaktiv.br.de/urbane-hitzeinseln/
[3] … https://www.openstreetmap.org/#map=14/51.4041/12.4419

Auch in diesem Jahr hat Topi Tjukanov zur #30DayMapChallenge aufgerufen [1], [2], genau wie im letzten Jahr [3], [4]. Jeden einzelnen Tag im November ein Karten-Thema, Start ist der 1.11.1021. Ich gebe den Aufruf hier gern weiter und fordere Euch auf, mitzumachen. Erweitert Euern und unseren “Map-Horizont”!

Zur #30DayMapChallenge schreibt Topi auf GitHub [2]

“Tägliches soziales Mapping-Projekt im November 2021
Das offizielle Repository für die #30DayMapChallenge, eine tägliche Mapping-/Kartografie-/Datenvisualisierungs-Challenge, die sich an die räumliche Gemeinschaft richtet.
Die Idee ist, an jedem Tag des Monats unter dem Hashtag #30DayMapChallenge Karten zu verschiedenen Themen zu erstellen (und zu veröffentlichen). Sie können die Karten im Voraus vorbereiten, aber die Hauptidee ist, Karten zu bestimmten Themen an bestimmten Tagen zu veröffentlichen, die unten aufgeführt sind. Fügen Sie einfach ein Bild der Karte hinzu, wenn Sie auf Twitter mit dem Hashtag posten. Sie müssen sich nirgendwo anmelden, um teilzunehmen. Es gibt keine Einschränkungen in Bezug auf die Tools, Technologien oder die Daten, die Sie in Ihren Karten verwenden. Es ist auch in Ordnung, weniger als 30 Karten zu erstellen (alle 30 zu erstellen ist wirklich schwer!). Siehe den Verhaltenskodex am Ende der Seite.” (Übersetzt mit www.DeepL.com/Translator (kostenlose Version))

[1] … https://twitter.com/tjukanov/status/1443868144905428992?s=20
[2] … https://github.com/tjukanovt/30DayMapChallenge
[3] … https://geoobserver.de/2020/11/06/taglich-soziales-kartierungsprojekt-30daymapchallenge/
[4] … https://github.com/tjukanovt/30DayMapChallenge/tree/master/archive/2020

Wie immer ist der OSM-Datenbestand besonders aktuell, das kann man auch mal wieder auf La Palma beim aktuellen Vulkanausbruch und den resultierenden Lavaströmen [1] sehen. Angepingt durch einen Tweet von Barry Rowlingson [2] wollte ich es auch mal selbst probieren, mit Overpass-Turbo [3]. Wie sich die Lava weiter ihren Weg sucht, zeigt folgender Tweet [4].

Hier die Overpass-Turbo-Abfrage mit dem Wizard erstellt:

/*
This has been generated by the overpass-turbo wizard.
The original search was:
“geological=volcanic_lava_field”
*/
[out:json][timeout:25];
// gather results
(
// query part for: “geological=volcanic_lava_field”
node"geological"="volcanic_lava_field";
way"geological"="volcanic_lava_field";
relation"geological"="volcanic_lava_field";
);
// print results
out body;;
out skel qt;

Über die Export-Funktion die Daten als GeoJSON herunter geladen und ins QGIS zur Visualisierung importiert.

[1] … https://www.openstreetmap.org/relation/13249829#map=14/28.6154/-17.8976
[2] … https://twitter.com/geospacedman/status/1443672538572283905?s=20
[3] … https://overpass-turbo.eu/
[4] … https://twitter.com/geospacedman/status/1444300844632002566?s=20

Letzte Woche wurde PostgreSQL 14 veröffentlicht, ich habe darüber berichtet [1]. Nun stand am Wochenende noch der Test aus und wie nicht anders von mir erwartet, es läuft! Völlig problemlos. Ich habe auf dem MAC (M1) die PostgreSQL.app (“Postgres.app mit allen unterstützten Versionen (Universal)”) genutzt [2], einfach, wie gewohnt [3] 🙂

Drei einfache Schritte:

• Server einrichten – v14 auswählen (ggf. Port ändern, siehe unten)
• DB auswählen (bei mir “mikee.”) und PostGIS für die mit „CREATE EXTENSION postgis;“ aktivieren
• neue DB-Verbindung im QGIS und ggf. DBeaver einrichten

Um meine bestehende DB-Instanz auch weiter zu behalten (“Never touch a running system!”), habe ich die neue v14-DB einfach auf einem anderen Port laufen lassen, statt Default-Port 5432 habe ich für die v14 den Post 5433 genommen und schon kann ich beide Datenbanken parallel betreiben und die Daten via QGIS von eine in die andere DB übertragen. Klappt prima, danke den Machern!!

[1] … https://geoobserver.de/2021/10/01/postgresql-released-v14/
[2] … https://postgresapp.com/de/
[3] … https://geoobserver.de/2019/05/14/postgismac/
[4] … https://geoobserver.de/2021/01/28/qgis-postgis-mac_arm_m1/

Und wieder nach fast genau einem Jahr wurde die weltweit fortschrittlichste Open-Source-Datenbank auf ein neues Release gehoben, seit gestern ist PostgreSQL v14 verfügbar! [1], [2]. Glückwunsch & Danke!

Alle Release-Notes findet Ihr in [1], hier die Liste der neuen Features und Verbesserungen (Google-übersetzt aus [1]):

• Gespeicherte Prozeduren können jetzt Daten über OUT Parameter zurückgeben.
• Der SQL-Standard SEARCH und CYCLE Optionen für allgemeine Tabellenausdrücke wurden implementiert.
• Die Subskription kann jetzt auf jeden Datentyp angewendet werden, für den sie eine nützliche Notation ist, nicht nur auf Arrays. In dieser Version haben die Typen jsonb und hstore Subskriptionsoperatoren erhalten.
• Bereichstypen wurden durch das Hinzufügen von Mehrfachbereichen erweitert, wodurch die Darstellung nicht zusammenhängender Datenbereiche ermöglicht wird.
• Für parallele Abfragen, stark gleichzeitige Workloads, partitionierte Tabellen, logische Replikation und Vakuumierung wurden zahlreiche Leistungsverbesserungen vorgenommen.
• B-Baum-Indexaktualisierungen werden effizienter gehandhabt, wodurch das Aufblähen des Index reduziert wird.
• VACUUM wird automatisch aggressiver und überspringt unnötige Bereinigungen, wenn die Datenbank beginnt, sich einer Transaktions-ID-Umbruchbedingung zu nähern.
• Für Ausdrücke können jetzt erweiterte Statistiken gesammelt werden, die bessere Planungsergebnisse für komplexe Abfragen ermöglichen.
• libpq hat jetzt die Möglichkeit, mehrere Abfragen zu Pipelines zu verarbeiten, was den Durchsatz über Verbindungen mit hoher Latenz steigern kann.

[1] … https://www.postgresql.org/docs/14/release-14.html
[2] … https://twitter.com/mapserving/status/1443599571133870088?s=20
[3] … https://geoobserver.de/2020/09/25/postgresql-released-v13/
[4] … https://geoobserver.de/2019/10/04/postgresql-released-v12/