Gute Weltkarte für OziExplorer gesucht ?!

    Zitat

    Original von niko75
    Dann muß man unter "Höhen-Konfiguration" die Querverzeichnisse für die DEM-Dateien angeben. Es stehen verschiedene Typen (NIMA DTED, Gtopo30, Globe(ArcView), Grid ASCII, USA DEM 250, USA DEM 24K) zur auswahl. Da ich meine vorhandenen DEM-Daten nicht zuordnen konnte habe ich reihum ausprobiert.


    Hallo Niko,


    Ich konnte bis TTQV Version 3.123 nur folgende DEMs lesen **
    1. Die "Original",nicht korrigierten SRTM3s von ftp://e0mss21u.ecs.nasa.gov/srtm/ Africa, Eurasia
    SRTM3 mit 90m Auflösung, Kacheln 1x1 Grad, N35E003.hgt
    2. SRTM30 mit 920m Auflösung E020N40.dem
    Jeder Datensatz besteht aus E020N40.dem im binären BIL Layout und einem Headerfile E020N40.HDR
    3. diverse Top dems dhm*.mph mit 50m Auflösung


    Die die korrigierten TIFF-DEM SRTM3s von cigar.org http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp
    SRTM3 mit 90m Auflösung, srtm_40_01.tif sind auch in TTQV Version 3.123 nicht als DEM importierbar.
    Ich vermute deshalb wie Anton, geht vermutlich auch in Ozi3D nicht.


    ** Bei TTQV arbeitet man an einer grundsätzlich neuen Konzeption der DEM Daten in TTQV.



    GlobalMapper importierte bei mir bislang jedes DEM Format


    Da Du aber auch GlobalMapper verwendest...... ein Tipp


    Man kann in GM die korrigierten TIFF DEMs (wie jede andere georef. Karte) SRTM3 (90m Auflösung) von cigar.org stückeln und passend zusammensetzen/schneiden und als *.dem exportieren.
    Dieses in GM nicht näher spezifizierte Format ist das USGS DEM-"Format.
    Diese USGS DEMs *.dem (ohne headerfiles) kann man auch in 3DEM importieren und auch als USGS ASCII DEM speichern / wandeln. Vielleicht mag Dein Ozi3D dieses Format lesen?


    Viel Spass beim Basteln


    ciao - Hans

    abdeldjfk


    Danke für den Tip. Nach nochmaligen genaueren Nachlesen (schlechte Englischkenntnisse lassen grüßen...) der Programmbeschreibung von Ozi3d auf der Ozi-HP (dort wurde der gleiche Link wie der deinige angegeben) hab ich die original Daten von dort nochmals downgeloaded.


    Und siehe da: damit funktioniert es einwandfrei. Somit bin ich am Ziel meiner Wünsche angekommen. Ich kann meine vielen ozf2's nun in 3d betrachten, und sogar meine für den Auslandsurlaub (A, HR) gescannten Ozi-Karten kann ich Europaweit in 3D betrachten. Ich bin begeistert.


    Einen kleinen Wehmutstropfen hat die Sache jedoch: Mit GlobalMapper konnte ich rießige tif's (1Karte 60x60km mit ~1,5GB!!!) in 3D super handeln. Selbst die 3D Grafikleistung war noch sehr beeindruckend. GlobalMapper schein daher sehr geschickt mit den Systemrecourcen umzugehen. In Ozi3D komme ich hingegen schon bei Karten mit ~30x30km (im ozf2-Format ~30MB) an die (erträgliche) Leistungsgrenze meines Systems. Bei GlobalMapper hätte man also die perfekte Leistung, hat aber nicht den Reichtum an Tools zur Verfügung. Unter Ozi3D hat man alle Tools, die man sich so wünschen kann, jedoch schwächelt die 3D Leistung "etwas". Trotzdem werde ich für die tägliche Arbeit wohl eher Ozi verwenden. Hier und da aber sicherlich auch hin und wieder GM.


    McQool


    auch an dich ein herzliches Dankeschön. Nachdem ich mit den hgt-Dateien klar gekommen bin, habe ich deinen Weg nicht mehr ausprobiert.


    all@


    Nachdem der ganze Thread zwischenzeitlich eine stattliche Länge erreicht hat, möchte ich noch anmerken: Auch wenn es sich für einen "Neueinsteiger" alles recht kompliziert und verworren anhört: Es ist letztendlich einen Versuch Wert, sich mit der Materie zu befassen. Ich habe lange damit gezögert und mich erst am Freitag dazu entschlossen auch den 3D-Weg zu beschreiten. Und siehe da: Nach drei Tagen kann ich alle meine bereits vorhanden Karten + zusätzlich heruntergeladene Karten nun optisch sehr ansprechend in 3D betrachten. Das, was die Firma MagicMaps bei ihren 3D-Karten verspricht und leider auf sehr keleine Ausschnitte beschränkt ist nunmehr mit Tips aus diesem Thread ohne Probleme möglich. Also: Nur Mut!


    niko

    Zitat

    Original von niko75
    abdeldjfk


    Einen kleinen Wehmutstropfen hat die Sache jedoch: Mit GlobalMapper konnte ich rießige tif's (1Karte 60x60km mit ~1,5GB!!!) in 3D super handeln. Selbst die 3D Grafikleistung war noch sehr beeindruckend. GlobalMapper schein daher sehr geschickt mit den Systemrecourcen umzugehen. In Ozi3D komme ich hingegen schon bei Karten mit ~30x30km (im ozf2-Format ~30MB) an die (erträgliche) Leistungsgrenze meines Systems.


    niko


    Hallo Niko,


    Versuch mal mit GM built in ECW-Compressor *.tif in *.ecw zu transformieren.
    Oder mit dem Freeware EWC-Compressor von http://www.ermapper.com/downloads/....


    Hat eine max.-Obergrenze von 500 MB Speicherbedarf im RAM - nicht Filegrösse.
    Das Format .ecw ist resourcensparender. Macht Sinn bei großen Satkarten, da der Freeware Compressor immer mit 24-bit Farbtiefe rechnet.
    Vielleicht hilfts auch im Ozi.


    ciao - Hans

    Jetzt hab ich doch ne Frage:


    Die original srmt gibts ja hier:
    ftp://e0mss21u.ecs.nasa.gov/srtm/


    Und die gepatchten/korrigierten srmt hier:
    http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp


    Ich hab jetzt den gesamten Thread nochmal durchsucht, aber nichts mehr darüber gefunden, was (außer des abgedeckten Bereichs der Einzeldateien) der Unterschied der beiden ist. Was wurde korrigiert? Was gepatcht? Ich meine, irgendwo gelesen zu haben, daß bei den gepatchten die Leerräume (zu. im Meer/Ozean) auch mit abgedeckt sind.


    Ich frage aus einem speziellen Grund: Die korrigierten SRMT-Dateien (2. Link) erzeugen unter GM einwandfreie 3D und 2D Karten. Die original SRMT-Dateien haben teilweise Lücken/Löcher. Im Flachen Gelände nur ganz selten, um so stärker das Gelände profiliert ist (Alpen), um so heftiger werden die Fehler! Ist das eventuell der Grund für die herausgebrachten korrigierten SRMT's? Wie geht ihr mit den Fehlern um? (In Ozi3d treten sie natürlich auch auf. Es liegt scheinbar daran, daß diese Bereich/Punkte nicht vermessen wurden...?)


    Niko


    Anbei ein Bildauschnitt der original-SRMT mit Globalmapper in 2d und 3d mit der angedeuteten Fehlern/Löchern:

    McQool


    Ups, das haben wir wohl eben zeitgleich gepostet...!!


    Mit den tif's liegt ein mißverständnis vor! Die Monster-tif's mit 1500MB sind ja gerade nicht das Problem! Die werden von GlobalMapper super schnell geladen und auch in GM-3D 3d schnell behandelt. Aber ich habe von diesen tifs nur noch eine hand voll (6 Stück!)


    Von den ozf's vom OziExplorer habe ich zwischenzeitlich ganz Süd- und Mitteldeutschland und Teile Kroatien (also >200). Deshalb "muß" ich mit den ozf's arbeiten. Und eigentlich ist das ozf2 ein sehr sparsames Format. Immerhin wird eine 60x60km Karte (welche als tif noch eine größe von 1500MB hatte) beim umwandeln durch Farbreduzierung etc. auf eine Größe von ~60-100MB verkleinert. Und wenn ich mit genau diesen "kleinen" ozf2's und Ozi3D dann im 3D Modus arbeite ist der rechner extrem langsam.


    Wie gesagt: Die tifs sind nicht das performande problem. Es scheint mir eher bei Ozi3D zu liegen. Bzw. ist GM sehr clever programiert...:-).


    Aber ich denke, daß ich eben damit leben muß. Dann denkt man eben ein bißchen mehr, wenn man diese 3D-Funktionen benutzt.


    Niko

    Zitat

    Original von niko75
    ..... Und eigentlich ist das ozf2 ein sehr sparsames Format. Immerhin wird eine 60x60km Karte (welche als tif noch eine größe von 1500MB hatte) beim umwandeln durch Farbreduzierung etc. auf eine Größe von ~60-100MB verkleinert. Und wenn ich mit genau diesen "kleinen" ozf2's und Ozi3D dann im 3D Modus arbeite ist der rechner extrem langsam.


    Wie gesagt: Die tifs sind nicht das performande problem. Es scheint mir eher bei Ozi3D zu liegen. Bzw. ist GM sehr clever programiert...:-).
    Niko


    Hallo Niko,


    ozf2 ist, wie Du schon sagst, ein hochkomprimiertes Format, optimiert für den Einsatz im OziCE. Es ist durchaus denkbar, daß Ozi3D deshalb damit nicht so performant umgehen kann.


    Trotzdem hat ich das Format ozf2 aus meiner Sicht ein paar Vorzüge:


    Daß Oziexplorer_PC dieses Format ozf2 - auch - lesen kann ist nicht selbstverständlich - siehe TTQV und Fugawi , die können die Formate ihrer PPC-Clients Pathaway und FugPPC eben nicht lesen.
    Einen unschätzbaren Vorteil von ozf2 sehe ich auch darin, daß die Oziexplorer-Vollversion 0zf2 in png etc. rücktransformieren kann, natürlich unter Verlust der Kalibrierung - aber die Kartenbilddatei bleibt erhalten und kann weiterverarbeitet werden in anderen Programmen. ozf3 kann das nicht mehr und ist damit ebenso ein Einbahn-Sackgassen-Format wie *.prc & Co.
    Für Leute, die dieselben (unverschlüsselten) Karten möglich universell in verschiedenen Programmen einsetzen wollen sind nach wie vor am brauchbarsten die Kartenformate [Bilddatei (png,jpg,tif,ecw,..) + Kalibrierungsdatei ( map,cal, prj ...) ] neben BSB,kap.


    ad Performance-Vergleich
    GM hat aber seinen 3D-Viewer in den letzten beiden Versionen 6.08 und 6.09 verbessert und beschleunigt. GM kann aber ozf2 ja nicht lesen, deswegen ist dieser Vergleich nicht möglich. Für einen Performance-Vergleich der 3D-Viewer von GM und Ozi wäre dasselbe Format, das beide lesen können, wie tif,ecw,png besser.


    ciao - Hans

    Danke für die ausführliche Erklärung. Mit ozf2 bin ich auch sehr zufrieden! Ich wüßte gar nicht, wo ich die Daten im original tif-format speichern sollte. Ich hab zwar schon 400GB-HHD-Platz, aber der würde wohl nicht reichen. Deshalb bin ich komplett zu ozf2 übergegangen...


    So nen performancevergleich mit identischen Daten (ne tiff in Ozi3D und im GM-3D laden) werd' ich bei Gelegenheit durchführen und mal berichten.


    Fällt diir zu den Löchern in den unkorrigierten SMRT's etwas ein?


    niko


    PS: Die größten Probleme sind ja bereits gelöst. Alles was jetzt noch kommt sind peanuts...

    Zitat

    Original von niko75
    Fällt diir zu den Löchern in den unkorrigierten SMRT's etwas ein?


    Hallo niko,


    da bist du bei mir richtig ;)


    lies mal meine Seite http://mac-im-netz.de/dateien/maps.html und die ausführlichere Anleitung von Emil: http://www.blauesboot.de/MapEditManual/howto108.htm


    Grüsse - Anton


    PS: für den Hausgebrauch habe ich ganz Süddeutschland und die Alpen bis Venedig von Hand ausgebessert. Falls du (oder andere) an den korrigierten HGT-Dateien Interesse hast, stelle ich sie soeben wieder für ein paar Tage online :)

    Einmal editiert, zuletzt von macnetz ()

    Hi Anton, du scheinst also genau die Lösung meines Problems zu kennen und zu haben... Klasse!


    Aber: Ich seh' den Wald vor lauter Bäumen nicht: Ich hab bei den angegebenen Links nirgend ne Downloadmöglichkeit für die von mir benötigten .hgt Dateien gesehen. Wo muß ich nachsehen???


    Süddeutschland über A bis I bzw HR wollte ich damit abdecken. Das trifft sich mit deinem Angebot sehr gut :-).


    niko

    Hallo niko,


    die Bäume im Wald sind hier versteckt: ;)

    Zitat

    Alpentransit
    E5
    Erste Versuche am 11.08 2004; 3DEM-Bild der SRTM-Daten (N45E010,N45E011,N45E012,N46E010,N46E011,N46E012) - bearbeitet

    und hier:

    Zitat

    Süddeutschland
    3DEM-Bild der SRTM-Daten (N47E009,N47E010,N47E011,N47E012,N48E009,N48E010,N48E011,N48E012) - bearbeitet


    die HGT-Dateien sind mit Links abrufbar, z.B. bei "N45E010", wobei im Bereich Süddeutschland nur N48E010, N48E011 und N48E012 als gezippte HGT-Dateien auf dem Server liegen.


    Grüsse - Anton

    Hallo Heiko und alle anderen!



    Ich habe gerade mal diesen - sehr interessanten - Thread diagonal überflogen. Wenn Du schreibst, dass die ESRI-Flussläufe gegenüber dem Raster systematisch verschoben sind, so erinnert mich das an das altbekannte Problem, das auftritt, wenn beide Karten mit verschiedenen Kartendaten georeferenziert wurden. ESRI schreibt zu seinen Daten (http://www.esri.com/data/download/basemap/), dass das Kartendatum NAD 83 verwendet wird. Habt Ihr das berücksichtigt? Liegt die Rasterkarte vielleicht in WGS84 vor?


    Viele Grüße
    Werner

    Hi Delago,


    danke für deine Antwort.
    Die verschiedenen Kartendaten habe ich schon durchprobiert. Die Unterschiede in den gezeichneten Vektoren sind einiges größer als die Unterschiede der Kartendaten WGS84 / NAD83. (Oder ich hab beim Ausprobieren wieder auf die falschen Knöpfe gedrückt... ?( )
    Die ESRI-Vektordaten sind wohl doch nur sehr grob erfasst worden und für genaue Navigation nicht brauchbar. Schade.


    Gruss
    Heiko J.