Sorry Martin habe ich übersehen. Ich möchte hier nicht tiefgreifend irgend etwas erklären da das kaum jemand interessieren dürfte. Aber ein untrügliches Merkmal an dem man Landclassfile erkennt bzw. auch von Meshfiles unterscheiden kann ist folgendes.
Bei Landclassfiles findest Du immer ab der dezimalen Adresse 344 die Bytekombination FF FF FF FF
Bei Meshfiles an der selben Adresse FE FE FE FE
Egal mit welchem Tool die Mesh oder Landclassfiles erzeugt wurden. Daran kann sie jederman immer identifizieren.
Grund ist auch das es keine Tools gibt die landclass direkt programmieren. Alle Tools erstellen ein Rohdatenfile und eine Informationdatei. Wie dieses auszusehen hat ist vorgeschrieben. Sprich hier treffen sich alle tools wieder auf einer Ebene. Die eigentliche BGL erzeugt immer die resample.exe des SDKs. Über diese Exe wird waterclass, Landclass, Fotoscenery, Mesh, Seasonfiles (Jahreszeitendefinition) programmiert. Ich hoffe ich habe nichts vergessen.
Logisch gibt es noch mehr Erkennungsmöglichkeiten. Dieses ist aber insofern günstig da man dieses auch mit einem Texteditor wie Wordpad erkennen kann. Dann findet man in Zeile 3 als erste Kombination die Buchstaben bbbb bei Meshfiles vor. Bei Landclassfiles yyyy allerdings mit Pünktchen über den y.
Leider kann es sein das Note- oder Wordpad Landclass oder Meshfiles nicht öffnen können wenn diese zu groß sind.
Auch ist nicht immer garantiert das man diese Zeichen in Zeile 3 findet. Kommt im BGL Code vor Byte 344 eine ASCII Zeichen kombination vor welches als Zeilenende oder Zeilenumbruch von Wordpad interpretiert wird, dann findet man es erst in einer späteren Zeile wieder.
Man findet dieses Zeichenkombination aber immer ab Zeichen 344. Man könnte das daher auch immer auszählen.
Sicherer ist das natürlich mit einem HEX Editor.
Zu Landclassfiles allgemein möchte ich nur das anmerken was Rainer in einem anderen Thread und ich auch früher schon erzählt habe.
Landclass frisst umso mehr Performance umso mehr verschiedene Landklassen in einem File zugewiesen werden.
Das default worldlc.bgl Landclassfile ist da sehr monoton und schont daher die Performance. Etwas anderes möchte ich aber noch anmerken.
Das passt hier gerade gut da wir beim Thema Header sind.
Landclassfiles definieren immer eine Fläche von ca. 300x300km. Anders geht es nicht.
Damit man aber auch kleinere Gebiete definieren kann hat Microsoft die Möglichkeit einer Art Transparenzlandclass mit Nummer 254 geschaffen.
Man kann also im Prinzip nur eine einzige Landclasskachel von ca. 1,2x1,2km mit Wald oder z.B Stadt definieren . Den Rest füllt man mit LC254 als unsichtbare Landclass. Das Umfeld bleibt dann durch dieses Landclassfile optisch unberührt.
Damit ist die Bedingung erfüllt das man 300x300km definiert hat. Da die Files komprimiert werden ist das noch nicht mal groß schädlich. Nur wenn jemand eine Fläche von 300x300km komplett neu definieren will ist es sinnvoll dieses nicht auf ev. mehrere 100 Files mit Transparenzlandclass zu verteilen. Sondern sinnvoller ist es dieses generell in einem File zu machen.
Grund ist der Header, der Kopf der Datei. Er beschreibt Designgrenzen und die BGL selbst.
Er ist zwar nicht mehrere hundert Bytes lang. Aber es ist leider so das es Landclassfiles gibt, da macht im Prinzip ein Drittel der Bytes des Einzelfiles unnütze vermeidbare Daten aus in Form von Header und Zusatzinformationen. Da die Fläche mit mehreren 100 Einzelfiles dargestellt wird es aber auch mit 1 File ginge könnte man sehr viel unnütze Daten vermeiden. Diese belasten das System da zum einen Daten verarbeitet und gelesen werden müssen, weiterhin der FS aus diesen überflüssigen Daten die Priorität der Files vergeben muß.
Ich gebe aber Rainer recht besser als nichts, solange nichts besseres da ist.
|