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.

Zu Braunewell

"woran liegt es denn nun, daß in einigen bereichen die seen auf plateaus angezeigt werden (z.b japan) in anderen nicht (z.b. Deutschland, Rumänien...)

wäre für jede hilfe dankbar"

Eigentlich kann man das in den Beiträgen nachlesen die ich schon zum Thema Mesh geschrieben habe.

Daher hier nur in Kurzform. Zum einen kann es an falschen Meshrohdaten liegen. Oder der jenige hat das Mesh falsch programmiert.

Diese beiden Sachen treffen in der Regel nicht zu.

Also ist es was anderes. Dazu folgender Sachverhalt. Microsoft kann in der Regel nur flache waagerechte Airports darstellen. Diese haben eine eigene Höhendefinition. das selbe gilt für Gewässer in Form von Seen oder großen Flüssen. In der Regel haben sie auch eine eigene Höhendefinition. Kommst Du jetzt mit einem Mesh an, welches an solche geflatteten Gebiete stößt ensteht wenn dieses nicht eine Höhe hat sondern stark von einander abweicht eine starke Steigung. Bei einer starken Steigung setzt das Landclasstextursystem automatisch Gebirgstexturen. Daher entstehen Tafelberge oder ähnliches oder Waldstreifen (bei geringerer Neigung im Mesh) Oder aber Senken in der Scenery. Warúm weichen aber Höhen stark von einander ab. Antwort weil MS bei den Positionen der Seen usw. geschlammpt hat. Bedeutet der See hat die richtige Höhe das Mesh auch. Nur der See liegt ganz woanders wo das Gelände natürlich real gar nicht mehr zur Seehöhe passt. Und schon hast Du eine starke Steigung oder Gefälle. Und damit das von Dir geschilderte Problem. In manchen Ländern haben sie halt genauer positioniert in anderen wieder nicht. Theorie warum siehe meinen vorigen Bericht. Das könnte einer der Gründe gewesen sein.

@ Gringo1:
'tschuldigung, da habe ich mich zu weit aus dem Fenster gelehnt. Die österreichischen/schweizer Grenzgebiete zu Frankreich, Deutschland und Italien sind durch Nanucq's Mesh abgedeckt, aber insbesondere die südliche Zentralschweiz fehlt. Dafür gibt's meines Wissens auch nichts wirklich Gutes als Freeware. Die SRTM-Daten für eisbedeckte oder sehr steile Berge sind sehr schlecht (kann leider keinen Screenshot posten, aber es ist, abgesehen von den -32000 m-Löchern voller völlig unmotivierter Kanten, Steilstufen von über 1000 m und merkwürdigen Zacken (ich war schon in den Alpen :) ). Das Matterhorn ist nicht ansatzweise erkennbar. Zu der ganzen Problematik mal im Mesh-Scenerydesign-Forum bei AVSIM nachschauen, da gibt's erschöpfende Ausführungen von den Experten (die z.Z. noch nicht sehr ermutigend sind).
@ JOBIA:
Die von Nanucq verwendeten DTED1-Rohdaten (wie ist der Bursche eigentlich da rangekommen, sind ja offiziell nicht frei) haben einen Sprung im Abstand der Datenpunkte: von 0-50 ° Breite sind sie 3' auseinander, danach bis (glaub ich 70°) 6'. Das heißt, mitten in Deutschland gibt es eine Verschlechterung der Auflösung, was Deinen Eindruck von der besseren Auflösung des SRTM-Meshs begründen könnte.(das von Dir getestete bgl in Hessen ist ja wohl nördlicher als 50°).
Zu den von Dir angesprochenen im Flachland sichtbaren kleinen Höhenunterschieden von wenigen Metern denke ich, daß es sich z.T. um das Rauschen des SRTM-Systems handelt. Begründung: schau Dir mal mit dem TMFViewer ein SRTM-bgl an, wo eine größere Wasserfläche drauf ist. Da gibt es auch die bewußten 2-3 Meter Höhendifferenz (max. etwa 5 Meter), die wohl (zumindest im Binnenland) nicht durch die Wellenhöhe zu erklären ist :) .

Soweit ich mich recht erinnern kann sind DTED Level 0 und 1 noch frei verfügbar. Erst ab DTED Level 2 kann man diese gegen Geld ordern. Kann mich täuschen. Ich würde mir sowas mit einem 56K Modem eh nicht antun.

Microdem unterstützt einen direkten Import von DTED1. Es gibt auch ein Konvertierungstool. Vermutlich sind deshalb die Faitman Mesh auch so gut. Vermutlich ist es hier genau so wenig Arbeit wie bei dem SRTM Tool weil alles fast von selbst geht. Man muß sich keine extrem großen Gedanken mehr machen.

Fertige Meshfiles anhand des Farbcodes des TMF Viewers zu beurteilen würde ich lieber sein lassen. Ich weis nicht ob Du das getan hast. Es hört sich aber so an. Da er sehr viele Höhen in einen Farbcode packt kann man da Fehler sehen die überhaupt nicht existieren. Setzt man die gemeldeten Höhen jedoch in eine Graubitmap um sieht das anders aus.

Wie gesagt anhand einer fertigen BGL möchte ich nichts beurteilen. Ich muß erst die Rohdaten haben um wirkliche Fehler zu sehen. Auch möchte ich mich vorerst nicht zu Fehlern des SRTM Verfahrens äußern. Da muß man sich erst mal einlesesn. Es muß ja nicht rauschen sein. Es können ja auch andere Laufzeit oder Phasenverschiebungen oder was auch immer sein die hier Fehler verursachen. Wie gesagt zum Messverfhren kann ich noch nichts sagen außer das ich beim überfliegen der DLR Seite den angegebenen Fehler von 6m gesehen habe.

@ JOBIA

Der TMFViewer hat unten in der Statuszeile eine Anzeige der geogr. Koordinaten und der Höhe in Metern für die Position des Mauspfeils. Man kann also wirklich genau sagen wie hoch ein bestimmter Punkt liegt. Zu den Fehlern, die die Interpolation beim BGL erstellen zusätzlich reinbringt, stimme ich Dir zu, aber dies dürfte auf großen Wasserflächen (Bodensee Mitte) keine Rolle mehr spielen, da weit und breit alle Datenpunkte auf einer Höhe sein sollten. Daher denke ich, die angegebene Höhenungnauigkeit von mehreren Metern (von mir salopp als Rauschen bezeichnet) hat 'ne Chance zu stimmen. Übrigens, wenn man mit den SRTM-Rohdaten ein Alpen-Mesh-bgl erstellt, findet man im Mont-Blanc-Massiv (der ist etwas über 4800 m hoch) maximal Höhen, die unter 4600 m liegen. Ebenso fehlen beim Matterhorn ca. 50 m. Das unterstreicht, wie problematisch das einfache Erstellen von Hochgebirgs-Mesh aus den unbearbeiteten SRTM-Daten ist.
Zu DTED habe ich übrigens gelesen, daß die US-Regierung aus Sicherheitsgründen die Daten nicht freigibt (lies mal http://cgdi.gc.ca/CGDI.cfm/fuseactio.../11972/gcs.cfm ).
Auch interessant: http://216.218.220.254/ozi3d/height_data.html

Zu Paulemann

Der TMF Viewer und dessen Funktionen sind mir genauestens bekannt. Nutze ich unter anderem schon seit den FS2002 SDKs da wurde er nämlich veröffentlicht. Das jetzt geschriebene ist offline geschrieben daher nicht ganz aktuell zu deinem Text.


Wen es nicht interessiert bitte nicht lesen. Es steht auch ein bischen allgemeines zu GPS drin, da dieses vermutlich gut zu dem SRTM Messverfahren für digitale Höhenmodelle passt. Ev. hilft es auch jemand das von Paulemann erwähnte Rauschen zu erklären.

Zu meinem Text von heute morgen. Ich war da zeitlich etwas unter Druck. Daher konnte ich hier nicht ausführlicher antworten. Nachdem ich deinen Text genauer nachgelesen habe konnte ich erkennen das Du ( um es an einem Beispiel festzumachen hier mal angenommen der Bodensee) bei den Höhen die das BGL File hier erzeugt festgestellt hast das hier Schwankungen in der Wasseroberflächenhöhe von bis zu 3m zu finden sind. Ich vermute mal das Du das BGL File welches das LWM Gewässer enthält im FS abgeschaltet hast. Bzw. du hast diese Beurteilung generell nicht im FS sondern anhand des tmf viewers gemacht. Hier nicht anhand des Farbcodes sondern der direkten Höhenangabe.

Du schreibst jetzt das man eigentlich davon ausgehen kann, dass ein Gewässer wie der Bodenssee in der Regel keine bis zu 3m hohen Wellen hat. Rein von der Theorie kann man hier also von reinen Meßfehlern bei der SRTM Mission ausgehen. Ich denke das war im wesentlichen auch auf meine Aussage bezogen das ich geschrieben habe das offensichtlich die Höhenauflösung des SRTM Mesh besser ist, da man quasi von Meshpunkt zu Meshpunkt andere Höhen feststellen kann. Es in diesem Sinne nicht so rund wie das Allemagne Mesh ist. Die Verrundung spricht ja in der Regel für eine niedrigere Rohdatenauflösung. Über die eventuellen Gründe bei Faitman hast Du ja was geschrieben. Die ganze Faitman Geschichte lasse ich außen vor da zu diesem Mesh genug geschrieben wurde. Es ist sehr gut und kann jedem nur empfohlen werden. Zumindest das Allemagne Mesh. Die anderen kann ich nicht beurteilen. Die Genaugkeit bei dem Allemagne Mesh zu anderen bisher sehr teuren Höhenmodellen ist auf jeden Fall gegeben.

Zu den Höhenfehlern bei Gewässern (habe da aber noch kein auf SRTM basierendes BGL File gesehen, kann dazu endgültig also noch nichts sagen) muß ich Dir von der Theorie her recht geben. Wir können natürlich nicht ausschliessen das diese Höhensprünge von Messfehlern der SRTM Mission her rühren. Wenn es bei Gewässern auftritt wird es über Land vermutlich nicht anders sein. Generell sagte ich ja das ich Abweichung von bis zu 10m zu TOP 50 gesehen habe. Auch die Aussage der NASA/DLR das hier Messfehler bis zu 6m existieren sagt ja schon einiges aus. Rein von der Theorie her dürften wir demnach sogar ein Ripple von 6m auf der Wasseroberfläche des Bodensees feststellen. Ich weis auch nicht wie die Höhenauflösung von SRTM ist. Es kann daher sein das es hier zu Höheninterpolationsfehlern des resample Tools kommt. Man beachte bei diesem SRTM Tool wird der alte resampler aus dem FS2000SDK verwendet und nicht der vom FS2002SDK. Ich erwähnte ja schon mal in Bezug zur Fotoscenery das der neue hier recht diffuse Bilder liefert. Offensichtlich hat man beim Mesh ähnliche Erfahrungen hinsichtlich Interpolation gemacht. Fehler von 3m schliesse ich aber durch den resampler aus. Hier dürfte man nur 1m im ungünstigen Fall 2m von zwei nahezu gleich hohen Messpunkten erwarten.

Wie gesagt ich habe bisher vorsichtig geschrieben und nie gesagt so und nicht anders ist es mit diesem SRTM Mesh. Denn wie gesagt ich möchte mir erst mal die Rohdaten ansehen.
Ob man da auch schon bei z.B Gewässern diese Höhenschwankungen sehen kann. Es muß dann auch ein Vergleich gemacht werden zwischen Rohdaten und denen der fertigen BGL. Denn hier kann auch einiges auf der Strecke bleiben. Sind natürlich alles Sachen die Zeit erfordern die ich momentan nicht habe, da ich an wichtigeren Sachen bezüglich FS arbeite. Bei Gelegenheit schaue ich mir das aber mal an.

Zu den theoretischen Messfehlern (auch deinem erwähnten Rauschen) bei SRTM selbst. Ich habe mir das wie gesagt überhaupt noch nicht angeschaut, auch nicht auf welcher Technik die Höhendaten aus TOP50 resultieren und wie hier die Fehler sind. Es war aber zumindest von der Qualität her das beste was man für Deutschland zu einem angemessenen Preis bekommen konnte. Ich denke bei SRTM handelt es sich um ein spezielles Meßverfahren. Da wird man nicht einfach mit einer elektromagnetischen Welle in welchem Frequenzbereich auch immer gearbeitet haben. Denn dieses Verfahren allein wäre zu ungenau. Man wird hier bestimmt mit aufmodulierten Trainingssequenzen gearbeitet haben. Ich sage mal ähnlich GPS. Zur besseren Erklärung was ich meine, zumal wir ja im FS ein simmuliertes GPS nutzen.

Ende Teil1

Teil2
Da kann es nicht schaden wenn man grob vereinfacht weis wie das GPS in der Realität funktioniert.

Hier ist es ja auch so das die GPS Satelliten auf Bahnen um die Erde kreisen (die Position der Satelliten muß nicht konstant sein). Diese Satelliten werden über eine Bodenstation gesteuert. Alle Satelliten haben eine hochgenaue Atomuhr an Bord. Alle Uhren der Satelliten und der Bodenstation laufen absolut zeitsynchron. Das ist immens wichtig. Auch sind alle Positionen der Satelliten im Orbit exakt bekannt. Der GPS Empfänger am Boden (ein Auto) empfängt jetzt einige dieser Satelliten. Er synchronisert sich jetzt auf die Satelliten. Er weis auch der Satellit 1 steht am Himmel an der Koordinate X der Satellit 2 an Y und der Satellit 3 an Z usw. Die Position der GPS Satelliten kann unser GPS Empfänger aus dem empfangenen Bitstrom jedes einzelnen Satelliten auslesen. Allle GPS Satelliten strahlen ihre eigene Position als Information ab. Er synchronisiert sich jetzt auf die Uhrzeit eines Satelliten. Er weis der Satellit 1 steht an Position X und gerade jetzt in diesem Bruchteil der Sekunde meldet er 12 Uhr. Im gleichen Moment melden die anderen eine andere Uhrzeit obwohl sie alle über Ihre internen Atomuhren 100%tig zeitsynchron laufen. Also kann man eines ganz genau sagen. Wir kennen jetzt die genaue Positionen der Satelliten (das haben sie uns in Ihrem Bitstrom mitgeteilt den unser GPS Empfänger empfangen hat) und wir kennen Ihre unterschiedlichen Uhrzeiten. Warum sind die Uhrzeiten aber verschieden?

Richtig weil unser Auto eine unterschiedliche Entfernung zu den einzelnen Satelliten hat. Auch das Licht bzw. die elektromagnetische Welle ist nicht unendlich schnell. Daher haben wir unterschiedliche Laufzeiten der Uhrzeitinformation zu unserem Fahrzeug und damit eben andere Uhrzeiten. Ein einfaches Beispiel. Neben mir steht ein Kumpel. 500m entfernt ein anderer. Beide haben synchrone Armbanduhren. Ich sage beiden bei 12Uhr hebt Ihr gleichzeitig den rechten Arm und ruft laut 12 Uhr.
Beide machen das auch. Ich habe mich vergewissert um 12 Uhr gehen beide Arme hoch. Den Kumpel neben mir höre ich rufen 12Uhr. Den anderen nicht. Erst später höre ich ihn 12Uhr rufen. Aufgrund der langsamen Geschwindigkeit des Schalls und wann sein 12 Uhr bei meinem Ohr ankommt kann ich jetzt aufgrund der Schallgeschwindigkeit die Entfernung zu Ihm bestimmen. Befinde ich mich genau zwischen den Kumpels gehen bei beiden zeitgleich die Arme hoch. Beide höre ich aber verzögert. Auch hier kann ich bestimmen wo ich mich genau zwischen beiden befinde. Kommt ein dritter Kumpel an anderer bekannter Position dazu, dann kann ich sogar im dreidimensionalen Raum bestimmen wo ich mich befinde. Also nicht mehr nur grob (es blieb ja vorher noch ein Fehler rechts oder links usw.) wo auf der Erdoberfläches sondern auch wie hoch. Jetzt könnte natürlich ein pfifiges Kerlchen sagen. Ja aber es kann jetzt ja sein das Du Dich 50m über der Erde oder aber auch 50m unter der Erdoberfläche befindest. Richtig. Nur das GPS System arbeitet mit seinen Antennen zur Erdoberfläche gerichtet. Damit schliest man die theoretisch in Frage kommende Positionen im Weltraum von vorne herein (auch über Logik) aus. Genau wie bei diesem Beispiel arbeitet stark vereinfacht GPS. Es reichen uns drei dieser koordinatenmäßig bekannten trigonomischen Punkte/ Satelliten aus um eine Positionsbestimmung vornehmen zu können.
Über diese Laufzeit der elektromagnetischen Welle (der aufmodulierten Bitmuster/Uhrzeiten) können wir eindeutig unseren Abstand zu den einzelnen Satelliten bestimmen. Damit natürlich auch unsere Position und Höhe auf der Erdoberfläche.

Übrigends jedes D-Netz Handy macht diese Positionsbestimmung anhand eines ähnlichen Verfahrens. Ein Handy muß nämlich auch grob wissen wo befindet es sich auf der Erdoberfläche. Ein Handy ist eigentlich mehr ein Messgerät als ein Telefon. Es nutzt diese Technik als zusätzliche Steuerinformation und übermittelt diese Daten auch an das Netz zurück (ohne das jemand telefoniert, es macht das aber nicht ständig sondern nur wenn es einen Bedarf aufgrund diverser Steuerparamater erkennt). Damit kann dann nämlich das Netz wiederrum einem Handy sagen. " Lieber Freund Du bist in meiner Funkzelle X registriert. Du bist aber zu weit weg von Funkzelle X, du darfst nicht über sie telefonieren, denn dann musst Du mit zu hoher Sendeleistung arbeiten und störst damit ev. andere Funkzellen die auf der selben Frequenz arbeiten". Ich will damit nur sagen das viele Systeme heute mit einer ähnlichen Technik arbeiten. Übrigends ein zusätzlicher Grund (außer dem das registriert wird in welchem groben Rufbereich sich ein Handy aufhält) warum ein Handy theoretisch ortbar ist wenn dieses die Staatsanwaltschaft wünscht. Freilich geht das nicht so auf die Schnelle.

Ende teil2

Teil3

Das nur mal ein kleiner stark vereinfachter Ausritt in die Technik. Theoretisch könnte man also auch mit GPS ein Höhenmodell erstellen. Das amerikanische Militär, Besitzer des GPS Systems ist natürlich fies. Für den normalen Nutzer ist der Code so verschlüsselt, das für ihn quasi diese Uhren künstlich immer wieder ein wenig verfälscht werden. Deshalb hat er nicht die Genauigkeit der Positionsbestimmung wie das Militär. Aber auch hier gibt es für den normalen User Abhilfen in Form von Differential GPS. Das interessiert hier aber nicht. Ich habe das Beispiel GPS aus einem anderen Grund angebracht. Bei diesem SRTM Radar arbeitet man ja offensichtlich stark gerichet. Man hat quasi nicht mehrere trigonomische Punkte. Im Prinzip ist es hier so das man Signale aussendet. Diese werden reflektiert und kommen zurück. Ein Teil trifft auf die Empfangsantenne. Jetzt kann man im Prinzip die Laufzeit ermitteln. Nur worauf synchronisert man sich. Ursprünglich kann man mit dem Radar eigentlich eher Geschwindigkeiten ermitteln anhand des Dopplerefektes. (Wenn man eine Welle abstrahlt und diese wird von einem Objekt welches sich auf einen zubewegt reflektiert hat dieses eine Phasenverschiebung zur Folge. Dieses wirkt sich in einer Frequenzerhöhung aus. Jeder kennt das wenn ein Fahrzeug mit Sirene auf einen zufährt hört sich dessen Ton höher an als wenn es sich von uns wegbewegt)

Jetzt gibt es mehrere Techniken um dieses in eine Entfernungsmessung umzusetzen. Ich vermute mal das hier bei SRTM aufmodulierte Daten verschickt werden ähnlich einer Uhrzeit wie bei GPS. Anhand dessen das man quasi die Mutteruhrzeit an Board des Shuttle hat mißt man jetzt die zurückgemeldete Uhrzeit der reflektierten Welle. Und schon hat man die Entfernung zum Boden. Nun wo sind die Fehler. Einmal in der Genauigkeit des Messystemes selbst. Also Unsynchronitäten des Messytemes und sonstiges. Dann kosmischen Effekte. Ev. auch Überlagerungen. Und natürlich Mehrwegeeffekte.

Erklärung: Das Signal trifft auf die Oberfläche auf wird mit unterschiedlicher Qualität reflektiert spiegelt sich ev. noch an anderen Oberflächen geht dann über längere Umwege zur Empfangsantenne des Shuttles. Oben kommt dann ein Summensignal an. Ein Gemisch aus verzögerten Uhrzeiten. Der Empfänger versucht jetzt daraus ein nuzbares Signal zu formen. Er muss sich ja für etwas entscheiden. Genau das könnte ich mir sehr gut vorstellen bei schroffen vereistem Gebirge (mehrfache Reflektionen). Daher bei SRTM ev. die Probleme speziell im Gebirge.
Ev. in geringem Maße auch auf Wasser.

Große Fehler versucht man halt dadurch zu verhindern das man Antennen mit starker Richtcharakteristik hat die Mehrwegeempfang möglichst ausschliessen.

Diese ganzen Vorgänge kann man dann halt auch als Rauschen bezeichnen. Denn es ist ja ein Gemisch aus verschieden Informationen. Im Endeffekt ist Rauschen ja nichts anderes. Ich habe eine Nutzinformation z.B dem Jobia sein Haus liegt tatsächlich auf 199 m Höhe. Das Signal des Shuttles schwankt nun aufgrund Mehrwegeempfang wenn man das über einen längeren Zeitraum beobachtet aber zwischen 201 und 197m Höhe. Ein Rauschen.

Da das Shuttle aber eine Momentaufnahme macht misst es heute mein Haus mit 197m ein paar Sekunden später das Nachbarhaus auf gleicher Höhe mit 201m. Morgen misst es mein Haus vielleicht auch auf 201m. Das war jetzt nur mal so ein kleiner sehr stark vereinfachter Abschweif worum es hier bei dem Problem gehen könnte bei der SRTM Technik.

Hallo JOBIA,

danke für Deine sehr umfangreichen Ausführungen. Ist nicht so, daß ich keine Ahnung hätte, was GPS macht, aber immer gut, das mal aufgefrischt zu bekommen ;) .
Zu SRTM: das Shuttle hatte 2 Radarsender/Empfänger, einen in der Ladebucht, einen an einem langen Ausleger. Die beiden Empfänger sehen die Erde aus etwas unterschiedlichem Blickwinkel (also stereo) und damit ist es möglich, Höheninformationen zu errechnen. Die Absolute Höhe des Shuttles über NN wird dabei sicherlich über diverse andere Techniken rückgerechnet.
Zu den Artefakten im Gebirge: es ist wohl (weiß nicht mehr, wo gelesen) so, daß der Radarstrahl nicht senkrecht sondern schräg auf die Erde auftraf, und damit sehr steile Bergflanken einfach im "Schatten" lagen. Das wurde z.T. dadurch abgefangen, daß jede Stelle der Erdoberfläche wenigstens 2x abgetastet wurde (hat aber auch nicht überall geklappt). Was es mit Schnee und Eis auf sich hat, weiß ich nicht, ich vermute mal extrem ungünstige Reflexionseigenschaften. Fakt ist jedenfalls für mich: Flachland bis Mittelgebirge - wirklich brauchbar, Hochgebirge - großflächig unbrauchbr (zumindest diese Rohdaten und mit diesem Verarbeitungstool). Wenn jemand schon irgendwelche Tricks kennt (anderes Resampling, halbwegs automatisches Lückenfüllen etc.), wär's toll.

Hallo Miteinander,

Danke Joachim. Sonst muß man für solche Informationen zahlen oder zeitaufwendig suchen - hier gibt es alles umsonst.

Sicher hat man von den Dingen einen "Schimmer", aber so umfangreich und noch nachvollziehbar aufbereitet - das ist wirklich eine feine Sache.

Nochmals vielen Dank für Deine wirklich außergewöhnliche Anstrengung zu unser aller Nutzen.

Gruß
Rolf