Aktualisierung von Luftraumdaten

[oekosoft]

AW: Aktualisierung von Luftraumdaten

Der XCglobe AirSpace Editor rundet Höhenangaben auf volle 100er Fuß, also quasie in Flightlevel

Mich stört weniger das Runden sondern dass in den OpernAir Dateien bei den Höhenangaben keine Einheit steht (ft oder m).

[BitBroker]

AW: Aktualisierung von Luftraumdaten

Mich stört weniger das Runden sondern dass in den OpernAir Dateien bei den Höhenangaben keine Einheit steht (ft oder m).

Auch das ist im Open Air Format nicht definiert! Die Interpretation kann man sich aussuchen! Überlich ist: kein Angabe -> m

Eine Angabe "m" habe ich noch nie gesehen und die Angabe in Fuß kenne ich als "ft", "FT" oder "F". Ist also auch eher Zufall.

Oder meinst du das diese Angabe in meinen "Test Open Air" Daten fehlt?

[oekosoft]

AW: Aktualisierung von Luftraumdaten

Eine Angabe "m" habe ich noch nie gesehen .. Oder meinst du das diese Angabe in meinen "Test Open Air" Daten fehlt?

Ja, ich meine deine "Test OpenAir" Dateien.
Z.B. bei flyland.ch gibt es die Daten wahlweise in Meter

AC CTR
AN ALPNACH CTR 128.475
AL GND
AH 3950 m

oder in Fuss

AC CTR
AN ALPNACH CTR 128.475
AL GND
AH 12959 ft

Bei dir wird das zu

AC CTR
AN ALPNACH A CTR 128.475
AH 13000 MSL
AL GND

Wenn du richtig liegst, dass die Einheitsangabe optional ist und Meter die defaultmässige Einheit ist, dann wären die Zahlen falsch (da in Fuss).
Vielleicht ist ja aber auch Fuss die Default-Einheit, keine Ahnung. Vielleicht ist das auch geräteabhängig. Bei einer so wichtigen Angabe sollte man sich besser nicht auf Defaultwerte verlassen.

[BitBroker]

AW: Aktualisierung von Luftraumdaten

Hallo Walter,
ich habe die Kennung FT hinter den Höhenangaben hinzugefügt, da es sich um Fußangaben handelt.
Damit sollte die Höhenangabe eindeutig und zumindest auf 100FT gerundet auch richtig sein.
Wäre schön, wenn du es nochmals - vll. auch in den original oab Daten - validieren könntest.
Gruß Burkhard

[shoulders]

AW: Aktualisierung von Luftraumdaten

Bei OpenAir ist Fuß Default.

Btw: PFB beinhaltet seit ca. 9 Jahren einen grafischen Luftraumeditor, verwendet intern ein eigenes Format, von und zu dem korrekt gegen OpenAir gerechnet wird, konvertiert Formate, errechnet automatisch Stützpunktgruppen aus Kreisbögen (weil die damals außer Flytec keiner interpretieren konnte) - und wird gerade auf den Import/Export von OAB erweitert...

Sobald ich von Xcontest Antwort auf meine Anfrage bzgl. Updateinterface habe, wird die vollautomatische Aktualisierung umgesetzt; automatisch angeschlossene Varios damit befüllen kann die Software ja schon seit 11 Jahren, und mit OAB dann demnächst auch ein Sk2.1

CU
Shoulders

"Echte Vögel kotzen nicht!"

[BitBroker]

AW: Aktualisierung von Luftraumdaten

wird die vollautomatische Aktualisierung umgesetz

Geht doch

[TOASTER]

AW: Aktualisierung von Luftraumdaten

Wie bereits mehrfach geschrieben, jetzt sind schon wieder mindestens zwei Leute etwas am programmieren - bei den Daten will aber niemand mithelfen. Und da liegt das Problem!
Es ist nicht gelöst, auch wenn man die XContest-Daten verwendet. Aber ihr könnt es gerne selber rausfinden, wenn ihr nicht fragen wollt... ich geb's auf.

Mfg Daniel

[marcel1]

AW: Aktualisierung von Luftraumdaten

etzt sind schon wieder mindestens zwei Leute etwas am programmieren - bei den Daten will aber niemand mithelfen. Und da liegt das Problem!

Das kann auch niemanden verwundern, da es eine Sisyphusaufgabe ist. Wenn das nicht von den staatlichen Stellen angeliefert wird, wird man da immer hinterherhecheln und mehr oder minder veraltete Daten sind dann leider normal.

Ich mach mir da keine Hoffnungen...

[TOASTER]

AW: Aktualisierung von Luftraumdaten

Das kann auch niemanden verwundern, da es eine Sisyphusaufgabe ist. Wenn das nicht von den staatlichen Stellen angeliefert wird, wird man da immer hinterherhecheln und mehr oder minder veraltete Daten sind dann leider normal.

Ich mach mir da keine Hoffnungen...

Für Deutschland und Österreich werden die Daten ja sehr gut zur Verfügung gestellt - es fehlt nur an Piloten die zum Beispiel mir solche Sachen melden würden. Das wird ja von sehr vielen Piloten bemerkt.
Der Aufwand diese Änderungen dann einzupflegen ist überschaubar. Ich stelle mich ja sogar dafür zur Verfügung - es braucht idealerweise noch ein paar Leute, die bei der Kontrolle mithelfen. Am Beispiel von BitBroker und all den Kommentaren dazu sieht man ja, dass die Kapazität vorhanden ist. Jetzt braucht es einfach mal ein bisschen Commitment für die Sache. Ihr verpflichtet euch damit ja zu nichts und übernehmt auch keine Verantwortung. Wäre es nicht einfach zu sagen: "ich helfe da mit und informiere dich zukünftig!"?"

Mfg Daniel

Sorry für den gelöschten Post, wollte beim letzten Satz noch was änden und dann löscht mir das Handy den ganzen Beitrag...

[danilo-b]

AW: Aktualisierung von Luftraumdaten

Beim Entwickeln des OpenAir Parsers für Rust (https://github.com/dbrgn/openair-rs) habe ich beim Testen mit Luftraum-Files von diversen Herstellern erhebliche Probleme mit den gängigen OpenAir Luftraum-Dateien bemerkt. Es ist echt katastrophal, wie die Qualität dieser OpenAir-Dateien ist. Ganz übel waren die Dateien von Syride, aber ich nehme an dass die die selben veralteten Lufträume copy-pasten wie alle anderen Hersteller auch. Die Luftraumdateien, die standardmässig auf dem Skytraxx 2 sind, sahen nämlich nicht viel besser aus.

Das Hauptproblem bei OpenAir ist, dass es keine richtige Spezifikation gibt. Das Format ist völlig unterspezifiziert, jeder Hersteller handhabt die Dateien wieder leicht anders. Das resultiert in ganz vielen Luftraum-Daten, die auf diverse Art und Weise inkompatibel mit Geräten oder Tools sind. Die einzige Art, wie ein Gerät solche Lufträume parsen kann, ist, indem es alles was es nicht versteht einfach ignoriert. Das bedeutet, dass möglicherweise gewisse Lufträume während des Fluges ohne Warnung nicht oder nicht korrekt angezeigt werden. Theoretisch müsste jeder Luftraum *auf dem Zielgerät* verifiziert werden, es reicht nicht, wenn man die Luftraumdateien einfach auf xcontest.org kontrolliert, herunterlädt und dann auf das Gerät kopiert.

Skytraxx hätte hier eine Chance, ihr neues Luftraumformat offen zu entwickeln, klar zu spezifizieren und es zu einem offenen Format weiterzuentwickeln. Leider bringt das für die bestehenden Geräte nicht viel.

Eine mögliche Alternative wäre das Erarbeiten einer Spezifikation, welche ein klar definiertes Subset von OpenAir darstellt. Beispielsweise würde eine solche Spezifikation definieren, dass ein Luftraum, welcher bis an den Boden reicht, mit "GND" gekennzeichnet werden muss, und nicht etwa mit "0 ft", "SFC" oder "0". Der Vorteil von OpenAir ist, dass es bereits weit verbreitet und einfach lesbar ist. Damit eine solche Spezifikation etwas bringt, müsste man aber Support von 1-2 Herstellern kriegen. Hat da jemand von euch entsprechende Kontakte? Hätte jemand Interesse, an so einem Projekt mitzuarbeiten?

--

Und bevor jemand sagt, dass ich nur neue Tools entwickle, statt die bestehenden Daten zu verbessern, hier die Email die ich an Syride gesendet habe. Leider weiss ich nichtmal, ob sie bei denen angekommen ist, ihr Kontaktformular auf der Website ist natürlich halb kaputt

Hello Syride

I am currently creating a parser for OpenAir files. While trying to process
airspace files generated by your website (https://www.syride.com/en/airspace),
I found the following problems in your files, grouped by category. I stopped at
some point, because the quality of the files was so bad...

*Invalid altitude format*

- [Austria / Germany / Czech Republic / Slovakia / others] Many airspaces have
lower or upper bound in the format "3600ft ft". This is clearly invalid, one
of the "ft" should disappear.
- [Germany] There are two airspaces ("Sector Mellenthin" and "Bale-Mulhouse 1")
that use the altitude format "ft GND". While I understand what this should
probably mean, the correct unit would be "ft AGL".
- [Germany / Canada] Ambiguous values: AL/AH records of the format "1000 GND",
"700AGL", "1000SFC" etc). Probably safe to assume that it's feet AGL, but
could also be meters, depending on the conversion source.
- [Colombia / Estonia / Macedonia / others] Many plain-numeric values (e.g. "AH
3500" for "SKE3"). What unit, feet AGL? Feet AMSL? Meters AGL?
- [Belgium] The airspaces "LILLE TMA 2.1" and "LILLE TMA 9.1" contain bounds in
the format "4500F ft". That is invalid.
- [Brazil] Multiple airspaces (e.g. "SBP341-HEFESTO") contain an "AL ft"
record. That is invalid.
- [Croatia] Free-form AH records, for example "AH 1000FT AGL (Above 1000 FT
AGL: upon NOTAM)".
- [France] Some airspaces have records that specify the height as both meters
and feet, e.g. "600M ft" in Phalsbourg.
- [France] Some airspaces have records that specify the height as both meters
and FL, e.g. "FL195 ft" in Calamar.

*Non-machine-readable or invalid altitude values*

- [Australia] There are airspace bounds called "BCTA". According to
https://vfrg.casa.gov.au/resources/a...-and-acronyms/, this means
"Base of CTA", where CTA stands for "Control Area". I doubt this
specification is of much use to a variometer.
- [Australia] There are airspaces with "AH NOTAM" records (e.g. "D267 WESTERN
HILLS"). Again, this is not something a variometer can use for warnings.
- [Australia / Malaysia] There are airspaces that have an "AH GND" record (e.g.
"R192D STIRLING"). Having an airspace with an upper bound on ground level
does not make sense at all.
- [Austria] Some airspaces (e.g. "TRA Bruck") have an AL record "variable lower
limit". A variometer cannot handle that for warnings.

*Invalid airspaces*

- [Estonia] The airspace "AREA G5 (NARVA)" contains two "AL" records and no
"AH" record
- [Estonia] The airspace "Zone 5 (Jägala) Paramotoring" has no upper or lower
bound
- [France] The airspace between "R170A+B CALAMAR 119.6" and "R172 Razimont tel
03 29 69 82 37" has no name.
- [France] The airspace "R 333 Bretigny Leudeville Drones" is invalid, it
starts with a name, followed by an empty line, and only then an AC record.
- [France] The airspace "Oostende APP 120.6" contains an invalid line ("Belgian-Dutch border")

*Invalid coordinates*

- [France] The airspace "R 368 E2 activité NOTAM" has a "DP" record without a
value

*General*

- [Croatia] The airspace "LDD21 RIJEKA (OMISALJ )" and others contain an inline
comment. I don't think that's supported by OpenAir, since the name might also
contain a `*` character.
- Some of your airspaces files seem to be UTF-8 encoded while others seem to be
latin1 encoded. It would be a good idea to use UTF-8 everywhere.

I suspect that the Syride device will simply ignore airspaces it cannot parse
without an error or warning. (I don't actually have a Syride device to verify
this.) Therefore it would be important that the airspace files you are offering
are at least parseable without a problem. Since people rely on the airspace
warnings by their flight devices, it's important that the boundaries are
properly understood by those devices.

If you need to know anything else, let me know!

Danilo

[shoulders]

AW: Aktualisierung von Luftraumdaten

Diese Probleme mit der zu freien OpenAir-Spezifikation ist doch schon uralt. Es ist aber auch definiert, was im Zweifelsfall "richtig" ist - z.B. ft als Standard bei fehlender Angabe. Da muss man halt den Parser etwas aufwändiger machen, das ist für PFB deshalb ja auch schon vor 10 Jahren passiert. Skytraxx ist dabei witzigerweise sogar weniger tolerant als PFB.

CU
Shoulders

"Echte Vögel kotzen nicht!"

[danilo-b]

AW: Aktualisierung von Luftraumdaten

Diese Probleme mit der zu freien OpenAir-Spezifikation ist doch schon uralt.

Das macht die Sache nicht besser

Es ist aber auch definiert, was im Zweifelsfall "richtig" ist - z.B. ft als Standard bei fehlender Angabe.

Wo? Gibt es neben http://www.winpilot.com/UsersGuide/UserAirspace.asp eine weitere Spezifikation? Und wenn Fuss, dann AGL, AMSL oder QNH?

Da muss man halt den Parser etwas aufwändiger machen, das ist für PFB deshalb ja auch schon vor 10 Jahren passiert. Skytraxx ist dabei witzigerweise sogar weniger tolerant als PFB.

Naja, wenn in den Airspace Files Dinge wie "600M ft" drin stehen, dann führt ein allzu toleranter Parser nur zu subtilen Fehlinterpretationen. Der Pilot denkt dann, dass alles seine Richtigkeit hat, und fliegt im dümmsten Fall unwissend in einen gesperrten Luftraum.

[shoulders]

AW: Aktualisierung von Luftraumdaten

Wo? Gibt es neben http://www.winpilot.com/UsersGuide/UserAirspace.asp eine weitere Spezifikation? Und wenn Fuss, dann AGL, AMSL oder QNH?
(...)
Naja, wenn in den Airspace Files Dinge wie "600M ft" drin stehen, dann führt ein allzu toleranter Parser nur zu subtilen Fehlinterpretationen. Der Pilot denkt dann, dass alles seine Richtigkeit hat, und fliegt im dümmsten Fall unwissend in einen gesperrten Luftraum.

Es sind AMSL. AGL wird explizit ausgewiesen. QNH ist keine Höhenangabe, sondern ein Einstellungsmodus - Du meinst damit vermutlich eine druckbasierte Höhe; die wird als FL angegeben. Und dass Lufträume ohne weitere Angabe in ft zu interpretieren sind, hat gar nichts mit irgendeinem Format zu tun, sondern ist in der Luftfahrt einfach üblich.

"600M ft" sind ein klarer Datenfehler. Das muss ein Parser nicht leisten - aber er kann es sogar, denn der gesunde Menschenverstand legt nahe, dass die angefügte Einheit gewollt und eine davor liegende, zweite vergessen worden sein dürfte. Also parst man in diesem Fall von rechts nach links bis zur Identifizierung aller Textelemente, zu denen Einheiten (ft, m) und Bezugsrahmen (AMSL, MSL, GND, SFC, AGL etc.) zählen. Alle Vorkommen nach dem jeweils ersten für eine Einheit bzw. einen Bezugsrahmen werden ignoriert, und ab der ersten Ziffer (streng genommen der letzten, aber wir kommen ja immer noch von rechts) werden weitere Alphazeichen sowieso ignoriert.

Damit bekommt man eine praktisch 100%ige Trefferquote - und wenn man jetzt noch über das reine Parsen hinaus denkt, kann man fehlende/unklare Daten nachverarbeiten. ParaFlightBook z.B. verwendet ein eigenes XML-Objektformat, in dem neben anderen Zusatzinfos wie Funkfrequenzen, Aktivierungszeiten etc. eben auch die Eindeutigkeit der Quelldaten (per numerischer Qualitätsstufe) und deren Ursprung (als Dateiname mit Zeitstempelinfo) hinterlegt sind. Im Programm werden solche "unsicheren" Lufträume visuell hervorgehoben - und wenn nun hieraus wiederum OpenAir-Dateien erzeugt oder in die proprietären Formate bestimmter Instrumente (z.B. alte Flymaster, oder FAF, oder Ascent) exportiert wird, kann man sie optional ausschließen. Ein Instrumentenhersteller könnte Ähnliches in seiner Firmware hinterlegen.

Dieser Lösungsansatz sowie die ihm zugrunde liegende Problemanalyse des OpenAir-Formats respektive der Datenquellen stammt übrigens aus dem Jahr 2009 und war schon damals keine Raketentechnik


CU
Shoulders

[BitBroker]

AW: Aktualisierung von Luftraumdaten

Hallo Danilo,

erst einmal vielen Dank für dein Engagement !!

Aus meiner Sicht ist das Open-Air-Format aus diesem Grunde tot (als direktes Inputformat von Varios).
Es gibt so viele "Schrott" Luftraumdaten im Netz, dass man sich eigentlich auf nichts verlassen kann!
Ich habe es schon selbst erlebt, dass ich eine Luftraumdatei auf dem SKYTRAXX 3.0 getestet habe und diese wurde fast vollständig verworfen!
Es gibt keine Möglichkeit über einen Errorlog oder ähnliches das Parsen auf dem SKYTRAXX zu verifizieren.
Ich denke das ist bei anderen Varioherstellern nicht anders.

Ich halte daher den Ansatz von SKYTRAXX für den richtigen Weg.
Die Daten werden mit einer Parser/Konverter (von SKYTRAXX zyklisch jede Nacht) erzeugt und der Anwender hat die Möglichkeit bei und nach der Generierung die Daten zu prüfen.
Z.B. Errorlog eines Parsers oder - wie es SKYTRAXX macht - daraus wieder eine KML erzeugen.

Skytraxx hätte hier eine Chance, ihr neues Luftraumformat offen zu entwickeln, klar zu spezifizieren und es zu einem offenen Format weiterzuentwickeln.

Was fehlt dir hierzu noch? Ist dir die Veröffentlichung unter github nicht verbindlich genug? Erwartest die zwei PDF Seiten Doku?

Es ist doch nicht wirklich zu erwarten, dass sich ein Mitbewerber da einklinkt!
Die kriegens ja schon nicht gewuppt so etwas wie FANET einzubinden und damit einen Standard zu generieren.

Und wie Email Support aussieht hast du ja schon selbst beschrieben.

Gruß Burkhard

[danilo-b]

AW: Aktualisierung von Luftraumdaten

Was fehlt dir hierzu noch? Ist dir die Veröffentlichung unter github nicht verbindlich genug? Erwartest die zwei PDF Seiten Doku?

Damit das Format eine Chance hätte, sich als Standard zu verbreiten, müsste es eine offene, versionierte Spezifikation geben (egal in welchem Format), sowie ein Abtreten von jeglichen Patent- oder Urheberrechtsansprüchen. Halt so, wie Standards (z.B. die der IETF) gemacht werden. Sonst setzt sich kein Mitbewerber dem Risiko aus, plötzlich von Syktraxx abgemahnt zu werden.

Es ist doch nicht wirklich zu erwarten, dass sich ein Mitbewerber da einklinkt!

Wieso nicht? Angenommen du entwickelst ein neues Vario und musst dich für ein Datenformat entscheiden. Falls die Bedingungen oben gegeben wären, warum nicht OAB?

Das vorgeschlagene Subset von OpenAir wäre aber natürlich auch eine Alternative, da es aktuell bereits kompatibel wäre mit allen Geräten. Aber man hätte damit dann erstmalig einen klar definierten Standard, wie die Dateien auszusehen haben.

Die kriegens ja schon nicht gewuppt so etwas wie FANET einzubinden

FANET ist noch jung. FANET kann man auch nicht "einfach so einbinden", sondern man muss die Hardware anpassen (Entwicklungsaufwand, Kosten, Zeitbedarf für Anpassung der Firmware). Zudem müssen meines Wissens direkt oder indirekt Lizenzgebühren an einen Konkurrenten bezahlt werden. Das könnte auch einige Anbieter stören.

Ich habe aber durchaus die Hoffnung, dass ein anderer Anbieter ebenfalls FANET in seine Geräte einbaut.