Undiskutierte (?) Änderungen in Wiki & DB bei Flugnavigationsanlagen

Hallo zusammen,

vor nun schon über 2 Wochen bin ich über diverse Änderungen auf den Wikiseiten zu aeroway=navigationaid und airmark=beacon gestolpert. Da ich persönlich diese Anlagen eher im aeroway-Schema belassen hätte und nun auf andere Meinungen bezüglich Pro & Contra gespannt war, habe ich mich dann auf die Suche nach Diskussionen in den Mailinglisten, hier im Forum und auf den Talk-Seiten gemacht, bedauerlicherweise ohne Erfolg. Ein darauffolgender Blick in die aktuellen Statistiken bei taginfo zeigte bis auf ganz wenige Ausnahmen eine, den Änderungen im Wiki entsprechende, Verteilung. Anschließend habe ich mal versucht, mir soweit möglich die vorherige Nutzung anzuschauen. Mit "OSM Tag History" ist das ja mittlerweile recht einfach und so zeigte sich, dass beide Schemas in der jüngeren Vergangenheit, je nach Blickwinkel, auf einem ähnlichen Niveau in der Datenbank vertreten waren. Irgendwie musste es also Anfang diesen Jahres eine drastische Veränderung gegeben haben. Auf gut Glück habe ich mir dann einfach ein VOR rausgesucht und bin dabei direkt auf einen schon bekannten Namen gestoßen: geozeisig, der auch die Änderungen im Wiki vorgenommen hatte. Ein weiterer Blick in seine History brachte dann auch viele weitere Änderungssätze zu diesem Thema ans Licht. Da ich wie gesagt bis dahin keine Diskussionen finden konnte, habe ich folglich zwei dieser Änderungssätze kommentiert, jeweils einen in Deutsch und Englisch. Der erstere wurde daraufhin auch recht flott beantwortet und ergab für mich tatsächlich den Hinweis auf die User:Talk-Seiten, an die ich zu dem Zeitpunkt noch gar nicht gedacht hatte. Leider haben sich dadurch für mich nur noch mehr Fragen ergeben, welche ich auch in einem weiteren Kommentar formuliert habe, die aber bis heute unbeantwortet blieben.

Nun stellt sich mir die Frage, wie es weitergehen soll? Wie gesagt hätte ich einen Verbleib bei aeroway=* bevorzugt, aber wenn es einen anderweitigen Konsens gibt, dann ist das halt so. Nur scheint das hier eben nicht der Fall zu sein und die Art und Weise, wie die Änderungen durchgedrückt wurden, hinterlässt bei mir bedauerlicherweise einen faden Beigeschmack. Daher würde ich das gerne an dieser Stelle zur Diskussion stellen.

Um das Ganze vielleicht etwas zu unterstützen, habe ich mir nochmal die Geschichte der einzelnen Tags detaillierter angeschaut. Beginnen möchte ich mit den Basistags, wobei ich für diese Betrachtung noch einige weitere Tags hinzugenommen habe:

Und im Detail:

Als allgemeineres Tag dominiert man_made=beacon natürlich, also konzentrieren wir uns zunächst auf die etwas spezielleren. Sowohl aeroway=navigationaid als auch airmark=beacon sind in der zweiten Jahreshälfte 2009 entstanden, wenngleich das erstere noch ein paar Monate früher dran war. Auffällig allerdings ist der katapultartige Start von airmark=beacon. Dem ein oder anderen wird eventuell die ähnliche Größe dieses Sprungs zu dem bei man_made=beacon aufgefallen sein; dies ist kein Zufall, wie sich gleich zeigen wird. Ansonsten ist bzw. war aeroway=navigationaid bis zuletzt am verbreitetsten, wobei fairerweise erwähnt werden sollte, dass dies auch nicht ganz verwunderlich ist, da dieses Schema zusätzlich visuelle Navigationshilfen wie z.B. Anflugbefeuerungen enthält.
Die beiden anderen Schemas sind wie zu sehen noch später entstanden und auch etwas weniger verbreitet. Beachten sollte man, dass in der Praxis durchaus Kombinationen von mehreren dieser 5 Grundtags an ein und demselben Objekt vorkommen können. Doppelt hält besser oder so... 🤔
Weiter geht es mit den Unterschlüsseln jeweils für VOR, NDB, ILS und TACAN:




Hier fallen ebenfalls zu Beginn Sprünge bei beacon:type=* auf, die zeitlich mit dem von man_made=beacon oben zusammentreffen. Das hat mich neugierig gemacht und tatsächlich gab es zu diesem Zeitpunkt einen Import, der im Wiki auf der Talk-Seite von man_made=beacon angekündigt wurde. Etwa 1 Jahr später, im August 2009, wurden diese Objekte dann im Rahmen eines, offensichtlich leicht fehlerhaften, weltweiten Änderungssatzes, der eigentlich wohl nur Seezeichen betreffen sollte, um seamark=beacon ergänzt. Dieser Fehler ist gut 3 Monate später durch denselben Mapper entdeckt und behoben worden. Die Korrektur erfolgte, indem einfach „sea“ durch „air“ ersetzt und somit airmark=beacon geschaffen wurde, siehe den weiter oben erwähnten Katapultstart.
Die Sprünge bei navigationaid=* und type=* vom Anfang diesen Jahres rühren von einer ganzen Reihe an Änderungssätzen (Beispiel), in denen jeweils einzeln Funkfeuer in Frankreich ergänzt wurden. Ich würde vermuten, dass es sich hierbei um einen händischen Import handelt, wobei leider die Quelle unklar ist, denn Namen und Frequenzen aus Luftbildern bei bing abzuleiten, erscheint dann doch leicht unwahrscheinlich... 🙂

Als Fazit dieses Blicks in die Vergangenheit bleibt, dass das Tagging in der Tat ein einziges Kuddelmuddel war (teilweise ist es das auch jetzt noch, denn geozeisig hat sich anscheinend lediglich alles mit navigationaid=* geladen und nur dort entsprechende Änderungen ausgeführt) und eine Bereinigung sicherlich angebracht ist. Die Vorgehensweise hier empfinde ich aber dann doch als problematisch.

Auch wenn das jetzt schon ein ziemlicher langer Text ist, will ich noch – hoffentlich – kurz auf Pro & Contra eingehen. Was den Hauptschlüssel betrifft, habe ich ja schon erwähnt, dass ich aeroway=* bevorzuge. Mit airmark=* wurde ein Schlüssel geschaffen, der momentan völlig alleine steht. Bei dem passenden Wert wird es etwas schwieriger, da „navigationaid“ so wohl nicht ganz korrekt ist. Wenn man bei einem der der bereits vorhandenen Werte bleiben will, wäre meiner Ansicht nach „navigation_aid“ richtig, wobei „navigational_aid“ anscheinend noch verbreiteter ist. Letzterer wäre allerdings völlig neu, was eventuell nur noch mehr Chaos stiften würde. Andererseits würde sich möglicherweise auch eine neue Chance ergeben, das ganze vernünftig mit einem Proposal etc. aufzubauen und letztlich reden wir hier über eine vergleichsweise geringe Menge an Objekten.
Bei den weiteren Tags gibt bzw. gab es von meiner Warte aus bei beiden Systemen Positives sowie Negatives. Als Plus bei airmark=* wäre zu erwähnen, dass die Werte für den Typ des Funkfeuers komplett groß geschrieben sind. Dies sind feste Abkürzungen und die werden soweit ich mich erinnere in der Regel nicht mit Kleinbuchstaben festgehalten, oder? Wenn ich dann weitergehe finde ich aber auch wieder einen negativen Punkt, da mit beacon:code=* wieder ein meiner Meinung nach unnötiger neuer Schlüssel geschaffen wurde, dessen Information genauso gut mit ref=* dargestellt werden kann.
Ein Punkt der beide Schemas betrifft dreht sich um das ILS. Diesen Wert finde ich völlig irreführend, denn ein ILS besteht aus zwei voneinander getrennten Sendern, dem Localizer und dem Glide Path oder Glide Slope. Der LOC befindet sich jeweils am gegenüberliegenden Ende der Landebahn während der Sender für den Gleitpfad sich neben dieser, etwa parallel zum kalkulierten Aufsetzpunkt, befindet. Hier wären also eigene Werte angebracht. Will man beide Sender dann noch kombinieren, könnte man wohl über Relationen nachdenken; da die Frequenzen von LOC und G/S aber fest verpaart sind, sollte bei korrektem Tagging eigentlich auch eine automatische Zuordnung möglich sein.
Die visuellen Systeme unter aeroway=navigationaid sind meiner Ansicht nach auch recht verbesserungswürdig. Bei den Anflugbefeuerungen beispielsweise ist unklar, ob die gesamte Anlage als einzelner Punkt oder jede Lampe bzw. jedes "barrette" (bin mir grad nicht sicher, wie der deutsche Begriff ist) seperat gemappt werden soll. Dies hat zur Folge, dass aktuell das, im Wiki nicht dokumentierte, "approach_light" laut taginfo der Topwert für navigationaid=* ist. Das System als ganzes wäre dann vermutlich wieder ein Fall für eine Relation.
Zum Schluss bleibt natürlich auch die Frage, wieso man überhaupt visuelle Hilfen und Funkfeuer in getrennten Schemas behandeln sollte. Letztlich sind beides Anlagen, die Piloten dabei helfen, ihre Postion im Raum festzustellen und möglicherweise ein bestimmtes Ziel anzufliegen. Die unterschiedliche Art, wie dies geschieht, lässt sich aus meiner Sicht ohne Probleme durch einen Unterschlüssel in der Art von navigationaid=* darstellen.

So das war‘s dann jetzt wirklich. Ich hoffe, ich habe soweit möglich alles reingepackt, bei Fragen, immer her damit.

Vielen Dank und gespannte Grüße,
Patrick (TOGA)