OpenStreetMap

Diary Entries in German

Recent diary entries

Nachweis für die sdw

Posted by postquantum on 30 April 2021 in German (Deutsch).

sha256-Hash der entsprechenden Datei als Nachweis für dieses Profil: 93e9f0fb9f2be28a9b54ad96f78d11a7895eb1e730f6fcd0754a7062813aeb0b

Test

Posted by MaceWindu33 on 24 April 2021 in German (Deutsch).

Test

Forst ist ein Reservat

Posted by Hungerburg on 20 April 2021 in German (Deutsch). Last updated on 27 April 2021.

Ein interessanter Wikipedia Artikel wurde auf der Seite zu einem umstrittenen Proposal zitiert - https://en.wikipedia.org/wiki/Royal_forest - Leider nur auf Englisch, hier aus der Einleitung:

In England ist ein Reichsforst (royal forest), gelegentlich Königswald genannt, eine Fläche die nicht der landschaftlichen Gerichtsbarkeit unterliegt. Das Wort leitet vom lateinischen “foris” her, das mit “draußen” übersetzt wird. Im England der Anglo-Sachsen (~500-1066) hat es solche Bereiche nicht gegeben, erst die Normannen (ab 1066) haben diesen Brauch eingeführt. Dabei ging es in erster Linie darum, Wild für die herrschaftliche Jagd zu reservieren. Die pflanzliche Grundausstattung der Gegenden spielte eine Rolle nur dieses Zieles wegen. Für die Einheimischen war es keine frohe Botschaft, wenn das Land auf und von dem sie lebten zum Reichsforst erklärt wurde. Die Praxis, der nachgesagt wurde, dass sie für verbrannte Dörfer und Entvölkerung zeichnete, wenn auch im Ausmaß gewiss nicht wie behauptet, verebbte Mitte des 17. Jahrhunderts, die Bezeichnungen überleben bis heute.

Aus meiner Hobbymapper Perspektive: Hier in der Gegend gab es zu Zeiten der Monarchie einen Reichsforst - ein forstwirtschaftlich unergiebiges felsiges Steilgelände, aber gut zur Gamsjagd. Geerbt haben das die Bundesforste - ein vergleichsweise umgänglicher und verständiger Waldbesitzer. Förster kennt man hier keine, die heißen seit der frühen Neuzeit Waldhüter, ganz offiziell inzwischen Waldaufseher. Ums Wild kümmern sich Jäger.

Mit Ausnahme von administrativen Bezeichnungen (Forstamt) ist das Wort Forst hierzulande das Gegenteil von geläufig. Trotzdem sind genau hier, wo laut amtlichen Daten nicht ganz zwei Drittel des Waldes im forstwirtschaftlichen Ertrag stehen, 99% des Waldes in der OSM als Forst kartiert, was eben genau das aussagen soll, dass dem so sei. Das stinkt zum Himmel.


Update: Hierzulande (österreichisches Bundesland) gibt es scheints zwei Ebenen der Forstorganisation:

  • Försterbezirke, die unterteilen die politischen Bezirke.
  • Waldbetreuungsgebiete, die unterteilen die Försterbezirke.

Waldbetreuungsgebiete sind meist den normalen Gemeindegrenzen gleich; heißen dann auch so. Daneben gibt es, gemeindegrenzenübergreifend, die Österreichischen Bundesforste und dann noch die “Forstbetriebe”: ZB ein Stift, ein Sägewerk, und die “Stiftung der Herzog von Sachsen-Coburg und Gotha’schen Familie”. Waldbetreuungsgebiete von ÖBF oder Betrieben können sich über mehr als einen Försterbezirk erstrecken.

Alle diese Grenzen liegen immer auf Grundstücksgrenzen aus dem Kataster. Daten zu “Abteilen” sind nicht online. Vielleicht haben das nur ÖBF und Betriebe intern? In den Gemeinden sind es wohl die Grundstückseigentümer.

In diesem Bundesland gibt es demnach keinen Wald, der nicht “betreut” wird, weil es kein Land gibt, das nicht zu einer Gemeinde gehören würde.

English version

The local open-government-data GIS shows only two levels of forestry organisation:

  • Forester districts (Försterbezirke), which subdivide political districts.
  • Forest management areas (Waldbetreuungsgebiete), which subdivide forester districts.

These cover all of the land. There is no space that is not managed, be there wood, farmland, settlements, commercial or industrial estate, what ever. Of course, they do not have much of a say where there is no wood. If an area is considered woods can be learned from the land register. The official GIS does not show compartments, which would further subdivide forest management districts.

Forest management areas mostly are congruent with municipal/communal districts. In fact, most of the land is forestally managed by them. Besides, parts of the country are forestally managed by the Austrian Federal Forests (Österreichische Bundesforste, ÖBF) and “forestry companies” (Forstbetriebe): e.g. a monastery, a sawmill, and the “Foundation of the Duke of Saxe-Coburg and Gotha’s Family”. Latter two (federal and companies) manage woods across management areas and even across districts.

All of the boundaries always lie on property boundaries from the cadastre. In the communal forests, perhaps these form the compartments, the individual land owners? ÖBF and enterprises perhaps have them internally?

Note: In some regions around here, the privilege to do forestry, in the sense of economic use of a property, is in the hands not of the owner of the land but a third party rights-holder. (The owner is likely the municipality/commune, and the right to do logging is held by a natural person. The institution is called “Teilwald/partial forest.) Sometimes property owners and rights-holders organize themselves in “farming associations” which may also manage all of the municipal/communal woods, for their own benefit alone. That caused some bad press lately.

Auf der Suche nach dem verlorenen Wald

Posted by Hungerburg on 19 April 2021 in German (Deutsch). Last updated on 21 April 2021.

Ein in Abstimmung befindliches proposal beinhaltet, dass die Kennzeichnung von Waldflächen mit “landuse=forest” als veraltet gelten soll. In deutschen Landen wird die allerdings gerne dafür verwendet, um Waldflächen nach ihrer wirtschaftlichen Nutzung zu unterscheiden. So liest man jedenfalls. Im deutschsprachigen Forum hieß es dementsprechend vor Kurzem wieder einmal: 95% des Waldes in D/A/CH sind seit hunderten von Jahren Nutzwald, gehören also mit “landuse=forest” getaggt. Woher stammt diese Zahl?

Aus den Daten der openstreetmap selbst? Im OHSOME Dashboard lassen sich Flächen von Wald (natural=wood) und Forst (landuse=forest) ausgeben. Die sind mit Taschenrechner schnell in Anteile umgelegt. Deutschland liegt mit 97% Nutzwald nicht weit von 95, Österreich mit 99,2% allerdings ordentlich daneben, die Schweiz mit 95,6% schießt den Vogel ab. Alles klar! Genauer als die Deutschen sind eben nur die Schweizer, die Österreicher können den beiden das Wasser nicht reichen, die können nicht einmal Daten richtig erfassen. So könnte man meinen.

In Österreich gibt es nun die Österreichische Waldinventur, eine amtliche Stelle, die genau diese Daten erhebt. Ihr zufolge sind in Österreich aber nur 83% des Waldes Ertragswald, will heißen, für die Holzgewinnung genutzt. Besonders eklatant fällt das in einem westlichen Bundesland auf, die Ertragswaldquote laut ÖWI liegt dort bei 65,4%, laut OSM dagegen bei 98,8. Das liegt ja noch weiter auseinander!

In diesem westlichen Bundesland gibt es zu unserer Freude auch ein öffentlich zugängliches Geoinformationssystem. Luftbilder und anderes lassen sich als Hintergrundebene in JOSM einblenden. Vielleicht lässt sich damit mehr über die Differenz erfahren? Hier ein paar Bildschirmfotos von der “Suche nach dem verlorenen Wald”, mögen es vier Prozentpunkte sein, oder 33.

Die folgenden Bilder zeigen Ausschnitte in denen die OSM-Carto Standardansicht mit Daten des Landes überlagert wurden.

Waldnutzung am Paschberg

Paschberg - Das sieht einmal gut aus: geschätzte 105% der in OSM als Forst erfassten Flächen gelten als Ertragswald. Man sieht nebenbei auch, fürs Amt zählen Kahlschläge zum Ertragswald, während OSM Laien dort Gebüsch sehen, zumindest ein paar Jahre lang. Vielleicht liegt das aber eher an der glazialen Langsamkeit, mit der in der Forstwirtschaft Zeit vergeht?

Waldnutzung im Gschnitztal

Gschnitztal - Es wird bunter: Während der ganze in OSM erfasste Wald Forst ist, im GIS des Landes sieht es durchmischt aus; und das nicht nur weil mehr als zwei Arten der Nutzung getrennt abgebildet werden. Da haben wir den Salat.

Waldnutzung im Vomperloch

Vomperloch - Es wird wieder weniger bunt: Viel Schutzwald außer Ertrag. Wer die Örtlichkeit nicht kennt: Hier holt man Holz auch schon einmal mit dem Hubschrauber.

Nichts, das daran Zweifeln machen könnte, dass die amtlichen Daten so weit daneben liegen. Woran scheitert die genaue Erfassung in der OSM?

  • Der meiste Wald hier ist vor 10 Jahren kartiert worden. Die 95%-Regel hat es wohl schon gegeben, kurz zuvor war viel Wald per bot zu Forst umgetaggt worden, es gab sehr viel zu tun, da musste es schnell gehen. Meine Vermutung: es wurde nach Empfehlung markiert, viel schief gehen kann eh nicht.
  • Auch auf dem besten Luftbild lässt sich die Nutzung eines Waldes schwer erkennen. So bunt wie auf den Bildern die Nutzungsartenn ausfallen sieht es mir danach aus, dass das auch am Boden nicht so ohne weiteres möglich ist.

Will man die Unterscheidung in den Daten korrekt abbilden müssen jede Menge neuer Löcher “natural=wood” in die “landuse=forest” Flächen gestanzt werden. Andernorts müssten Löcher entfernt werden. Wie die dann füllen, wenn nicht Information verloren gehen soll?

Will man die Unterscheidung, forstwirtschaftlich genutzt kontra ungenutzt überhaupt abbilden? Das erwähnte proposal kurioserweise, das sich um die Erfassung von Forstbezirken kümmert, scheint es darauf nicht besonders abgesehen zu haben. Ich habe keine Möglichkeit gesehen, wie Wald als “use=industrial” oder ähnlich markiert werden könnte. Bisher scheint das noch nicht vermisst worden zu sein.

Dafür erwähnt das proposal den Schlüssel leisure - Erholungswald, eine Kategorie, die auch das Amt kennt, in einem andren Datensatz abgelegt, also oben nicht aufscheinend. Ein weiterer Datensatz heißt übrigens “Landnutzung”: Den habe ich nicht ganz verstanden, nur soviel, dass darin keine Unterscheidung von Wald nach Nutzung vorgenommen wird.

Die vorgeschlagenen neuen boundaries vermute ich, werden dabei auch nicht wirklich hilfreich sein. Die Waldkategorien, die auf den Diagrammen oben so schöne abstrakte Bilder zeichnen, folgen nämlich nicht den Grundstücksgrenzen; und das offensichtlich nicht, weil die Waldkategorien eventuell nur schleißig gezeichnet wurden, manchmal teilen sie Grundstücke, nicht nur kleine, genau in der Mitte. Ob Forstbezirke genauso wenig an den Kataster gebunden sind?

Quellen: Grundkarten © Openstreetmap Contributors +++ ÖWI Daten © Bundesforschungszentrum für Wald - https://www.bfw.gv.at/waldinventur-zwischenergebnisse-2016-2018/ +++ © Waldkategorien: Amt der Tiroler Landesregierung, Abteilung Raumordnung und Statistik, https://gis.tirol.gv.at/arcgis/rest/services/INSPIRE/AT_0024_17_Bodennutzung/MapServer/exts/InspireView/service - CC BY 3.0 Österreich - Zur Legende: Wenn hellrosa grün überlagert sieht es recht grau aus, nicht Baumbestanden Flächen sind im WMS nicht hellblau sonder schwarz +++ Bilder von der Überlagerung mit dem Kataster können hier nicht veröffentlcht werden, weil die den Nutzungsbedingungen des BEV unterliegen.

Eigene Karten erstellen und in die eigene Website einbetten nach dem Vorbild von G Maps?

Posted by web-seitig on 12 April 2021 in German (Deutsch). Last updated on 18 April 2021.

Hallo, ich habe die zuvor eingebettete Google Maps Karte über den Kanal du Midi in Südfrankreich erstellt. Also den Kanal in der Karte nachgezeichnet und damit für User hervorgehoben zur Orientierung. Die Karte sollte in den Blogartikel über den Canal du Midi https://www.urlaubs-reisetipps.de/?p=898 integriert werden. Leider ist das offenbar von Google nicht erlaubt. Nun bin ich auf OpenStreetMap aufmerksam geworden und ich würde gerne a) den Canal du Midi in der Karte von OpenStreetMap hervorheben (falls das möglich ist und falls es so eine Karte noch nicht gibt) b) diese Karte in meinem Reiseblog-Artikel einbetten Ich bitte dazu um Hilfe und Unterstützung, da ich noch neu bin in OpenStreetMap und micht noch nicht gut auskenne. Mit IT an sich bin ich aber fit. Vielen Dank Stefan

Auftakt für die Bürgerentscheidskarte!

Posted by RanJenner on 7 April 2021 in German (Deutsch).

Der Anfang ist gemacht. Habe nun ein paar zukünftige Bürgerentscheide in die Karte eingefügt. Idealerweise möchte ich diese Karte auf der Internetseite meines Vereins verlinken. Werde aber noch klären müssen, ob das rechtlich alles ok ist hinsichtlich der Lizenzen der Karte. Unabhängig davon macht das Erstellen der Karte wirklich Spaß, werde also so oder so weitermachen und auch in Zukunft Bürgerentscheide in meine Karte eintragen.

Vollbildanzeige

Mappen von Bürgerentscheiden

Posted by RanJenner on 6 April 2021 in German (Deutsch).

Habe jetzt erst mit dem Mappen angefangen. Ich werde mich auf Objekte und Bereiche in Bayern spezialisieren, die in irgendeiner Form mit Bürgerentscheiden zusammenhängen. Somit möchte ich graphisch darstellen, wo in Bayern Bürgerentscheide stattfinden.

Ein Stück weiter in Burkersdorf

Posted by Hamp on 6 April 2021 in German (Deutsch).

In den letzten zwei Jahren seitdem ich mit dem Mappen angefangen habe, war ich öfters im beschaulichen Burkersdorf im Landkreis Kronach unterwegs. Dort habe ich immer wieder Daten nachgetragen.

Ein größeres Projekt wird im Sommer sein den lokalen Fluss “Fabrikgraben” weiter zu mappen. Auf Luftaufnahmen ist der Verlauf nicht erkennbar. Das Flussbett entfernt sich immer wieder weit vom Weg und es gibt mindestens eine Gabelung im weiteren Verlauf des Waldes. Deswegen werde ich vermutlich im Sommer eine Flusswanderung unternehmen um den tatsächlichen Verlauf zu kartieren. An einer Stelle gibt es noch eine zusätzliche Brücke die aber, wie der Weg dazu auch, nicht eingezeichnet ist.

Es gibt daher weiterhin bei Burkersdorf viel zu tun.

Wenn ich draußen unterwegs bin und nicht mappe, dann wandere ich.

Location: Burkersdorf, Küps, Landkreis Kronach, Bayern, 96328, Deutschland

Extrahieren von Objekten anhand der Tag-Historie und der beteiligten User

Posted by rainerU on 29 March 2021 in German (Deutsch). Last updated on 6 May 2021.

Extrahieren von Objekten anhand der Tag-Historie

Mit dem Werkzeug osmium-tool kann man OSM-Extrakte nach Schlüssel/Wert-Kombinationen filtern. Das funktioniert auch mit History-Dateien. Dabei werden alle Objekte herausgefiltert, bei denen es einen Version mit der gesuchten Schlüssel-Wert-Kombination gibt. Auf diese Weise ist es z.B. möglich, alle Objekte zu extrahieren, bei denen der Wert eines Schlüssel in der Versionshistorie des Objekts in einer bestimmten Weise geändert wurde, z.B. von highway=track auf highway=service|unclassified|tertiary:

# Create data file from history file to ensure consistency between data and history files:
osmium time-filter extract.osh.pbf -o extract.osm.pbf

# Get all ways with highway=track in any version 
# (Discard nodes in the first step in order to eliminate nodes that are no longer part of the current versions of the ways)
osmium tags-filter --omit-referenced extract.osh.pbf w/highway=track -o track-w.osm.pbf
osmium getid --id-osm-file track-w.osm.pbf --add-referenced extract.osm.pbf -o track.osm.pbf

# Keep only ways that are now service,unclassified or tertiary:
osmium tags-filter track.osm.pbf w/highway=service,unclassified,tertiary -o no-track.osm

Die Datei no-track.osm kann mit JOSM geöffnet werden.

Filtern nach User und Tag-Änderung

Manchmal ist es hilfreich, Objekte zu extrahieren, an denen der ursprüngliche oder der aktuelle Wert von einem bestimmten User gesetzt wurde. Mit osmium ist das leider nicht möglich, da nicht nach den Schlüsseln user und uid gefiltert werden kann.osmium kann aber die History-Datei in eine OPL-Datei umwandeln, ein Textformat mit einer Zeile pro Objektversion, in der auch der Username enthalten ist. Eine andere Möglichkeit bietet das Tool osm-tag-csv-history. Beide Wege werden nachfolgend beschrieben. In beiden Fällen wird zunächst eine History-Datei der bisher herausgefilterten Objekte erstellt:

osmium getid --id-osm-file no-track.osm --with-history extract.osh.pbf -o no-track.osh.pbf

Mit osmium und OPL-Datei

Erzeugen der History der OPL-Datei:

osmium cat -t w no-track.osh.pbf -O -o no-track.opl

Interessiert man sich für alle Wege, bei denen ein bestimmter User den Schlüssel highway von track auf einen anderen Wert gesetzt hat, dann kann man die entsprechenden Einträge in der OPL-Datei z.B. mit grep und awk finden:

awk -F' ' '{if($1==id){\
              p=match($0,"highway=");\
              if (p>0){\
                 h2=substr($0,RSTART+RLENGTH,5)\
              }else{\
                 h2=""\
              }\
              if (h1=="track" && h2!="track"){\
                 print $0\
              }\
           }\
           h1=h2;\
           id=$1\
           }' no-track.opl|\
grep u<username>|\
cut -d' ' -f1> no-track.id

Und zu guter Letzt wird eine OSM-Datei erzeugt, die man nach JOSM laden kann:

osmium getid --add-referenced --id-file no-track.id extract.osm.pbf -O -o no-track-${USER}.osm

Mit osm-tag-csv-history und CSV-Datei

Die von osm-tag-csv-history aus der History-Datei erzeugte CSV-Datei enthält für jede Änderung eines Schlüssel oder Werts eine Zeile enthält, in der u.a. der Schlüssel, der alte und der neue Wert und der Username des Benutzers aufgeführt ist, der die Änderung durchgeführt hat.

Zu der in den bisherigen Schritten erzeugten .osm-Datei wird zunächst eine History-Datei erzeugt:

osmium getid --id-osm-file no-track.osm --with-history extract.osh.pbf -o no-track.osh.pbf

Aus dieser History-Datei wird eine CSV-Datei erzeugt:

osm-tag-csv-history -i no-track.osh.pbf -o no-track.csv

In dieser Datei sucht man nun nach den Objekten, an denen man interessiert ist und erstellt eine Liste der Ids dieser Objekte zur anschliessenden Verwendung mit osmium. Die Suche kann mit den üblichen Textanalysewerkzeugen erfolgen, grep, sed, awk, usw.

Ist man im obigen Beispiel nur an den Wegen interessiert, die man selbst auf highway=track gesetzt hat, dann genügt ein einfacher Aufruf von grep und csvtool:

grep ^highway,track no-track.csv | grep ,<eigener Username>,|csvtool col 4 - > myUser.id

Mit osmium kann man eine OSM-Datei erstellen, die in JOSM geöffnet werden kann:

osmium getid --add-referenced --id-file myUser.id no-track.osm.pbf -o myTracks.osm

Covid-19 Teststationen

Posted by Nielkrokodil on 27 March 2021 in German (Deutsch).

Einleitung

In Niederösterreich gibt es seit Jänner 2021 zahlreiche permanente Covid-19 Teststationen, die von den Gemeinden und dem Land NÖ betrieben werden. Getestet wird mit Antigen-Schnelltests. Man ist nur während der Probenentnahme dort. Das Ergebnis bekommt man ca. 30 Minuten später per SMS.

Je nach (Bundes)Land variiert das System ein wenig (Terminreservierung Pficht, Ergebnis muss vor Ort abgewartet werden, etc). Grundsätzlich ist das hier beschriebene Tagging-Schema aber auf alle Covid19-Teststationen übertragbar.

Mein Tagging

Ich habe diese Teststationen wie folgt auf OSM eingetragen:

  • healthcare=sample_collection
  • healthcare:speciality=covid19 (Anmerkung: Mittlerweile wurde auf der Covid-19 OSM-Wikiseite geschrieben, dass das nicht ins Schema passt. Mangels Alternativen belasse ich es trotzdem dabei, bis eine bessere Methode beschrieben wird
  • covid19:antigen_test=yes (falls zutreffend auch covid19:pcr_test=yes)
  • check_date=2021-MM-DD
  • name=Covid-19 Teststation ORTSNAME (Das ich wichtig, um sie in JOSM aus einer Liste auswählen zu können) description=Permanente Covid19-Teststation. Es werden Antigen-Schnelltests für die Niederösterreichische Bevölkerung angeboten. Anmeldung unter www.testung.at/anmeldung
  • fee=no
  • opening_hours=
  • reservation=recommended
  • website=https://notrufnoe.com/testungen-bezbl/ (bzw. die Seite des jeweiligen Bezirks)

Meine Methode zur Wartung

Da seit Einführung im Jänner zahlreiche neue Teststationen hinzugekommen sind, die Öffnungszeiten erweitert wurde oder die Stationen verlegt wurden, ist eine systematische und effiziente Wartungsmethode hilfreich. Hier beschreibe ich meinen Ablauf.

Export der bestehenden Daten

  1. Aufruf von https://overpass-turbo.eu/
  2. Öffnen des Abfrage-Wizards
  3. Abfrage erstellen und Ausführen mit folgendem Text: healthcare=sample_collection AND healthcare:speciality=covid19 in “Bezirk Bruck an der Leitha” (Hinweis für Österreich: Statutarstädte sind eigene Bezirke und müssen daher extra abgefragt werden).
  4. Auf die Daten Zoomen hier klicken das ist das Ergebnis
  5. JOSM starten
  6. Export -> Daten in OSM-Editor exportieren -> JOSM. Hier wird vorgeschlagen, die Abfrage zu reparieren. Ich mache das (weiß nicht, ob unbedingt notwendig). Hier klicken Das ist das Ergebnis

JOSM vorbereiten

  • Ich arbeite mit dem Hintergrundbild Basemap.at Orthofoto und dem basemap.at Overlay.
  • Es muss das todo-Plugin installiert sein

Stationsliste abarbeiten

  1. Alle exportierten Elemente markieren (Strg+A)
  2. check_date auf heutiges Datum setzen
  3. Alle Elemente in die Aufgabenliste (von todo-Plugin) legen. (Leider kann man diese Liste nicht alphabetisch sortieren)
  4. Website der Teststationsliste aufrufen, zB diese hier
  5. Erstes Element auf der Website anschauen, Adresse (Hausnummer) merken.
  6. Wechsel zu JOSM. Element in der Aufgabenliste suchen und Doppelklicken (es springt dann dorthin und das Element wird ausgewählt)
  7. Überprüfen, ob die Lage/Adresse noch stimmt oder die Station verlegt wurde
  8. Öffnungszeiten in JOSM anschauen
  9. Wechsel zur Website. Prüfen, ob die Öffnungsziten noch aktuell sind.
  10. Element auf der Aufgabenliste als erledigt markieren
  11. nächster Eintrag auf der Website analog kontrollieren

Wenn eine neue Station geöffnet wurde, dann suche ich die Adresse wie folgt:

In JOSM: Herunterladen -> Gebiete um bestimmte Orte –> Adresse und Ort eingeben (klappt nicht immer, aber meistens) –> Das passende Element (meistens Gebäude) doppelklicken. Hier doppelklicken Das ist das Ergebnis

Wenn die Adresse nicht eingetragen war, ergänze ich diese, jedoch nicht am Teststations-Element, sondern am Haus. (Weil die Teststationen werden wir hoffentlich irgendwann nicht mehr benötigen und dann kann man sie einfach löschen, solange sie als separates OSM-Objekt vorliegen).

Die neue Station erstelle ich meistens nicht von neu, sondern kopiere mir einen Node aus der Nähe und ändere die betreffenden Werte.

Wenn die Aufgabenliste leer ist und ich am Ende der Liste auf der Website bin, lade ich alles hoch und stürze mich auf den nächsten Bezirk.

Location: VAZ St. Pölten, Spratzern, St. Pölten, Niederösterreich, 3100, Österreich

Buildings: Nebengebäude(Deutsch)= pavilion(Englisch)? Wie ist es mit Zubau am Hauptgebäude? Annex ? Outbuilding

Posted by Znaika on 23 March 2021 in German (Deutsch).

https://wiki.openstreetmap.org/wiki/DE:Key:building https://de.wikipedia.org/wiki/Pavillon

Hallo zusammen,

ich bin seit einem Jahr vielleicht falsch unterwegs gewesen und nun ein wenig verwirrt, wie man die Gebäudeteile, die mit Hauptgebäude verbunden sind, definiert.

Ein Nebengebäude ist gegeben, wenn es im Vergleich zum Hauptgebäude untergeordnete Bedeutung hat und zu diesem hinzukommt. Im Unterschied zum Nebengebäude liegt ein Zubau vor, wenn eine Verbindung zum Hauptgebäude besteht, die zumindest optisch den Eindruck eines Gesamtbaus erweckt. Der Anbau eines Nebengebäudes an das Hauptgebäude verändert seinen Charakter aber nicht, solange es statisch unabhängig ist.

Nebengebäude können möglich sein: Stellplatz Garage Pavillon (Ein Gebäude mit Einrichtungen für Benutzer von Sportgelände laut Wiki) Gartenhaus Terrassenüberdachung Gerätehaus => carport; garage; pavilion; shed; roof; barn

Was ist die Definition für Zubau? Pavillon als Teil eines größeren Gebäudes?

Mapillary Aufnahmen mit Hilfsmitteln machen

Posted by cyton on 15 March 2021 in German (Deutsch).

Da ich nicht mit ausgestrecktem Arm und das Handy in der Hand haltend herum Laufen/Radfahren wollte, hab ich mir mit der Zeit verschiedene Gedanken gemacht und einige ausprobiert.

Helm

helm_hinten.jpg

Idee

Da das Anbringen des Handys am Lenker nur für verwackelte Bilder sorgt, wollte ich mich selbst als Stoßdämpfer zwischen Rad und Handy bringen.


Das hat auch soweit funktioniert, auf den Bildern kann man scharf alles erkennen (naja mit Einschränkungen, so ganz Perfekt geht es halt nicht mit dem Handy). Das Problem ist, dass da ein relativ großes Gewicht obendrauf kommt. Außerdem kann ich mich nicht frei umsehen, ohne die Richtung der Bilder zu verändern (macht man ja mal auf dem Rad).

helm_seite.jpg

Erst hatte ich das Mittig angebracht als Test, bin damit auch gefahren, aber die Bilder sind halt nur so lala, und das mit dem Umhersehen und dem extra Gewicht stört doch zu sehr.

helm_detail.jpg

Fazit

Keine gute Idee!

Hab ich direkt wieder abgemacht, und anders verwertet.

Ganz zu schweigen davon, was passiert, wenn ich in einen Unfall verwickelt wäre und da ein extra Gewicht an meinem Helm hängt, womit der nicht ausgelegt ist.

Die Beispielbilder habe ich nicht hochgeladen, sondern gelöscht, da die Halterung selber zu gut sehen war.


Jacke

jacke_ganz.jpg

Idee

Im Prinzip wollte ich eine Halterung für das Handy an meiner Person für das Spazieren gehen. Also jeweils nach Vorn, Rechts und Links sehend. Also ein wenig Stoff gekauft, ein Muster für eine Jacke (noch mit dem Gedanken da etwas in der Form eines Brustgurtes wie für eine GoPro zu schneidern) und drauf los genäht.

Naja nicht ganz, das hat doch etwas gedauert.


An den Ärmel kommt eine Tasche:

jacke_tasche_aermel.jpg

Sowohl links und rechts (rechts nicht abgebildet).

jacke_aermeltasche.jpg

Die gleiche auf die Brust; deshalb ist auch der Reißverschluss so schief.

jacke_tasche_brust.jpg

Innen zwei großzügige Taschen zum Halten einer Power-Bank, dem Kabel dazu und eventuell irgendwelchen Krams.

jacke_innentasche.jpg

Ans Ende der Handytaschen habe ich ein kleines Loch geschnitten innen für das Ladekabel:

jacke_kabel.jpg

Eine Paspeltasche rechts und links, nahe der Seitennaht, da kommen die Flossen rein. Das dient auch der Armposition und somit der Orientierung der Tasche an der Schulter und dadurch der Drehung des Handys (wenn auch gering).

jacke_paspeltasche.jpg

Und ein solider Haken darf nicht fehlen!

jacke_haken.jpg

Fazit

Gute Idee! Nur hab ich gemerkt, dass ich beim Reinfummeln des Handys diese leider einmal gesperrt habe und somit hat es auch keine Bilder gemacht. Aber da hilf der geführte Modus, erst einschalten, dann kann ich das Handy nicht mehr sperren oder sonst damit interagieren.

Schulter rechts Beispiel Schulter Links Beispiel Nach vorn Beispiel

Altes iPhone 4 zur Seite (iPhone 8 nach vorn wird noch verarbeitet) Beispiel Theoretisch könnte ich also mit drei Handys gleichzeitig aufnehmen, hab nur keine drei.


Rucksack

geruest_in_rucksack.jpg

Idee

Angelehnt an Tordans Versuche wollte ich auch höher hinaus. Da ich aber nun mein iPhone 8 nehmen wollte und keine GoPro kaufen, wollte ich es nicht versuchen das am Rad anzubringen aufgrund meiner schlechten Erfahrungen mit Halterungen am Lenker.

geruest_ganz.jpg

Das ganze besteht aus Verpackungsmaterial einer Tischplatte, diese Teile waren rundherum als Schutz der Kante in der Pappe mit dabei, nun kleingesägt haben sie doch noch einen nutzen. Und Lochband und vielen kleinen Schrauben.

geruest_unten.jpg

Kurz abgehobelt für einen sicheren Halt am Besenstiel (beim Schneefegen zerbrochen, nicht extra hierfür geopfert). Diese beiden Löcher hab ich vorgebohrt, die anderen alle nicht, da war mir das nicht so wichtig, ich wollt erst wissen, ob das überhaupt funktioniert mit diesem Prototypen.

geruest_ball_mount.jpg

Genauso am anderen Ende, dann aber einfach übertrieben mit Lochband. Am Ende wackelt es noch immer ein wenig, aber das muss so gehen.

geruest_stiel_anbgebracht.jpg

Diesen “Fuß” habe ich angebracht, da das ganze sonst im Rucksack verrutscht (vorne - hinten), hiermit ist es nun nahezu rutschfrei fixiert. Außerdem gibt das dem Ganzen ein Gewicht am unteren Ende und hebt nicht so leicht von meinem Rücken ab.

geruest_fuss.jpg

Da das ganze noch drohte Windschief sich zu verziehen habe ich den Hohlraum kurzerhand “bespannt”:

geruest_bespannt_2.jpg

So passt das dann in den Rucksack, ist dort also nicht permanent fixiert:

geruest_halb_rucksack.jpg

Am oberen Ball kann ich nun meinen RAM-Mount anbringen und mein Handy, dann noch den Bildausschnitt justieren mithilfe von meiner Apple Watch (live zusehen). Dann starte ich Mapillary und Fahre los.

Fazit

Die Konstruktion sieht nicht so prickelnd aus, aber funktioniert super, und der Rucksack verbirgt das Schreinerische Grauen. Beispiel

Das ganze könnte noch ein wenig weiter vom Kopf weg sein nach hinten, mit dem Helm stoße ich da manchmal hinten an. Beispiel


Auto

Ja gut, Ram Mount mit Saugnapf an die Frontscheibe innen, leicht nach rechts ausrichten, hoch, damit die Motorhaube nicht drauf ist, und los. Damit mache ich Tags super Bilder mit dem Handy. Nur mag ich nicht extra mit dem Diesel umherfahren, nur um Bilder zu machen.

Das benutze ich also nur, wenn ich mal mit dem Auto wo hinfahre, wo ich noch keine Bilder gemacht habe, dann kann ich aber auch mal einen kleinen Umweg fahren.

Wenn ich stehe ist alles Scharf und nicht verwackelt. Beispiel

Aber ich stehe ja nicht immer… Beispiel

Sobald es Dunkel wird, sieht es nicht mehr so gut aus. Beispiel

Wie viele Autos sind in einem Gebäude angemeldet? Kleinräumige statistische Auswertungen mit OpenData und OSM – ein Interview.

Posted by tordans on 13 March 2021 in German (Deutsch).

Ein Interview von Tobias @tordans mit Alex @Supaplex030.

Tobias: Hallo Alex, du arbeitest gerade an einem spannenden Projekt an der Schnittstelle von OSM und der Verkehrswende in Berlin, nämlich einer Parkraumanalyse für den Ortsteil Neukölln. Das ist sehr vielfältig – heute wollen wir uns ein Detail anschauen, bei dem es um OpenData und OpenStreetMap und die Verbindung von verschiedenen Datenquellen geht.

Anzahl angemeldeter Autos pro Haus

Eine Zielsetzung dabei ist, herauszufinden wie viele Autos in einem Häuserblock angemeldet sind. Dafür gibt es keine direkten Daten, aber es gibt Daten über die man Näherungswerte schaffen kann mit Hilfe von anderen OpenData-Quellen und OSM. Und diese Daten hast du dann später in der Auswertung verwendet, über die wir auch noch mal an anderer Stelle sprechen: Eine Karte, in der visualisiert wird, wie viele Parkplätze pro Auto es im Umkreis eines Ortes gibt: https://supaplexosm.github.io/strassenraumkarte-neukoelln/?map=parkingmap

Die Karte zeigt anhand der Daten, die wir hier besprechen, wie hoch der “Parkdruck” pro Fläche sein müsste, wenn man alle verfügbaren Parkplätze darstellt und die Autos der Anwohner einrechnet. Quelle Screenshot

Alex: Genau, ich habe eine Stellplatzdichte-Verteilung ermittelt. Wie du schon sagst: Dafür habe ich verschiedene Daten verwendet, die auf verschiedenen räumlichen Ebenen vorliegen. Einmal die von dir angesprochenen Kfz-Daten, die habe ich auf Anfrage vom Amt für Statistik Berlin-Brandenburg auf LOR-Ebene bekommen, da es leider keine aktuelle Veröffentlichung dazu gab. LOR steht in Berlin für “Lebensweltlich orientierte Räume”. LOR sind im Prinzip Kieze, also kleine Stadtviertel, da wohnen ungefähr 10.000 bis 20.000 Menschen pro LOR. Das ist – glaube ich – die kleinste Einheit, auf der man die Daten mal eben bekommen kann.

LOR-Daten zu Kfz-Anmeldungen

Tobias: Wie sehen die LOR-Daten aus, die uns zur Verfügung stehen?

Alex: Neben dem LOR-Namen, beispielweise “Schillerkiez”, enthalten die Daten verschiedene demografische Werte wie die Anzahl der Erwachsenen im Kiez und verschiedene Kfz-Zahlen. Vor allem die Gesamtzahl der zugelassenen Fahrzeuge, unterteilt in Pkw und sonstige Fahrzeuge – also gewerbliche Laster, Kleintransporter, Motorräder und ähnliches. Die Pkw machen ca. 80 Prozent aus, die sonstigen Fahrzeuge teilen sich zum größten Teil etwa gleich auf Kleintransporter und Motorräder auf. Nicht enthalten ist eine Unterscheidung in private und gewerblich genutzte Fahrzeuge, aber das brauche ich auch für meine Auswertung nicht, denn ich beziehe ja auch gewerblich genutzte Parkplätze mit ein. Die Daten sind übrigens von Juni 2020.

Zu den Daten: Melderechtlich registrierte Einwohnerinnen und Einwohner am Ort der Hauptwohnung in Berlin am 30.06.2020 nach Planungsräumen und KfZ-Bestand

Daten vom LOR auf einzelne Gebäude runterbrechen

Tobias: Wie hast du dann die Präzision der Daten vom Kiez auf Haus-Ebene erhöht?

Punktewolke zeigt Bewohner pro Haus – statistisch gesehen. Quelle OpenStreetMap Wiki

Alex: Richtig, wir starten zunächst groß auf Kiez-Ebene, für die wir die Kfz-Daten haben. Eine Ebene darunter gibt es – zumindest in Berlin – OpenData der Häuser-Block-Flächen. Sozusagen die Bereiche zwischen den Straßen, auf denen Häuser stehen. Zu diesen Blöcken gibt es Bevölkerungsdaten, die mir pro Block sagen, wie viele Menschen auf dieser Fläche wohnen. Aber das ist immer noch nicht klein genug für meine Auswertung, denn das ist immer noch ein großer Block mit vielen Häusern, dazwischen auch unbewohnte Gebiete wie z.B. Kleingärten. Dank OSM und anderen OpenData-Datensätzen in Berlin habe ich aber Informationen über die einzelnen Gebäude im Block. Über diesen Weg kann ich die Daten von den Blockflächen nochmal runterrechnen auf die einzelnen Gebäude. Dabei ist die Grundidee, dass man die statistisch gemeldeten Personen in einem Block auf die Gebäude verteilt, und zwar entsprechend ihrer Wohnfläche. Für jedes Gebäude kann ich anhand seiner Funktion, z.B. “Wohngebäude”, “Gewerbegebäude” oder eine Mischnutzung, und anhand seiner Stockwerkszahl ermitteln, wie viele Bewohner dort statistisch zu erwarten sind. Das ist also keine tatsächliche Zahl, die ich da vom Kingelschild abgelesen habe, sondern ich interpoliere das anhand der Gebäudedaten, die wir haben. Das gewünschte Ergebnis ist, dass ich für jeden Menschen im Gebäude einen Punkt habe. Und das entspricht mit einer relativ hohen Wahrscheinlichkeit dann der tatsächlichen Bevölkerungsdichte im Berliner Stadtraum.

Von den Menschen zu den Autos

Alex: Dieses Bevölkerungsmodell können wir jetzt nehmen und mit den Daten zu den angemeldeten Kfz kombinieren. Wenn ich weiß, wie viele Autos in einem Gebiet angemeldet sind, kann ich für jeden Menschen, also Punkt in unser Karte, angeben, mit welcher Wahrscheinlichkeit dieser Mensch ein Auto besitzt. Ich ordne jedem Menschen eine Zufallszahl von 1-100 zu und bei einer angenommenen Auto-Besitz-Quote von 20 Prozent ist dann jeder fünfte Punkt – statistisch gesehen – ein Autobesitzer.

Exkurs: Mit dieser Herangehensweise könnte man noch viele andere, spannende Auswertungen von demografischen Daten machen, vielleicht auch noch eine genauere Zuordnung. Beispielsweise gibt es Zensusdaten von 2011 im 100-Meter-Raster.

Tobias: Jetzt schauen wir gemeinsam das Ergebnis an: Auf einer OSM-Karte sehen wir Gebäude und Punkte. Dahinter steckt die Umrechnung vom Kiez auf den Häuserblock, dann auf das Gebäude unter der Berücksichtigung einer Wahrscheinlichkeit anhand der Stockwerkzahl, Grundfläche und Funktion des Gebäudes. Also eine Karte der Bevölkerungsdichte, bei der jeder Mensch mit einem statistischen Punkt repräsentiert wird.

OpenData in Berlin: ALKIS

Tobias: Welche Rolle spielten bei der Auswertung OpenData-Quellen des Berliner Senats?

Alex: Alles, was ich gemacht habe, wäre theoretisch mit OSM-Daten möglich gewesen. Aber da vor allem die Gebäudedetails in OSM nicht überall erfasst sind, habe ich für meine Auswertung Daten aus dem ALKIS der Stadt verwendet (Anmerkung: ALKIS: Amtliches Liegenschaftskatasterinformationssystem).

Für die Auswertung sind drei Faktoren entscheidend: Die Stockwerkzahl, die Funktion und die Grundfläche des Gebäudes.

In OSM – gerade in Neukölln – haben wir die Stockwerkzahl schon ziemlich gut erfasst. Auch die Grundfläche ist – auch hier dank der OpenData des Senats – sehr präzise erfasst. Aber gerade bei der Funktion erschienen mir die ALKIS-Daten vollständiger.

Ich habe daher die ALKIS-Daten als Basis genommen und an den Orten, von denen ich wusste, dass die OSM-Daten aktueller sind, die OSM-Grundrisse übernommen. Insbesondere bei Neubauten. Das ist nur möglich, weil die Daten in einer offenen Lizenz – auch OSM-kompatibel – vorliegen.

Datenquelle: ALKIS Berlin (Amtliches Liegenschaftskatasterinformationssystem)

Tobias: Welche Auswirkung hatte die Funktion eines Gebäudes für deine Auswertung?

Alex: Ich habe für die Berechnung nur Wohnflächen berücksichtigt. Auf der Karte sind daher überall dort Lücken, wo bspw, Kirchen, Schulen, etc. als Gebäudefunktion angegeben sind. Ebenso werden Hinterhöfe, Garagen, Gewerbegebäude, Kleingärten usw. ausgeschlossen. Bei reinen Wohngebäuden habe ich alle Obergeschosse des Gebäudes bei der Wohnfläche berücksichtigt. Bei der Kategorie “Wohngebäude mit Gewerbenutzung”, bei der typischerweise das Erdgeschoss gewerblich genutzt wird, habe ich entsprechend ein Stockwerk abgezogen. Bei der Kategorie “Gewerbegebäude mit Wohnnutzung” ist unklarer, wie viel davon bewohnt wird. Ich habe dann die Hälfte des Gebäudes angerechnet. Das war glücklicherweise nur ein kleiner Teil der Daten. Andere Kategorien, die eindeutig nicht als Wohnraum gedacht sind, habe ich ausgeschlossen.

Einen Teil der Kfz-Daten habe ich übrigens auf alle Gebäude verteilt, und nicht nur auf die Wohngebäude bzw. die Bewohner-Punkte, denn vor allem gewerblich angemeldete Fahrzeuge können ja auch einem unbewohnten Gebäude zugeordnet sein.

QGIS

Tobias: Mit welcher Software hast du gearbeitet?

Alex: Ich habe alles mit QGIS gemacht. QGIS ist ein Geoinformationssystem – Open Source und frei. Da habe ich die Block- und Gebäudedaten aus ALKIS und OSM eingeladen, verarbeitet und die Bevölkerungswerte daraus berechnet. Als Ergebnis bekomme ich dann eine Zahl pro Gebäude, wie viele Menschen hier statistisch zu erwarten sind. Am Ende kann man zufällig genau so viele Punkte über das Haus verteilen wie Menschen dort wohnen, um die Daten sozusagen auf die individuelle Ebene zu bringen.

Wohnen im Kleingarten oder Industriegebiet

Tobias: Was haben wir bisher vergessen?

Alex: Ein interessantes Detail ist, dass ich in einem Kontrollschritt festgestellt habe, dass ich 450 Menschen weniger hatte als tatsächlich in Neukölln leben. Dann ist mir aufgefallen, dass es Häuserblöcke gibt, in denen ich keine Wohngebäude identifiziert und berücksichtigt habe, aber wo tatsächlich Menschen gemeldet sind. Beispielsweise ein einem Kleingartenareal, wo ich erstmal keine Bevölkerung angenommen habe, da man dort meines Wissen nicht wohnen darf. Aber vermutlich haben einige Bewohner dort Bestandsschutz, so dass doch Menschen gemeldet sind. Die fehlenden Personen habe ich dann auf alle Gebäude verteilt.

Tobias: Vielen Dank, Alex, für diese interessanten Einblicke!

In einem nächsten Interview schauen wir auf ein Nebenprodukt deiner Auswertung, die Straßenraumkarte für Neukölln mit einem Schwerpunkt auf Micromapping und Karten-Rendering. Und beides zusammen kann man sich auch schon jetzt anschauen unter https://supaplexosm.github.io/strassenraumkarte-neukoelln/?map=parkingmap#15/52.4772/13.4393.

Location: Neukölln, Berlin, Deutschland

Parkplatzzählung und Parkraumanalysen auf OSM-Basis

Posted by Supaplex030 on 12 March 2021 in German (Deutsch). Last updated on 13 March 2021.

This post is also available in English.

OSM-Daten bieten das Potential, präzise Parkplatzzählungen und Parkraumanalysen durchzuführen und damit wertvolles Wissen für Diskussionen rund um die Verkehrswende, Stadtentwicklung und Mobilität bereitzustellen. Vielerorts gibt es nämlich noch gar kein systematisches Wissen, wo es wie viele Parkplätze am Straßenrand (oder auch darüber hinaus) gibt. In aufwendigen Studien müssen diese Daten bei Bedarf erfasst werden – und meist sind diese Daten anschließend nicht für die Öffentlichkeit zugänglich. Im Gegensatz dazu stellt OSM eine optimale Umgebung dar, in der solche Daten frei zugänglich erfasst und analysierbar gemacht werden können.

Am Beispiel des Berliner Stadtteils Neukölln haben wir demonstriert, wie urbane Parkplätze systematisch auf OSM-Basis kartiert und mit Geoinformationssystemen (hier: QGIS) und unter Einbezug weiterer offener Daten hochaufgelöst ausgewertet werden können. Dieser Blogpost soll euch einen Überblick über die Methodik geben und ein paar wichtige Ergebnisse und Erfahrungen für die OSM-Praxis mit euch teilen.

Einen ausführlichen Blick auf die Ergebnisse und Daten könnt ihr in der Neuköllner Parkraumkarte werfen, in der die Parkplatzinformationen visualisiert werden, die zugrunde liegenden Daten zum Download bereit stehen und bei Bedarf ausführlichere Infos zur Herangehensweise und Methodik zu finden sind.

Parkraumkarte Abbildung 1: Ausschnitt der Parkraumkarte, die auf verschiedenen Zoomstufen verschiedene Ergebnisse visualisiert: Von einzelnen Stellplätzen über straßenzugsweise Stellplatzzahlen bis hin zur Stellplatzdichte und dem Flächenverbrauch durch geparkte Fahrzeuge.

Hinweis: Die hier vorgestellte Parkraumanalyse geht auf erste Experimente im vergangenen Jahr zurück, über die hier damals bereits berichtet wurde. Das Verfahren ist inzwischen weiter automatisiert worden, sodass es leichter auf andere Orte übertragen werden kann. Da OSM-Daten zum Parken am Fahrbahnrand aber bisher an vielen Orten noch nicht zu den „Standardinformationen“ gehören und oft nur rudimentär oder gar nicht erfasst sind, ist es dafür wohl meistens notwendig, diese Daten selbst zu kartieren bzw. zu vervollständigen.

Methodik

Für die hier vorgestellte Parkraumanalyse sind im letzten Jahr zunächst systematisch alle straßenbegleitenden Parkplätze (Parkstreifen am Straßenrand) im Untersuchungsgebiet in OSM kartiert worden – ebenso wie andere relevante Objekte wie Grundstückseinfahrten und Informationen zu Gehwegübergängen (da dort nicht geparkt werden darf). Das zur Erfassung straßenbegleitenden Parkens etablierte OSM-Schema ist das parking:lane-Schema: Auch wenn dieses Schema seine Macken hat, ihm eine Weiterentwicklung an manchen Stellen gut tun würde und es nicht alternativlos ist (siehe letzter Abschnitt), eignet es sich grundsätzlich dennoch sehr gut für Auswertungen wie diese und liefert relativ präzise Ergebnisse. Der Ansatz dieses Schemas ist es, einem Straßensegment jeweils Informationen zum Parken am linken und rechten Fahrbahnrand zuzuordnen. Dazu gehören vor allem die Art des Parkens (entweder Park- oder Halteverbote oder die Anordnung/Ausrichtung der geparkten Fahrzeuge, insbesondere Längs-, Schräg- und Querparken), die Position des Parkens (die Fahrzeuge können auf der Fahrbahn, in einer Parkbucht, auf dem Gehweg, halb auf dem Gehweg oder auf dem Seitenstreifen stehen) sowie Bedingungen und Einschränkungen (Stellplätze können insbesondere für bestimmte Nutzergruppen reserviert, zeitlich begrenzt nutzbar oder gebührenpflichtig sein).

Die Straßensegmente liegen geometrisch als Linienobjekte vor, die geteilt werden können, wenn sich Attribute im Straßenverlauf ändern. Besteht entlang eines Teilabschnitts einer Straße beispielsweise ein Parkverbot, kann dieses direkt über ein eigenes Straßensegment differenziert werden. Kurze und kleinteilige Änderungen (wie Halteverbote vor Einfahrten oder an Gehwegübergängen) müssen – und sollen – nicht gesondert segmentiert werden, da ansonsten eine unübersichtliche Anzahl von Linienstücken entstehen würde und diese Informationen im späteren Verlauf der Auswertung ohnehin aus den entsprechenden OSM-Datenobjekten abgeleitet werden können.

Die Verarbeitung der OSM-Daten erfolgte unterstützt durch Python-Skripte in QGIS (ein Skript zur Erzeugung von Parkstreifen aus OSM-Daten ist hier zu finden) und orientierte sich etwa an dieser Abfolge:

  • Entsprechend der Fahrbahnbreite, die entweder direkt am Straßenobjekt hinterlegt ist oder aus seinen Attributen abgeschätzt werden kann, können die räumlichen Verläufe der jeweils linken und rechten Parkstreifen (durch versetzen) mit ihren jeweils spezifischen Eigenschaften abgeleitet werden.

  • Bereiche, an denen laut Straßenverkehrsordnung ein Park- bzw. Halteverbot besteht oder die sich entsprechend ihrer baulichen Anlage nicht zum Parken eignen, und die nicht bereits durch beschilderte Park- und Halteverbote mit dem parking:lane-Schema abgebildet sind, können anschließend aus den Daten ausgeschlossen werden, in dem dort Abschnitte mit einer vorbestimmten Länge abgetrennt werden. Die Ausdehnung dieser Bereiche ergibt sich aus juristischen Richtwerten oder ihrer typischen baulichen Anlage (z.B. kein Parken 5 Meter vor Kreuzungen oder 15 Meter vor oder hinter einer Bushaltestelle, kein Parken vor Einfahrten, an Fußgängerüberwegen oder im Bereich von Gehwegvorstreckungen etc.).

  • Objekte, die das Parken im Parkstreifenbereich verhindern, wurden vor der Auswertung systematisch kartiert und in einem separaten Arbeitsschritt mit Sicherheitsabständen von den Parkbereichen abgezogen (z.B. Straßenbäume, Laternen, Poller, Bordsteinstrukturen, Fahrradständer und insbesondere beim Parken auf Gehwegen auch Straßenschilder, Straßenmöbel und Gehweg-Einbauten wie Verteilerkästen).

  • Das Ergebnis wurde anschließend für die vorliegende Auswertung auf Fehler überprüft und teils aufwendig manuell nachbearbeitet, um die Präzision der Ergebnisse zu erhöhen (siehe Parkraumkarte). Die allgemeine Aussagekraft der Ergebnisse wäre (bei ausreichend guter Kartierung der wesentlichen Objekte) aber auch ohne eine solche Nachbearbeitung gegeben und ist bei Übertragung auf andere Orte daher eher verzichtbar.

  • Abschließend wurden Stellplatzkapazitäten für zusammenhängende Parkstreifensegmente berechnet (Quotient aus der Länge eines Segments und dem Abstand der dort geparkten Fahrzeuge, je nach Ausrichtung des Parkens).

Parkstreifenabschnitte generieren Abbildung 2: Generierung von Parkstreifensegmenten (blau) und baulichen Park-/Halteverbotszonen (Kreise). Weitere Objektgeometrien, die das Parken verhindern, können an die Parkstreifen gesnappt und von diesen abgezogen werden (hier Fahrradständer im Fahrbahnbereich, gestreifte Flächen). Kleiner Ausschnitt des Untersuchungsgebiets und provisorische Visualisierung während des Berechnungsprozesses.

Die hier vorgestellte Parkraumanalyse berücksichtigt darüber hinaus auch Informationen zu (meist privaten) Stellplätzen abseits des Straßenraums, die ebenso systematisch erhoben wurden. Dazu zählen allgemeine, meist ebenerdige Park- und Stellplätze, Tiefgaragen, Garagen und Carports sowie Parkhäuser. Für diese Objekte kann häufiger eine genaue Stellplatzzahl angegeben werden, da diese oft markiert und abzählbar sind. Aus ihrer Grundfläche (und, bei mehrstöckigen Objekten, ggf. unter Berücksichtigung ihrer horizontalen Ausdehnung) kann die Stellplatzkapazität aber auch hier geometrisch abgeschätzt werden.

Da viele dieser Stellplätze nicht oder nur schwer aus dem öffentlichen Raum zugänglich oder erkennbar sind, wurden für die Erhebung und Vervollständigung dieser Flächen einige externe Geodatensätze einbezogen, die hier in Berlin zum Glück zahlreich in guter Qualität und frei verwendbar vorhanden sind: So wurden Luftbilder systematisch auf Stellplätze in Hinterhöfen etc. geprüft und Tiefgaragenflächen oder Infos zu Garagengebäuden konnten aus dem Amtlichen Liegenschaftskatasterinformationssystem (ALKIS) abgeleitet werden. Nach Plausibilitätsprüfung fanden diese Daten Eingang in die verwendeten Rohdatensätze – insbesondere bei den Tiefgaragen wurden in OSM aber nur die vor Ort überprüfbaren Merkmale hinterlegt, also die Ein- und Ausfahrten, aber nicht die Grundflächen.

Die Stellplatzdaten sind damit nicht nur geometrisch erfasst, sondern können auch zusätzliche Attribute enthalten wie zu Beschränkungen der Nutzung oder Zugänglichkeit (öffentlich/privat/Kunden etc., Gebühren, zeitliche Beschränkungen) und können auf dieser Grundlage gezielt ausgewertet werden.

Bei einer Größe des Untersuchungsgebiets von über 20 km², einer Länge des dortigen Straßennetzes von etwa 170 km, insgesamt 2.200 in OSM gemappten Grundstückseinfahrten und über 2.000 Parkplatzflächen klingt dies zunächst nach erheblichem Arbeitsaufwand. Tatsächlich war es aber innerhalb weniger Monate ohne weiteres möglich, diese Informationen auch als Einzelperson zu erfassen bzw. zu prüfen und zu vervollständigen – umso schneller geht es natürlich, wenn mehrere Mapper arbeitsteilig vorgehen.

Zentrale Zahlen und Ergebnisse

Viele Ergebnisse und Zahlen des Projekts sind in der Neuköllner Parkraumkarte dargestellt und können kaum übersichtlich in Worte gefasst werden. Der Fokus dieses Projekts lag auch eher in der Entwicklung einer Methode und der Bereitstellung der Daten als in der Interpretation von Ergebnissen, daher soll hier nur kurz darauf eingegangen werden. Mehr Daten und Zahlen sind außerdem im Methodenbericht und auf der Datenseite zum Projekt zu finden.

Für den Ortsteil Neukölln, einem großstädtischen Wohnquartier mit etwa 165.000 Einwohnenden, ergaben sich insgesamt über 27.300 Kfz-Stellplätze im öffentlichen Straßenraum. Dazu kommen noch einmal etwa 12.200 Stellplätze abseits des Straßenraums, die sich dauerhaft bzw. über Nacht zum Parken für Anwohnende eignen (sowie 8.100 nicht zum dauerhaften Parken geeignete Stellplätze wie Mitarbeiter- und Kundenparkplätze und knapp 430 ungenutzte Stellplätze, beispielsweise in leerstehenden Tiefgaragen).

Werden die beiden Gewerbegebiete am Rande des untersuchten Stadtteils außen vor gelassen – also nur die Wohnquartiere berücksichtigt – stehen zusammen 35.447 Stellplätze zum dauerhaften Parken zur Verfügung, denen 33.513 angemeldete Kraftfahrzeuge im gleichen Gebiet gegenüber stehen. Theoretisch stehen für jedes Kraftfahrzeug also 1,08 Stellplätze zur Verfügung.

Die Parkraumanalyse umfasste auch eine kleinräumige Berechnung von Stellplatzdichten, wofür ein eigenes Bevölkerungs- und Kfz-Datenmodell auf Grundlage von externen geografischen und demografischen Daten sowie Kfz-Meldedaten entwickelt wurde (Details dazu können im Methodenbericht nachgelesen werden). Damit lassen sich die verfügbaren Stellplätze in einem kleineren Gebiet oder im Umkreis um einen Wohnort mit den tatsächlich dort zugelassenen Kfz ins Verhältnis setzen. Für die Parkraumanalyse wurden diese Stellplatzdichten für eine Distanz von 350 Metern um einen Wohnort – bezogen auf ein engmaschiges Gitternetz – berechnet (350 Meter entsprechen dabei der Nahdistanz um einen Wohnort, also einer Entfernung, die innerhalb von 3 bis 4 Minuten – bei 7 bzw. 5 km/h – fußläufig erreichbar ist). Im Durchschnitt (Median) ergibt sich dabei für die Neuköllner Wohnquartiere eine Anzahl von 835 Stellplätzen (604 davon im öffentlichen Straßenraum) und eine Zahl von 759 zugelassenen Kraftfahrzeugen.

Stellplatzdichte Abbildung 3: Parkraumdichte in den Wohnquartieren des Untersuchungsgebiets: Verhältnis zwischen verfügbaren Stellplätzen und angemeldeten Kraftfahrzeugen im Umkreis von 350 Metern (3-4 Minuten Fußweg) um einen Ort.

Im Zuge der Verkehrswende und den Debatten über lebenswertere Städte stehen die am Straßenrand geparkten Fahrzeuge zunehmend im Fokus, da sie sich vor allem durch einen dauerhaften, vergleichsweise hohen Flächenverbrauch auszeichnen. Allein für die Neuköllner Wohnquartiere kann dieser Flächenverbrauch durch geparkte Fahrzeuge im öffentlichen Straßenraum auf eine Fläche von insgesamt 327.000 Quadratmetern beziffert werden, was 19 Prozent des öffentlichen Verkehrsraumes und 4,4 Prozent der Gesamtfläche des Gebiets entspricht. Parkplätze und Stellflächen abseits des Straßenraumes beanspruchen darüber hinaus noch einmal zusätzlich 171.000 Quadratmeter (2,3 Prozent der Gesamtfläche des Gebiets). In die obligatorischen Fußballfelder umgerechnet bedeutet dies, dass 70 Fußballfelder allein in den Wohnquartieren Neuköllns für stehende Fahrzeuge in Anspruch genommen werden, 46 davon im öffentlichen Straßenraum.

Bewertung von Unsicherheitsfaktoren des Datenmodells

Die vorgestellte Parkraumanalyse basiert auf einem interpolativen Datenmodell, also aus geografischen Daten und empirischen Annahmen abgeleiteten Aussagen und Vereinfachungen, um die (komplexe) Realität modellhaft abzubilden und „berechenbar“ zu machen. Viele der zu Grunde liegenden Annahmen und Ergebnisse können in der tatsächlichen Realität überprüft, gezählt oder gemessen werden, andere unterliegen bestimmten Unsicherheiten, die sich kaum oder nur mit erheblichem empirischen Aufwand quantifizieren lassen.

Da das Straßenparken die Parkraumsituation wesentlich prägt, ist sie das Kernstück des Datenmodells. Zwar wurden die automatisiert erzeugten Parkstreifendaten der vorliegenden Parkraumanalyse einer aufwendigen manuellen Nachbearbeitung unterzogen, allerdings wichen die Ergebnisse dieser Nachbearbeitung nur um 0,6 Prozent von den direkt aus OSM erzeugten Rohdaten ab. An anderen Stellen können aber signifikante Fehlerquellen lauern. So wurden die interpolierten Stellplatzzahlen durch Zählung von über 1.500 Fahrzeugen und Parklücken mit der Realität verglichen (ohne Falschparker dabei mitzuzählen). Dabei zeigte sich mit einer Abweichung von unter einem Prozent zwar eine insgesamt sehr hohe Übereinstimmung, allerdings gab es drei Straßenabschnitte mit auffallend hoher Abweichung. In diesen Straßen, in denen jeweils Schräg- oder Querparken angeordnet ist, überschätzte das Datenmodell den Einfluss von Einfahrten und blockierenden Objekten im Parkraum (Bäume, Straßenlaternen). In solchen Fällen kann es sich also lohnen, das Ergebnis mit der Realität zu vergleichen und ggf. nachzujustieren oder schon während der Erfassung die tatsächliche Anzahl von Stellplätzen anzugeben, wenn diese durch Markierungen eindeutig abzählbar sind. Eine Schätzung von nicht markierten oder klar zählbaren Stellplatzkapazitäten sollte man beim Mapping aber eher vermeiden – das kann ein GIS im Zweifelsfall besser und dabei flexibel auf zugrundeliegende Annahmen wie durchschnittlichen Fahrzeuglängen Rücksicht nehmen.

Darüber hinaus gibt es eine Reihe anderer Faktoren, die zu einer Über- oder Unterschätzung der realen Parkraumsituation im Vergleich zum Datenmodell führen können. Für einige der vermutlich wichtigsten Faktoren wurde eine Schätzung angestellt, um ihren Einfluss bei der Interpretation der Daten berücksichtigen zu können (ausführlicher im Methodenbericht). So bildet das Datenmodell eine juristische, StVO-konforme Situation ab; in der Realität ist jedoch häufiges Falschparken zu beobachten – vor allem zu enges Parken an Kreuzungen oder Parken vor Gebäudedurchfahrten (von denen es in Berlin viele gibt, und die häufig nicht beachtet werden). Nimmt man an, dass vor Kreuzungen im Mittel nur ein Abstand von 2,5 statt 5 Metern eingehalten und vor jeder zweiten Einfahrt geparkt wird, erhöht sich die Zahl der „Stellplätze“ beispielsweise bereits um 6 Prozent. Andererseits gibt es in der Realität insbesondere durch Dienst- und Mietwagen wahrscheinlich auch mehr Fahrzeuge als in der Meldestatistik – dabei kann wohl von einer Größenordnung von etwa 5 Prozent mehr Fahrzeugen ausgegangen werden.

Ein weiterer wesentlicher Faktor: Insbesondere die Stellplatzangaben außerhalb des öffentlichen Straßenraums müssen als theoretisch verfügbare Stellplatzpotentiale verstanden werden und nicht als tatsächlich genutzte Kfz-Stellplätze, da ihre tatsächliche Auslastung meist unbekannt bleibt. Vor allem Garagen werden beispielsweise häufig anders genutzt als zum Abstellen eines Kfz (unter der Annahme, dass jede zweite Garage nicht zum Abstellen eines Kfz genutzt wird, reduziert sich das Gesamt-Stellplatzangebot im Datenmodell beispielsweise um 3 Prozent). Auch die Parkhäuser im Untersuchungsgebiet stehen zwar Anwohnerinnen und Anwohnern zur Verfügung und tragen insgesamt fast 4 Prozent der Gesamtstellplatzkapazitäten im Datenmodell bei, faktisch wird dieses Potential jedoch offenbar nicht ausgeschöpft, da oft ein größerer Leerstand beobachtet werden kann.

Erkenntnisse für die OSM-Mapping-Praxis

Die sehr geringen Abweichungen zwischen den interpolierten bzw. aus den OSM-Daten berechneten Stellplatzzahlen und der realen, gezählten Situation sind im vorliegenden Fall vermutlich auf den vergleichsweise hohen Detailgrad der OSM-Daten im Untersuchungsgebiet zurückzuführen. So wurden beispielsweise die Gebäude- und Grundstückseinfahrten systematisch vervollständigt und teils mit Breitenangaben versehen, auch einige Straßen verfügen über exakte Breitenangaben (OSM-Key: width:carriageway – obwohl sich die Breite einer Straße im Allgemeinen ausreichend genau aus ihren Attributen wie Straßentyp, Einbahnstraße oder Anzahl der Fahrspuren ableiten lässt). Vor allem aber wurden die Parkstreifeninformationen relativ genau erfasst: Ausgeschilderte Park- und Halteverbote wurden dabei ebenso berücksichtigt wie andere Bedingungen zum Parken von „signifikanter“ Länge, auch wenn diese z.B. nur ein 15 Meter langes Straßensegment betreffen. Einige Mapper erschaudern vermutlich angesichts so viel Micro-Mappings – solch präzise Daten können aber nicht nur für ein Projekt wie dieses äußerst wertvoll sein.

In den meisten Fällen ist es aber gar nicht notwendig, Straßen in viele kleinteilige Segmente zu zerstückeln, da sich die relevanten Informationen aus anderen Objekten im Raum ableiten lassen, wenn diese gut erfasst sind: So ist klar, dass auf einem Zebrastreifen, vor einer Bushaltestelle oder im Bereich einer Fußgängerampel nicht geparkt werden darf. Für einige speziellere Situationen haben sich hier in der lokalen Mapping-Community auch neue Tags etabliert, die sich als sehr nützlich für diese Auswertung herausgestellt haben: Insbesondere Details an Gehwegübergängen im Kreuzungsbereich wie Gehwegvorstreckungen oder randseitige Straßenmarkierungen für Fußgänger sind hier vielerorts kartiert (Diskussionen zu solchen Taggings finden hier vor Ort vor allem in der Berliner Verkehrswendegruppe statt und münden z.B. in Empfehlungen wie diese zum detaillierten Mappen von Gehwegübergängen). Auch das neue Schema zum genaueren Kartieren von Parkbuchten (parking=street_side) ist teils vor dem Hintergrund dieser Parkraumanalyse entstanden.

Eine spannende Frage ist natürlich, welchen Einfluss die kartografische Präzision auf das Ergebnis der Parkraumanalyse hat. Im Detail konnte ich das bisher noch nicht ergründen. Bei den ersten Versuchen für solche Parkraumauswertungen vor einem Jahr habe ich aber die Erfahrung gemacht, dass es vor allem bei Schräg- und Querparken (wenn die Fahrzeuge im Winkel zum Fahrbahnverlauf stehen) schnell zu größeren Abweichungen kommen kann, da hier sehr viele Fahrzeuge entlang relativ kurzer Wegstrecken parken. Beginnt das Schrägparken beispielsweise erst 20 Meter hinter einer Kreuzung und wird der Bereich davor nicht mit einer entsprechend abweichenden Parkstreifeninformation erfasst (und ist diese auch sonst nicht aus anderen Objekten ableitbar), summiert sich bereits ein Fehler von mehreren Stellplätzen. Feinteiliges Mappen lohnt sich also insbesondere beim Quer- und Schrägparken.

Die vorliegende Parkraumanalyse zeigt, dass mit einer genauen Kartierung eine äußerst präzise Wiedergabe der Realität erreicht werden kann. Sie ist aber auch an die Grenzen einiger Tagging-Schemata und des „Geschmacks“ einzelner anderer Mapper gestoßen. Alles in allem hat sich OSM aber als perfektes Werkzeug bewiesen, um auch solche speziellen Informationen zu erfassen und analysierbar zu machen. Unglücklich kann manchmal der Umstand erscheinen, dass die Parkstreifeninformationen geometrisch an der Straßenlinie erfasst werden, und nicht dort, wo sie on-the-ground ihren Ursprung haben, nämlich an einer Bordsteinlinie. Zwar gibt es seit ein, zwei Jahren mit CurbLR eine OpenData-Spezifikation zur Erfassung von Parkstreifen an der Bordsteinlinie mit ausführlichen Überlegungen und Tagging-Schema zur Umsetzung in OSM. Dieser Vorschlag hat bisher aber noch keinen Einzug in die tatsächliche Mappingpraxis gehalten. Nach den Erfahrungen, die ich mit der vorliegenden Parkraumauswertung gesammelt habe, hat sich das OSM-parking:lane-Schema aber als ausreichend genau und vermutlich einfacher auszuwertendes Schema erwiesen.

Ich bin gespannt, wie sich der Erfassungsgrad von Parkstreifen in OSM weiter entwickelt. In den letzten beiden Jahren scheint der Gebrauch des parking:lane-Schemas etwas zugenommen zu haben. Ebenso nehmen vor allem in Großstädten die Diskussionen um stehende Fahrzeuge und Flächengerechtigkeit im öffentlichen Straßenraum zu, womit Daten wie die hier vorgestellten eine immer wichtigere Bedeutung in der Stadtentwicklung, Planung und demokratischen Diskussion darum einnehmen werden. OSM hat sich wieder einmal als geeignetes Werkzeug erwiesen, um solche Daten für alle zugänglich zu machen – nun ist es an uns, diese Daten auch zu erfassen.

Location: Neukölln, Berlin, Deutschland

Notizen vom Treffen des OSMF-Advisory-Boards am 24.02.

Posted by imagico on 24 February 2021 in German (Deutsch).

Heute hat der OSMF-Vorstand ein Treffen mit dem Advisory-Board abgehalten. Anwesend waren Vertreter der Local Chapters (so weit ich mich erinnere Italien, Irland, Belgien, Tschechien, Kozovo, Slovakei, Schweiz, UK, US und Deutschland), ein Firmenverterter (Andrew Turner, ESRI) sowie der OSMF-Vorstand (alle anwesend außer Tobias). Im Grunde war es also ein zweites Treffen zwischen dem Vorstand und dem local-chapter-Teil des AB (nach dem ersten Treffen am 5 October 2020) - wenngleich ich es ausdrücklich würdigen möchte, dass Andrew Turner teilgenommen hat, während die übrigen Firmenvertreter durch Abwesendheit glänzten (und vermutlich ihre Separat-Treffen mit dem Vorstand bevorzugen). Ich will das heutige Treffen hier noch mal detailliert kommentieren, da es mein letztes Treffen dieser Art sein wird (ich trete auf der Mitgliederversammlung des FOSSGIS im März wie bereits erwähnt nicht mehr für diese Funktion an) - in der Hoffnung, dass die geschilderten Erfahrungen für andere in der Zukunft von Nutzen sind.

Es gab eine Tagesordnung mit fünf Punkten und einem engen Zeitplan, der - durchaus erwartbar - am Ende um 50 Prozent überschritten wurde. Abgesehen von der Runde zu den Plänen 2021 der Local Chapters (wo jeder was gesagt hat) war das Treffen von den Gesprächsanteilen vom Vorstand dominiert, gefolgt von den englischen Mutterprachlern aus den LCs (insbesondere Rob und Dermot). Ich hab von den nicht englischen Mutterprachlern vermutlich am meisten geredet, aber insgesamt wohl nicht mehr als etwa 3 Prozent der Zeit.

Nachdem ich beim vorherigen Treffen den Eindruck hatte, dass dieses vor allem auch wegen fehlender Vorbereitung wenig produktiv war, hab ich dieses Mahl ein bisschen Zeit in die Vorbereitung investiert und meine Notizen dazu den anderen vorher zugänglich gemacht. Diese sind auch im folgenden auf Englisch enthalten. Geholfen hat das nicht allzu viel, eine tiefer gehende Diskussion zu den Themen kam kaum zustande. Das ist jetzt nicht wirklich verwunderlich und auch nichts, wo man irgendjemandem jetzt individuell einen Vorwurf draus machen kann. Meine Schlussfolgerung ist aber im Grunde, dass für die Aufgabe, die das Advisory-Board meiner Ansicht nach haben sollte und hat, live-Audio/Video-Treffen ein wenig geeignetes Format sind. Selbst mit umfassender Vorbereitung aller Teilnehmer auf die Themen und unbegrenzt verfügbarer Zeit wäre so was in Anbetracht der kulturellen und sprachlichen Vielfalt im AB eine riesige Herausforderung. Und in einem eng getakteten Zeitplan mit 10-Minuten-Slots für die Themen ist das praktisch unmöglich.

Board to share themes & plans from the 2021-02 Board Screen2Screen meeting - Rory (Board)

Der Vorstand hat hier ein bisschen von seinem internen Klausur-Treffen berichtet, aber recht allgemein, weniger ins Detail eigentlich als die veröffentlichten Notizen.

Gab dazu keine Fragen oder Kommentare.

Meine Notizen aus der Vorbereitung

  • suggest to discuss the matters openly with the community, ideally before they are discussed in depth within the board and plans have already been made.
  • comprehensive discussion of all the individual topics probably far outside the scope of an AB meeting, board should be specific on what they seek advice on from the AB.

roundtable update: 2021 plans from local chapters and companies? - Mikel (Board)

Hier wurden die Vertreter im Advisory-Board Reihe um gebeten, die Pläne ihrer Organisation für das nächste Jahr vorzustellen. Jeder hatte dafür maximal eine Minute, war also nicht viel zu sagen. Ich hab im Wesentlichen meine Notizen wiedergegeben:

  • first virtual FOSSGIS AGM in March
  • virtual 2021 FOSSGIS conference in June
  • further explore and improve on use of virtual meetings to maintain social connections within the OSM community (both locally in Germany as well as across borders)

Delegating some microgrant decision-making to Local Chapters - Jez (OSMUK)

Das war ein Punkt, der von OSMUK vorgeschlagen worden war. Meine Vorbereitungs-Notizen dazu:

  • could be of value if there is substantial delegation of decision making powers, not if it just means the LCs - like the microgrants committee - do the work but the board has the ultimate decision on everything.
  • so far there has been complete silence from the OSMF on the microgrants after the announcement of the recipients.
  • subsidiarity - local microgrants should be prioritized over OSMF ones.
  • learn substantially from LC microgrants for OSMF microgrants (missed opportunity during first round).

Die Diskussion war nicht sehr konkret. Ich hatte ein bisschen den Eindruck, dass es in erster Linie um die Idee ging, für das eigene LC ein Kontingent oder ein Stimmrecht oder schlicht und einfach einen Batzen Geld zum Verteilen zu bekommen. Ich hab noch mal kurz beschrieben, wie im FOSSGIS das Förderprogramm läuft und ansonsten auf die Punkte in den Notizen verwiesen.

Positiv zu erwähnen ist, dass der Vorstand hat durchblicken lassen, dass er sich bewusst ist, dass da bei den Microgrants eine ganze Menge unbearbeitete Hausaufgaben bei der OSMF liegen (Details).

How will OSMF ensure progress is made on infrastructure things that are stuck? See examples below. - Rob (OSMUK)

  • Translations on diary posts (this was an action from last year’s OSMF Board & LC meeting). How to move the issue on?
  • Mailing lists migration to Discourse (GH issue)

Das war einer von zwei Punkten, die Rob eingebracht hatte, der andere war die OSM-Webseite, der hat es aber nicht auf die Tagesordnung geschafft. Meine Notizen sind deshalb aus beiden Punkten aggregiert:

  • decisions on the OSM website are traditionally made through do-ocracy and community consensus and out of scope of the OSMF. That means if someone makes a concrete suggestion to change something on the website, discussion will attempt to reach consensus on this. For larger changes this has historically been a wider discussion.
  • unless the OSMF board decides to take control of the website i would not be comfortable discussing this on the AB and subvert do-ocracy and community consensus building. Discussion of OSM website design questions should happen in public, be open to everyone and be based on concrete do-ocratic proposals.
  • the OSMF could of course support translations in general by supporting development and access to translation tools and sevices.
  • in any case mind the FOSS policy (https://wiki.osmfoundation.org/wiki/FOSS_Policy: “All software used to run the core website and API services of OpenStreetMap will always be open.”)
  • the OSMF providing a new communication platform/channels (discourse) - it seems that matter is currently in the stage of early consideration of feasibility. Volunteer support for OSM systems integration would probably be welcome but without the OWG stating that other forms of support are explicitly wanted there does not appear to be anything the AB can productively do.
  • the question if individual communities using certain communication channels in OSM would like to migrate to a new platform. While there have been some preliminary discussions on this on the forum IIRC that practically can only be decided through consensus of the specific community on every single of the communication channels after it is clear and can be tested what functionality the new platform will offer practically.
  • i would strongly advise against trying to forcibly unify and homogenize different communication channels with different social traditions, conversation styles or subcultures - see also Andy Allan’s comment on github on this (https://github.com/openstreetmap/operations/issues/377#issuecomment-602457045)
  • diversity is a major asset of OSM - also in communication channels.

In der Diskussion ging es in erster Linie um Discourse wenngleich Rob auch versucht hat, das Webseite-Thema mit anzuhängen. Die Diskussion blieb aber oberflächlich (Notwendigkeit eines Ersatzes für die aktuelle Software auf help.openstreetmap.org und dem Forum, wenngleich die eigentliche Motivation bei manchen recht klar primär zu sein schien, das bei ihnen verhasste Medium Mailigliste aus OSM zu verbannen). Gab auch natürlich wieder das bekannte Framing der Fragmentierung in der OSM-Community (Context). Kurz zusammengefasst: Im Westen nichts neues.

Dankenswerterweise wurde von Guillaume zumindest erwähnt, dass die OSM-Webseite eigentlich nicht zum Aufgabenbereich der OSMF gehört. Interessant war auch zu hören, dass es anscheinend konkrete Pläne vom OSMF-Vorstand gibt, jemanden für Arbeit zu Discourse zu engagieren (der verwendete Begriff war ‘hire’ - es ist aber schon bekannt, dass der OSMF-Vorstand diesen auch für unabhängige Ausftragsnehmer (contracting) verwendet) - etwas, das bis dahin nocht nicht öffentlich bekannt war.

Report on OSMF Survey - Allan (Board)

Hier hat Allan die Ergebnisse der vom Vorstand durchgeführten Umfrage der OSM-Community vorgestellt und es wurde zum ersten Mal deutlich, wie der OSMF-Vorstand anscheinend beabsichtigt, die Ergebnisse politisch zu verwenden. Ich hatte die bis dahin veröffentlichten Ergebnisse schon angeschaut und auf Grundlage davon folgende Notizen gemacht:

  • Preliminary comments based on what has been published so far on (https://wiki.osmfoundation.org/wiki/2021_Survey_Results) - which looks very promising in terms of plans to transparently publish results as far as possible while preserving anonymity.
  • already commented in details on issues with the survey design (https://www.openstreetmap.org/user/imagico/diary/395471), lack of outside review has led to serious missed opportunity.
  • survey results will reflect communication differences (variability in understanding of the questions, variability in baseline for the answers and how to articulate ‘none of the above’ answers in the absence of such option) at least as much as sentiments regarding the subject matter.
  • surveys are not a suitable substitute for argument based discourse, on most of the subjects the board has not engaged in an open argument based discourse with the community so far.
  • missing in published data so far: Free form answers in original language and identification if the text is a translation.
  • p-test indicates probability that the results can be explained by null hypothesis, nothing else.
  • beware influences of undertermined demographic biases. The composition of respondents from one country/gender or other group could for example differ significantly from the rest in terms of education levels, wealth, social environment or other factors and the difference in response could be due to the latter and not the former.

Allan hat in der Präsentation recht viel Zeit und Energie darauf verwendet, die Behauptung zu untermauern, die Erhebung wäre weitgehend frei von Verzerrungen (Bias) und würde ein repräsentatives Meinungsbild der OSM-Community darstellen. Weiterreichende Schlussfolgerungen wurden noch nicht gezogen, aber wesentliche Punkte schienen zu sein:

  • Der Vorstand sieht sich in seinen Entscheidungen aus dem vergangenen Jahr bestätigt.
  • Der Vorstand sieht sich auch in seiner Priorisierung von Zielen für die nähere Zukunft bestätigt, wenngleich Details in der Reihenfolge der Prioritäten ein bisschen Erstaunen hervorgerufen haben.
  • Bezüglich der Frage zur Verwendung von Maschinenlernen im Mapping wurde konstatiert, dass eine Mehrheit der Befragten die Entscheidung dazu den lokalen Communities überlassen möchte.
  • Bezüglich der Frage zu vector tiles auf osm.org war die Schlussfolgerung, dass es keine klare Mehrheit für aktive Maßnahmen der OSMF gibt.

In der Diskussion habe ich erwähnt, dass ich der These, dass die Erhebung keine wesentlichen Verzerrungen (bias) aufweist, nicht zustimmen würde. Allan hat zum Beispiel eine signifikant höhere Zustimmung von Frauen aus Deutschland und Frankreich im Vergleich zu Männern zur Diversity-Politik des Vorstands konstatiert. Abgesehen davon, dass hier Deutschland und Frankreich herauszugreifen, wärend zu keiner anderen Region eine vergleichbare Analyse durchgeführt wurde, einen recht merkwürdigen Schwerpunkt setzt und dass eine Zustimmung zur Frage F1 kaum als allgemeine Zustimmung zur Diversity-Politik des Vorstands interpretiert werden kann, ist die Annahme, dass die männlichen und weiblichen Teilnehmer an der Umfrage abgesehen vom Geschlecht vergleichbar sind natürlich nicht belegt. Folglich: Auch wenn es durchaus einleuchtend wäre (um icht zu sagen: naheliegend), wenn Frauen und Männer zum Themengebiet der Frage F1 im statistischen Mittel eine unterschiedliche Haltung haben, steht die Behauptung, dass die Umfrage-Daten dies für Deutschland und Frankreich belegen, auf sehr dünnem Eis. Praktisch ist dies in diesem Fall nicht so sonderlich wichtig, da es sich wie gesagt nicht um eine wirklich überraschende Schlussfolgerung handelt, es besteht aber eine erhebliche Gefahr, dass die Interpretation der Umfrage nach diesem Schema hochgradig zu einer Kaffeesatz-Leserei ausartet, wo jeder das in die Daten hineinliest, was er da drin sehen möchte.

Es gab zur Umfrage eine ganze Reihe von durchaus interessanten Kommentaren verschiedener Teilnehmer, die ich aber aus dem Gedächtnis nur ungenau wiedergeben könnte - deshalb sei hier auf das offizielle Protokoll der Sitzung verwiesen, wenn dieses verfügbar ist - wie auch zu Details zu den übrigen Punkten.

Erster

Posted by Synkopenleben on 13 February 2021 in German (Deutsch).

Überschrift

  • Übermensch
  • Über Synkopenleben gibt es hier fast nichts zu erfahren.
Location: Garitz, Bad Kissingen, Landkreis Bad Kissingen, Bayern, 97688, Deutschland

Letzter Bericht aus dem Advisory-Board

Posted by imagico on 18 January 2021 in German (Deutsch). Last updated on 19 January 2021.

Der FOSSGIS wird voraussichtlich im März seine Mitgliederversammlung veranstalten - dieses Jahr natürlich virtuell - was ich ungeachtet der oft durchaus netten Atmosphäre, die auf FOSSGIS-Versammlungen traditionell herrscht, für eine gute Entwicklung halte, da sie deutlich mehr Leuten, insbesondere auch aus der OSM-Community, die Chance gibt, daran teilzunehmen.

Für die Mitgliederversammlung möchte ich hiermit, diesmal aus Gründen, die ich erläutern werde, schon deutlich im voraus, meinen traditionellen Bericht als Vertreter des FOSSGIS im Advisory-Board der OSMF geben.

Dieser Bericht fällt dieses Jahr sehr knapp aus, denn wie schon im letzten Jahr erwähnt, ist das Advisory-Board der OSMF als Ganzes so gut wie tot. Der Vorstand konnte sich bis jetzt nicht dazu aufraffen, das Gremium tatsächlich offiziell zu schließen, aber seit der OSMF-Vorstand mit den Firmenvertretern im Advisory-Board regelmäßig nicht öffentliche Gespräche führt, hat im Advisory-Board als Ganzem nichts mehr von Substanz stattgefunden.

Was im letzten Jahr neu eingeführt wurde, sind die 10-Minuten-Präsentationen der lokalen OSM-Communities in den öffentlichen OSMF-Vorstands-Sitzungen. Wir waren da im August dran, Interessierte aus dem Verein waren vorher zu einem Mumble-Meeting eingeladen, um zu diskutieren, was wir da präsentieren wollen. Die Präsentation hat Hanna aus dem FOSSGIS-Vorstand gehalten. Neben dieser regulären, dauerhaften Rolle der lokalen Vertretungen, welche zunächst im Grunde die einzige Rolle war, die aus dem Advisory-Board erwachsen ist (die Unternehmens-Vertreter bekamen ein monatliches Privat-Meeting, die lokalen Vertretungen einen 10-Minuten-Präsentations-Slot in einem öffentlichen Meeting) gab es dann im Oktober noch ziemlich ad hoc eine Einladung zu einem Live-Meeting der Vertreter der local chapters mit einigen Mitgliedern des Vorstands. Es gibt von diesem Treffen noch kein Protokoll, anwesend waren von den lokalen Vertretungen neben mir so weit ich mich erinnere Rob von OSM UK, Dermot von OSM Ireland und Edoardo von OSM Oceania. Es wurden einige Themen angeschnitten, aber auch aufgrund der Tatsache, dass nur wenige Vertreter der lokalen Vertretungen anwesend waren und da kein klares Mandat existierte, welche Funktion diese Art von Treffen haben soll, gab es keine Ergebnisse von Substanz oder einen detaillierteren, vorbereiteten Austausch von Ideen, wie es für ein Berater-Gremium wünschenswert wäre. Ob das zu einer regelmäßigen Veranstaltung werden soll, ist noch nicht klar. Daneben gibt es jetzt in der OSMF auch eine wieder neu geschaffene Arbeitsgruppe LCCWG, wo einige Vertreter von lokalen Vertretungen sich engagieren, deren Funktion in der OSMF aber auch recht unklar ist und wo anders als im Advisory-Board nicht alle lokalen Vertretungen gleichberechtigt eine Stimme haben, die kulturell und sprachlich viel homogener ist und und deren Aktivitäten bis jetzt auch recht spezielle Interessen vertreten.

Insgesamt kann man die Situation der lokalen Vertretungen in der OSMF derzeit also als recht fluide und undefiniert betrachten. Das birgt Potential, Entwicklungen anzustoßen aber keine Verlässlichkeit was Rollen und Einfluss-Möglichkeiten betrifft. Vor diesem Hintergrund hatten wir im letzten Jahr schon ein paar Ansätze gemacht, von Seite des FOSSGIS außerhalb des Advisory-Board Stellungnahmen zu aktuellen Themen in der OSMF abzugeben. Dazu haben wir einige OSMF-Stammtische auf Mumble abgehalten. Als tatsächliche Stellungnahme des FOSSGIS wurde am Ende nur etwas zu bezahlten Kräften in der OSMF veröffentlicht (auch auf Englisch), aber auch die Diskussionen zu anderen Themen waren nützlich. Ich war an diesen Diskussionen beteiligt, aber nicht federführend - Hanna und Michael (Nakaner) haben hier auch erheblich zu beigetragen. Der Unterschied ist natürlich, dass sowas immer nur das Resultat einer Diskussion in der deutschen OSM-Community unter sich ist, während die Idee des Advisory-Board es ursprünglich war, durch einen Austausch zwischen den verschiedenen lokalen Vertretungen Ratschläge und Ideen zu entwickeln, die darüber hinaus gehen, was aus den einzelnen lokalen Communities für sich genommen entwickelt werden kann.

Auf der Mitgliederversammlung des FOSSGIS steht auch die Wahl der Vertretung des FOSSGIS im Advisory-Board an. Und auch wenn das Gremium wie erläutert als Ganzes weitgehend tot ist, fungiert diese Vertretung für den OSMF-Vorstand doch als Ansprechpartner und sollte deshalb vom FOSSGIS und der deutschen OSM-Community produktiv genutzt werden.

Ich verrichte diese Aufgabe jetzt seit drei Jahren und habe schon letztes Jahr angekündigt, dass ich es gut fände, wenn da jemand anderes übernehmen würde und frischen Wind in die Rolle einbringt. Das möchte ich jetzt forcieren und kündige deshalb an, dass ich für die Rolle bei der Wahl im März nicht mehr antreten möchte.

Vor diesem Hintergrund möchte ich noch einen kritischen Gesamt-Rückblick auf die letzten drei Jahre anschließen. Bin ich mit dem, was ich während dieser Zeit erreichen konnte, zufrieden? Sicherlich nicht in jeder Hinsicht. Was mich im Rückblick am meisten ärgert ist, dass ich es nicht geschafft habe, mit anderen lokalen Vertretungen ein Gegengewicht zur englischsprachigen Dominanz in der OSMF zu organisieren. Dies hat sicherlich viel mit der Sprach-Barriere zu tun. Dem FOSSGIS käme hier als dem mit großem Abstand größtem nicht englischsprachigem local chapter eine zentrale Rolle zu, dennoch wäre es für eine solche Initiative essentiell, sich mit anderen nicht englischsprachigen lokalen Vertretungen zu koordinieren, hier insbesondere natürlich die französische, was durch entsprechende Sprachkenntnisse deutlich einfacher wäre.

Ich habe allerdings auch den Eindruck, dass im FOSSGIS der Wille und die Bereitschaft, eine solche Rolle als Gegengewicht gegen die englischsprachige Dominanz in der OSMF einzunehmen, recht begrenzt sind und viele mit der Situation wie sie ist eigentlich recht zufrieden sind und wenig Bedarf nach substantiellen Änderungen sehen. Meine Wahrnehmung, dass aus der Größe und Bedeutung der deutschen OSM-Community hier eine moralische Verpflichtung resultiert, sich für mehr sprachliche und kulturelle Vielfalt und Repräsentation in der OSMF generell einzusetzen, ist eher ein persönlicher Spleen von mir als eine im FOSSGIS verbreitete Überzeugung. Und natürlich sprechen viele im FOSSGIS Englisch besser als jede andere Fremdsprache und die meisten fühlen sich auch der britischen und amerikanischen Kultur näher als den meisten anderen einschließlich der europäischen Kulturen.

Positiv verbuchen möchte ich vor allem, dass es mir während der drei Jahre recht erfolgreich gelungen ist, zu vermeiden, dass das Advisory-Board zu einer Lobbying-Plattform für Unternehmens-Interessen verkommt. Die Bedeutung dieses Einflusses der Repräsentanten der lokalen Communities ist denke ich vielen erst in Nachhinein klar geworden, als, nachdem der OSMF-Vorstand begonnen hat, sich separat mit den Unternehmensvertretern zu treffen, diese sofort begonnen haben, diese Treffen rücksichtslos zum Lobbying und für Einschüchterungs-Versuche gegenüber dem Vorstand zu nutzen. Dass der wichtigste Verdienst aus meiner Zeit im Advisory-Board es also möglicherweise ist, etwas verhindert zu haben, anstatt positiv etwas erreicht zu haben, ist natürlich etwas bedenklich. Überspitzt-kritisch zusammengefasst könnte man auch sagen, dass das Advisory-Board ein vierjähriger Stand-off zwischen den kurzfristigen Profitinteressen größtenteils amerikanischer Unternehmen und den Wertvorstellungen größtenteils europäischer Craft-Mapper-Communities war. Ob das ja jetzt definitiv eingetretene Ende dieses Patts langfristig zu positiven oder negativen Entwicklungen führt, wird sich erst noch herausstellen.

Was sollte ein Kandidat/eine Kandidatin für diese Rolle an Qualifikation mit sich bringen? Neben Verständnis für und Erfahrungen mit der deutschen OSM-Community und Erfahrungen mit der OSMF halte ich möglichst breite Sprachkenntnisse für recht bedeutend. Ich glaube, dass meine eigene Wirksamkeit, im Advisory-Board positiv etwas zu bewirken, vor allem auch dadurch begrenzt war, dass der Austausch und die Koordination mit den anderen lokalen Vertretungen nur auf Deutsch oder auf Englisch möglich war. Wer hier zusätzliche sprachliche Fähigkeiten vorweisen kann, wäre enorm im Vorteil. Daneben sind denke ich vor allem ein gutes Urteilsvermögen und eine Unabhängigkeit von wirtschaftlichen Partikularinteressen im OSM-Umfeld sowie eine Fähigkeit, sich in der englischsprachigen Kommunikation mit Muttersprachlern artikulieren und behaupten zu können, von Nutzen.

Was ich auf jeden Fall anregen möchte, ist, dass diese Funktion des FOSSGIS nicht nebenbei von einem Mitglied des FOSSGIS-Vorstands übernommen wird, sondern eine separate Rolle bleibt.

Wer sich für die Aufgabe interessiert, aber nicht sicher ist, ob das zu ihr oder ihm passt, kann mich gerne nach meiner Meinung oder zusätzlichen Informationen fragen.

Mappen: Grundriss oder Markanter Umriss?

Posted by Robhubi on 14 January 2021 in German (Deutsch). Last updated on 15 January 2021.

Die reine Lehre ist da eindeutig: der Grundriss soll dargestellt werden. Gut, was aber, wenn (a) der Grundriss nicht sichtbar und (b) er völlig anders aussieht, als die Umrisse im Luftbild? Welche Darstellung bringt mehr Vorteile?

Der betreffende Gebäudekomplex hat funktionell 2 Ebenen: die Geschäftsebene besteht aus einem großen Parkplatz, einem Supermarkt und weiteren Geschäften. Diese Ebene bildet das Erdgeschoß und ist vollständig überdacht. Die zweite Ebene - die Wohnebene - besteht aus vier Wohngebäuden, die auf der Überdachung gründen.

Zu dem Zeitpunkt waren in OSM die Wohngebäuden aus dem Luftbild gemappt. Für die Orientierung im Gelände war dieser markante Umriss sicher vorteilhaft. Andererseits, ist nicht die Lage eines Parkplatzes zu einem Supermarkt von noch größerem Interesse?

Abb1: Bauphase Projekt “City Gate” im Luftbild (li) und in OSM (re)

CG01_Luftbild

Ich meine ja und habe mich daher entschlossen, das bestehende Mapping abzureißen und neu aufzubauen. Doch halt, abreißen ist nicht gerade die feine, englische Art, also besser umbauen. Die Idee: Grundriss wie üblich in 2D darstellen und bestehende Wohngebäude in 3D überführen.

Abb 2: Restrukturierung in OSM. Grundriss in 2D (Level 0), Gartendeck und Wohngeschoße in 3D (Level 1 bis Level 15). (c) OpenLevelUp! und (c) OpenStreetMap Contributors

CG02_restruk

Mapping 2D

Die Gebäudeteile im EG sind über eine Multipolygon Relation zusammengefasst. Prinzipiell ist das nicht notwendig, aber es erleichtert die Selektion, da doch sehr viele 3D-Linien darüberliegen.

Linien Tags
CG03_multipoly Relation
— type=multipolygon
— landuse=residential

Mitglieder
outer
— (ohne Tags)
inner
— building=yes
— height=3.5
— level=0

Mapping 3D

Die 3D-Gebäude sind in einer Building Relation zusammengefasst. Die Rolle outline fehlt per Design, da der Grundriss unabhängig davon modelliert wurde.

Linien Tags
CG03_multipoly Relation
— type=building

Mitglieder mit Rolle part
— building:part=yes
— height=…
— min_height=…
— building_levels=…
— building:min_level=…

Darstellung in Karten

Bei diesem Design ist die Grundrissdarstellung vollkommen unabhängig von der darüberliegenden 3D-Struktur. Das störungsfreies 2D Rendering war daher zu erwarten. Die 3D-Struktur ist durch das fehlende outline-Mitglied eine wenig ungewöhnlich. Die meisten der getesteten 3D Renderer kommen aber damit zurecht:

Kendzi 3D - ok
OSM Buildings - ok
3Dbuildings - ok
OSMgo25 - fast ok, Stiegenhaus 165 fehlt
F4map - ok

Resümee

Die in der Realität vorhandene, deutliche Trennung der Geschäftsebene von den darüberliegenden Wohnebenen lässt sich gut in den OSM 2D- bzw. 3D-Datenstrukturen spiegeln.

Edit 16. Jän. 2021: F4map rendert nun alle Gebäudeteile, ohne dass die Datenstruktur geändert wurde.

Location: Air Liquide, Liebenau, Graz, Steiermark, 8041, Österreich

WillhemburgerReichsstrasse

Posted by Bernd Böhmer on 11 January 2021 in German (Deutsch).

Hallo, seit Mitte Dezember 2020 sind die Baustellen auf der WillhemburgerReichsstrasse weg und alle Geschwindigkeits Begrenzung aufgehoben. Wann wird das hier im System geändert? Ich bekomme dadurch immer eine Schlechte Bewertung!!!! Mit noch freundlichen Grüßen Bernd

Quatsch-tags an Autobahnen...

Posted by MKnight on 5 January 2021 in German (Deutsch).

Haben wir - zumindest in .de - 2021 auch endlich überwunden.

Gut, da fehlen noch ein paar in der Liste, wie boat=no oder dog=no und dergleichen, die waren allerdings immer schon™ eher unterrepräsentiert.

(gezählt wurde ausschliesslich highway=motorway, kein Link etc.)