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… :confused:
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… :slight_smile:

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)

Das hast du ja fleißig zusammen gefasst. Nur zu viele Worte. Es wird keiner ganz lesen und verstehen. Selbst mir fiel es schwer.
Am besten du fasst mal irgendwo zusammen wie deine Vorschlag ist. Z.B. in einem Proposel oder auch hier.
Ich wäre nur gegen Relationen. Die ILS ist ein System, das sich in LOC und GS aufteilt. Machmal wurde schon localiser=yes bzw. glidepath=yes hinzugefügt.
Auch alle Navigationslichter eines Flughafens einzeln zu mappen (egal ob mit oder ohne Relation) scheint mir nicht sehr sinnvoll.

Bei den Lichtern bin ich bei Dir, ein großer Teil aller Anflugbefeuerungen z.B. wird nach einer entsprechenden Standardkonfiguration aufgebaut. Ich hatte ja bereits angedeutet, dass ich mir über den gesamten Themenbereich Gedanken gemacht habe und meiner Meinung nach lassen diese sich einfach durch Tags an der Landebahn darstellen. Daneben gibt es aber durchaus auch Systeme, die aus der Reihe tanzen und hier wären eigene Objekte für Anfluglichter eben doch angebracht, ein berühmteres Beispiel hierfür ist der Parkway Visual bzw. Canarsie Approach in New York (Video).

Was LOC und GS angeht, würde ich nicht ganz zustimmen. Mein Problem hierbei ist, dass es durchaus auch Landebahnen gibt, die nur mit einem LOC ausgestattet sind und dort ergibt es für mich keinen Sinn mit “ILS” als Wert und weiteren Tags zu arbeiten. Von daher bräuchte man schon für diese Fälle einen eigenen Wert und dann ergibt sich für mich durchaus die Frage, wieso der eine Localiser als “ILS” und der andere als “LOC” getaggt werden sollte, obwohl sie doch den gleichen Aufbau haben, das gleiche Signal senden etc… Von daher würde ich, wie gesagt, genau andersherum vorgehen als bisher und eben, wenn überhaupt gewünscht, das ILS als Zusatz taggen. Die Relationen habe nur mit in die Diskussion werfen wollen, wirklich nötig sind sie wahrscheinlich nicht.

Ich werde wohl tatsächlich mal schauen, dass ich das in einem Proposal zusammenschreibe. Im Wiki geht das mit Tabellen und ähnlichem, denke ich, übersichtlicher als hier im Forum. Da ich aber momentan nicht so viel Zeit habe, kann das noch ein paar Tage dauern.

Gut dann sind wir ja schon drei die am Thema interessiert sind und an eine guten Wiki- Dokumentation machen wollen. Nur sollten wir in englisch schreiben damit Chrabros mit machen kann (was mir selbst etwas schwer fällt).
Ein Proposal ist sicher etwas handfesten, nur würde ich glauben das wenig Beteiligung sein wird wenn es zur Abstimmung kommt. Und ob der Status eines tags “approved” oder “In use” ist macht auch keinen großen Unterschied. Vielleicht wäre die Diskussionsseite einer Wiki-Seite geeignet.
Je nachdem was geändert werden soll kann man auch anders vorgehen. Natürlich muss, wenn eine bestehender tag geändert werden soll, die Prozedur für Massenedits beachtet werden. Weniger gut wäre es wenn es neue und alte tags (für lange Zeit) parallel geben würde.