![]() |
![]() |
|
|
|||||||
| Simulationen Alles zum Thema Simulation |
|
|
Themen-Optionen | Ansicht |
|
|
#17 |
|
Inventar
![]() Registriert seit: 02.01.2002
Alter: 62
Beiträge: 4.238
|
Auf der linken Seite sieht das aber anders aus. Daher ist meine Vermutung das auf der rechten das mesh schon so programmiert wurde. Ansonsten weiter gehts mit Niedersachsen im Test.Niedersachsen in flachen Gebieten geringe Fehler. Auch in dem meisten Gegenden mit stärkeren Erhebungen so um die 300m Höhe sind die Fehler zum Teil sehr gering, bei ca. max. 2-3m. Bei Georgsmarienhütte 7m Fehler.
Es gibt eine Erhebung bei Zernien diese nennt sich Hohen Mechtin mit 142m hier beträgt der Fehler 11m. Bei Bad Münder die Erhebung Hohe Egge mit 437m. Der Fehler hier ca. 7m. Etwas neben dieser Koordinate messe ich im FS 434m, die Kontrolle in Top 50 ergibt an dieser Koordinate auch 434m Höhe. Das ist eigentlich auch ein Beweis der dafür spricht, dass diese Abweichungen die man jetzt messen kann zum Teil daher rühren, dass als Rohdaten nur ein ca. 90m Mesh vorgelegen hat. Diesem realen Rohdatenmesh fehlen natürlich einfach Höhenpunkte. Zum anderen rühren die Fehler natürlich daher, dass der Resampler beim abtasten zum Teil an der entsprechenden Koordinate, die er aufgrund des LOD Rasters darstellen muss keine reale Höhe vorfindet. Nun muss er hier einen interpolierten Wert berechnen der zwischen den nächsten wahren Rohdaten die ihm zur Verfügung stehen an dieser Stelle vermutlich liegen würde. Dabei entstehen natürlich Fehler, da die Natur sich nun mal nicht an Berechnungsalgorithmen hält und es hier in der Realität ganz anders aussehen kann. Der Wurmberg im Harz 971m hoch. Meine Messtelle lag hier in Top 50 aber bei 953m. Der Fehler im FS hier 13m. Momentan der Aussreisser mit der höchsten Abweichung die ich im Mesh gefunden habe. Aber auch hier ist, wenn man nur geringfügig daneben geht eine identische Höhe zwischen TOP50 und FS zu messen. Siehe der Sachverhalt zuvor. Da ich offline schreibe weis ich nicht genau ob es sich bei dem Problemscreenshot hier im Forum der im Harz einen See mit einer unnatürlichen Mauer/Schwelle anzeigt, um den gleichen handelt den ich jetzt im Anhang zeige. Sollte es der selbe sein (davon gehe ich aus, da hier auch so eine Art Mauer zu sehen ist) handelt es sich um den Oderstausee. Wie wir ja bisher wissen ist das Mesh eigentlich sehr genau. Fehler entstehen nur durch die oben genannten Gründe. Der Oderstausee ist in TOP 50 mit 377m Höhe definiert. Nun ist es natürlich so, dass diese Höhe eigentlich nicht real sein kann, denn es ist ein Staussee bei dem die Höhe je nach Regenfall eh schwanken dürfte. Ich vermute aber das es in der Kartographie hier eine Einheitshöhe geben dürfte (statistischer Füllgrad des Sees oder ähnliches) Dieser könnte ich mir vorstellen wird bei allen Kartenwerken genutzt. Nun gibt es natürlich viele verschiedene Höhenmodelle auf verschiedener Basis/ Technik z.B SRTM. Was ich jetzt nicht weis worauf sich MS bezieht. Anhand SDK vermute ich GTOPO30. Ich wies nicht auf welcher Art Höhenmessung GTOPO30 beruht bzw. das hier beim Allemagne Mesh verwendete DTED LEVEL1. Das könnte man rausbekommen, dürfte uns aber nicht interessieren. Fakt ist im FS wird die Höhe des Oderstausees mit 415,47m gemessen. Eine extreme Abweichung zu 377m. Ich denke auch nicht das bei dem Oderstausee diese Toleranz im Wasserstand von ca. 39m jemals vorgelegen hat. Also würde ich mal sagen die Hauptfehlerquelle ist hier schon mal eine falsche Höhendefinition des FS Sees. Daher habe ich mal die Nordwesteuropascenery abgeschaltet, dadurch verschwindet der See ganz und ich kann sehen mit welcher Definition das AllemagneMesh diesen See darstellt. Ergebnis etwas schwankend so um die 377 bis 378,5m. Aha das passt. Die Schwankungen sind normal aufgrund der Auflösung des Mesh und dürften im Randbereich nocht etwas höher ausfallen. Nur auch hier muss ich jetzt zusätzlich feststellen, dass der See nicht die Form hat, die er haben sollte bzw. nicht 100% positioniert ist. Daher habe ich selbst noch mal einen Bild im Anhang. Es zeigt unten den See so wie wir Ihn im FS sehen. Man sieht sehr schön wie die falsche LWM Höhe des MS Sees mit 415,47m das Mesh auf der linken Seite hoch zieht. (Genau so wie bei Airports das Flattenpolygon. Anmerkung wie erwähnt würde bei Terrain_Max_Vertex_Factor=21 vermutlich dieser Anstieg so steil ausfallen, dass hier unter Umständen auch der Landclassautomatismus Gebirge zur Anzeige bringt, könnt Ihr ja mal ausprobieren) Auf der rechten Seite sieht man wie der See das hier wesentlich höher liegende Mesh zerschneidet und Gebirge zur Anzeige bringt. Im Hintergrund seht Ihr diesen Anstieg des Gewässers. Dieser dürfte eigentlich nicht existieren. Da die LWM Höhe eine höhere Priorität als Mesh hat. Die obere Hälfte des Bild zeigt die selbe Stelle mit deaktivierter Nordwesteuropascenery. Dadurch fehlen sämtliche Seen und weitere Scenerymerkmale. Nun kann man unbeeinflusst die Höhendefinitionen des programmierten Mesh erkennen. Zur besseren Übersicht habe ich die gelben und roten Führungslinien eingezeichnet, dadurch kann man besser sehen, das es sich hier um die identischen Stellen handelt. Leider kann man im Screenshot diese real existierende Kante bzw. Erhebung im Mesh nicht erkennen. Grob in grün eingezeichnet sieht man wie gesagt den realen Verlauf des Oderstausees. Hier ist im Mesh auch alles flach. Auch dieses bedeutet für uns, dass Mesh ist wieder sehr gut entsprechend der verfügbaren Rohdaten umgesetzt. Fehler entstehen auch hier nur durch falsche Microsoftdefinitionen. Der Zippel wo man den See hochsteigen sieht ist hinsichtlich See von den Positionen wieder falsch gesetzt. Der See liegt in Wahrheit weiter links. Aber woher kommt jetzt der Fehler wenn doch LWm eine höhere Priorität hat. Vergesst das was ich oben noch in dem Screenshot zur Kante stehen habe. MS hat hier doppelt geschlampt. Sie selbst haben hier die LWM Höhe falsch positioniert. Macht euch doch mal den Spaß und schaltet das Deutschland Mesh ab. Dann werdet Iht sehen, das dieser Fehler auch im Default FS 2002 Mesh weiter existiert. Ende Teil1 |
|
|
|
| Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1) | |
|
|