Harmonische Datenstruktur für die Feuerwehr

Communities Deutschland (Germany)
1

Hallo zusammen,

für spezielle Fragestellungen aus Sicht der Feuerwehr möchten wir relevante Objekte in OSM mit angepassten Tags versehen. Diese sind aber nicht kritisch oder besonders schützenswert sondern eher allgemeiner Natur. Die meisten Informationen werden für den “Normal-User” vermutlich auch nicht von Bedeutung sein.

Die Überlegung, hierfür OSM zu verwenden, haben wir jedoch sehr bewusst angestellt. Hierdurch wird es möglich, auch externen Nutzern Informationen auf einfachem Wege zur Verfügung zu stellen.

An zwei paar Beispielen möchte ich verdeutlichen, wo wir hin wollen.

Beispiel 1: Spielplätze
Die städtischen Spielplätze sind alle nummeriert und mit entsprechenden Hinweisschildern versehen um den Ort bei einem Notfall schnell benennen zu können. Aus diesem Grund könnten diese mit entsprechenden Infos zur Nummer, Stadt und Stadtteil getaggt sein. Nach bisherigem Informationsstand ist aber z.B. addr:suburb=* für den Stadtteil usw. nicht üblich, weil es sich nicht um eine postzustellfähige Adresse handelt. —

Beispiel 2: Sackgassen
Aus taktischen Gründen kann die Information hilfreich sein, ob es sich bei einer Straße um eine Sackgasse handelt. Dies ist weniger für eine Navigation von Bedeutung, da ein Navi das Ende einer Straße erkennt. Das Tag noexit=* hat für unseren Fall aber nicht die richtige Bedeutung. Vielmehr interessiert uns hierbei auch nicht nur das Ende (node) sondern der Straßenverlauf (way), der als Sackegasse endet. —

Ich habe bei unserem Verkehrsverbund gesehen, dass die Haltestellen mit einem individuellen Tag “VRS” versehen sind (Bsp.: VRS:gemeinde=KÖLN). Und nun ist die Frage, ob eine vergleichbare Lösung auch für die Feuerwehr Köln möglich ist (z.B. FWK:xyz=*) und welche Regeln dabei gelten. Weiterhin sollen die Einträge erkennen lassen, dass wir diese Objekte nutzen, was ggf. noch durch einen standardisierten Hinweistext erfolgen soll. Zwar verhindert das keine Löschung oder Veränderung, aber es erzeugt ggf. erhöhte Aufmerksamkeit.

Ich möchte diese Nachricht nicht künstlich strecken. Gerne gehe ich natürlich auf spezielle Fragen ein.
Für Eure Auskünfte danke ich aber schon mal.

Viele Grüße
Karsten

2

Das Problem kenne ich, eine Lösung gibt es, das object-Schema kann analog zum addr-Schema verwendet werden, ist suboptimal dokumentiert
https://wiki.openstreetmap.org/wiki/Key:object
lässt sich aber genausogut auswerten und vermeidet Ärger in der Form “Seit wann hat denn ein Spielplatz einen Briefkasten???!!!”
Das Taggig wäre
object:city=*
object:suburb=*
object:street=*

3

Bei uns in Bielefeld sind die Spielplätze nicht nummeriert, auf den Hinweisschildern ist nur der “Ort” angegeben, in der Regel der Name der nächstliegenden Straße.

Das habe ich bisher einfach mehr oder weniger passend als name=… eingetragen. Wenn ich jetzt drüber nachdenke wäre aber vermutlich ref=… oder gar eine Kombination aus emergency und ref passender.

In eurem Fall dann vielleicht:

emergency:ref=…
emergency:city=…
emergency:suburb=…

?

4

Hallo und willkommen bei OSM!

Zu den Sackgassen: noexit=yes dient nicht dazu, Sackgassen (Verkehrszeichen 357) zu kennzeichnen, sondern ist ein Information für Tools zur Qualitätssicherung. Wenn zwei Wege sehr dicht beieinander liegen, aber in OSM nicht verbunden sind, könnte das ein Fehler in den Daten sein. Wenn die Wege tatsächlich nicht verbunden sind (Mauer dazwischen o.ä.) dann setzt man noexit=yes, damit der Fehler nicht mehr angezeigt wird. Ähnliches auch für Waldwege, die einfach mitten im Wald enden. “Hier geht es wirklich nicht weiter!”.

Dass ein Straßenverlauf in eine Sackgasse mündet, muss aus den Daten selbst berechnet werden. Von der Theorie her eine simple Sache, praktisch hab ich sowas noch nie versucht zu programmieren. Gefühlt wird es dazu aber einige Beispiele als OpenSource geben.

Zu den Spielplätzen: Diese könnte man mit ref=* taggen, vielleicht auch mit einem Namespace, ref:keineahnung=*.
Wie sehen diese Nummerierungen denn aus? Sind die Nummern im ganzen Stadtgebiet einmalig, oder nur je Stadtteil?

Ich bin kein Fan davon, derartige Informationen an Objekte zu schreiben. Wenn die Nutzung eines Tags im Wiki dokumentiert ist, sollte ein interessierter User das finden können.

Wenn man eigene Daten mit OSM synchron halten will, empfiehlt es sich ggfs. auch, eine eigene Datenbank vorzuhalten und diese regelmäßig automatisiert mit OSM zu vegleichen. Dann können unachtsame Änderungen durch User zügig korrigiert werden bzw. neue Spielplätze eingetragen werden und ehemalige entfernt werden. Mit Overpass Turbo und paar Zeilen Programmcode ist sowas schnell erledigt. Die Änderungen an OSM würden trotzdem manuell erfolgen.

5

Hallo und danke für die bisherigen Infos.

Der Gedanke bei den Ways der Sackgassen war, diese mit einem Tag als solche zu kennzeichnen. Auch hier von mir aus auch nur als emergency-Tag. Denn wir wissen nun mal nicht, ob die Info noch jemand anderes braucht. Wir haben schon einen programmierten Weg getestet, dieser brachte aber nur Näherungswerte…

Die Nummerierung ist für das ganze Stadtgebiet eindeutig und ich würde sie auch mit ref=* taggen. Scheinbar ist es aber unüblich, die definierte Örtlichkeit (Stadtteil, nächste Straße) als addr=* zu taggen. Bei der Option, den Stadtteil mit ins ref=* zu packen war ich mir nicht sicher ob das regelkonform ist.

Diese Idee habe ich mir bei Kollegen aus der Schweiz abgeguckt. Die schreiben einen kurzen Vermerk als note=* rein. Immer gleich und einheitlich. Hat zwar bei der Community für ein paar Diskussionen gesorgt, letztlich wurde die Sinnhaftigkeit aber erkannt. Schon alleine aus diesem Grund werfe ich die Thematik hier frühzeitig in den Ring. Ziel soll es sein, OSM-Regelkonform zu agieren und trotzdem das Ziel zu erreichen.

Eine entsprechende “Überwachung” relevanter Inhalte ist dabei tatsächlich vorgesehen. Allerdings vertrauen wir auch auf die Community.

Gruß
Karsten

6

Zu den Spielplätzen:

Sollte man da nicht ggf. was mit emergency verwenden analog zu https://wiki.openstreetmap.org/wiki/Tag:highway%3Demergency_access_point ?
Dann wäre klar, dass es sich um eine Information für Rettungseinsätze von Feuerwehr und Krankenwagen handelt, um einen Spielplatz schnell und eindeutig anfahren zu können.

7

Zu Sackgassen:

noexit=yes wird zwar immer wieder fälschlich dort gesetzt, wo das Sackgassen-Verkehrsschild steht, gehört da aber definitiv nicht hin. (vgl. https://wiki.openstreetmap.org/wiki/DE:Key:noexit ) - Wenn ich sowas vorfinde, wird das von mir immer korrigiert.

Man könnte natürlich einen node (Punkt) an den Schilderstandort eintragen mit https://wiki.openstreetmap.org/wiki/Item:Q19660 traffic_sign=DE:357 - aber wäre dies für Feuerwehr und Rettungsdienst auswertbar?

Vielleicht wäre das eher etwas, was man auf als Punkt direkt auf die Straßenlinie setzen sollte wie man das ja auch bei Stopp- und Vorfahrtszeichen macht, ebenso bei Ortseingangsschildern (wobei dies bei Letzterem nicht unumstritten ist, gab hier erst neulich eine Diskussion, ob dies bei Ortseingangsschildern sinnvoll sei) - Vorteil dabei wäre, es wäre eindeutig einer Straße zuzuorden und könnte somit sowohl auf Karten angezeigt also auch in Routern angesagt werden (so wie das z.B. manche Router bei traffic_calming=yes machen - Ansage: “Vorsicht, Verkehrsberuhigung”)

Es bräuchte dann aber noch eine Variation für die Sackgassenschilder “mit Hintertür” Zeichen 357-50, Zeichen 357-51 und Zeichen 357-52

Wenn jemand dafür mal ein vernünftiges Tagging-Schema entwickeln und im OSM-Wikipedia etablieren könnte, würde vielleicht auch die falsche Verwendung von noexit=yes mal aufhören.

8

Du solltest mal erläutern wie und durch wen die zusätzlichen Daten ausgewertet werden. Oder anders gefragt: Ist die potentielle Datenergänzung wirklich der beste Weg zur Zielerreichung?

9

Hi toc-rox,

Einerseits werden die Daten intern verwendet um im GIS diverse Objekte einchließlich ihrer Attribute darzustellen bzw. die Daten daraus nutzen zu können. Dies dient dann aber eher als reine und schnelle Informationsquelle. Andererseits sollen externe Personen (z.B. Studenten) Zugriff auf solche Daten bekommen, wenn sie die für Facharbeiten o.ä. brauchen. Und das eben auch von zu Hause oder aus der Uni. Würden wir die Daten in unserem GIS erstellen, so kämen diese Daten nicht nach außen. Somit sind sie für Externe nicht nutzbar. Wir wollen aber ein bisschen vom “Inseldenken” weg und Open Data quasi leben.

Umgekehrt bietet OSM aber wiederum die Option, dass Mitarbeiter von außen die Daten pflegen können. Die Tätigkeit in unserem GIS ist komplex. Zudem ist das System von außen nicht zugänglich. Bei OSM wäre das anders. Hinzu kommt, dass man jemandem, der nur temporär unterstützt, einfache Handgriffe OSM-Datenpflege anhand Standards schneller erklären kann, als unser komplexes GIS.

Sicherheitsrelevante Daten verbleiben natürlich immer in unserer Hand. Aber allgemeine Informationen (ohne diese jetzt schon abschließend bestimmen zu können) sehen wir durchaus bei OSM. Eine gewisse “Überwachung” ist natürlich vorgesehen.

Gruß
Karsten

10

“Datenstruktur für [irgendjemand]” scheint mir grundsätzlich unkorrekt. Wir haben nur eine Datenstruktur und die soll alle Dienen.

11

Eine Sackgassensituation im Sinne von DE:357 sollte generell dann entstehen, wenn 1. die an einer OSM-Node hängenden Ways, die mit highway=(primary|alles was mit motor_vehicle fahrbar ist) getaggt sind, die Anzahl 1 nicht übersteigt, oder wenn 2. die Node ein barrier=* ist.

Auf automatische Auswertung sollte man sich allerdings nicht immer verlassen. Vielleicht gibt’s ja eine bessere Zugangsstraße wie in

12

die addr: tags sind für Adressen, bei Spielplätzen sind sie in der Regel nicht passend weil Spielplätze keine Adressen haben. Wenn Ihr sowieso ein GIS habt braucht Ihr die Städte nicht explizit taggen, diese Info ergibt sich bereits aus der Lage. Bei den Straßen ist es ähnlich, außer man will da nicht unbedingt die nächste Straße drinhaben sondern eine handverlesene.

13

Hi,

Das soll sie ja auch. In unserem Fall steht eine speziellere Fragestellung im Raum und wir suchen eine Antwort darauf. Und genau aus diesem Grund trage ich das frühzeitig in diese Community. Mir liegt daran, OSM für uns nutzbar zu machen und dennoch regelkonform zu bleiben. Damit nicht nur wir was davon haben sondern alle.

Gruß
Karsten

14

Hi,

Dann frage ich einmal direkt: Was wäre denn die richtige bzw. eine saubere Lösung?

Aus meiner Sicht ist es grundsätzlich unschädlich, Tags mit Infos zu Nummer, Straße(n) und Stadtteil hinzuzufügen. Ob diese letztlich immer mit einem GIS ausgewertet werden oder als Excel-Tabelle vermag ich nicht zu sagen. Ich suche lediglich eine allgemeinverträgliche Lösung, die von der Community mitgetragen wird und -wichtig- nicht als falsch deklariert und von anderen Mappern wieder gelöscht wird.

Gruß
Karsten

15

Die OSM-DB ist keine öffentliche Ablage für private Daten. Die Aussage “die Daten nutzen uns” ist unzureichend und hat mit der “Open-Idee” nicht viel zu tun. Vielmehr sollte klar werden, warum die neuen Tags von allgemeinen Interesse sind. Die Tags sind ja im Wiki zu dokumentieren und werden dann deutschland- oder weltweit erfaßt.

16

Hi,

Sie nutzen auch uns. Und natürlich jedem, der sie nutzen möchte.
Ich kann es nur noch einmal betonen, dass ich nach einer allgemeinverträglichen Lösung suche. Natürlich ist es auch wichtig, was man üblicherweise nicht macht. Mehr helfen mir aber Hinweise, wie ich es richtig machen kann. Damit es eben von allen mitgetragen wird.

Gruß
Karsten

17

Moin zusammen,

noch als Ergänzung, wie es die Kollegen von Schutz & Rettung Zürich machen.

https://wiki.openstreetmap.org/wiki/Organised_Editing/Activities/SchutzRettung_Rescue

Dort hat man sich im Vorfeld ebenfalls mit der Community ausgetauscht und pflegt inzwischen einen konstruktiven Austausch. Anfangs gab es hier nachvollziehbar Bedenken, die man im Dialog aber ausräumen konnte. Gerade deswegen ist mir die Kommunikation diesbezüglich so wichtig.

Viele Grüße
Karsten

18

1-2 Beispielfotos wären super!

Hinweisschilder sind vor Ort überprüfbar und damit genau die Art von Daten, die wir gerne in OSM haben möchten :wink:

PS:
Haben wir noch die Chance, den Thread hier in zwei Teile zu teilen, einen für die Spielplätze, einen für Sackgassen?

19

Hallo Karsten,

ich stand viele Jahre im Impressum als Ansprechpartner für Behörden und mache die bundesweite Qualitätskontrolle der Rettungspunkte. Daher habe ich sehr viele Kontakte zu Rettungsleitstellen und sonstigen BOS auf allen Ebenen.

Die Ergänzung der Spielplätze mit den Referenznummern der Stadt halte ich für die Koppelung von Leitstellen- und OSM-Daten sehr sinnvoll, die addr:*-Tags in der jetzigen Form jedoch nicht. Letztere sind unvollständig und fallen bei der Qualitätssicherung der Adressen negativ auf. Viele in der Community sind nicht so begeistert, wenn diese Tags an alles mögliche drangehängt werden. Extra Namensräume führen sehr schnell zu einer Zersplitterung. Da wären konkrete Szenarien hilfreich zur Beurteilung.

Dies betrifft natürlich nicht Gebäudeobjekte,wie z.B. Feuerwachen, die eine postalische Adresse haben. Da ist die Vervollständigung sehr willkommen

Bis auf wenige Ausnahmen orientieren wir uns daran, was an Beschriftungen sichtbar ist Die Angabe einer Adresse auf einem Spielplatz-Schild ist vor allem eine Zusatzinformation für den Hilfesuchenden beim Telefonat mit der Leitstelle, denn eine Adresse in der Nähe findet jeder in seinem System, egal ob Feuerwehr, Rettungsdienst, THW oder auch die Tierrettung. Aber dafür ist es nicht notwendig dass am OSM-Spielplatz die Adresse steht. Normalerweise sind im Einlastleitsystem alle Angaben zu einem Objekt bereits im Vorfeld eingetragen. Bei dem letzten Haus in einer Sackgasse z.B. “Drehleiter zuerst” für die Ausrückreihenfolge, während 3 Häuser vorher genügend Platz für die normale Aufstellung ist. Für die Anreicherung der OSM-Daten mit einsatzspezifischen Daten sollte gelten: Soviel wie nötig, aber so wenig wie möglich.

In Zürich ist es mitunter seltsam, was die Feuerwehr als Einsatzrelevant betrachtet: http://overpass-turbo.eu/s/11sy

Feuerwachen, Krankenhäuser, Parks oder auch das Gesamte Flughafengelände würden die Mapepr auch so aktuell halten. Ärgerlich ist, dass bei Flächenobjekten wohl versehentlich die Notiz auch an jeden einzelnen Knoten eines Flächenobjektes gehängt wurde.

Die ergänzende Kennzeichnung von abweichenden Beschränkungen (Gewicht, Höhe, Breite) für Notfalleinsätze kann sinnvoll sein.

Bei allem, was eine Leitstelle mit OSM-Daten macht, sollte stets berücksichtigt werden, dass die OSM-Infrastruktur, ebenso wie das Internet, jederzeit ausfallen kann. Die wichtigen Dinge wie Rohdaten, Kachelserver, Routing-Server und Suchserver (Nominatim) sollten sich redundant im eigenen gesicherten Netzwerk der Leitstelle befinden und regelmäßig aktualisiert werden.

Viele Grüße
Joachim

20

Jetzt noch mal auf die Spielplätze bezogen: so ganz habe ich das Problem noch nicht verstanden. Die Daten liegen doch grundsätzlich vor - nur eben nicht am Objekt selbst, sondern in den üblichen OSM-Strukturen.
Ich nehme einfach mal willkürlich einen Eintrag der Liste https://www.stadt-koeln.de/leben-in-koeln/freizeit-natur-sport/spielplaetze/index.html.

Nominatim spuckt für

playground genovevastraße, köln

aus

Bachstraße, Mülheim, Köln, Nordrhein-Westfalen, 51063, Deutschland (Playground)

D.h. der richtige Stadtteil wird ermittelt. Was vielleicht wirklich fehlt, ist ref=*

Ein anderes Beispiel für eine andere Stadt:
Nominatim für

playground 2802, neuss

wirft aus

Max-Ernst-Straße, Gier, Rosellen, Allerheiligen, Neuss, Rhein-Kreis Neuss, Nordrhein-Westfalen, 41470, Deutschland (Playground)

einschließlich wichtiger Informationen wie

Teletubbie-Spielplatz (loc_name)
Max-Ernst-Straße (name)
Max-Ernst-Straße (name:de)
2802 (ref)

Die (städtischen) Spielplätze sind hier beschildert mit

  • Name
  • Referenz (vierstellig: 2 Stellen für den Bezirk, dann laufende Nr.)

Die Referenz kennt der Leitrechner und wird entsprechend in die Alarmierung aufgenommen. Falls also jemand auf die Idee käme, OSM im Einsatz zu nutzen, wären grundsätzlich alle wichtigen Daten vorhanden.