Skytraxx 2.1

[hilde]

AW: Skytraxx 2.1

OT Liegts an der Schnelllebligkeit der Märkte? Oder ist die Schnelllebigkeit eine Folge der Umsatz- und Profitgier der Märkte?

[Stephan Knips]

AW: Skytraxx 2.1

Es liegt an dem Quatsch, daß viele glauben, jedes Jahr das neueste Händi haben zu müssen.
Obwohl das von vor 3 Jahren auch schon fast alles konnte.

Das wird dann auf Produkte ähnlicher Kategorie übertragen.

Knipsi

[hilde]

AW: Skytraxx 2.1

Das mag bei Lifestyleprodukten gelten. Betrifft aber leider mittlerweile auch Industriegüter etc wo nicht jeder immer das Neueste haben will und muss...
Kriegs tagtäglich mit bei einem Großdieselmotorenhersteller am schwäbischen Meer.
Und Boeing (737MAX) schmeiss ich gleich mit ins Boot..aber wir driften ab

[Onk]

AW: Skytraxx 2.1 - Luftraumdten

Das ist ein heutiges weitverbreitetes Problem wie überall in der Technik. Der Marktdruck ist so hoch, das man sein Produkt möglichst schnell am Markt haben muss, zur Not halt in der Beta-Version, und dann den Rest ankündigen und über updates nachschieben.
das liegt an der Schnelllebigkeit der Märkte, leider....

Es liegt auch daran, dass es überhaupt geht.
Früher (bleiben wir beim Vario) musste die Firmware bei Auslieferung komplett fertig sein. Möglichkeiten zum Update gab es nicht.
Heute sind das etablierte Mechanismen.
Diese erlauben ein Produkt früher auf den Markt zu bringen und später im Funktionsumfang zu erweitern.
Das ist an sich nichts verwerfliches. Es erlaubt einen früheren Markteintritt und reduziert damit auch die erforderlichen finanziellen Mittel in der Entwicklung etc. Es muss nicht alles vorfinanziert werden, sondern ein Teil der Kosten für die Weiterentwicklung kann aus Einnahmen gedeckt werden.
Natürlich geht es auch um Wettbewerb und dass, was die Konkurrenz an den Start bringt.
Zentrale Versprechen bzgl. Funktionsumfang, die auch intensiv beworben werden sollten schon am Start entsprechend erfüllt werden.

[BitBroker]

Luftraumdaten im OAB Format

Weil ich mich sowieso mal mit dem oob und oab Format des SKYTRAXX 2.1 beschäftigt habe – SKYTRAXX veröffentlicht alle seine Formate (hier wird ziemlich viel Müll von angeblichen Leuten vom Fach geschrieben) – habe ich auf meiner Homepage jetzt mal aufbereitete Luftraumdaten für Deutschland, Österreich und der Schweiz zur Verfügung gestellt.

Da ich kein SKYTRAXX 2.1 habe kann ich es nicht testen, erst wenn dass 3.0 auch oab verwendet

Vermutlich wird ja auch bald der automatisierte Import von XContest kommen, da die OpenAIP (Daten) Aktualisierung auch ziemlich hinterherhinkt.

Das ist nur eine einmalige Aktion weil ich Spass dran habe! Ich werde keinen Aktualisierungsdienst aufsetzen und keine Luftraumdaten auf Anforderung oder nach Wunsch konvertieren!

Gruß Burkhard

[TOASTER]

AW: Luftraumdaten im OAB Format

Weil ich mich sowieso mal mit dem oob und oab Format des SKYTRAXX 2.1 beschäftigt habe – SKYTRAXX veröffentlicht alle seine Formate (hier wird ziemlich viel Müll von angeblichen Leuten vom Fach geschrieben) – habe ich auf meiner Homepage jetzt mal aufbereitete Luftraumdaten für Deutschland, Österreich und der Schweiz zur Verfügung gestellt.

Da ich kein SKYTRAXX 2.1 habe kann ich es nicht testen, erst wenn dass 3.0 auch oab verwendet

Vermutlich wird ja auch bald der automatisierte Import von XContest kommen, da die OpenAIP (Daten) Aktualisierung auch ziemlich hinterherhinkt.

Das ist nur eine einmalige Aktion weil ich Spass dran habe! Ich werde keinen Aktualisierungsdienst aufsetzen und keine Luftraumdaten auf Anforderung oder nach Wunsch konvertieren!

Gruß Burkhard

Hallo Burkhard,
Kannst du dich präziser ausdrücken und solche leeren Worte sparen? Welcher "Müll" wurde von wem behauptet und ist falsch? So trägst du nur zur Verwirrung der Leser bei.
Skytraxx stellt keine Möglichkeit zur Verfügung von .oab zurück und eine schwer bedienbare von openaip zu .oab. Ist das falsch?

Hier noch zwei Hinweise für deine Seite:

Nachteile von OpenAIR
Es gibt Bereichsüberschreitungen

Hat mit OpenAir gar nichts zu tun - ist bei OpenAIP nämlich nicht anders. Für jedes Land gibt es eine Datei, an den Grenzen kommt es so zu Überschneidungen und doppelten Lufträumen. Muss auch da irgendwie gefiltert werden....
Aktuelles Beispiel -Lufträume bei Basel. Irgendwer muss das jetzt zu einer einzelnen Welt-Datei zusammensetzen und das ist aus mehreren Gründen problematisch. Wenn irgendwo in Tschibuti ein Luftraum ändert, bekomme ich einen neuen Zeitstempel. Wie kontrollierst du so grosse Dateien ohne Tool?

Du ersetzt die Kreise in deinen Files mit Vielecken. So entstehen lokale Abweichungen von ca. 25m (bei 32 Ecken, 5km) diese Punkte werden dann im Openair Format ohne Kommastelle angegeben - weitere Fehler von 25-30m horizontal und vertikal möglich.
In deinen Files gibt es somit Abweichungen von 50m. Das kann grundsätzlich bei jeder Konvertierung passieren und ist auf den ersten Blick nicht ersichtlich. Was die Geräte mit den Kommastellen machen würden, ist noch eine ganz andere Frage und kann man nur mit sehr viel Aufwand nachvollziehen. Trotzdem gibt es jetzt eine "weitere Variante" der Schweizer Lufträume online....
Wer soll da den Überblick behalten?

Mfg Daniel

P.S.
Wie wäre es mit einem korrekten Header für die OpenAir-Daten, wo du deine Quellen auch angibst? Gehört sich eigentlich so...

************************************************** *************
* Open Air File generated by oab4mgr
* Copyright (C) 2018 Burkhard Vogt, Muenster, Germany
*
* >>>>> UNOFFICIAL, USE AT YOUR OWN RISK <<<<<
*
* NOT to be used as a primary navigational aid.
* ALWAYS refer to current charts for definitive information.
*
* LICENSE CC BY-NC-SA
* Distribution by commercial companies not allowed.
* Courtesy of www.bitbroker.eu info(ät)bitbroker.eu
************************************************** ************

LICENSE CC BY-NC-SA
Nächstes mal mache ich noch ein Copyright mehr - auf meinen Header. Sieht er nicht schön aus ;-) Diese Provokation musste jetzt sein.

* ************************************************** ************* *
* AIRSPACES OF SWITZERLAND
* OPTIMIZED FOR GLIDER ACTIVITY
* Creation date: 01.05.2019 18:00
*
* Main Data Source
* www.flyland.ch
* Download date: 05.04.2019 19:17
*
* This file is provided free of charge with no warrantees
* >>>>> UNOFFICIAL, USE AT YOUR OWN RISK <<<<<
*
* NOT to be used as a primary navigational aid.
* ALWAYS refer to current charts for definitive information
*
* LICENSE CC BY-NC-SA
* Distribution by commercial companies not allowed.
* Courtesy of www.skyride.ch daniel(ät)skyride.ch
* ************************************************** ************* *

[BitBroker]

AW: Luftraumdaten im OAB Format

Hallo Daniel,

Kannst du dich präziser ausdrücken und solche leeren Worte sparen? Welcher "Müll" wurde von wem behauptet und ist falsch? So trägst du nur zur Verwirrung der Leser bei.
Skytraxx stellt keine Möglichkeit zur Verfügung von .oab zurück und eine schwer bedienbare von openaip zu .oab. Ist das falsch?

da wurde in Posts von proprietären Formaten gesprochen, das ist Quatsch!
Unter github sind alle genannten Formate beschrieben und Codefragmente für die Konvertierung vom OpenAIP XML Format in das oab Format veröffentlicht.
Deshalb dieser Hinweis.

Zu den fehlenden Konvertern für Anwender hast du natürlich recht.
Sollen / Werden aber hoffentlich bald kommen.

Hat mit OpenAir gar nichts zu tun - ist bei OpenAIP nämlich nicht anders. Für jedes Land gibt es eine Datei, an den Grenzen kommt es so zu Überschneidungen und doppelten Lufträumen. Muss auch da irgendwie gefiltert werden....
Aktuelles Beispiel -Lufträume bei Basel. Irgendwer muss das jetzt zu einer einzelnen Welt-Datei zusammensetzen und das ist aus mehreren Gründen problematisch. Wenn irgendwo in Tschibuti ein Luftraum ändert, bekomme ich einen neuen Zeitstempel. Wie kontrollierst du so grosse Dateien ohne Tool?

Du ersetzt die Kreise in deinen Files mit Vielecken. So entstehen lokale Abweichungen von ca. 25m (bei 32 Ecken, 5km) diese Punkte werden dann im Openair Format ohne Kommastelle angegeben - weitere Fehler von 25-30m horizontal und vertikal möglich.
In deinen Files gibt es somit Abweichungen von 50m. Das kann grundsätzlich bei jeder Konvertierung passieren und ist auf den ersten Blick nicht ersichtlich. Was die Geräte mit den Kommastellen machen würden, ist noch eine ganz andere Frage und kann man nur mit sehr viel Aufwand nachvollziehen. Trotzdem gibt es jetzt eine "weitere Variante" der Schweizer Lufträume online....
Wer soll da den Überblick behalten?

Das hat eher was mit Software zu tun, du siehst das "nur" aus dem Blickwinkel des Luftraumerstellers.
Kreise und Kreisbögen sind bei Programmen so ungefähr das Schlimmste was dir passieren kann!
Es gibt keine vernünftigen mathematischen Algorithmen um SCHNELL sphärische geometrische Funktionen zu rechnen.
Das braucht man aber, wenn z.B. ein Vario mit begrenzter CPU Leistung diese Berechnungen für Luftraumwarnungen "on the fly" durchführen muss.
Daher werden eigentlich immer Kreisbögen (Kreise bzw. Zylinder sind noch machbar) in Polygone zerlegt.
Also warum nicht sofort Kreisbögen auflösen und direkt als Polygone erfassen?
Dann weiß auch der Anwender was die Grundlage ist.

P.S.
Wie wäre es mit einem korrekten Header für die OpenAir-Daten, wo du deine Quellen auch angibst? Gehört sich eigentlich so...
LICENSE CC BY-NC-SA
Nächstes mal mache ich noch ein Copyright mehr - auf meinen Header. Sieht er nicht schön aus ;-) Diese Provokation musste jetzt sein.

Verstehe ich jetzt nicht?
Ich habe beschrieben, dass diese Dateien aus dem zuvor erstellten oab Dateien für das SKYTRAXX 2.1 entstanden sind, also nicht mehr deinem Original entsprechen.
Das hast du jetzt wohl nicht verstanden und vermutlich werden das dann andere Anwender auch nicht richtig verstanden haben ...

Ich habe das jetzt auf meiner Seite geändert, damit ist noch deutlicher wird.
Es handelt sich um einem Export damit man die oab Dateien prüfen kann!
Nicht, um diese als Open Air Dateien für andere Varios zu verwenden!
Ich hätte auch GPX oder sonst was daraus machen können, es muss nur virtualisierbar sein.

Dein Copyright ist leider im oab Format nicht mehr vorhanden, also auch nicht mehr im Export.
Deine Vorlage fand ich gut und habe sie dann - mehr oder weniger - einfach übernommen.
Was soll ich löschen oder was stört dich genau?

Gruß Burkhard

[BitBroker]

AW: Skytraxx 2.1

Der XCglobe AirSpace Editor rundet Höhenangaben auf volle 100er Fuß, also quasi in Flightlevel
Jedenfalls bei der OpenAIP Ausgabe aus zuvor eingelesenen Open Air Format Dateien.

Soviel mal zum Thema: Verlässliche digitale Luftraumdaten

Habe meine Seite mit einem entsprechenden Hinweis wieder online geschaltet.
Außerdem habe ich in den Exportdateien im Open Air Format nochmals einen Hinweis eingebracht und den Text geändert.

Dazu nochmals ein Hintergrund zum Open Air Datenformat:

Hier mal ein kurzer Teilausschnitt aus den Open Air Daten von Daniel aus XContest
Meiner Meinung nach ein Beispiel mit bestem Aktualisierungs- und Pflegegrad!

AC D
AN BALE TMA 1
SB 0,150,255
AH FL145
AL 1000ft AGL
V X=47:37:58.00 N 007:29:58.00 E
V D=+
DB 47:28:55.00 N 007:23:41.00 E, 47:45:37.00 N 007:20:24.00 E

Dies ist ein Kreisbogenausschnitt aus der TMA BALE

Angegeben ist der Mittelpunkt "V X=..." sowie Start- und Endpunkt und eine Drehrichtung D=+

Diese Beschreibung enthält keinen Radius!

Allein zwischen dem Startpunkt (Radius ca. 18,53km) und dem Endpunkt (Radius ca. 18,55km) klafft eine Differenz von ca. 20m.

Soviel mal zum Hintergrund warum solche Differenzen entstehen wie von Daniel beschrieben
und warum ich vom Open Air Format mit Kreisbögen absolut nichts halte.

Gruß Burkhard

[Onk]

AW: Luftraumdaten im OAB Format

da wurde in Posts von proprietären Formaten gesprochen, das ist Quatsch!
Unter github sind alle genannten Formate beschrieben und Codefragmente für die Konvertierung vom OpenAIP XML Format in das oab Format veröffentlicht.
Deshalb dieser Hinweis.

Danke für den Hinweis.
Mit der Veröffentlichung auf github ist es kein proprietäres Format im eigentlichen Sinne mehr.
Die Skytraxx-Webseite (skytraxx.eu) enthält meines Wissens keinen Hinweis auf eine Offenlegung.
Hier im Beitrag wurde die Veröffentlichung schon mehrfach erwähnt.
Ohne gezielte Nachforschung kann ansonsten aber schnell der Eindruck eines nicht offenen Formats entstehen.

Für den normalen Vario-Nutzer bleibt das aber rein akademisch.
Der normale Nutzer kann mit den vorliegenden Veröffentlichungen nichts anfangen.
Er sieht sich einem geschlossenen System gegenüber. Aber darüber besteht ja soweit Einigkeit.
Das Wort proprietär wurde hier von mir in einem früheren Beitrag etwas lax und damit formal nicht korrekt verwendet.

[TOASTER]

AW: Luftraumdaten im OAB Format

da wurde in Posts von proprietären Formaten gesprochen, das ist Quatsch!
Unter github sind alle genannten Formate beschrieben und Codefragmente für die Konvertierung vom OpenAIP XML Format in das oab Format veröffentlicht.
Deshalb dieser Hinweis.

Zu den fehlenden Konvertern für Anwender hast du natürlich recht.
Sollen / Werden aber hoffentlich bald kommen.

Merci, hat ja zur Klärung beigetragen

Das hat eher was mit Software zu tun, du siehst das "nur" aus dem Blickwinkel des Luftraumerstellers.

Nein, ich sehe das aus der Sicht wie die Lufträume definiert sind. Wenn ein Luftraum als Kreis mit Radius definiert ist, dann ist das eben so.
Ich habe nur darauf hingewiesen, weil es heikel ist wenn einfach irgendwer diese Daten verändert. Ich muss das leider auch immer wieder mal...

Kreise und Kreisbögen sind bei Programmen so ungefähr das Schlimmste was dir passieren kann!
Es gibt keine vernünftigen mathematischen Algorithmen um SCHNELL sphärische geometrische Funktionen zu rechnen.

Der Abstand zu einem Kreis ist doch einfacher zu berechnen, als bei einem Vieleck, wo man erst die nächste Kante suchen muss.
Werden Bojen für's Wettkampffliegen in Polygone umgerechnet? Ich denke mal nicht.
Die Definition der Kreisbögen im OpenAir musste ich übrigens so machen, weil das Skytraxx 3.0 einen Bug hat. Man kann Kreisbögen auch mit Zentrum, Radius und Winkel definieren.
Skytraxx 3.0 ignoriert das dann einfach und deshalb habe ich alle Lufträume umgezeichnet. Ist bisher wohl niemandem aufgefallen...

Das braucht man aber, wenn z.B. ein Vario mit begrenzter CPU Leistung diese Berechnungen für Luftraumwarnungen "on the fly" durchführen muss.
Daher werden eigentlich immer Kreisbögen (Kreise bzw. Zylinder sind noch machbar) in Polygone zerlegt.

Wie gesagt, ich behaupte den Abstand zum Kreis ist rechnerisch einfacher. Für die Anzeige auf dem Display sieht das vielleicht anders aus.

Also warum nicht sofort Kreisbögen auflösen und direkt als Polygone erfassen?
Dann weiß auch der Anwender was die Grundlage ist.

Polygon mit dem genauen Luftraum als Inkreis, oder Umkreis? oder etwas dazwischen? Wieviele Punkte? Wer soll das definieren?
Der Gerätehersteller kann intern rechnen was er will und sich beim Start auch zu jedem Luftraum noch 10 Hilfspolygone berechnen. Die Datenquelle sollte sich nicht darum kümmern müssen.

Verstehe ich jetzt nicht?
Ich habe beschrieben, dass diese Dateien aus dem zuvor erstellten oab Dateien für das SKYTRAXX 2.1 entstanden sind, also nicht mehr deinem Original entsprechen.
Das hast du jetzt wohl nicht verstanden und vermutlich werden das dann andere Anwender auch nicht richtig verstanden haben ...
...
Dein Copyright ist leider im oab Format nicht mehr vorhanden, also auch nicht mehr im Export.
Deine Vorlage fand ich gut und habe sie dann - mehr oder weniger - einfach übernommen.
Was soll ich löschen oder was stört dich genau?

Hab ich schon verstanden. Wenn du eine Datei zum Download anbietest solltest du die Quellen auch direkt in dem File angeben. Wenn du jetzt einfach meinen Header und Daten nimmst, leicht modifizierts und deinen Namen drüber setzt erfüllt das die CC-Lizenz noch nicht. Andere Seiten verlinken unter Umständen nur die Datei, diese wird rumkopiert.... Ich verweise bei mir auch auf Flyland, wo ich die Daten teilweise her hab.

Ich habe das jetzt auf meiner Seite geändert, damit ist noch deutlicher wird.
Es handelt sich um einem Export damit man die oab Dateien prüfen kann!
Nicht, um diese als Open Air Dateien für andere Varios zu verwenden!
Ich hätte auch GPX oder sonst was daraus machen können, es muss nur virtualisierbar sein.

Reicht nicht, wie man jetzt ja merkt werden bei der Konvertierung nach OpenAir Koordinaten gerundet, die Höhen verändert und es können noch weitere Sachen passieren.
Man kontrolliert also nicht die Daten, die aufs Gerät kommen sondern im Moment vor allem dein Konvertierprogramm - von dem her sinnlos diese Daten zu veröffentlichen.
Es besteht jetzt sogar die Gefahr, dass Leute diese Daten zum Fliegen verwenden, anstatt direkt bei der Quelle zu holen.
Bei einem Skytraxx 3.0 beispielsweise sollten deine Daten nicht verwendet werden, sondern es können direkt die offziellen Daten draufkopiert werden.

Dies sollte übrigens auch auf dem Skytraxx-Server (für's 3.0) endlich mal einer machen, das ist eine Sache von 5min!

Mfg Daniel

[BitBroker]

AW: Luftraumdaten im OAB Format

Der Abstand zu einem Kreis ist doch einfacher zu berechnen, als bei einem Vieleck, wo man erst die nächste Kante suchen muss.
Werden Bojen für's Wettkampffliegen in Polygone umgerechnet? Ich denke mal nicht.
...
Wie gesagt, ich behaupte den Abstand zum Kreis ist rechnerisch einfacher.

Da hast du natürlich recht.
Aber bitte nicht Kreise und Kreisbögen in einen Topf werfen.
Für Kreise stimme ich dir vollkommen zu, bei Kreisbögen ist es nicht so trivial.
Aber auch bei einem Kreis, in Wirklichkeit ein Zylinder, sind Eintrittspunkt und Austrittspunkt einer durchstoßenden Linie nicht SCHNELL zu berechnen.
In Wettbewerben eine Kreisfläche zu erreichen ist da schon viel trivialer, wobei sich da auch Variohersteller lange Jahre schwer getran haben.
(Siehe Optimierung einer Wettkampfroute anhand kürzester Entfernung zwischen gegebenen Zielkreisen)

Polygon mit dem genauen Luftraum als Inkreis, oder Umkreis? oder etwas dazwischen? Wieviele Punkte? Wer soll das definieren?

Der Ersteller der Luftraumdaten, so jedenfalls meine Interpretation.
Bei Lufträumen aus Kreisen sind diese doch sogar häufig als Mittelpunkt und Radius definiert (nach AIPs z.B.)
Das ist bei Kreisböden doch meistens nicht der Fall, sondern eine sein stilistische Darstellung, oder?
Und zu Sicherheit des Piloten (frühzeitige Luftraumwarnung) sollte natürlich eine umgebene Fläche per Polygon definiert sein.

Reicht nicht, wie man jetzt ja merkt werden bei der Konvertierung nach OpenAir Koordinaten gerundet, die Höhen verändert und es können noch weitere Sachen passieren.
Man kontrolliert also nicht die Daten, die aufs Gerät kommen sondern im Moment vor allem dein Konvertierprogramm - von dem her sinnlos diese Daten zu veröffentlichen.

Ich habe kein SK2.1, deshalb brauche zumindest ich so eine Prüfhilfe und ich habe diese zur Unterstützung daher auch für andere zum Download bereitgestellt.
Hat ja zumindest - was einen Hinweis betraf - auch zur Validierung der Daten beigetragen.

Vll. schaust du dir die Hinweise auf meiner Seite nochmals an und auch den Text, den ich jetzt im Header der Dateien geschrieben habe.
Wenn du dazu Änderungswünsche oder Hinweise hast nehme ich diese gerne auf. Bitte dann den Text als PN oder Mail. Danke.

Gruß Burkhard

[shoulders]

AW: Skytraxx 2.1

Was Kreise und Kreisbögen als Luftraumgrenzen angeht: bleibt bitte mal auf dem Teppich

Wie ist das denn bisher? Da malt einer einen Kreis(-bogen) auf die ICAO-Karte, und das schaut sich dann ein Pilot mit Kniebrett im Flug gegen Landmarken an. Was auch immer man mit einer Umrechnung des Kreisbogens in Stützpunkte (wobei übrigens ein Inkreis herauskommt) erreichen kann - PFB zum Beispiel erzeugt einfach so viele Stützpunkte, dass deren Abstand zueinander einen Maximalwert nicht überschreitet - ist daher hinreichend genau. Immerhin haben wir ja auch Lufträume in der Form von Landesgrenzen (die CTAs von Österreich zum Beispiel), die auch nur Näherungen darstellen.

Abgesehen davon (ich hab' keine Lust, das ebenfalls in zwei Threads zu posten, Daniel) - was für einen "Fehler" soll denn das SK3.0 mit Kreisbögen im OpenAir-Format haben? Braucht doch jeder nur mal die CTRs um Nürnberg oder München anzusehen, um zu erkennen, dass das einwandfrei funktioniert.

Selbst dem Problem von Doppelungen im Grenzbereich von Luftraumdateien kann man mit einer vernünftigen Logik beikommen. Da errechnet man nämlich einfach die Deckungsgenauigkeit der Flächen zweier solcher Kandidaten und nimmt dann die strengere Definition, so ist man auf der sicheren Seite. Klar wäre eine weltweit koordinierte Datenpflege besser, aber das gilt auch für den Weltfrieden - ein netter Traum, aber illusorisch, solange nicht alle mitspielen. Es sind also doch die vielgeschmähten Programmierer gefragt, um das Beste aus der bestehenden Datenlage zu machen - und die können sowas auch!


CU
Shoulders

[TOASTER]

AW: Luftraumdaten im OAB Format

Da hast du natürlich recht.
Vll. schaust du dir die Hinweise auf meiner Seite nochmals an und auch den Text, den ich jetzt im Header der Dateien geschrieben habe.
Wenn du dazu Änderungswünsche oder Hinweise hast nehme ich diese gerne auf. Bitte dann den Text als PN oder Mail. Danke.

Gruß Burkhard

Ich finde die Infos auf deiner Seite gut, du solltest noch in den Files die du zum Download anbietest auf die Quellen verweisen. Mache ich auch überall, wo ich andere Daten verwende.

Was Kreise und Kreisbögen als Luftraumgrenzen angeht: bleibt bitte mal auf dem Teppich

Wie ist das denn bisher? Da malt einer einen Kreis(-bogen) auf die ICAO-Karte, und das schaut sich dann ein Pilot mit Kniebrett im Flug gegen Landmarken an. Was auch immer man mit einer Umrechnung des Kreisbogens in Stützpunkte (wobei übrigens ein Inkreis herauskommt) erreichen kann - PFB zum Beispiel erzeugt einfach so viele Stützpunkte, dass deren Abstand zueinander einen Maximalwert nicht überschreitet - ist daher hinreichend genau. Immerhin haben wir ja auch Lufträume in der Form von Landesgrenzen (die CTAs von Österreich zum Beispiel), die auch nur Näherungen darstellen.

Die grossen Flugzeuge navigieren also immer noch mit Landmarken ;-) Solche Beispiele kommentiere ich nicht weiter. Von dir hätte ich erwartet dass du den Nutzen von genauen und eindeutigen Luftraumgrenzen etwas höher gewichtest.
Viele Piloten haben mehr als ein Gerät auf dem Cockpit. Was ist, wenn nur ein Gerät warnt? was ist wenn die Grenzen um 100m verschieden sind?

Man kann auch recht einfach auch den Umkreis oder den Mittelwert machen.
Da du mit PFB die Grenzen veränderst mal eine Frage:
- Wieso machst du den Luftraum kleiner als er ist und nicht grösser? Widerspricht deiner Aussage weiter unten, wo du ja auf Nummer sicher gehen willst und im Zweifel den größtmöglichen Luftraum zeichnen willst.
- Wie entscheidest du, was "hinreichend genau ist? Welche Toleranz legst du fest? Regelst du das über den Abstand der Punkte oder Abstand zur "richtigen" Grenze?
- Wie informierst du einen Piloten, dass du die Daten veränderst?

Das sind rethorische Fragen und müssen nicht beantwortet werden. Es geht wirklich ins Detail. Ich stelle diese Fragen nur, weil ich genau dasselbe Problem habe und eigentlich der falsche bin um solche Veränderungen vorzunehmen.
Trotzdem mache ich das viel zu oft....

Wenn man aber von einer sauberen Definition der Lufträume ausgeht, sollte in einer Master-Datenbank ein Kreis eben ein Kreis sein, eine Gerade nur mit zwei Punkten definiert werden und nicht mit mehreren Stützpunkten. Was die Hersteller dann daraus machen ist ein anderes Thema. Notam-Lufträume sind meistens Kreise. Das kann man ignorieren ist aber nicht wirklich professionell - ich finde die Argumentation das sei technisch zu aufwändig lustig, weil das auf einem Oudie mit 10 jähriger Hardware problemlos funktioniert. Die Karten sind ja auch Vektorgrafiken - wieso soll das bei Lufträumen unlösbar schwierig sein?

Abgesehen davon (ich hab' keine Lust, das ebenfalls in zwei Threads zu posten, Daniel) - was für einen "Fehler" soll denn das SK3.0 mit Kreisbögen im OpenAir-Format haben? Braucht doch jeder nur mal die CTRs um Nürnberg oder München anzusehen, um zu erkennen, dass das einwandfrei funktioniert.

Ja es verzettelt sich etwas....schwierig den Überblick zu behalten.
Soweit ich das ausprobiert habe, kann das Skytraxx 3.0 diesen Luftraum nicht darstellen. Kreisbögen können eben auch mit Radius und Winkel definiert werden. Keine Rückmeldung von Skytraxx zu diesem Thema.

AC R
AN test
AL 0
AH FL 180
V X=39:13:00 N 118:13:00 W
DA 5,0,175

Das ist ein Kreisbogen mit 5 Meilen Radius, start bei 0° positive Drehrichtung bis 175°.
Wie gesagt, deshalb habe ich die Lufträume dann anders definiert. War aber jahrelang anders und wurde dementsprechend auf dem Skytraxx 3.0 (und weiteren Geräten) nicht richtig dargestellt. Solche Bögen werden einfach ignoriert und die Form des Luftraums massiv verändert oder gar nicht dargestellt.

Selbst dem Problem von Doppelungen im Grenzbereich von Luftraumdateien kann man mit einer vernünftigen Logik beikommen. Da errechnet man nämlich einfach die Deckungsgenauigkeit der Flächen zweier solcher Kandidaten und nimmt dann die strengere Definition, so ist man auf der sicheren Seite. Klar wäre eine weltweit koordinierte Datenpflege besser, aber das gilt auch für den Weltfrieden - ein netter Traum, aber illusorisch, solange nicht alle mitspielen. Es sind also doch die vielgeschmähten Programmierer gefragt, um das Beste aus der bestehenden Datenlage zu machen - und die können sowas auch!

Ich behaupte: das ist nicht so einfach. Du kannst mich gerne vom Gegenteil überzeugen - der Beweis kann nur mit einem funktionierenden Tool erbracht werden.
Da du dich da auskennst kannst du gerne mal die Stunden schätzen und vielleicht noch, wie gut der Programmierer sein muss, der das macht.
Etwas ironisch finde ich in dem Zusammenhang, dass ein Parsen von OpenAir unmöglich scheint (trotzdem können das einige Hersteller recht gut) - gleichzeitig soll aber Lufträume mit unterschiedlichen Anzahl Punkten vergleichen trivial sein. Das muss mir wohl erst mal einer erklären.
Mit der Geometrie hört es ja nicht auf - bei der aktuellen Frequenzumstellung muss man alle Funkfrequenzen ändern. Wie soll so etwas vollautomatisch gehen? Wo bekommst du diese Daten und in welchem Format? Und würdest du sowas in deinem Programm schon vorsehen?

Meine Schätzung um die Datenqualität / Aktualisierungsgrad auf ein gutes Mass zu erhöhen:
- in Deutschland und Österreich 10 Leute, die sowieso schon ihre Pilotenpflicht wahrnehmen.
- Wenn der DAEC oder AustroControl die Daten ändert ->Mail an mich / DHV / XContest / OpenAIP. Das wars schon!
- Das könnten auch Auswerter oder Fluglehrer sein, das wäre also ihr Job sich damit auseinanderzusetzten.
im Prinzip ist aber jeder seriöse Pilot für diese Aufgabe geeignet!

Das ist ein Zusatzaufwand von 10min pro Änderung und Pilot! Sind wir ehrlich die Zeit hätte jeder der hier im Forum schreibt.
Wenn ich dann 10 Mails mit der gleichen Änderung bekomme - was soll's??
Ist doch motivierend wenn andere mitdenken und mich ab und zu kontrollieren

Mfg Daniel

[Riarruf]

AW: Skytraxx 2.1

Ich habe ein Mail von Skytraxx bekommen in dem klar steht dass das Update für diese Woche geplant ist und danach eigene Lufträume geladen werden können.

[danilani]

AW: Skytraxx 2.1

Neues Update ist draußen:

Version 05/2019

• 3 neue Bildschirm Seiten: Barogram, Lufträume, Queransicht.
• Akkuanzeige beim Ausschalten hinzugefügt.
• Bei der XXL Seite kann man nun auch Windrichtung und Windstärke anzeigen.
• MSL kann über Wegpunkt gesetzt werden.
• Bei den Auswahlfeldern kam QNE und QFE ausgewählt werden.
• WLAN Verbindungsaufbau verbessert.
• Fehler bei Hinderniswarnung korrigiert.
• Gleitzahl Anzeige verbessert.
• FANET, Richtung korrigiert.
• OpenAir Format für Lufträume hinzugefügt. (max. 3000 Polygonpunkte)