Freeware 38m Mesh für die Alpen

[JOBIA]

Zu

Original geschrieben von Falko
@Holger

<Falko, ich gebe dir natuerlich Recht, dass eine Kompilierung von kleineren Zellen das Updaten vereinfachen wuerde. Allerdings wuerde das den Modemnutzern nur bei Patches helfen, denn das Gesamtpaket muessen sie ja so oder so laden.>

- Genau das meine ich, es würde das Ausbessern von Fehlern sehr vereinfachen.

<Ausserdem scheint die Groesse der Teilstuecke das Ladeverhalten (d.h. die Prioritaet) zu beeinflussen, zumindest waere das eine logische Erklaerung fuer das Phaenomen, das Joachim und ich weiter oben angesprochen haben.>

-Das ist ja gerade das Problem, man kann große Teile nicht mit kleineren Teilen mit gleichem LOD überschreiben. Sind alle Teile klein kann man sie einfach austauschen.

<Fuer den Meshersteller ist der Umstand aber schon groesser, wenn man Fleckerlteppisch-Mesh erstellt. Entweder schneidet man aus den Rohdaten die Teilstuecke aus oder man nutzt die UseSourceDimensions Einstellungen in der inf Datei. In beiden Faellen muss man aber erst die Rastergrenzen fuer die entsprechenden LODs ermitteln, um Ueberschneidungen oder Loecher zu vermeiden. Das kann man zwar mit EXCEL oder Scripten teilweise automatisieren, aber ob ich das fuer ein grosses Stueck mache oder fuer 50 kleine ist schon ein Unterschied.>

-Also, ich hab das für Deutschland in LOD9 mit den inf-Dateien gemacht. Das sind inzwischen sogar 99 Dateien. Für die Rastergrenzen habe ich die den HGT-Dateien entsprechenden Grenzen gewählt, jeweils die nächste LOD9-Grenze nördlich oder östlich zu den HGT-Grenzen. Falls man sich auf so eine Norm einigen könnte wären die verschiedenen Mesh's kompatibel zueinander. So habe ich z.B. für Deutschland vier verschieden Mesh's von gleicher Qualität die alle nicht zueinander passen.
Falls Du für Dein LOD9-Puffer-Mesh auch die erste LOD9 Grenze nördlich des letzen verwendeten nördlichen Breitengrads gewählt haben solltest, hätte man einen Nahtlosen Übergang von Deinem Alpen-Mesh zu meinem Micro-Tile-Mesh für das restliche Deutschland. Die LOD Grenzen kann man sehr einfach berechnen.

Gruß, Falko

Nun zunächst mal verwendest Du unkorrigierte SRTM Meshdaten. Ich glaube das ergibt eh keinen Sinn diese Daten die ja jedermann ohne Basiswissen per SRTM Tool einfach innerhalb weniger Minuten in eine FS Mesh BGL resampeln kann zu nutzen.

Leider gibt es die sinnvolle Korrektur selbst in einigen Addon Meshfiles nicht.

Warum ergibt es aber keinen Sinn Microfiles zu machen.


Klar wäre das praktisch wenn man mal bei Bugs kleine fehlerhafte Teile wie jetzt geschehen austauschen kann.

Nur nutzt man unkorrigierte SRTM Daten, dann würde ich schon sagen, das man die ganze Alpenregion als einen einzigen Bug bezeichnen könnte, selbst wenn sehr vieles korrekt ist.

Außerdem entstehen hier wieder hunderte an Dateien wie man ja bei Dir schon (jetzt schon 99 Stück) sieht.

Im Fehlerfall oder sinnvolle Priorität ist das überhaupt nicht mehr zu bewältigen.

Nehmen wir doch einfach mal die Bugs an Airports wie sie z.B Henning meldet. Also z.B auch Bodentexturflackerprobleme durch Wechselwirkung AREA16N Flatten, Runwaycode und Mesh.

Klar kann man das zunächst ermitteln in dem man irgendeine Scenery abmeldet. Nur will man dann hunderte BGls absuchen um die zu ermitteln um die es sich handelt. Der Aufwand welches Addon nun gerade hinsichtlich Priorität je nach Startort (der Bug den wir hier erwähnten) wird mit Microfiles noch unberechenbarer.



Was aber meiner Meinung auch dagegen spricht ist der Barth Effekt.

Kennst Du noch die ersten Barth Landclass LC Files für Deutschland?

Das was ich jetzt überarbeitet hatte, was man im Zuge des German Landscape Projektes Downloaden kann.


Der Verwaltungsaufwand für den FS wird sehr hoch. Man hat wesentlich längere Ladezeiten.

Da jedes Landclass und natürlich auch Meshfile einen Datenheader mit sich schleppt wird das Verhältnis Nutzdaten zu Datenheader extrem ungünstig.

Deckt ein File 300 x 300 km ab ist der Datenheader nicht anders als bei einem kleinen File welches nur 1km x 1km abdeckt. Nur das Du jetzt 90000 mal diesen Header der auszuwerten ist hast.

Ist natürlich jetzt ein Beispiel welches nicht ans LOD Raster angelehnt ist.

Das Prinzip ist aber leider so.

Weiterhin ist die Datenkompressionsrate der BGls bei großen Files größer als bei vielen kleinen.

Bedeutet hat man exakt identische Informationen für eine große Fläche, dann ist unabhängig vom Header das große File kleiner in den MBs als die vielen Einzelfiles die die selbe Fläche abdecken.

Meiner Meinung spricht sehr vieles gegen kleine Files.

Wenn man ein gutes perfektes Mesh hat, dann wird es auch keiner nötig haben hier irgendwelche Bereiche raus abzuschalten.

Wenn ich mal Mesh außen vor lasse und nehme mal Landclass, dann möchte ich behaupten das fast alle Anwender mittlerweile Chaos und keinen Überblick haben und kaum einer wissen dürfte welches Landclassfile wo gerade aktiv ist.

Das selbe gilt für Mesh auch. Wenn dann noch diese Microfiletechnik kommt ev. dann auch noch mit ein oder zwei Puffermesh die dann natürlich auch noch in Microtechnik sein sollten dann gute Nacht FS.