AED-Erfassung – Offene Tagging-Fragen

Hallo zusammen,

wir sind das Team der TURMsolutions GmbH und konzipieren derzeit ein Open-Source-Projekt, über das Nutzer:innen AED-Geräte erfassen und die Daten über die OSM-API hochladen können. Bevor wir in die eigentliche Implementierung gehen, möchten wir unser Vorhaben frühzeitig mit der Community abstimmen.

Wir arbeiten eng mit verschiedensten Behörden und Leitstellen zusammen und möchten gerne eine Lösung ausarbeiten, bei der aktuell nicht öffentlich zugängliche AED-Daten frei verfügbar gemacht werden. Damit wollen wir die Sichtbarkeit öffentlicher AED-Standorte verbessern und einen Beitrag zum Gemeinwohl leisten. Darüber hinaus sollen die AED-Daten in Zukunft für unser Ersthelfer-Alarmierungssystem KatRetter genutzt werden, um die Hilfeleistung im Notfall zu verbessern.

Das Endprodukt richtet sich an Organisationen, Behörden und Privatpersonen, die AEDs melden möchten. Wir möchten sicherstellen, dass unsere Einträge qualitativ hochwertig sind und den bestehenden OSM-Konventionen entsprechen. Es soll außerdem sichergestellt werden, dass keine doppelten Einträge entstehen. Ein Teil der Daten würde voraussichtlich aus Vor-Ort-Erfassungen stammen, ein anderer Teil aus internen Registern in Zusammenarbeit mit Leitstellen, Behörden oder Organisationen.

Wir haben uns intensiv mit dem bestehenden Tagging-Schema für emergency=defibrillator beschäftigt und sind auf einige offene Fragen gestoßen, zu denen wir gerne die Meinung der Community einholen würden.

1. Wir sind der Meinung, dass es eine sinnvolle Ergänzung wäre, die Ablauf- und Prüfdaten der AED-Geräte in OSM sichtbar zu machen, um die Verlässlichkeit der AED-Geräte besser einschätzen zu können. Hierbei denken wir insbesondere an das Ablaufdatum der Elektroden und Batterien bzw. das Datum auf der Prüfplakette. Sind diese Informationen aus Sicht der OSM-Community relevant und wie könnten diese am besten abgebildet werden?

2. Wie handhabt die Community den Fall, dass ein AED temporär zur Wartung außer Betrieb ist? Eignen sich dafür Lifecycle-Präfixe?

3. Aus unserer Sicht könnte es hilfreich sein, wenn zusätzlich zum access-Tag eine nähere Beschreibung zum Zugang des AEDs existiert. Wir hatten dabei an den access:description-Tag gedacht. Laut unserer Recherche scheint dieser Tag jedoch bislang noch nicht für AEDs in OSM genutzt zu werden. Wäre hier der description-Tag besser geeignet?

Wir freuen uns über Erfahrungen, Hinweise auf bestehende Diskussionen oder Wiki-Seiten, die wir möglicherweise übersehen haben. Falls es bereits etablierte Lösungen für einzelne Punkte gibt, nehmen wir das gerne als Grundlage.

Vielen Dank!

TURMsolutions-Team

Für die OSM-DB : mMn nein.

1 Like

https://openaedmap.org/ ist euch bekannt?

Geht es hier um Zugangsbeschränkungen oder eine genauere Beschreibung für den Zugang? Für letzteres gibt es defibrillator:location.

Dem schließe ich mich an. Für die Dokumentation von Wartungsintervallen sollten andere Systeme genutzt werden, keine Geo-Datenbank.

3 Likes

Kennt ihr die OpenAEDMap? Die ist open source (→ Frontend und Backend auf GitHub) und mit OpenStreetMap Polen steht da auch eine Organisation dahinter, die das Projekt langfristig leiten kann. Darstellung vorhandener Defis und geführtes Eintragen geht da schon sehr gut. Vielleicht könnt ihr eure Verbesserungsvorschläge und Erweiterungen dort einbringen? Dann müsst ihr nicht ganz von vorne anfangen und es gibt nicht zwei konkurrierende Projekte :slight_smile:

Wenn diese Daten vor Ort erkennbar sind, könnte man sie meiner Meinung nach schon in OSM eintragen. Bisher gibt es da aber glaube ich kein Tagging-Schema dafür. Es wäre also erstmal zusätzlicher Aufwand, sich dieses Schema auszudenken und im Proposal-Prozess zur Abstimmung zu stellen.

disused:* in Verbindung mit einer note würde sich da meiner Meinung nach schon eignen. Aber nur, wenn der Defi wirklich über längere Zeit nicht benutzbar ist; für weniger als ca. ein Monat würde ich das gar nicht eintragen (die meisten Datennutzer aktualisieren ihre Daten auch gar nicht so häufig von OSM).

Die OpenAEDMap zeigt description (bzw. description:<language code>) und defibrillator:location (bzw. defibrillator:location:<language code>) an, beide Tags werden auch im Wiki empfohlen: Tag:emergency=defibrillator - OpenStreetMap Wiki. Ich würde mich da an diese bestehenden Tags halten, da dann auch alle Datennutzer und Apps wie CoMaps direkt profitieren.

Bitte lest euch dazu die Import Guidelines durch.

Auf jeden Fall ein sehr cooles Projekt! Vielen Dank schonmal für eure Arbeit und die Offenheit :slight_smile:

2 Likes

Ist uns bekannt und mit den Entwickler:innen stehen wir auch im Austausch.

Es geht z.B. um das Szenario, dass access=private hinterlegt ist und man die Zugangsbeschränkung näher beschreiben möchte → “Schlüssel für den Koffer am Empfang” o.Ä. Würde sich dafür auch der defibrillator:location-Tag eignen?

Alles klar, dann werden wir uns da konzeptionell nochmal etwas anderes überlegen.

Vielen Dank!

1 Like

Wir haben uns mehrere AEDs vor Ort angeschaut und bei den meisten kann man das Prüfsiegel und das kleine Sanduhren Symbol (bis wann das Gerät bzw. die Verbrauchsmaterialien einwandfrei funktionsfähig und zugelassen sind) ablesen, auch ohne den Kasten zu öffnen. Die Frage ist hier ob für die Dokumentation solcher Wartungs- oder Prüfintervalle die OSM geeignet ist oder eben nicht, wie andere hier bereits geschildert haben.

Wir hatten bereits die Überlegung disused:emergency=defibrillator + fixme=under maintenanceo.Ä. dafür zu nutzen. Ist aus deiner Sicht der note-Tag dafür besser geeignet?

Sind wir bereits dabei, gerade was die Linzenzen angeht sind wir im Austausch.

Finden wir ebenso. Vielen Dank auch für das hilfreiche Feedback.

1 Like

Ja, siehe DE:Key:fixme - OpenStreetMap Wiki:

Im Unterschied zu note=* zeigt eine Fixme-Markierung, dass der entsprechende Bearbeiter von einem Fehler an dieser Stelle ausgeht.

1 Like

Laut defibrillator:location | Keys | OpenStreetMap Taginfo gibt es bereits einige solche Werte (such dort mal nach „Schlüssel“ oder „Key“).

1 Like

Solche Texte würde ich ebenfalls in defibrillator:location eintragen. Und auch wenn das nur ein Beispiel ist: Den AED benötigt evtl. jemand, der fremd im Gebäude ist. Wenn der Empfang also nicht direkt neben dem AED ist, sollte auch der Ort beschrieben werden.

Bitte aber genau überlegen, welches access gesetzt wird. private wäre für mich ein AED, der für die Öffentlichkeit grundsätzlich nicht erreichbar ist. Dein Beispiel wäre eher permit, weil er auf Nachfrage (hier: Schlüssel) nutzbar ist.

1 Like

Für jemanden, der AEDs wartet/pflegt/betreibt, würde ich empfehlen, den Ablauf des Prüfsiegels außerhalb von OSM zu pflegen und auch aus Souveranitätsgründen nicht allein OSM als Datenbankbetreiber zu nutzen. Die Stärke von OSM ist, Daten unabhängig von Betreibern aus einer Quelle bereitzustellen und dabei noch menschliche Prüfungen einzubauen, um Fehler zu erkennen.

Dennoch würde ich die Erfassung des Ablaufdatums in OSM begrüßen, wenn es vor Ort durch Mapper überprüfbar ist, ohne den Kasten zu öffnen.

Bei vielen AED und allerlei anderen Objekten wird bereits mit check_date=* das Datum erfasst, an dem das letzte Mal ein Mapper sich von der Existenz des Objekts vor Ort überzeugt hat (es ist nicht definiert, ob das alle Tags des Objekts umfasst). Es dient primär der OSM-internen Qualitätssicherung. StreetComplete nutzt es beispielsweise, um “alte” Objekte Mappern zur erneuten Prüfung vorzulegen.

check_date=* in Verbindung mit einem Haltbarkeits-/Prüfdatum auf medizintechnischer Sicht ist IMHO eine nützliche Kombination. Ich sehe da mehrere Anwendungsfälle. Die interessierte Öffentlichkeit kann prüfen, ob die AEDs überhaupt noch gewartet werden oder bloß als Dekoration dienen. Mapper können gezielt AEDs zur Prüfung aufsuchen, deren Prüfsiegel abgelaufen ist. Ich gehe davon aus, dass AEDs am ehesten nach Ablauf des Prüfsiegels abgebaut werden, wenn jemand das tut. Nutzer bzw. deren Software kann eine Verlässlichkeitsabschätzung treffen, welche Einträge verlässlicher wirken.

5 Likes

Hi,
Ich habe einen öffentlichen Defi gemappt, wo folgendes drauf steht:

  • Björn Steiger Stiftung
  • Deutsche Herzstiftung
  • DRK

Was ist denn nun davon der Operator?

Ergänzung: den Barcode ( der auf ein Anleitungsvideo linkt) einfach als URL eintragen?

Kannst du das noch näher erläutern? Wie groß ist dieses Delta (Schätzung)? Und warum sind die Daten nicht öffentlich zugänglich? Sind das z. B. Geräte in privaten Gebäuden (Firmen)?

1 Like

Frag mal bei der Stadt nach.

Ich denke ich werde folgendes eintragen:

  • operator= DRK Ortsverein Senden e.V.
  • donor=Björn Steiger Stiftung

Habt ihr auch Kontakt mit den Menschen der https://defikarte.ch/ ?
Die haben auch eine App entwickelt: defikarte.ch - die Defikarte der Schweiz

2 Likes

Wie lange ist denn so ein Defi in Wartung? Doch vermutlich kürzer als der übliche Aktualisierungszylkus von Kartenanbietern? Deshalb würde man mit disused:* ggf schnell mehr Schaden als Nutzen anrichten.
Eine Möglichkeit wäre, bedingte Beschränkungen ähnlich temporär gesperrter Straßen zu nutzen.

Also z.B.

`access:conditional=no @ (2024 May 22-2024 Oct 7)`

Das ist zwar etabliert, klingt aber weder nach Wartung noch ist es vor Ort überprüfbar?

1 Like

Die beiden Defis bei uns in der Stadtverwaltung sind so geschätzt inkl Abholung usw ca 14 Tage bei der Wartung.

2 Likes

Hier eine konkrete Schätzung zu geben ist schwierig, weil wir selbst nicht wissen wie viele AED Daten in den einzelnen Leitstellen so rumliegen. Die AED Daten sind nicht öffentlich zugänglich, weil die Leitstellen und Behörden diese intern pflegen, aber nicht über eine Schnittstelle o.Ä. nach außen bereit stellen. Mit dem Einpflegen dieser Daten auf die OSM würden sie für alle sichtbar gemacht werden.

Der Punkt ist, ob diese AED öffentlich zugänglich sind oder nicht. Nichtöffentliche AEDs in privaten Gebäuden (z.B. Firmen) halte ich im Sinne von OSM für sehr problematisch, da der Status (zum Beispiel, ob es sie überhaupt noch gibt) nicht durch Mapper überprüfbar ist. Solche AEDs gehören m.E. nicht in OSM.

5 Likes