Schlagwort-Archive: Schwarmintelligenz

Hydrantenmapping in OpenStreetMap – Schoener leben mit Fast-Linked-Open-Data

Ich hatte neulich zweieinhalb Wochen Urlaub und bin dabei unvermittelt in eine ganze Reihe von Rabbit Holes gefallen, in die ich mich ueber den Urlaub hinweg reingegraben habe. Das ueberrascht niemanden, die/der mich kennt, aber ich fand die Zusammenhaenge dazwischen so spannend, dass ich das mal aufschreiben wolle.

Alles fing mit einem Abend in der Feuerwehr an. Wir sollten ueber mehrere Abende alle Hydranten im Ortsgebiet anfahren, kontrollieren, spuelen und – wo noetig – Maengel aufschreiben. Fehlt ein Hinweisschild eines Unterflurhydranten, laesst sich ein Hydrant nicht vernuenftig oeffnen – oder aber auch, sind neue hinzugekommen, die wir nicht in unserem Hydrantenplan haben. In einer idealen Welt gaebe es natuerlich einen gut funktionierenden Austausch zwischen Gemeinde, Wasserversorger und Feuerwehr, so dass alle immer denselben Zustand dokumentiert haben. Aber ich muss ja niemandem erzaehlen, dass wir nicht in einer perfekten Welt leben.

Wo sind Hydranten – von analog zu digital?

Als ich 1999 zur Feuerwehr kam, bestand der Hydrantenplan aus einer fotokopierten Ortskarte, in die mit roter und blauer Farbe die Ueber- und Unterflurhydranten haendisch hineingemalt worden waren. Kurz darauf erstellten zwei Kollegen quasi ein „Lookbook“, in dem jeder der Hydranten mit einem Foto des Umfelds und einer kurzen Beschreibung je eine Karteikarte in einem Ordner bekam, die dann alle alphabetisch nach Strassennamen sortiert waren.

Beide Ansaetze haben Vor- und Nachteile: Bei der Uebersichtskarte sieht man stets den geographischen Kontext – gerade Unterflurhydranten tarnen sich aber gelegentlich recht gut in ihrer Umgebung, so dass man sie nicht immer leicht findet. Das Umfeldfoto hilft beim Auffinden, dafuer kann man ohne eine Kontext-Karte umliegende andere Hydranten uebersehen, die in einer anderen, aber nahen Strasse liegen.

Wegen eines anderen Urlaubs-Rabbitholes kam ich daher recht schnell auf die Idee, Umfeldfotos und Karte mit Koordinaten zu verbinden – und was laege da naeher, als eine gute Vermessung mit Hilfe von OpenStreetMap und Wikimedia Commons!

Die ersten Hydranten habe ich ganz klassisch nur per Smartphone positioniert. Da wir im temporaerhaus aber seit diesem Jahr einen echtzeitkinematikfaehigen simpleRTK2B-GNSS-Empfaenger samt passender Antenne haben, wollte ich das natuerlich etwas genauer haben 😉 Und so kam es zu einem unvorhergesehenen Projekt zwischen temporaerhaus und Feuerwehr Altenstadt.

Und was mappt man da?

RTK-Mapping: Positioniere Antenne ueber Hydranten, warte auf RTK-Fix, trage Position und Tags in OSM ein. Links ein alter Erhard-Ueberflurhydrant, rechts ein Unterflurhydrant.

Eigentlich alles, was in emergency=fire_hydrant auf OSM beschrieben ist. Um moeglichst alles abzudecken, kann man recht einfach zwischen Tags fuer alle Hydranten und Erweiterungen jeweils fuer Ueber- und Unterflurhydranten unterscheiden:

Fuer alle Hydranten

refDie Hydrantennummer auf dem Hinweisschild oder dem Hydranten selbst – sofern vorhanden
fire_hydrant:pressureDas laesst sich quasi nie ermitteln, d.h. hier einfach yes
fire_hydrant:positiongreen fuer Gruenflaeche, lane fuer die Fahrbahn, sidewalk fuer den Gehweg und parking_lot fuer Parkplaetze. Insbesondere bei Unterflurhydranten ist es super gut zu wissen, ob er auf einer Parkflaeche liegt!
water_sourcein der Regel main, also die abhaengige Loeschwasserversorgung
survey:dateDas Datum, an dem du diesen Hydranten eingetragen hast, YYYY-MM-DD
Auf solch einem Hinweisschild ist normalerweise haeufig eine Identfikationsnummer zu sehen. Hier aber leider nicht. Immerhin laesst sich der Leitungsdurchmesser 80 mm durch das „80“ rechts vom „H“ ablesen.

Speziell fuer Unterflurhydranten

fire_hydrant:typeunderground
fire_hydrant:diameterDas ist der Wert auf dem zugehoerigen Hydrantenschild – sofern das vorhanden ist! Falls keines vorhanden ist, siehe…
fire_hydrant:diameter:signed=noWenn kein Hinweisschild vorhanden ist. Dadurch lassen sich auch leicht die Hydranten ohne Schilder spaeter ermitteln

Speziell fuer Ueberflurhydranten:

fire_hydrant:typepillar
couplingsDie Anzahl der Festkupplungen, z.B. 2 oder 3
couplings:typeHier in der Regel storz
couplings:diametersNach den deutschen Kupplungsbezeichnungen, z.B. B;B oder B;B;A oder gar C;C;B (ja, das gibt es, und das festzustellen, ist spannend!)
manufacturer…irgendwann lernt man dann auch die Hersteller anhand der Logos oder Aufschriften zu unterscheiden und kann entweder den Hersteller oder die Wikidata-ID des Herstellers eintragen…
Links ein alter VAG-Hydrant mit „DN 80“ im Guss, rechts ein Erhard-nach-1996-Hydrant mit „DN 80“ auf dem Typenschild – das sagt aber nichts ueber die Versorgungsleitung aus.

Zu beachten bei Ueberflurhydranten: Die haben zwar bisweilen auch einen Rohrdurchmesser angegeben – bei den alten Hydranten im Guss im Hydrantenkoerper, bei den neueren auf den Typenschildern ausgewiesen. Dieser Durchmesser gilt aber nur fuer das Steigrohr, nicht fuer die Wasserversorgung selbst. Im OSM-Wiki wird daher davon abgeraten, diesen Durchmesser als Leitungsdurchmesser zu taggen!

Auch nur eine Karte – aber auswertbar

Darstellung in der OpenFireMap

Zunaechst hat man damit auf den ersten Blick nicht viel gegenueber der alten handgemalten Karte gewonnen: Die Hydranten sind in OpenStreetMap eingetragen, und in Ansichten wie z.B. dem „Humanitaer“-Layer kann man sie in der gerenderten Karte auf openstreetmap.org auch anzeigen – wobei die nicht einmal zwischen Ueber- und Unterflurhydranten in der Darstellung unterscheidet.

Auf OSMHydrant oder der OpenFireMap bekommt man jedoch schon jetzt eine genauere Darstellung und bei OSMHydrant per Klick auf den Hydranten auch weitere Informationen. Damit alleine liesse sich schon auf einem Alarmmonitor im Feuerwehrhaus anzeigen, welche Wasserentnahmestellen es im Umfeld eines Einsatzorts bei einem Brandalarm gibt!

Zu beachten: Die OpenFireMap wird nur woechentlich am Dienstag aktualisiert. Von der Eintragung bis zur Anzeige im Kartenlayer kann also bis zu einer Woche vergehen.

Links ein alter VAG-Hydrant mit nur zwei C-Abgaengen und einem B-Abgang – ungewoehnliche Konstellation, die wir bei der Erhebung „Hutzelmaennchen“ genannt haben. Man beachte die Oeffnungsvorrichtung oben, die nicht einmal einen Sechskant fuer den Hydrantenschluessel Typ B hat. Rechts ein moderner VAG Nova Niro 365 mit zwei B-Abgaengen.

Die eigentliche Magie beginnt aber, wenn man die so hinterlegten Daten weiter direkt aus der Overpass-API auswertet, beispielsweise mit OverpassTurbo. Beispielsweise koennen wir uns alle Unterflurhydranten ausgeben lassen, fuer die wir angegeben haben, dass sie keinen angegebenen Leitungsdurchmesser haben – also das zugehoerige Hinweisschild fehlt:

node["emergency"="fire_hydrant"]["fire_hydrant:type"="underground"]["fire_hydrant:diameter:signed"="no"]({{bbox}});

Genauso koennen wir spaeter so alle Hydranten abfragen, als JSON exportieren und weiterverarbeiten – beispielsweise, um eine Kartei mit einer Karte pro Hydrant daraus zu erstellen. Oder aber auch, um die „besonderen“ Hydranten zu identifizieren, die beispielsweise nur zwei C-Abgaenge haben.

Und auch die Versorgung von Gebaeuden laesst sich dadurch auswerten. OSMHydrant bietet einen ersten Eindruck, indem man dort Umkreise um Hydranten zeichnen kann – das hilft schon fuer einen groben Ueberblick. In der Realitaet lassen sich Schlauchleitungen aber nicht in Luftlinie von einem Hydranten verlegen, sondern muessen Strassen folgen – und koennen z.B. auch nicht einfach eine Bahnlinie queren.

Wunderbar passend bloggte Supaplex030 genau zum Zeitpunkt der Erhebung, wie man solch eine Analyse auch mit dem freien GIS QGIS erstellen und dabei entlang von Strassenzuegen arbeiten kann. So laesst sich beispielsweise pruefen, welche Strecken beispielsweise mit einer oder zwei Einpersonenhaspeln oder dem Rollschlauchmaterial auf einem Loeschfahrzeug entlang kartierter Wege erschliessen lassen – und wo die Strecken zu weit dafuer sind. Ein Bonuslevel waere natuerlich die Verbindung mit einem Digitalen Hoehenmodell, wo eine Haspel nicht mehr so einfach bergauf gefahren werden kann – aber prinzipiell geht auch das 😉

Bonuslevel: Fotos machen!

Ein modernerer Erhard-Hydrant mit zwei B-Abgaengen, Modellserie nach 1996

Was in so einer Karte dann aber noch fehlen wuerde, ist das Umfeldfoto, wie es in der frueheren, mit Word erstellten Kartei zu finden waere. Das koennen wir aber beheben!

Wir haben beim Einmessen auch Fotos eines jeden Hydranten mit der Hauskamera aus dem Technikpool des temporaerhaus gemacht und auf Wikimedia Commons in die Kategorie Fire hydrants in Altenstadt (Iller) geladen, die ich dafuer angelegt hatte. In der OpenStreetMap lassen sich solche Fotos ueber Photo Linking mit Objekten verknuepfen. Hier habe ich jedem Hydranten ueber den Tag wikimedia_commons die jeweilige Datei zugeordnet, z.B. File:2025 Altenstadt (Iller) Hydrant Memminger Straße 54.jpg

Hydranten, die zwar schon vermessen, aber noch nicht mit einem Foto versehen sind, lassen sich natuerlich auch einfach mit Overpass Turbo abfragen – man muss die Suche lediglich erweitern, dass kein wikimedia_commons-Tag vorhanden ist:

node["emergency"="fire_hydrant"][!"wikimedia_commons"]({{bbox}});

Spaeter lassen sich diese Fotos so extrahieren und weiterverwenden. Sowohl Hydranten als auch Gebaeuden liesse sich auch ein URL zu Panoramax zuordnen, einer Freien Alternative zu Google StreetView – damit liesse sich noch mehr Kontext herstellen, aber auch die direkte Ansicht einer Adresse vom Strassenniveau aus waere auf dem Einsatzmonitor moeglich, wenn ein Alarm eingeht!

Und jetzt… verlinkt?

Schon mit diesem Informationsbestand ist deutlich mehr moeglich, als das in den bisherigen Hydrantenkartierungen meiner Feuerwehr der Fall war:

  1. Die Koordinaten sind – vor allem durch die RTK-Vermessung – viel praeziser
  2. Wir haben Metadaten zu den Schildern (oder ihrer Abwesenheit), dem Nenndurchmesser der Zuleitung (sofern erfassbar), den Abgangsgroessen und vielem mehr
  3. Wir koennen diese Informationen automatisiert weiterverarbeiten
  4. Auswaertige Kraefte koennen ohne weiteres auf diesen Bestand in OSM zugreifen
  5. und auch andere MapperInnen koennen dazu beitragen, den Bestand zu verbessern, falls z.B. irgendwo ein Hydrant errichtet wurde, den wir gar nicht auf dem Schirm hatten!

Ein typischer Einwand koennte hier sein, dass ja der Datenbestand in der OSM jederzeit boeswillig veraendert werden koennte. Das ist prinzipiell richtig. In der Realitaet kommt das aber beruhigend selten vor. Dennoch koennte es sinnvoll sein, einen eigenen, geprueften Informationsbestand vorzuhalten – der auch Annotationen haben koennte, die in OSM nicht so gedacht sind.

Ein „Tele-Hydrant“ von Hawle. Der telefoniert nicht etwa, sondern er kommt ohne Standrohr aus: Ein Rohr mit zwei B-Abgängen lässt sich einfach herausziehen.

Man koennte beispielsweise all die eingetragenen und geprueften Koordinaten fuer sich vorhalten und periodisch mit OSM vergleichen: Kam etwas hinzu, wurde etwas veraendert, muss ich das pruefen, um meinen Informationsbestand valide zu halten? Was hierfuer in meiner Gemeinde fehlt, ist eben der ref-Identifier, den OSM hier eigentlich vorsieht. Weder die Hydrantenschilder noch die Hydranten selbst haben irgendwo eine ID angegeben, mit der man den Hydranten identifizieren koennte. Zu pruefen waere hier, ob es irgendwo tatsaechlich eine offizielle Nummer gibt, die man „nur“ anbringen und dann einpflegen muesste.

Man koennte hier natuerlich Wikidata missbrauchen, alle Hydranten dort als Datenobjekte anlegen und das als Identifier nutzen – das hielte ich aber schon fast fuer eine Zweckentfremdung des Projekts. Eine eigene Wikibase-Instanz fuer die Feuerwehr, um den bestaetigten Stand festzuhalten, faende ich… lustig! Das ordne ich mal unter „Seitenprojekt des Seitenprojekts“ ein, wenn mir mal langweilig sein sollte 😀

Spannend finde ich zuletzt aber, dass die gewachsene Cottage Industry rund um „Datenverwaltung in Feuerwehren“ eine sehr unterschiedliche Haltung zu so einer Verlinkung faehrt. Einzelne Softwaresysteme erlauben wohl eine Verbindung zu OSM, andere scheinen darauf zu setzen, dass man z.B. Hydranten rein in ihrem Oekosystem pflegt, auf dass man z.B. eine Tablet-Version ihrer Software kauft, die die Anzeige dieser Daten ermoeglicht. Das Charmante am OSM-Mapping finde ich, dass man damit zumindest nach aussen jegliche dieser Lock-Ins aufbricht: Egal woher eine ueberoertliche Unterstuetzung kommt und welche Systeme sie verwendet: Wenn sie OSM auswerten kann, bekommt sie zumindest die grundlegenden, wichtigen Informationen.

Und das zeigt fuer mich wieder einmal: Die ganzen Loesungen, die auf Vermarktung und Verwirtschaftlichung ausgerichtet sind, machen das Ergebnis meist eher nur shitty. Die Erfassung aller Hydranten in einer – zugegeben, im Kernort nur um die 4000 BewohnerInnen starken – Kommune hat mich einen Mittwochabend und einen Sonntagnachmittag gekostet. Eine Befahrung fuer Panoramax waere an einem weiteren entspannten Nachmittag moeglich und haengt gerade nur daran, dass die 360°-Kamera des temporaerhaus wegen eines Defekts die letzten Wochen ausgefallen war. Wenn wir nur allen Menschen mehr Freizeit ermoeglichen wuerden, waere so viel Cooleres, Besseres moeglich. Und ganz nebenher kann man dabei lernen, verschiedene Hydrantenhersteller auf einen Blick zu erkennen und etwas ueber das Hydrantenkartell zu lernen 😀

Was ist denn dieses “Crowdsourcing” ueberhaupt?

Einige Leser duerften sich jetzt ausklinken, aber ich muss dieses Blog mal wieder dafuer nutzen, wofuer ich es urspruenglich angeschafft habe: Als Gedankenmuellhalde, auf der ich meine Ueberlegungen ablegen und dabei strukturieren kann ;)

Eine meiner Seminararbeiten dieses Semesters wird sich naemlich um Crowdsourcing drehen, und obwohl ich das Thema urspruenglich gar nicht haben wollte, finde ich es immer faszinierender. Und da ich jetzt mit der Literaturrecherche anfange und mich durch tausend Papers wuehlen werde, moechte ich erst einmal das festhalten, was ich mir bisher ausgedacht habe.

Erst einmal ist der Begriff relativ diffus — im Wesentlichen geht es einfach nur darum, dass eine bestimmte Arbeit an viele Leute verteilt wird. Entweder macht man das, weil man selber keine Lust darauf oder Ressourcen dafuer hat (Firmen wollen damit auch gerne Geld sparen). Oder aber man vertraut dabei auf die Intelligenz der Masse, weil heterogene Ansammlungen ganz verschiedener Leute, anders als man vielleicht zunaechst meinen wuerde, bei der Erledigung mancher Aufgaben deutlich besser sind als einzelne Experten. Letzteres ist gar nichts so neues, Francis Galton nannte es schon 1906 Vox Populi: Als damals 787 Leute das Lebendgewicht eines Ochsen (1198 Pfund) schaetzen sollten, lagen die einzelnen Schaetzungen zwar zum Teil weit vom tatsaechlichen Ergebnis entfernt, den Mittelwert aller Schaetzungen errechnete Galton aber bei 1207 Pfund, also mit nur 0,8% Abweichung vom tatsaechlichen Ergebnis. Klingt also prinzipiell prima: Der Schwarm ist intelligenter oder zumindest staerker als die einzelnen Mitglieder des Schwarms, also schreiben wir alle Probleme oeffentlich aus, und der Superorganismus Internet wird’s schon richten.

Klappt aber nicht. Jedenfalls nicht immer.

Im Fontblog gibt es heute eine beispielhafte Aufzaehlung von Crowdsourcing-Aktionen, die in die Hose gegangen sind, natuerlich aus dem Designbereich. Der Logowettbewerb von Frank-Walter Steinmeier ist nur ein Beispiel. Andere Wettbewerbe — dem Gefuehl nach hauptsaechlich die Aktionen, die von irgendwelchen Werbeagenturen konzipiert werden — locken keinen Hund hinter dem Ofen hervor. Woran koennte das liegen?

Die erste Idee war, die Crowdsourcing-Konzepte, die ich kannte, ein wenig zu ordnen. Man kommt auf diese Weise relativ schnell auf die folgenden Kategorien:

  • Grosser Sandhaufen, viele Schaufeln: Man hat einen grossen Haufen simpler Arbeit, die von Maschinen nicht, von Menschen aber relativ einfach erledigt werden kann. Auf diese Weise funktionieren recaptcha oder das Projekt des Guardian, zwei Millionen(!) Seiten Dokumente von 20.000 Freiwilligen durchsuchen zu lassen, um so eine Schmiergeldaffaere aufarbeiten zu koennen. Die einzelnen Arbeitsbloecke lassen sich mehr oder weniger beliebig gross einteilen, bauen nicht oder nur kaum aufeinander auf, koennen parallel abgearbeitet werden und lassen sich hinterher problemlos wieder zusammenfuehren. Distributed-Computing-Systeme wie SETI und Co. wuerde ich auch gefuehlsmaessig hier einordnen, auch wenn hier tatsaechlich die Maschinen arbeiten, nicht die Menschen.
  • Irgendwo wird sich schon ein Experte finden: Wir haben ein Problem, fuer das es viele moegliche Loesungen gibt, letzlich kann aber nur eine einzige eingereichte Loesung verwendet werden. Kollaboration ist quasi nicht moeglich, und oft bedarf es ausreichender Kenntnisse, um eine hochwertige Loesung zu finden. Typische Vertreter dieser Gattung sind Logowettbewerbe oder Logo-crowdsourcing-Plattformen.
  • Evolutionaere Projekte: Man beginnt mit einem relativ einfachen Grundstock, der sukzessive kollaborativ erweitert wird, bis man einem Ziel moeglichst nahe kommt. In den unterschiedlichen Entwicklungsstadien (die bisweilen innerhalb eines Projektes auch gleichzeitig vorkommen) koennen Personen verschiedener Kenntnisstaende ihre Beitraege leisten und fuer die Weiterentwicklung des Systems sorgen. Beispiele sind die Wikipedia und Open-Source-Projekte.

Die Grenzen sind bisweilen fliessend.

Zweitens faellt auf, dass es quasi immer eines Anreizes bedarf, Zeit und Hirnschmalz fuer diese Arbeit zu investieren. Bei der Schmiergeldaffaere ist es tatsaechlich “oeffentliches Interesse”, wegen dessen sich ein Teil der interessierten Oeffentlichkeit durch die Akten wuehlt, bei den Logowettbewerben ein ausgelobtes Preisgeld oder die schiere Begeisterung fuer die Sache (Obama! Piraten! Jehova!), und bei vielen Open-Source-Projekten einfach die pure Notwendigkeit, dem WLAN-Router jetzt auch noch Asterisk, VLANs und ENUM-Lookup beizubringen (und, natuerlich, Muhgeraeusche zu machen. Das ist meistens wichtiger als alles andere).

Die fehlgeschlagenen Kategorie-2-Crowdsourcingprojekte scheinen also hauptsaechlich daran zu scheitern, dass die wirklich guten Experten keinen Anreiz hatten, sich an den Wettbewerben zu beteiligen — ich bin mir aber ohnehin uneins, ob man hier den Begriff “Crowdsourcing” ueberhaupt verwenden sollte. Sollte “Crowd” schon deswegen gelten, weil man den Auftrag an eine grosse Menge von Leuten ausschreibt, oder sollte das erst zutreffen, wenn auch tatsaechlich eine gewisse Menge von Menschen am Endprodukt mitarbeitet?

Einmal davon abgesehen, ist eine weitere Frage, wie man einen geeigneten Anreiz fuer die Arbeit an Crowdsourcingprojekten findet. Recaptcha kombiniert das klassische Captcha — das auszufuellen notwendig ist — mit der Eingabe ocr-unlesbarer Texte, also quasi die Kombination des Notwendigen mit dem Nuetzlichen. Nachdem es fuer einige Menschen offenbar auch die vollkommene Erfuellung darstellt, taeglich stundenlang ihre Farmen auf Facebook zu pflegen, koennte man auch darueber nachdenken, verteilte Arbeiten in Spielen loesen zu lassen. Es scheint also so, als muesste ich auch mal bei den Psychologen anklopfen ;)

…ja, das sind die Fragen, mit denen ich mich jetzt so beschaeftigen werden. Und einmal aufgeschrieben wirken sie gar nicht mehr so maechtig und bedeutend wie im Kopf. Aber zumindest habe ich jetzt einmal einen Anfang — und kann nun herausfinden, wie viel des oben geschriebenen schon vor Jahren in wissenschaftlichen Journals klassifiziert und beschrieben wurde :D

Edit: Fleissaufgabe — in welche Kategorie faellt die Blogosphere?