Oft wurde und wird über Open Data philosophiert, die einen erwarten Milliarden Wirtschaftseffekte, Synergien, gänzlich neue Ideen. Die Anderen waren schon immer am zweifeln. Eins jedoch ist wichtig: möglichst vielen Leuten einen einfachen Zugriff zu den Daten zu ermöglichen, auch Leuten ohne GIS-Kenntnisse. Außerdem sollten die Daten mit anderen Daten kombiniert und mit Ideen und Funktionen verknüpft werden. Als Einstieg möchte ich hier mal kurz zeigen, wie man quasi ohne Programmierkenntnisse mit einen kostenlosen GIS, hier QGIS, mal schnell eine einfache Web-Anwendung kreieren kann.
- Laden der Baum-Daten vom OpenData-Portal der Stadt Halle (Saale), z. B. als ESRI-Shape-File
- diese dann in QGIS 3.x öffnen
- Spalten-Aliase definieren, damit es nicht so technisch aussieht
- ggf. Spalten neu sortieren, damit die Ausgabe besser sortiert ist (suche “Refactoring fields” in der Toolbox)
- Hintergrundkarte einfügen (XYZ-Raster-Kacheln, z. B. OpenStreetMap)
- Plugin “qgis2web” nutzen
Achtung: hier sind 35201 Bäume als Punktdaten im JSON-Format in den Browser zu laden, deshalb ist ein im JS schneller(!) Browser zu bevorzugen, z. B. Chrome. Hier geht’s zum Demo: http://www.geoobserver.de/HAL_OpenDataExample_Baum/
Update 23.04.2019: Es wurde ein neuer Client eingestellt: Leaflet-basiert mit korrigierter Projektion der Bäume (EPSG:2398)
Update 13.07.2019: Datenaktualisierung
Screenshot des Demos, Bäume im Paulusviertel Halle
(Quelle: http://www.geoobserver.de/HAL_OpenDataExample_Baum/)
Eine Frage: Wieso ist denn bei den WMS-Daten das KBS 3396 (Zone 3) hinterlegt? Und nicht, wie auf der Halle-Seite erläutert, das 2398?
Der WMS unterstützt mehrere Projektionen, die können über den GetCapabilities-Request angezeigt werden. Hier der entsprechende Ausschnitt aus dem ursprünglichen XML* des GetCapabilities:
Bäume (Ausspielung Baumkataster)
EPSG:2398
EPSG:2397
EPSG:2398
EPSG:2399
EPSG:2166
EPSG:2167
EPSG:2168
EPSG:3035
EPSG:3396
EPSG:3397
EPSG:3398
EPSG:3399
EPSG:32631
EPSG:32632
EPSG:32633
EPSG:4326
EPSG:31466
EPSG:31467
EPSG:31468
EPSG:31469
EPSG:31462
EPSG:31463
EPSG:31464
EPSG:31465
EPSG:25832
EPSG:25833
EPSG:900913
EPSG:3395
EPSG:4647
EPSG:5650
Sie müssen in Ihrem Ziel-Klienten/Programm nur den von Ihnen benötigten anfordern, z. B. den 2398. Dieser wird beim generierten GetMap-Request entsprechend als Parameter mitgegeben.
* … WordPress eliminiert die XML-Tags
Funktioniert alles, bestens. Eine Frage noch:
Ich hab den Baumdatenbestand in einen Layer aus den Shape-Daten hinzugefügt. Dann hab ich die Stadtgrundkarte als WMS-Layer daruntergelegt. Mir ist nun z.B. im Bereich der nördlichen Körnerstraße aufgefallen, dass der Baumdatenbestand etwas nach Osten verschoben ist, die Bäume stehen auf der Straße bzw. auf Privatgrundstück. Ich hab das mit Ihren Daten gegengeprüft, scheint ebenso der Fall zu sein. Woran liegt das? An der Genauigkeit der Baumkoordinaten? Aber warum scheint es dann für die Nord-Süd-Ausrichtung zu stimmen?
Und als Bonus: Könnten Sie evtl. Ihre Punkte drei und vier der Meldung noch etwas konkretisieren?
Vielen Dank und schöne Ostern!
Sorry, ich kann Ihre Anmerkungen nicht nachvollziehen. In der Körnerstraße gibt es doch keine Bäume im Baumkataster(!?), nur in der Friedenstraße und Richard-Wagner-Straße. Sind Sie sich sicher, dass beide Layer (Baum-Kataster & der WMS Digitale Stadtgrundkarte) in der richtigen und gleichen(!) Projektion geladen wurden? Bitte beide Themen in EPSG:2398 laden, das QGIS-Projekt auch in dieser! Ich habe es mal probiert, passt und sollte so aussehen: https://geoobserver.files.wordpress.com/2019/04/baumkataster_dsgk_hal_screenshot1.gif
Autsch, mein Fehler. Ich meine natürlich in der nördlichen Richard-Wagner-Straße. Entschuldigen Sie bitte. Ja, auf Ihrem Screenshot sieht das jetzt gut aus, aber nicht auf Ihrer Web-Präsentation. Da laufen die östlichen Bäume in der R.-Wagner-Straße nördlich und südlich der Körnerstraße – das wollte ich schreiben – in die Grundstücke rein. Sehr deutlich zu sehen! Aber das hat vielleicht etwas mit dem Plugin oder der Web-Präsentation zu tun. Vielleicht ging es Ihnen aber auch wie mir: Ich hatte beim Einlesen der Baumdaten die korrekte Projektion eingestellt – die sich aber nun doch wieder verstellt hatte. Korrigiert und es passt nun. Danke für Ihre Prüfungen!
Jo, jetzt hab ich das Problem verstanden. Im OL-Demo wird 3857 (Pseudo Mercator) genutzt. Es ist nur ein Sample, ggf. muss noch mal an den Projektionen “gespielt” werdn.
QGIS erkennt das Shape übrigens als EPSG: 5674, wenn man es dann richtig projeziert (2398) ist alles im Lot. Hier ein Beispiel mit der 3857(Pseudo Mercator) im QGIS-Projekt: https://geoobserver.files.wordpress.com/2019/04/baumkataster_hal_screenshot_2.gif
Update 23.04.2019: Es wurde ein neuer Client eingestellt: Leaflet-basiert mit korrigierter Projektion der Bäume (jetzt explizit EPSG:2398 statt automatisch erkannter EPSG:5674)
Eine Frage noch: Kann ich denn – außer durch die Angabe der Objektanzahl – irgendwo an den Baumdaten sehen, ob der Datensatz auf dem OpenData-Portal der Stadt verändert/ergänzt wurde? Und gibt es eine Möglichkeit, dies in QGIS vergleichend zu visualisieren?
Den Stand der Daten sieht man direkt im Open Data Portal beim Thema unter “letzte Aktualisierung”, also bei den Bäumen hier: http://www.halle.de/de/Verwaltung/Online-Angebote/Offene-Verwaltungsdaten/Mit-Kartenbezug/index.aspx?ID=f2087a53-2c10-f7c5-4dba-9ad5112a90cb
>Und gibt es eine Möglichkeit, dies in QGIS vergleichend zu visualisieren?
Ja: 1. Beide Themen laden und unterschiedliche visualisieren (symbolisieren) oder 2. beide Themen laden und “Difference” (“Unterschied”) nutzen
Herzlichen Dank. Ich finde dieses Baumkataster eine schöne Sachen, um mit QGIS mal etwas rumzuprobieren und sich vertraut zu machen. Schönen Feiertag!
Da ich dankbar für kleine Hilfestellungen bin, um mit QGis vertrauter zu werden: Gibt es denn eine vermeintlich einfache/nachvollziehbare Möglichkeit, in QGIS komplexere Suchen zu definieren? Ich hab mir z.B. mal die Winterlinden rausfiltern lassen. Kann man sich denn auch die Stelle/Bereich raussuchen lassen, wo eine Winter- und eine Sommerlinde am nahesten beieinander stehen (um sie zu vergleichen)?
Ich meine, interessant könnte die Funktion “nearest neighbor” sein, einfach mal googlen, z. B. https://www.google.com/search?q=qgis+nearest+neighbor oder hier im #geoObserver, wo es auch schon mal Thema war: https://geoobserver.de/2017/02/20/qgis-naechster-nachbar/
Pingback: OpenTrees: So schnell ist OpenData bei Bäumen! | #geoObserver
Mit der QGIS Ergänzung QField bekommt man die Baumkataster auch schön aufs Handy:
https://cloud.infra4future.de/s/TR6mMmJYDmz8xrL
Pingback: Update: Baumkataster Halle (Saale) | #geoObserver