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

Ich muß gestehen das ich das was Pauleman hier schreibt auch sehr interessant finde. Klar mit der Stereotechnik also räumlichen sehen wird das alles noch genauer. Ich denke das Grundverfahren zur Entfernungsermittlung wird aber vermutlich ähnlich sein wie ich es beschrieben habe. Übrigends kein Witz. Bei den aktuellen TOP50 Digitalen Karten ist im Lieferumfang eine 3D Brille dabei damit mn sich das Gelände auch räumlich anschauen kann. Wie gesagt bei Gelegenheit werde ich mir mal das SRTM Verfahren auf der DLR Seite oder anderswo zu Gemüte führen.

Die Rohdaten von Christoph habe ich jetzt auch. Mal sehen ob man mit z.B Microdem direkten Zugriff auf die Files hat. Dann kann man unabhängig von ev. verhunzten BGLs sich das ganze mal direkt anschauen.

Hallo Joachim und alle anderen,

ein wirklich gutes Freeware Programm um die SRTM Daten direkt einzulesen und in 2D bzw. 3D in Echtzeit zu rendern gibt es unter:

http://www.visualizationsoftware.com/3dem.html

Mit ca. 4 MB ist es zudem noch ein recht kleiner Download der sich wirklich für alle diejenigen lohnt, welche mit den SRTM Daten arbeiten. Die Messfehler bzw. Löcher besonders in den Alpen werden damit auch sofort sichtbar.

Viele Grüße,
Michael Grüterich

Wirklich klasse diese Diskussion, von allen Teilnehmern. :)

Neben der noch genaueren Qualifizierung der Daten sehen ich für uns Simmer (bzw. designer oder besser Landvermesser) nun folgende Aufgaben:

Um das x-fach-sampeln der Daten zu vermeiden und die Ergebnisse nicht überall suchen zu müssen, müßte man einen Webspace finden in denen diese Daten strukturiert hinterlegt werden können.

Weiterhin sollten wir versuchen das Beste aus allen Quellen heraus zu holen, z.B. bei den Problemstellen der einen Quelle, die hier besseren Daten einfließen zu lassen - sprich eine Gewichtung durch zu führen. Es wäre im Bezug auf die Fehlerangabe auch interessant zu wissen ob es min-max Fehler sind oder (oh je, hoffentlich stimmt das jetzt, das ist schon sooo lange her...) eine (2) sigma Umgebung der Gausschen Normalverteilung. Aufgrund des Fehlers müsste man die Rohdaten dann glätten, sonst hat man zuviele "Sanddünen" wo keine sind. Zumindest Ausreißer hätte man dann im Griff. Schwierig stelle ich mir allerdings dann die Übergänge der Quellen vor.

Es muss also ein Tool her, welches die unterschiedlichen Quellen (eventuell der Einfachhalt halber aus den BGLs - dann aber wieder mit höheren Fehlern) qualitativ zusammen führen kann.

Wirklich ärgerlich sind die Strassen, Eisenbahnen, Airports und Seen. Vielleicht läßt sich für die Seen eine Lösung finden wenn wir den "Verschiebefehler" herausfinden und dann über einen automatischen Algorithmus alle Seen verschieben und damit korrigieren. Stelle ich mir aber wirklich nicht einfach vor und setzt vorraus, dass so eine Verschiebung einer genau bestimmten (nicht unbedingt linearen) Richtung entspricht.

-Wirklich ärgerlich sind die Strassen, Eisenbahnen, Airports und Seen
-wenn wir den "Verschiebefehler" herausfinden

Ich glaube, genau dies ist das Problem.
Denn ob die Daten um 2 oder 5 m abweichen ist egal, aber die ünschönen Effekte werden durch diese Tatsache bewirkt.

Horst

Zu MIG29.

Habe mir dieses 3DEM gezogen. Gott war der Download über die Mirror
FTP Server lahm. Im Prinzip leider alle gleich lahm. So im Schnitt
ca. 2,2KB. Also für mich ist diese ganze Mesh Geschichte zumindest
wenn man welche selbst produzieren wollte nichts. Nicht mit 56K
Modem.
Das nächste Drama ginge dann beim Upload los.
Ich habe mir das 3DEM noch nicht angeschaut. Auf jeden Fall kann
MICRODEM 7.0 auch SRTM lesen. Es wird aber drauf hingewiesen das das
Referenzdatum für Höhen fehlt. Daher sind in Microdem die Höhen
zunächst mit Vorsicht zu geniessen. Da Microdem eigentlich ein eher
wissenschaftlicher Alleskönner ist, denke ich kann der Bezug ev.
über 3DEM geschaffen werden. Wer es nicht weis bei Microdem stand
eine Info das man niemals den Namen einer SRTM Datei verändern darf.
Die Dateien haben keinen eigenen Header. Der Name selbst ist schon
eine Sceneryinformation. Ui ich hoffe Christoph Du hast das jetzt
bei deiner CD nicht gemacht. Ansonsten kann man sagen Microdem kann
sehr viel hier können auch Daten manipuliert werden. Damit wäre es
theoretisch möglich die meshfiles zu korrigieren. Nur mal ehrlich
drehen wir uns hier nicht im Kreis. Vorher hatten wir das Problem
das man schlecht sehr gute Meshfiles machen konnte weil wir speziell
für Europa das Problem haben kostengünstig an hochaufgelöste Rohdaten heranzukommen. Jetzt tut sich da eine Quelle auf wo man sehr gut an vermeintlich hoch aufgelöste Daten herankommt. Die Meshprogrammierung ist sogar ganz einfach. Wir wissen die theoretisch möglichen Höhenfehler von ca. 6m. Damit könnten wir im Gebirge gar leben. Nur wir müssen auch wieder sehen der Amerikaner
sagt wie so oft nur die halbe Wahrheit. Denn wenn man jetzt aufgrund
der Erfahrung von einigen Usern hier hört das hier ein Loch ist. Da
passt es überhaupt nicht. Ja woher wollen wir denn jetzt wissen wo
denn nun die 6m zutreffen und wo nicht. Wo kann ich mich denn
halbwegs drauf verlassen. Wenn ich jetzt dahingehen muß und meine
Rohdaten zunächst anhand anderer Höhenmodelle wieder auf den
Wahrheitsgehalt zu prüfen. Am besten natürlich genau an den Quellen
an die wir vorher schon nicht gekommen sind. Ja was nützt mir dann
SRTM. Doch eigentlich nichts. Was kann ich denn momentan sagen. Ja
es sieht in einigen Bereichen toll und spektakulär aus. Ob es der
Wahrheit entspricht?

Könnte sein oder aber auch nicht. Da bin ich nicht viel weiter als
bei den Straßen. Passen sie?

An manchen Stellen in der FS Welt schon an anderen wieder nicht.

Jetzt hier anzufangen irgendwelche Löcher mit irgendwelchen anderen
ev. schlechter aufgelösten (ansonsten vermutlich richtigen Höhen) zu
stopfen kann es doch nicht sein. Auch wenn man versucht jetzt über
welche Routinen auch immer hier das Mesh zu konstruieren wo es nicht
stimmt. Das kann es doch nicht sein. Wieviel Fehler mögen dabei
entstehen. Die Natur lässt sich wenn hier größer Bereiche fehlen nun
mal nicht wahrheitsgerecht nachbilden. Auch in anderen Bereichen
nicht. Man sieht das ja immer an der Wetterforschung. Man kommt zwar
weiter aber das Ende der Fahnenstange hat man noch lange nicht
erreicht.

Deshalb meine Aussage wir drehen uns hier im Kreis. Oder natürlich
wir vertreten auch die Meinung und betrachten den FS als Spiel.

Wie im gelobten Land. Wichtig ist die Show, was dahinter steckt ist
nicht so wichtig.

Ich sag mal so was ich gerne hätte.

Das sinnvoll machbare hat ja Jobia schon viel weiter oben beschrieben, die "optimale" Auflösung vom Flusi. Daran sollen sich die Rohdaten auch richten, also nach Möglichkeit genau diesen LOD Level haben. Alles was darüber hinaus geht ist quatsch. (Beziehungsweise doppelt so genau, wie war das noch mit der Datentechnik? ;) Dann muß man die Daten aber runter rechnen.)

Jetzt haben wir also inzwischen zwei Quellen, das Faitman Mesh und die SRTM Daten, die dieser Voraussetzung allen Anschein nach entsprechen. Beide haben anscheinend ihre Schwächen und ihre Stärken.

Warum dreht man sich im Kreis wenn man die Stärken kombinieren will?

Was ich weiter will ist, dass ich möglichst wenig offensichtliche Fehler sehen will. Dabei meine ich nicht unbedingt den Vergleich mit der Wirklichkeit. Aber wenn ich VFR durch die Landschaft fliege stören offensichtliche Brüche, Gruben und Plateaux, die eindeutig von nicht zusammen passenden Daten stammen oder von fehl liegenden Seen und Airports stammen, einfach.

Darum finde ich diese sture Umrechnung nicht befriedigend.

Was mich bei weitem weniger stört - und mir warscheinlich nicht einmal auffällt, ist wenn einem Berg einmal 10 meter fehlen und von den sieben sichtbaren Schutthalden nur drei sichtbar sind und der Rest zusammengewachsen ist.

Zu Andragar

Wir drehen uns im Kreis aus folgendem Grunde. Wie gesagt für mich kommt der Download der DTED Level Daten nicht in Frage das hatte ich schon geschrieben. Es wurde auch geschrieben das diese DTED Level1 Daten angeblich nicht frei verfügbar sind. (Komisch irgendwie war ich der Meinung das das erst bei Level 2 anfing) Aber wie man oben liest kann ich mich täuschen. Also man wunderte sich oben wie der Faitman überhaupt an die Daten herangekommen ist. Theortisch stehen sie uns also nicht zur Verfügung. Woher wollen wir denn dann die Daten nehmen zum flicken. Bliebe uns ja nur das was der Faitman bisher veröffentlicht hat. Mir hat die Seele schon beim Deutschland Mesh mit dem 56K Modem weh getan. Das nächste Problem ist wie willst Du die Löcher flicken. Etwa im FS die Höhe messen und dann in das Rohdatenfile von SRTM reinkaspern. Ev. mit dem TMF Viewer aber das ist auch nicht viel besser.

Wie gesagt eigentlich bin ich immer noch der Meinung das DTED Level1 worauf Faitman beruht frei war. Dann ginge das mit Microdem. Dieses 3DEM ist zwar ganz nett zum anschauen aber es kann nichts was uns weiterhilft. Nichts desto trotz steckt jede Menge Arbeit drin wenn jetzt jemand die SRTM Daten überarbeiten wollte. Weiterhin wissen wir jetzt aber auch das wir uns auf SRTM absolut nicht verlassen können. Wo fängt man jetzt überhaupt an zu überarbeiten. Warum also den ganzen Aufwand wenn wir nicht beurteilen können ob es wirklich besser ist. Eine verlässliche Arbeit hat der Faitman abgeliefert zumindest für Deutschland. Daher mein Tipp gleich seine Mesh Files nutzen wer den Download vieler MBs nicht scheut.

Da hast Du natürlich recht.
Wenn uns nur eine Quelle zur Verfügung stehen ist eine solche Erörterung bezüglich Datenzusammenführung zwecklos.

Auch das ein Überarbeiten von Daten eine imense Arbeit darstellt ist mir klar. Das sowas nicht händisch gehen kann ist logisch. Was wir bräuchten wäre ein bgl disassambler der die Höhendaten z.B. der Seen ermitteln kann und dann sinnvolle Anpassungen an den vorhandenen Rohdaten macht. Außerdem scheint mir eine (so gut die Wellen auch aussehen mögen...) Abflachung des Rauschens sinnvoll.

Bei der ganzen Konvertiererei mit den SRTM Daten scheint mir doch die Faitman Lösung, wie du schon sagtest, momentan am sinnvollsten.

Die Höhen der MS Seen kann ich Dir sagen auf den cm genau das ist nicht das Problem. Die Löcher bzw. generell fehlerhaften Daten des SRTM Mesh bereiten mir da eher Gedanken.

Hallo Leute,

seht' s doch nicht so verbissen. Erstens sind die jetzt veröffentlichten SRTM-Daten ausdrücklich Rohdaten (ob allerdings die korrigierten in 1-2 Jahren dann auch noch so frei verfügbar sein werden...), und zweitens haben wir für viele uns interessierende Länder Europas schon (v.a. Faitmain, aber auch Austria prof. u.a.) recht ordentliches Mesh. Drittens (meine persönliche Vermutung/Hoffnung) könnte es ja sein, daß MS in der nächsten Flusi-Ausgabe endlich auch Gebrauch (und zwar nicht so rudimentär wie im 2004er) von LOD9 macht und bei der Gelegenheit auch für seine linearen Landschaftselemente (Flüsse, Seen, Infrastruktur) mal bißchen Geld ausgibt. Die jetzigen Fluß- und Straßenverläufe sowie Seen entstammen nämlich (bin ich sicher) der selben Quelle wie die Daten im MS Encarta Weltatlas - und das mindestens seit der 1997er Auflage (schaut's Euch an, es stimmt). Daher ist es wohl auch kein Wunder, daß es diesen blöden ca. 100m-Horizontalversatz zw. Mesh und Flüssen gibt.
Wir sollten die jetzt verfügbaren SRTM-Daten dafür nutzen, von topographisch interessanten Gebieten (v.a. Mittelgebirgen), die bisher in LOD 5 bis 7 abgedeckt sind, ohne großen Aufwand fehlerfreie
und recht nahe an der Wirklichkeit liegende bgl-s zu erstellen (siehe letzte uploads von Java, den venezuelanischen Tepuis und und ...). Ich werde mir jedenfalls (bis auf mal ein paar ganz kleine Löcher, die recht schnell von Hand zu flicken gehen) nicht die Arbeit machen, um dann nach einem Jahr das ganze evtl. frei (naja ;) ) Haus zu bekommen. Man will ja auch ab und zu einfach mal fliegen. :D

Gruß an alle anderen Scenerybesessenen

Also verbissen sehe ich das überhaupt nicht. Ich verwende die Bezeichnung Rohdaten übrigends nur deshalb weil es die Basisdaten für den resample Prozess sind.

Das mit der Encarta erwähnte ich ja schon. Nur auch hier muss es damals mal einen Grund gegeben haben das hier große Fehle drind sind.

Es geht hier ja auch mal um 500m und mehr und nicht nur 100.

Aber ansonsten bin ich deiner Meinung. Ich denke auch man sollte da wo es was gutes bereits gibt das gute verlässliche verwenden, wenn wir uns bei dem anderen nicht sicher sein können was stimmt. Ist ja im richtigen Leben nicht anders. Erst sieht alles toll aus. Wenn man aber irgendwann merkt da stimmt was nicht, da auch nicht, dort wieder nicht dann nützt das aber nichts mehr wenn die restlichen 70% perfekt sind. In dem Moment wo man sich nicht drauf verlassen kann ist es vorbei.

Verbissen sehe ich das ganz und gar nicht. Warum auch? Ist doch eine ganz sachliche Diskussion.

Jobia, was ich sagen will, es nützt nicht viel wenn man sagen kann wieviel cm ein spezieller See "falsch" ist. Das würde nicht gehen, alle Daten händisch anpassen zu wollen. Darum müsste sich ein findiger Programmierer finden, der eben dieses Anpassen automatisiert.

Ansonsten stimme ich euch durchaus zu. :)

Ich bin jetzt zunächst davon ausgegangen das Du einen anderen weg gehen wolltest. Nämlich den Trick anwenden das Du die falsch positionierten Gewässer anhebst auf nahezu Meshhöhe. Das war beim alten LWM Code kein Problem das wäre halbwegs schnell gegangen auch ohne Automatismus. Tja da wir beim neuen FS2004 aber einen neuen LWM Code haben und der liebe MS Mann in Paderborn laut Schubi ja mehr oder wenig garnichts zu der SDK Veröffentlichung gesagt hat, heist es hier dicke Backen machen. Nichts desto trotz auch ein verschieben welches über Automatismus ev. machbar wäre (wer will das Tool schreiben, da es meiner Meinung nach überflüssig ist).

Warum. Ganz einfach weil erstens die Seen eh nicht die richtige Form haben und zweitens die Abweichung sich nicht immer ganz konstant verhält. Was soll es, da kann man es ja gleich von der Karte neu abzeichnen so wie das der Rainer macht. Denn bei diesem Automatismus mußt du ja eh schon fast jeden See individuell anpassen. Das gleiche gilt für die Straßen.


Hat in meinen Augen daher keinen richtigen Sinn leider.

Ich möchte mich hier nochmals bei Christoph dafür bedanken, dass er mir die SRTM Daten von mehreren Ländern geschickt hat. Wenn ich fliege dann überwiegend in Deutschland. Andere Faitman Mesh oder ähnliches werde ich mir aufgrund der Downloadmenge deshalb bestimmt nicht runterladen.

Aufgrund dessen das ich durch ihn jetzt fast 600MB Rohdaten für mehrere Länder habe, kann ich mir aber für alle anderen angrenzenden Länder auf die Schnelle eigene Meshfiles erzeugen. Denn in der Regel sind sie auf jeden Fall besser als die Defaultwelt. Da wo natürlich erkennbare Löcher oder ein Mont Blanc hinterher schlechter als in der Defaultwelt aussieht da sollte man dann schon die Finger von lassen.

Stimmt. Haette also eigentlich nur fuer Rainers Fluesse und Seen Sinn.
Hab ich nicht bedacht gehabt, wenn die Form nicht stimmt ist es eh fuer die Katz.

... und da stimmt oftmals nicht nur die Form nicht (die stark vereinfacht dargestellt wird). Da wird kreativ umgegangen und aus mehreren Seen schon mal 1 einziger See gemacht etc... Was ich da gerade im Berliner Umfeld fast graue Haare bekommen habe... :rolleyes:

Ciao,
Rainer.

Ist aber auch nicht so einfach...
Mit unserer Waltour sind wir gerade in der Westsahara. Was es dort für Seen und nicht vorhandenen Seen gibt... hängt eben auch etwas vom Wetter ab. :D

Mal ne kleine Frage an die Mesh Profis :) :

Ist dieser Mesh von den Daten her besser für Andalusien als der von Faitmain??

hier der Link: http://personal.telefonica.terra.es/...ginas/sec1.htm

Friedrich

Hallo Rainer,

Deine Arbeit ist übrigends gerade im neuen "Fliegermagazin" gewürdigt worden, auch wenn der Redakteur scheinbar nicht weiss, wieviel Arbeit das war. Übrigends, es hat mich gefreut am Samstag den Beifall für Dich zu hören. Haste Dir auch verdient!

Schade, dass wir uns so schnell wieder aus den Augen verloren haben.

Hallo Börries,

Interessiert mich, der Artikel. ;) Wie kann ich da drankommen?

:D War eine ganz besondere Situation. Hatte niemals mit sowas gerechnet. Toll!!! :D

Habe leider mit vielen nur ganz kurz reden können. Es war eine Menge los. So ohne Namensschild hatte ich es dann doch leichter wie andere... :p

Ciao,
Rainer.

Hi Rainer,

Ausgabe Dez 2003, Seite 85 blauer Kasten rechts unten.

Die email des Autors ist: "geier@bnhof.de". Schreib Ihn doch mal an.

Werd' ich gerne machen. Hätte nur zu gerne erst den Artikel gekannt und ein Kiosk ist so weit... :heul:

Ciao,
Rainer.

Na komm Börries mach den Scanner an, ich kann den Rainer nicht weinen seh'n;)

Hast Post Rainer! :D

Ich hab Ihm gemailt. Du weisst doch: "Copyright" ;)

Alladin Alladin... tse tse tse... ;)

Dann wollen wir mal gucken, wie wir es dem Redakteur heimzahlen können. :D

Ciao,
Rainer.

So war's auch gemeint, jetzt lacht er wenigstens wieder.:cool:

Um noch mal auf das Tool usw. zurückzukommen. Es interpoliert schon während der Mesherstellung. Wie genau habe ich mir noch nicht angeschaut. Auf jeden Fall gibt es Beeinflussungsmöglichkeiten.

Ansonsten kann ich sagen wer es nicht so genau nimmt (wenn man eh schon falsche Straßen und Seen hat) der kann sich hiermit auf die Schnelle zumindest optisch gut aussehende Meshfiles mit mal geringen und auch mal größeren Fehlern erstellen.

In der Regel auf jeden Fall besser als Default FS2004. Wer einen Fernseher einschalten kann der kann hiermit auch Meshfiles erstellen.

Man braucht sich über rein garnichts mehr Gedanken machen. Früher von Hand mußte man sich da doch schon einige Gedanken machen. Hier nicht mehr.

Es braucht halt nur eine gute Datenrate beim Download.

Ob man mit den Switches bzw. bei der Interpolation noch was verbessern kann muß man sehen. Wie gesagt wer sich keine Gedanken macht startet das und fertig ist das Mesh.