@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