Während eines akuten Unwetternotfalls treffen Informationen darüber, wo Hilfe gebraucht wird und wo Hilfe verfügbar ist, schnell und in völlig uneinheitlichem Format ein. Eine regionale Gruppe zur Koordinierung von Hilfsmaßnahmen sammelte Standorte von Notunterkünften, Ausgabestellen für Hilfsgüter und Meldungen über hilfsbedürftige Menschen von Freiwilligen, die per SMS schickten, was ihnen gerade einfiel: eine Straßenkreuzung, ein Wahrzeichen, eine unvollständige Adresse, ein Koordinatenpaar aus der Karten-App eines Telefons.
Nichts davon lässt sich ohne ein gemeinsames Format darunter direkt auf einer gemeinsamen Karte verwenden. Die Koordinierungsgruppe musste jede eingehende Meldung in dasselbe umwandeln, ein Koordinatenpaar, egal wie sie eintraf. Meldungen, die als Text kamen, als Adresse oder als Beschreibung, die einer Adresse nahe genug kam, liefen über /v1/forward, um einen Standorttreffer zu erhalten. Meldungen, die als Koordinaten kamen, kopiert aus der Standortfreigabe eines Telefons, liefen über /v1/reverse, um eine lesbare Adresse und Verwaltungseinheit zurückzubekommen. Das war nützlich, um Freiwilligen eine verständliche Beschreibung des Ortes zu zeigen statt eines bloßen Zahlenpaars auf der Karte.
Da jede Meldung auf eine Koordinate normalisiert war, wurde es einfach, sie zusammen auf einer gemeinsamen Karte darzustellen, und vor allem wurden sie vergleichbar: Eine Ausgabestelle und ein gemeldeter Bedarf ließen sich nach tatsächlicher Entfernung gegeneinander abwägen. Das war enorm wichtig, um Freiwillige effizient einzusetzen, statt die Nähe anhand schriftlicher Beschreibungen zu erraten, die offensichtlich nichts miteinander zu tun hatten.
Die Gruppe wickelte das über ein schlankes Erfassungsformular ab statt über etwas Aufwendigeres, da während eines laufenden Einsatzes Geschwindigkeit und Einfachheit wichtiger waren als Feinschliff. Ein Freiwilliger, der eine Meldung abschickte, musste nicht wissen oder sich darum kümmern, welcher Endpunkt sein jeweiliges Eingabeformat verarbeitete. Das Erfassungsformular entschied das danach, ob die Eingabe wie Text oder wie Koordinaten aussah, und beide Wege endeten im selben normalisierten Punkt auf der gemeinsamen Karte.
Die Qualität des Treffers war hier wichtiger als bei den meisten anderen Anwendungen der Geokodierung, denn eine Meldung in einem Notfall, die auf den falschen Ort aufgelöst wird, selbst nur mit geringer Abweichung, kann Hilfe genau in dem Moment an den falschen Ort schicken, in dem es am meisten darauf ankommt. Das Erfassungsformular der Gruppe zeigte die von der Geokodierung (Adresse zu Koordinaten) zurückgegebene Trefferkonfidenz direkt der Person an, die eingehende Meldungen prüfte. So bekam ein Treffer mit niedriger Konfidenz eine kurze menschliche Prüfung, bevor man ihm vertraute und handelte, statt mit derselben scheinbaren Sicherheit wie ein sauberer Treffer auf der Karte zu erscheinen.
Dafür war keine spezielle Software für das Notfallmanagement nötig. Die Koordinierungsgruppe betrieb ihr Erfassungsformular auf bereits vorhandener Infrastruktur und fügte die Geokodierung als das eine fehlende Stück hinzu, durch das unstrukturierte, von Freiwilligen gemeldete Ortsbeschreibungen zu etwas wurden, das eine gemeinsame Karte tatsächlich anzeigen und vergleichen konnte.
Das Anfragevolumen stieg während eines laufenden Einsatzes stark und kurzzeitig an, ein Muster, für das sich im Voraus schwer ein festes Budget planen lässt. Das kostenlose Tageskontingent deckte die normale Nutzung für Planung und Vorbereitung zwischen den Ereignissen ab, und Prepaid-Guthaben fing die Spitze während eines tatsächlichen Einsatzes auf, ohne dass sich die Gruppe an einen größeren laufenden Tarif binden musste, den sie den größten Teil des Jahres nicht brauchen würde.
Die Dokumentation zu beiden Endpunkten finden Sie unter /docs/forward-geocoding/ und /docs/reverse-geocoding/.