Hochauflösendes Mesh weltweit - Gratis!!!

[JOBIA]

Was ich weiter oben mangels Zeit noch vergessen habe. Diese SRTM Geschichte selbst geistert ja schon ein paar Monate durch die ausländische Designerscene. Damals waren die Rohdaten zumindest weltweit wohl noch nicht verfügbar, so das man was den europäischen Bereich betraf wenig davon gehört hat.

Was mir aber erwähnenswert erscheint, ist das diese gute Höhenauflösung, die feine Struktur von Christoph seinen Mesh auf gar kein Fall irgendein Quatsch aus dem resample Prozess des SDK Tools sein kann. Es basiert definitiv auf den Höhendaten der SRTM Rohdaten. Das kann man schon mit dem Auge optisch erkennen wenn man sich im Umfeld umschaut. Das sähe nämlich ganz anders aus. Ein Bild von einem LOD11 Mesh welches diese fehlerhaften Kennzeichen zeigt hatte ich vor ganz langer Zeit im Forum mal gepostet.

Sicherlich wird auch dieses Mesh viele interpolierte Daten haben, denn anders geht das aufgrund des LOD Rasters überhaupt nicht. Denn die vorliegenden SRTM Rohdaten wird man nie in dem Raster vorfinden wie sie der FS gerade bräuchte. Zumal das im FS selbst ja auch schwankt (unter der Vorraussetzung das man hier den Abstand der Höhenpunkte in Metern angibt) In Grad ist es natürlich konstant. Das Problem trifft aber auf alle Meshfiles zu. Um so dichter das Raster der SRTM Rohdaten ist, umso genauer wird das natürlich insofern man beim resample Prozess den LOD Level beibehält.

Es kann daher auch durchaus sein das man mal Glück hat und die Rohdaten passen zufällig mal besonders gut ins verwendete LOD Raster, dass würde ein sehr genaues Mesh ohne große Interpolation geben. Das dürfte aber äußerst selten der Fall sein.

Das Faitman Mesh hat aber gezeigt, das das resample Tool ausreichend genau arbeitet, wenn man gewissenhaft seine *.inf Datei vorbereitet.

Wie gesagt ob man mit dem Konvertierungstool usw. groß Fehler produzieren kann muß ich sehen.
Was auch alles abzuklären ist, ob denn die SRTM Rohdaten komplett auf WGS84 beruhen hinsichtlich Elipsoid und geodätischen Datum. Denn da hat Micosoft selbst offensichtlich bei einigen Airports geschludert. Rolf Schon hatte hier im Forum ja schon mal was gepostet, dass sie z.T Abweichungen bei einigen Airports zwischen FS2002/2004 festgestellt haben. Leider bei einem Airport den sie selbst in Ihrer VFR VOL Serie abdecken. Da ist jetzt nämlich die Frage wo gehört er denn wirklich hin. Wolfgang Schwarz, Simflyers erwähnte ja bei dem Flattenbeitrag selbst das sie momentan eigentlich zu den Vorgaben von MS tendieren. Diese mögen zwar falsch sein, bereiten aber hinterher die geringsten Probleme bei AFCAD usw. Meine Messung hat ergeben das dieser von Rolf erwähnte Airport sowohl im FS2002 als auch im FS2004 falsch liegt. Im FS2002 waren die Koordinaten richtig wenn man diese mit einer realen Airportkarte vergleicht. Nur der Knackepunkt ist, das diese Koordinaten der Airportkarte wohl auf dem geodätischen Datum "European Datum 50 also ED50 beruhen". Zumindest dann wenn ich den Vergleich zu TOP50 ziehe, da passen die Koordinaten 100%tig wenn ich von WGS84 auf ED50 einstelle. Hier kann man nämlich zwischen allen möglichen Koordinatensystemen umschalten. Die Airportkarte selbst schweigt über das geodätische Datum. Mich würde aber nicht wundern wenn man in Deutschland auf ein europäisches Datum zurückgreift. Man hätte die Position also erst auf WGS84 umrechnen müssen. Dann liegt der Airport nämlich ganz woanders. Microsoft hat vermutlich diesen Fehler beim FS2002 bemerkt und ihn daher im FS2004 neu positioniert. Nur offensichtlich haben sie dieses mal einen neuen Fehler mit eingebaut.

Problematisch wird diese Geschichte dann wenn in diesem Bereich eine Fotoscenery veröffentlicht wird.

Die restlichen MS Airports liegen in der Regel halbwegs genau. Ich hatte Rolf gegenüberschon mal den Verdacht geäußert, dass es sogar sein könnte das genau dieser Fehler des geodätischen Datums ev. auch eine Rolle für die falsch positionierten MS Seen und Straßen sein könnte. Geprüft habe ich das aber noch nicht. Die Basis der Straßenführung, Seen usw. soll wohl der MS Encarta entnommen worden sein. Könnte nämlich durchaus sein das MS die Daten von irgendeiner europäischen Karte übernommen hat. Die Daten waren ev. auch schön in Dezimalgrad bezogen aber ev. auf ED50.

Ev. hat man dann gedacht: "schön Dezimalgrad also WGS84" hat das dann so auch programmiert. Eine Umrechnung von ED50 auf WGS84 hat man ev. vergessen weil man von diesem Umstand gar nichts wußte. War jetzt nur Theorie müsste man wie gesagt prüfen. Auf jeden Fall ist das komplette Straßen und Gewässersystem nicht grundsätzlich falsch sondern nur falsch positioniert also verschoben.

Auch werde ich mal versuchen rauszufinden worauf das digitale Höhenmodell der TOP50 Serie beruht. Wie diese Höhendaten ermittelt wurden und ob sie wirklich noch das Maß der Dinge sind.

Optisch muß ich Christoph recht geben. Das was ich mir hier heute morgen angeschaut habe sieht besser als das Faitman Mesh aus. Bei gleichen LOD Raster sind wie gesagt viel mehr verschiedene Höhen im Gelände aufzufinden. Man kann wirklich sagen von einem Höhenpunkt zum nächsten Höhenpunkt variiert die Höhe und wenn es nur 1Meter ist. Wie gesagt wenn man sich ein halbwegs flaches Gelände rauspickt dann können das unmöglich Interpolationsfehler des SDK Resample Tools sein. Die SRTM Rohdaten geben das offensichtlich her.

Ehrlich gesagt da die SRTM Rohdaten von einer amerkanischen Mission kommen gehe ich schon mal ganz stark davon aus das sie komplett auf WGS84 beruhen. Das soll der FS laut SDK auch. Da wird extra drauf hingewiesen das man hier drauf achten soll wenn man mit Koordinaten bezogenen Daten arbeitet. Das ist aber in der Regel beim Scenerydesign immer der Fall. (Man sollte also besser aufpassen als MS selbst). Grins!!!!


Fehler aus der Richtung schliesse ich bei dem Mesh also fast aus.