THW: Wie Zuständigkeitsbereiche richtig erfassen?

Hallo!

Bevor ich wild das Experimentieren anfange: Welche Vorgehensweise haltet ihr für die sinnvollste, um die Zuständigkeitsbereiche/“Wachgebiete” der Dienststellen des Technischen Hilfswerks (stellvertretend für andere Organisationen) zu erfassen? Diese folgen einer eigentlich simplen Hierarchie, die aber einige blöde Ausnahmen hat:

  • ganz oben für die ganze Republik die Bundesanstalt mit Dienststelle in Bonn

  • darunter 8 Landesverbände, die ein (z. B. der LV Bayern) oder mehrere (z. B. der LV Berlin, Brandenburg, Sachsen-Anhalt) Bundesländer abdecken, mit je einer physischen Dienststelle des/-r Landesbeauftragten im Gebiet

  • darauf verteilt insg. 66 Geschäftstellen mit je einer physischen Dienststelle, die jeweils mehrere Landkreise abdecken (z. B. GSt München: “Landkreis Aichach-Friedberg, Landkreis Augsburg, Stadt Augsburg, Landkreis Dachau, Landkreis Ebersberg, Landkreis Erding, Landkreis Freising, Landkreis Fürstenfeldbruck, Landeshauptstadt München, Landkreis München”)

  • je Geschäftstelle mehrere Ortsverbände mit je einer physischen Dienststelle, die normalerweise einen Landkreis, selten eine große Stadt und ganz selten einen Teil einer Großstadt abdecken (z. B. OV Dachau für den Landkreis Dachau, OV Augsburg für Stadt und Landkreis Augsburg, die OVe München-West, -Mitte und -Ost für die Stadt München und den OV München-Land für den Landkreis München)

Für den Großteil könnten also bestehende admin boundaries herangezogen werden, lediglich die Großstadt-Ortsverbände müssten wohl händisch angelegt werden, so sie nicht exakt Bezirksgrenzen o. ä. folgen, das ist kein Hindernis.

Grundsätzlich ist es eine einfache Hierarchie von relations, aber bevor ich irgendetwas kaputtmache: Kann ich einfach bspw. für den LV Bayern die admin boundary des Bundeslandes mit einer entsprechenden role als Mitglied hinzufügen, oder führt das zu Problemen? Ist es evtl. sinnvoller, das zugrundeliegende area zu duplizieren und eigens mit den THW-relevanten Daten zu taggen? Ich mappe zwar schon länger, aber vor relations habe ich mich bisher gedrückt.

Es geht mir bei der ganzen Sache nicht um die Darstellung in den gängigen Kartenrenderern! Für die sind diese Informationen irrelevant. Sondern um die Möglichkeit für die, die damit arbeiten wollen, die Daten in einem GIS oder einem eigenen Renderer abzufragen und zu verarbeiten.

Schon mal herzlichen Dank!

Dann wäre es doch ausreichend die Daten in geeigneten Formaten an geeigneter Stelle zum Download anzubieten.

Gruß Klaus

Das ist der Status quo, den wir gerne überwinden würden. Erstens, weil es konkret im THW keine geeignete Stelle gibt. Zweitens, weil es durchaus Anwendungsfälle auf OSM-Basis dafür gibt, nur eben nicht für die normale Straßenkarte.

Ich beobachte seit einiger Zeit gelegentliche THW-Edits…

so wurde z.B. kürzlich eine THW-Grenze des Landesverbandes Berlin,Brandenburg,Sachsen/Anhalt erstellt:
https://www.openstreetmap.org/relation/5742317

Ein anderer User hat (wohl im Rahmen einer studentischen Arbeit) Tags der Form squad_n=* gebildet (n=Ziffern 1 bis 9; = Squad-Werte entsprechend Wiki) Auf Nachfrage teilte er mir diese Dinge mit und daß er auch mit Q-Gis arbeitet. Nach einer Präsentation einer Lösung von Abfragen mit Semikolon im Wertefeld und ohne Verwendung von squad_1= sowie in Zusammenhang mit Quick-OSM kam leider keine weitere Reaktion. Der Tagging-Abfall key_n=* (mit n zwischen 1 und 9) ist zum Teil weiter in der Datenbank enthalten.

Wiki: http://wiki.openstreetmap.org/wiki/Tag:emergency_service%3Dtechnical

Tags mit variierenden Zahlwerten im Key sollten um jeden Preis vermieden werden. In einem ähnlichen Fall wurde die Verwendung von name_n=* (mit n als Zahlwerte 1- unendlich) als deprecated erklärt.

Sven

Edit: Link korrigiert

Über einige solcher Edits bin ich auch gestolpert. Das zu bereinigen ist dann der nächste Schritt. Das Problem ist, dass derzeit mehrere THWler in verschiedenen Ecken der Republik unabhängig voneinander mit unterschiedlichen Zielsetzungen mappen, eben weil es keine interne Möglichkeit gibt, Infrastruktur für GIS und Geodaten zu stellen. Darum auch meine Frage oben, wie man solche Informationen richtig einstellt, damit es keine Konflikte für die Renderer gibt.

Ich werfe mal die Frage auf, ob so etwas überhaupt in die OSM-Datenbank gehört?

Meine Meinung: Nein.

Grundsätzlich meine ich, daß sich das THW-Tagging wie es im Wiki http://wiki.openstreetmap.org/wiki/Tag:emergency_service%3Dtechnical keine nennenswerte Belastung der OSM-Datenbank darstellt. Im Gegenteil. Ich sehe ein geeignetes THW-Tagging in Verwandschaft und in Ergänzung zu dem sonstigen emergency-Tagging… Notfall-Rettungspunkte, Feuerwehr, Hydranten… ect.

Sven

Leider werdet ihr Euch der Herausforderung stellen müssen und Eure Daten auf sinnvolle Weise mit OSM verbinden, ohne sie in OSM einzutragen.

OSM erfasst in der Regel Dinge, dir vor Ort “on the ground” überprüfbar sind. Von dieser Regel machen wir ein einigen wohl begründeten Fällen eine Ausnahme. Das bedeutet aber nicht, dass jeder, der findet, dass es “einen Anwendungsfall gibt”, unsere Datenbank benutzen darf, um seine eigenen Verwaltungsdaten da einzukippen.

Als nächstes kommen dann die (verschiedenen) Kirchen mit ihren (je nach Glaubensgemeinschaft unterschiedlichen) Bezirksgrenzen, oder Notrufleitstellen, oder Schulbezirke - für all das gibt es nützliche Anwendungsfälle, aber ist in in OSM kaum wartbar, und erschwert drastisch die Arbeit mit den vorhandenen Daten (man überlege sich, in wie vielen Relationen irgendwann ein durchschnittlicher Grenz-Way ist).

OSM sollte sich auf die Basisdaten beschränken - was eben vor Ort ist - und jeder, darauf basierend Nutzdaten erfassen will (z.B. die Vertriebsgebiete des eigenen Verlages oder Pizzadienstes modellieren), der muss Wege finden, das zu tun, ohne seine Organisationsstruktur in OSM zu taggen.

Bye
Frederik

Nun, die Dienststellen sollen ohnehin sukzessive eingetragen werden. Eine Verknüpfung über die oben angesprochene relations-Hierarchie ist naheliegend, und als “Filialen” einer Organisation mit verschiedenen Ebenen oder Teilen auch durchaus nicht ohne Beispiel. Die Neuerung, wegen der ich anfrage, ist eigentlich nur die Zuordnung eines Gebiets zur jeweiligen Dienststelle. Im einfachsten Fall also ein zusätzliches Mitglied in einer Relation. Wir reden von insg. knapp 750 Dienststellen, also einem überschaubaren Datenaufkommen. Durch die Koppelung an admin boundaries hielte sich auch der Wartungsaufwand in Grenzen. Mir ist nur wichtig, gerade an den admin boundaries keine Probleme zu verursachen.

OSM fehlt es an dieser Stelle, für bestimmte Dinge eine eindeutige feste ID zu vergeben, die als verbindender Identifikator verwendet werden kann.

Ich schätze aber, auch ohne eines solchen sollten die Standorte der THW-Niederlassungen sehr wohl vor Ort recherchierbar sein.

Hier die aktuelle Situation auf Basis operator=Bundesanstalt Technisches Hilfswerk(THW)
In wie weit das auch auf die einzelnen Aufgabenbereiche zutrifft, weiß ich nicht, das squad-Tag ist jedenfalls im Wiki definiert. Ansonsten denke ich, daß mit einem geeignetem Tagging die Standorte und Aufgabenbereiche mit dem aktuell definierten Tagging möglich sein dürfte. Was die Zuständigkeitsbereiche anbelangt, kann hier auf Gemeindeschlüssel/ Regionalschlüssel der admin-Relationen zurückgegriffen werden.

Sven

Der THW als sehr große technische Organisation soll nicht in der Lage sein einen Download-Server zu betreiben? Das kann ich nicht glauben.

Weitere Fragen die sich aufgrund deiner Ausführungen stellen:

  • Wer ist das “wir” (Aktive vor Ort, die Organisationsleitung, …)?
  • Was soll überwunden werden und warum?
  • Wie sehen die Anwendungsfälle aus?
  • Wer sind die Datennutzer?
  • Und wieso ist OSM für das Vorhaben die “richtige” Ablage?

Die Erfassung der Standorte, Übungsplätze (gibt es z.B. in Münster: https://www.openstreetmap.org/#map=17/51.98864/7.73167)) usw. ist kein Thema. Aber die Zuständigkeitsbereiche der einzelnen Organisationseinheiten? Vermutlich bringen uns die Antworten auf die Fragen weiter …

Gruß Klaus

Zuständigkeitsbereiche gehören mE nicht wirklich rein - ebenso wie bei Feuerwehr. Das ist viel zu schnell geändert, zum Teil sogar ohne dass die Betroffenen etwas davon mitbekommen. Gerade bei Verschiebungen in München kann ich mir durchaus vorstellen, dass das häufiger passiert…

Warum nicht einfach an allen THW-OVs (die zweifellos eingetragen gehören) einen Eintrag zu Geschäftsstelle und Landesverband?

Genau. Sind ja tendenziell firmeninterne Daten.

Hi Frederik,

ich habe versucht, dieses “die müssen einen Weg finden” auf dem Hack-Event in KA anzusprechen, bekam aber keine allzugrosse Resonanz. Ok, damals ging es mehr um SEO-Mapper und nicht um “spezielle” Grenzen.

Dennoch bin ich der Meinung, dass sich OSM dazu Gedanken und daraus abgeleitete Vorschläge machen könnte. Wir sagen Jedem: “Bitte nicht in OSM erfassen, lass dir gefälligst was einfallen” - aber einen eigenen Lösungsansatz haben wir nicht. Nur ein paar diffuse Vorstellungen, die wohl die Geoposition der betroffenen Objekte nutzen sollen.

Auch würden Informationen darüber, ob und wie das von bestimmten Anwendern gelöst wurde, sehr hilfreich sein.

Ein: “Mach das doch so” ist 1000x besser als “Lass dir was einfallen”.

Gruss
walter

Da ja auch Wahlbezirke erfasst werden sehe ich keinen prinzipiellen Grund, THW Grenzen nicht zu erfassen. Das THW ist ja nicht ein xbeliebiges Unternehmen. Bleibt also die Nachprüfbarkeit anhand freier Quellen. Und der Wille des mutmaßlichen Hauptnutzers, die Daten dann auch zu pflegen.

<Gebetsmühle>dass anderswo in OSM Mist gemacht wird, sollten wir nicht als Freibrief betrachten, beliebig viel Mist nachzulegen</Gebetsmühle>

Dann löschen wir lieber die Wahlbezirke, die haben nämlich in OSM auch nichts verloren und sind nur da, damit alle paar Jahre mal jemand eine nette Karte malen kann…

Bye
Frederik

Hallo,

ich weiß nicht, was der Vorteil sein soll, diese THW-Bezirke in OSM zu haben. Vielleicht weil OSM einfach von manchen Leuten als kostenloser Geodatenhoster verwendet wird?

Es würde doch genügen, die Polygone als Shapefile oder GeoJSON auf einer externen Website (z.B. die des THW) unter einer freien Lizenz bereitzustellen. (Wenn sie von OSM-Daten abgeleitet sind, muss es halt die ODbL sein) Dann kann jeder, der eine THW-Karte braucht, die Zugehörigkeit einer THW-Dienststelle mittels räumlicher Abfragen bestimmen. (Damit wäre die von wambacher “geforderte” Alternative aufgezeigt)

Viele Grüße

Michael

Ich weiß es auch nicht. Aber ich weiß auch nicht, was der Vorteil ist, Kindergartenöffnungszeiten im OSM zu haben. Und wenn ich mich zwischen Kindergartenöffnungszeiten und den Zuständigkeitsbereich der THW Dienststellen entscheiden müsste, dann würde ich mich für THW entscheiden, denn das sind wenigstens GEOdaten.

Zum Glück geht es hier nicht darum zu entscheiden was sinnvoller ist, sondern nur darum, ob etwas sinnvoll ist. Dann geht auch beides. :wink:

Aber THW-Zuständigkeitsbezirke…das denke ich, ist wirklich keine gute Idee. Sicherlich kann man die Gründe warum man das machen wollte sehr gut nachvollziehen, aber da gäbe es hunderte andere Fälle, die genau die gleichen Gründe vorlegen könnten. Und geht man dann mal davon aus, man soll ja immer vom worst case ausgehen, dass diese auch alle ihre Zuständigkeitsbezirke und ähnliches in OSM an die Boundaries machen wollen…juhu, dann ist Chaos und Unübersichtlichkeit vorprogrammiert.

Ich halte es da eher mit Wambacher, dass man attraktive Alternativen schaffen sollte wie man das Gewünschte quasi extern einfach lösen könnte. Dann könnte man auch leicht die Wahlbezirke auslagern.

Was ich an der Sache nicht verstehe: wieso will man, trotz der Vorteile, seine Daten in die OSM-Datenbank einpflegen, wo man nie sicher sein kann, dass sie ausversehen oder mutwillig zerstört werden? Da ist es doch wesentlich risikoärmer und vom Pflegeaufwand nicht höher, wenn man sich selber was bastelt, wo nur eingeschränkt Leute drauf Zugriff haben (wobei man natürlich wieder bei Wambachers Anmerkung wäre, dass man konkrete Lösungsansätze vorhalten sollte).