sha256-Hash der entsprechenden Datei als Nachweis für dieses Profil: 93e9f0fb9f2be28a9b54ad96f78d11a7895eb1e730f6fcd0754a7062813aeb0b
Test
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:
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.
The local open-government-data GIS shows only two levels of forestry organisation:
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.
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.
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?
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.
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?
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.
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
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
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.
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.
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.
no-track.osm
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
user
uid
osmium getid --id-osm-file no-track.osm --with-history extract.osh.pbf -o no-track.osh.pbf
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:
highway
track
grep
awk
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
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.
osm-tag-csv-history
Zu der in den bisherigen Schritten erzeugten .osm-Datei wird zunächst eine History-Datei erzeugt:
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:
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
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.
Ich habe diese Teststationen wie folgt auf OSM eingetragen:
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.
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.
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.
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?
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.
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).
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.
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.
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:
Sowohl links und rechts (rechts nicht abgebildet).
Die gleiche auf die Brust; deshalb ist auch der Reißverschluss so schief.
Innen zwei großzügige Taschen zum Halten einer Power-Bank, dem Kabel dazu und eventuell irgendwelchen Krams.
Ans Ende der Handytaschen habe ich ein kleines Loch geschnitten innen für das Ladekabel:
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).
Und ein solider Haken darf nicht fehlen!
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 Schulter Links Nach vorn
Altes iPhone 4 zur Seite (iPhone 8 nach vorn wird noch verarbeitet) Theoretisch könnte ich also mit drei Handys gleichzeitig aufnehmen, hab nur keine drei.
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.
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.
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.
Genauso am anderen Ende, dann aber einfach übertrieben mit Lochband. Am Ende wackelt es noch immer ein wenig, aber das muss so gehen.
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.
Da das ganze noch drohte Windschief sich zu verziehen habe ich den Hohlraum kurzerhand “bespannt”:
So passt das dann in den Rucksack, ist dort also nicht permanent fixiert:
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.
Die Konstruktion sieht nicht so prickelnd aus, aber funktioniert super, und der Rucksack verbirgt das Schreinerische Grauen.
Das ganze könnte noch ein wenig weiter vom Kopf weg sein nach hinten, mit dem Helm stoße ich da manchmal hinten an.
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.
Aber ich stehe ja nicht immer…
Sobald es Dunkel wird, sieht es nicht mehr so gut aus.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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
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:
Das war ein Punkt, der von OSMUK vorgeschlagen worden war. Meine Vorbereitungs-Notizen dazu:
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).
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:
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.
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:
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:
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.
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.
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)
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
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.
Die 3D-Gebäude sind in einer Building Relation zusammengefasst. Die Rolle outline fehlt per Design, da der Grundriss unabhängig davon modelliert wurde.
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
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.
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
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.)
