Information
zu den überarbeiteten Landclassfiles
von Frank Barth
Bei vielen Anwendern
sind die Freeware Landclassfiles von
Frank Barth für Deutschland sehr beliebt.
Aus gutem Grund. Sie lassen doch manches
Paywareprodukt hinsichtlich Positionierungsgenauigkeit
bzw. verwendeten Landklassen hinter
sich. Bei Verwendung ungünstiger Landclassnummern
kommt es bei manchem Paywareprodukt
zu dem Effekt, dass die Erdoberfläche
teilweise eher an vertrocknete Steppen
und Wüstenstädte erinnert.
Die Erdoberfläche
sieht dann leider nicht unbedingt
nach Deutschland aus.
Was die Positionierungsgenauigkeit
betrifft muss man folgendes sagen.
Benutzt man z.B das
sehr gute Paywareaddon "All Roads
of Europe" ( welches hochgenaue
Straßen und Küstenverläufe, Seen installiert)
muss man sich eingestehen, dass auch
Frank seine Landclassfiles nicht die
Positionierungsgenauigkeit mit sich
bringen, die theoretisch mit dem Landclassystem
erreichbar wäre. Des öfteren fehlen
auch komplette Ortschaften. Ich habe
nur Stichproben geprüft. Für mich
(Jobia) kamen diese Landclassfiles
aber aus anderen Gründen nie in Frage.
Zunächst mal eine
Übersicht welche Fläche die sieben
von mir überarbeiteten Einzellandclassfiles
abdecken. Diese Flächen entsprechen
logischerweise exakt den sieben ursprünglichen
Einzelpaketen von Frank. Ein grober
Vergleich welches Landclassfile beim
Überflug im FS aktiv ist, kann mit
der Vogelperspektive des FS vorgenommen
werden.
Flecke die wir innerhalb
der weissen Flächen sehen, sind Transparenz
LC. Dieses sind z.B größere Gewässer.
Logisch das man dort keine Landclass
definieren muss.
Fast alle Anwender
loben Frank seinen Landclassarbeit
als das Beste, was es momentan für
Deutschland gibt. Leider besitzen
Frank seine Landclassfiles ein Manko,
welches viele Anwender sehr stört.
Dieses Manko war auch für mich der
Grund diese Files nicht zu nutzen.
Der Grund sind die
extrem langen Ladezeiten der Scenery,
bevor man mit einem Flug beginnen
kann. Auch die eigentliche Performance
während des Fluges bricht hin und
wieder zyklisch stärker als bei anderen
Landclassfiles ein.
Worauf diese Problematik
zurückzuführen ist, hatte ich früher
schon öfters im FXP Forum erwähnt.
Dazu sollte man folgenden
Sachverhalt wissen.
Ein Landclass Sceneryfile
*.bgl wird mittels Microsoft SDK Tools
(resample.exe usw.) produziert. Es
muss immer eine Fläche ca. 300km x
300km programmiert werden. Da führt
auch kein Weg dran vorbei. Möchte
man optisch weniger programmieren,
dann kann man eine spezielle LC Nummer
als quasi transparente Füllung einsetzen
um die Grundbedingung 300 x 300km
zu erfüllen.
Die Programmierung
mittels SDK resample.exe setzt gewisse
Grundkenntnisse der Scenerytechnik,
geografischer Systeme, Projektionsverfahren
und Weltmodelle voraus. Es müssen
Rohdaten anhand der Topografie vorbereitet
/ entzerrt werden. Diese müssen ein
spezielles Format vorweisen. Weiterhin
müssen Informationsdateien erstellt
werden die dem Resample Prozess Definitionen
liefern, damit das Tool überhaupt
weis, wie es die Informationen zu
verarbeiten hat.
Werden hierbei Fehler
gemacht, dann erhält man entweder
Datenmüll oder schlimmsten Falls überhaupt
keine Ergebnisse. Man bleibt dann
in der Regel unwissend wo die Fehler
gemacht wurden.
Diese SDK Tools sind
in der Regel schlecht dokumentiert.
Aus diesem Grunde
haben findige Leute Designtools programmiert
die einem die Vorarbeiten abnehmen.
Man wird als Landclassproduzent mit
den eigentlichen Resample Prozess
und den zu erstellenden Rohdaten bzw.
den Informationsdateien überhaupt
nicht belässtigt. Das läuft im Designtool
alles im Hintergrund automatisch ab.
Zur Landclassproduktion
kann man verschiedene Designtools
nutzen, z.B Ground2K oder das Schiratti
Control Center ( SCC ) um ein paar
wenige zu nennen.
Allerdings ist nicht
jedes Tool ideal für eine großflächige
Landclassproduktion.
Frank hat das Schiratti
Control Center genutzt. Er schreibt:
Ich habe dieses
Landclass mit Hilfe des neuen Schiratti
Control Centers erstellt und muss
Sagen, es ist eine ganzschöne klickerei.
Man brauch schon viel Geduld; Zeit
und eine robuste Maus. Um eine möglichst
große Genauigkeit zu erreichen habe
ich mir eine Karte als Hintergrund
in den SCC unterlegt. Was auch nicht
ganz einfach mit den richtigen Zoomeinstellungen
war. Nach vielen rumprobieren hat
es dann doch geklappt.
Ich kenne den Entwickler
des SCC ganz gut. (leider wird das
SCC nicht mehr weiter entwickelt)
Das SCC ist ein Designtool
welches zu FS2002 Zeiten vorrangig
dem Design von Airportscenerien diente.
Mit ihm wurden Bodenpolygone wie Runways,
Taxiways, Rasenflächen, Straßen und
weiterhin Objekte also Gebäude, Bäume
usw. auf der Erdoberfläche aufgebracht.
Dieses ist nur ein kleiner Auszug
der Möglichkeiten des SCC.
Im SCC wurde auch
ein Landclassdesignmodus integriert.
Dieser sollte dem Designer dazu dienen,
dass Airportumfeld hochgenau mit passenden
Landclassdefinitionen zu versorgen.
Da man seine bisherigen programmierten
Elemente wie Runways, Straßen usw.
auf dem Bildschirm sehen kann, weiterhin
eine Karten oder Luftbildhinterlegung
möglich ist, können hier sehr genau
die Landclassdefinitionen verteilt
werden. Da das SCC eher dem Airportdesign
dient, ist der integrierte Landclassdesignmodus
allerdings nur für kleine Flächen
ausgelegt. Mit anderen Worten, SCC
unterstützt die Produktion eines großflächigen
Landclassfiles 300 x 300km welches
den Informationsinhalt von 257 x 257
LC Definitionen trägt leider nicht.
Das SCC lässt nur
die maximale Definition von 10 x 10
LC Nummern zu. Das sind ca. 12 x 12km.
Für eine Airportscenery mit Umfeld
reicht das in der Regel aus.
Ein sinnvolles großflächiges
Landclassfile für z.B Deutschland
kann man mit dem SCC also nicht programmieren.
Die Programmierung
im SCC hat allerdings einen Vorteil.
Man muss ein in Designtools
hinterlegtes Referenzluftbild bzw.
Referenzkarte vorher auf das Raster
des Designtool entzerren. Leider wird
dieser Sachverhalt, der auch für die
meisten anderen Designtools gilt in
der Regel oft nicht beachtet. Daraus
resultieren später grobe Positionierungsfehler.
Da man im SCC nur
kleine Bereiche programmieren kann,
wirkt sich hier eine vernachlässigte
Entzerrung weniger aus. Die Positionierungsfehler
sind geringer.
Um beim SCC trotz
der Beschränkung auf kleine Bereiche
die Grundbedingung 300 x 300km für
den resample Prozess zu erbringen,
wird der Rest vom SCC (ohne das es
der Designer bemerkt) mit der transparenten
LC Definition aufgefüllt.
Landclassfiles sind
in einem undokumentierten Kompressionsallgorithmus
komprimiert. Diese konstante Transparenzfüllung
bläht unser Einzellandclassfile hinsichtlich
Speicherlast daher zunächst nicht
auf. Von der Theorie her haben wir
also noch keinen wesentlichen Nachteil
durch diese Art der Programmierung.
Da das SCC aber nur
kleinflächige nutzbare LC Bereiche
definieren kann, besteht so ein einzelnes
Bundesland bei Frank später zum Teil
aus weit über 400 Einzel LC Files.
Das Bayern Landclass kommt so auf
434 einzelne LC Files. Damit der FS
aber weis, um was für einen Sceneryfiletyp
es sich bei den LC Files handelt,
wann es in den Speicher zu laden ist,
welche Fläche es abdeckt, wie die
Informationen zu verarbeiten sind,
muss man diesem File einen Datenkopf
auch Header genannt beifügen. (geschieht
automatisch beim Resample Prozess)
So ein Header benötigt
eine gewisse Anzahl von Datenbytes.
Dieser Header ist bei Landclassfiles
immer gleich groß. Das Dumme an Frank
seinen Landclassfiles ist, dass man
z.B die Landclass Information seiner
434 Einzelfiles die Bayern bei ihm
abdecken auch in einem einzigen Landclassfile
unterbringen kann.
Das bedeutet ich benötige
für ganz Bayern nur einen einzigen
Header und dessen Bytes. Da Frank
434 Einzel BGL Files für Bayern nutzt,
benötigt man bei diesem Verfahren
auch 434 Header.
Das Verhältnis Bytelast
der Header zu Bytelast der Nutzdaten
ist bei seinen original Landclassfiles
extrem schlecht. Im Prinzip schleppt
man unnötigen Datenmüll in den FS
ein.
Die Files benötigen
daher viel Speicherplatz, was bei
den heutigen Festplatten tolerierbar
wäre. Schlimmer wiegt der Verwaltungsaufwand
für den FS. Er muss von 434 Einzelfiles
die Header auslesen und die Priorität
der einzelnen Files festlegen. Aus
den Files die im Umfeld des Flugzeuges
aktiv genutzt werden, müssen die Dateninformationen
ausgelesen werden.
Dieses Verhalten spiegelt
sich in den extrem langen Ladezeiten
Frank seiner Landclasscenerien wieder.
Der FS muss während
des Fluges auch ständig überwachen,
ob Daten von Einzellandclassfiles
die noch nicht im Speicher vorliegen
nachgeladen werden müssen. Dieses
Nachladen geschieht nicht kontinuirlich
während des Fluges, sondern bei Überschreitung
bestimmter Grenzen.
Das bedeutet die Grundperformance
zwischen Frank seinen original Files
und meiner optimierten Variante ist
während des Fluges zunächst ähnlich.
Die erreichbaren Frames (Bilder pro
Sekunde) liegen nicht weit auseinander.
Werden allerdings
diese Überwachungsgrenzen überschritten,
dann muss der FS je nach Position
innerhalb einer Landclasscenery mehr
oder weniger viele LC Daten nachladen.
Bei meiner optimierten
Variante lädt der FS im schlimmsten
Fall Daten aus einem einzigen aktiven
LC File nach. Bei Frank seiner Variante
muss der FS zusätzlich je nach Position
nicht nur Daten aus einem aktiven
File nachladen, sondern viel schlimmer
es müssen sehr viele LC Files überwacht
und wenn erforderlich komplett neu
eingelesen werden um Daten für die
Erdoberfläche zu haben.
Bei Frank seinen LC
Files brechen daher die Frames je
nach Flugrichtung und Geschwindigkeit
zyklisch wesentlich stärker als bei
meiner neuen Variante ein. Der Flug
kann unrhytmischer werden.
Weiter unten folgen
ein paar Zahlen zu dieser Thematik.
Was habe ich
bezüglich Optimierung durchgeführt?
Nun irgendwie hat
es sich im Zuge von anderen Diskussionen
mit dem VFR Airfields Designteam ergeben,
dass sie gerne Frank seine Landclassfiles
in einem Freeware Projekt verwenden
würden.
Da ich mich sehr gut
mit Landclass auskenne, kam die Frage
auf ob ich irgendeine Möglichkeit
sehe diese Probleme bei Frank seinen
LC Scenerien zu beseitigen.
Ich habe kein Problem
gesehen, insofern noch die Rohdaten
die das SCC erstellt hat vorhanden
sind. Diese lagen aber leider nicht
mehr vor. Nur die fertigen LC BGLs
so wie man sie downloaden kann, waren
verfügbar.
Dieses macht die Sache
aufwendiger aber nicht unmöglich.
Im Zuge anderer Arbeiten
hatte ich vor längerer Zeit den undokumentierten
Kompressionscode von Landclassdaten
usw. dekodiert. Mittels eigener Routinen
bin ich in der Lage z.B Landclass
/ Waterclass / Mesh Daten usw. dekodieren,
editieren, koordinatengerecht weiterverarbeiten
bzw. miteinander verschmelzen zu können.
Mittels dieser Technik
kann man auch Daten aus verschiedenen
Addons miteinander kombinieren. Man
kann sich z.B ideale Masterlandclass
oder Meshfiles erstellen. Das schont
die Performance und verhindert Prioritätsprobleme.
Aus lizenzrechtlichen
Gründen natürlich nur für sich privat.
Da das VFR Airfields
Team (und mittlerweile auch ich) das
"OK" von Frank für eine
Optimierung seiner Files hatte, konnte
ich diese optimieren.
Mittels meiner Routinen
werden aus 7 original Scenerien /
Regionen bestehend aus 2646 kleinen
Einzel LC BGL Files (aus dem SCC)
später 7 LC Files. Für jede Region
ein einzelnes LC File. Aus den 2646
ursprünglichen BGL Files werden Header
und Nutzdaten dekodiert und ausgewertet.
Ein weiterer Prozess setzt die vielen
Nutzdaten anhand der Abdeckungsinformationen
koordinatengerecht zu einem großen
Datensatz zusammen. Es wird für jede
der 7 Regionen ein Datensatz erzeugt.
Diese Datensätze werden zu 7 neuen
Landclass BGL kompiliert. Anstatt
Datenbytes für 2646 Header zu verschwenden,
reichen uns nun 7 Header aus um den
selben Dateninhalt zu definieren.
Auch dem Kompressionsverhältnis der
eigentlichen Nutzdaten kommt diese
Überarbeitung zu Gute.
Der wesentliche Vorteil
liegt aber darin, dass der FS bei
identischen Sceneryinformationen im
Gegensatz zu vorher nur noch extrem
wenig Daten auszuwerten bzw. zu verwalten
hat.
Wie sieht das z.B
anhand Bayern aus?
Das Bayern Landclass
von Frank besteht ursprünglich aus
434 einzelnen Landclassfiles, die
passgerecht miteinander in einem neuen
File unterzubringen sind.
Logisch, dass man
so etwas bei der Gesamtsumme von 2646
Einzelfiles nicht in Handarbeit erstellen
kann (das würde der Arbeit entsprechen
die sich Frank damals gemacht hat).
Ich habe unheimlichen Respekt, dass
sich Frank diese Klickerei für 2646
Einzefiles im SCC angetan hat.
Mal ein paar Zahlen
zum Ergebnis. Aus 434 LC Files von
Bayern wird nun ein einziges LC File.
Ich hätte auch alle sieben LC Projekte
von Frank in eines integrieren können.
Bei 7 Files hat man aber noch die
Möglichkeit, dass ein oder andere
LC File nicht zu nutzen bzw. die Priorität
der Files untereinander anders zu
steuern. Das ergibt für den ein oder
anderen ev. einen Sinn wie wir später
noch sehen werden. Einen Performancegewinn
hätte man mit der Kombinierung in
einem File nicht mehr erreichen können.
Vorher waren die 434
Bayern LC Einzelfiles zusammen 559KB
groß. Nach meiner Überarbeitung ist
dieses eine Bayern_LC File nur noch
22,7KB groß. Bei gleichen Dateninhalt
der Scenery ist die Information um
den Faktor ca. 25 fach geschrumpft.
Das selbe gilt natürlich
auch für den RAM wenn die Daten genutzt
werden.
Die Zahlen oben sind
die nackten Dateigrößen. Wer die Datenstruktur
von Festplatten und deren Dateiverwaltungsgrößen
kennt, weis das es kleinste logische
Einheiten (Cluster) gibt, die adressierbar
sind.
Optimale Ergebnisse
erhält man bei großen Festplatten
unter Windows XP eigentlich nur unter
dem System NTFS.
Das Bayernlandclass
belegt mit seinen 434 Einzelfiles
effektiv 1,69MB auf Festplatte. Meine
Einzeldatei mit identischen Dateninhalt
belegt nur 24KB.
Wir sehen bei meiner
Variante ist der Speicherplatzbedarf
auf Festplatte gar um den Faktor ca.
72 fach geschrumpft.
Beim FAT32 System
wäre der Faktor in der Regel noch
sehr viel extremer.
Für alle sieben LC
Packete sieht das wie folgt aus:
Sie haben im Urzustand
eine reine Datengröße von 3,53MB und
belegen unter XP bei mir 10,5MB auf
Festplatte.
Meine optimierte Variante
der sieben Files hat eine reine Datengröße
von 126KB und belegt unter XP bei
mir 144KB auf Festplatte.
Das bedeutet die reine
Datengröße ist ca. um den Faktor 28,7
geschrumpft.
Der Speicherplatzbedarf
unter XP ist ca. um den Faktor 74,7
geschrumpft.
Meiner Meinung nach
ganz erhebliche Unterschiede.
Was hat das für Auswirkungen
für unseren FS2004. Meine Testergebnisse
anhand des Betriebes nur mit dem Bayernlandclass.
Das laden eines Fluges
innerhalb der BayernScenery ist bei
mir (P4 2,53Ghz Notebook) von 1 min
10 sec (im original Zustand) auf ca.
30 sec. geschrumpft. (übrigends sind
alle 2646 original LC Files im FS
angemeldet, kann das Laden je nach
Position auch schon mal mehrere Minuten
dauern, auch hier liegt man bei meinen
sieben Files in der Regel unter 60
Sec.)
Die Grundperformance
ist ähnlich hinsichtlich Frames. So
ca. 23 Frames bei mir. Nur bei Frank
seinen original Files gibt es während
des Fluges immer wieder starke Einbrüche
auf 8 Frames wenn der FS Einzellandclassfiles
bzw. dessen Informationen nachlädt.
Bei meiner Kombivarinate gibt es auch
Einbrüche, aber nur noch auf ca. 14
Frames. Die Einbrüche sind auch seltener.
Auf meinem Destop PC 3,4GHz habe ich
das nicht geprüft.
Das ganze hängt natürlich
von der Hardware jedes einzelnen ab.
Weiterhin von diversen Einstellungen
des FS2004 bzw. der FS9.CFG.
Auch ob der FS das
erste mal während der PC Sitzung gestartet
wurde, bzw. ob er schon mal gestartet
war.
In jedem Fall dürfte
eine wesentliche Verbesserung der
Problematik eintreten.
Ein paar sehr wichtige
Punkte muss ich noch erwähnen!
Ich habe keinerlei
Prüfungen durchgeführt ob die Landclassinformation
korrekt positioniert bzw. vernünftig
von Frank gewählt wurden. Dementsprechend
erhält man durch mich nur einen optimierten
Code der LC Daten. Der Informationsinhalt
selbst bleibt unverändert. Ich erwähne
das deshalb, weil ich ein paar Besonderheiten
entdeckt habe. Es gibt zwischen den
einzelnen original Landclassprojekten
in "seltenen Fällen" kleine
Definitionslücken. Das wirkt sich
dann je nach Landclassaddons die der
Anwender für dieses Gebiet mit niedriger
Priorität betreibt in der Form aus,
dass in diesen Lücken andere LC Addon
Daten niederer Priorität zur Anwendung
kommen.
Ich demonstriere das
mal anhand eines Screenshots. Bei
diesem Screenshot ist nur das Barth
LC Projekt aktiv, weiterhin das Default
Worldlc.bgl des FS2004. Das Default
Worldlc.bgl hat die niedrigere Priorität
liegt quasi optisch unten. In den
Definitionslücken des Barth Projektes
sehen wir also LC Informationen des
Worldlc.bgl. Wir wissen, dass es dort
überwiegend so eine Art Tundra in
Deutschland gibt. Genau diesen Defaulttundrastreifen
sehen wir in der Definitionslücke.
Noch
einen Punkt gilt es zu erwähnen. Die
beiden Projekte Hannover100 und SchleHolNied
haben etwas weiter im Westen (auf
dem Screenshot nicht sichtbar) einen
etwas größeren Überlappungsbereich.
Das bedeutet wir haben einen Bereich
in dem beide Files LC Nummern definieren.
Allerdings finden wir in den Überlappungsbereichen
verschiedene LC Definitionen vor.
Eigentlich dürfte das ja nicht sein,
wenn man immer identisches Kartenmaterial
hat. Ich habe nicht kontrolliert welches
der Projekte Hannover100 oder SchleHolNied
im Überlappungsbereich das genauere
ist. Meine sieben LC Varianten haben
exakt die Priorität die eintreten
würde, wenn man Frank seine 2646 Files
alle in einen Sceneryordner packen
würde. Aufgrund der alphabetischen
Reihenfolge wird das File SchleHolNied_lc.bgl
später als das Hannover100_lc.bgl
geladen. Im Überlappungsbereich sind
daher die LC Daten des SchleHolNied_lc.bgl
aktiv.
Hat jemand
früher Frank seine sieben Projekte
als Einzelscenerien angemeldet, dann
kann es sein, dass er das Hannover100
Projekt in der Scenerybibliothek höher
als das SchleHolNied angemeldet hat.
Dann würden im Überlappungsbereich
die Daten des Hannover100 aktiv sein.
Es ergibt sich eine andere Optik.
Wenn
man der Meinung ist Hannover100 ist
im Überlappungsbereich realistischer,
kann man ganz einfach vorgehen. Man
benennt mein SchleHolNied_lc.bgl nach
GSchleHolNied_lc.bgl um. Die alphabetische
Reihenfolge ändert sich. Das Hannover100_lc.bgl
wird nun später geladen und geniesst
die höhere Priorität.
Damit
es durch den Umbenennungsprozess keine
Fehlermeldung im FS gibt, bitte die
Scenery.dat dieser optimierten Barth
Scenerien löschen. Der FS baut sie
dann entsprechend des neuen Namens
neu auf.
Ev. wenn ich mal wieder
mehr Zeit für den FS habe, werde ich
ein eigenes Landclass für Deutschland
/ Europa anhand verschiedener kombinierter
Rohdaten erzeugen. Leider scheint
es keine optimalen Rohdaten zu geben
die allen Belangen gerecht werden.
Wenn die Zeit es zulässt, werde ich
mich ev. damit beschäftigen.
Jobia
LandscapeGermanyLandclass.exe
(2,4 MB)
|
