Das liefert das gleiche wie mit xy.gif. Das wird auch gar nicht erst in die Kartensammlung übernommen - weder in eine neue noch in eine bestehende.
Dieses F1 F6 ist mir eh suspekt, weil da dann steht "Erzeuge Kartensammlung aus Geotiff" Das sind aber keine Geotiffs.
Was ich in Erinnerung habe, kann gdal eine map+ozfx öffnen. Man muß dann die *.map angeben und die ozfx muß in der map eingetragen sein. Weiters kann gdal gif+map oder jpg+map öffnen, dann muß man aber die *.gif angeben und die *.map muß den gleichen Namen haben. Das liegt daran, daß das von verschiedenen Leuten völlig unkoordiniert da reingehackt wurde. tif+map geht merkwürdigerweise nicht.
Ich hab jetzt mal folgendes ausprobiert: gif+map (russische Genstabkarte) mit gleichem Namen: gdalinfo xy.gif liefert was vernünftiges. gdalinfo xy.map liefert not supported file format. QLandkarte Karte laden xy.gif liefert "keine Georefernzinformationen gefunden"
F1 F6 hinzufügen xy.gif liefert "Laden der Datei xy.gif fehlgeschlagen"
Nachtrag: für map+ozfx wurde ein eigener Treiber geschrieben, das ist also die "ordentliche" Variante, und nachdem sie von Des Newman die Erlaubnis bekommen haben, die Ozi Datumsdefinitionen zu verwenden, wird das wohl da eingebaut werden.
Für gif+map wurde einfach nur der gif Treiber gehackt und deshalb funktioniert das wohl nur mit einigen ausgewählten Datums und Projektionen und wird vermutlich nicht weiter ausgebaut werden.
Hallo,
GDAL kann ja Ozi map Dateien in gewissen Grenzen lesen. Ich schaffe es aber nicht, sowas in QLandkarte zu laden, weder direkt noch über F1, F6. Wird das geblockt oder wie muß man da vorgehen?
Hallo,
ich hab hier eine Unmenge von png Kacheln. Zu jeder Kachel gehört eine gmw Datei, die die Kalibrierung enthält. Diese kann ich auch öffnen und das dann in einen Map Catalog verschieben. Wenn ich jedoch versuche, die gmw direkt einem Map Catalog hinzuzufügen, dann kommt immer die Fehlermeldung: "Unable to add any maps to the map catalog".
Überseh ich da irgendwas oder geht das tatsächlich nicht?
Hallo,
gibt es eine einfache Möglichkeit, die Rectifiction Method Polynomial bei vielen Karten mit einem Mal auszuwählen? Ich finde das nur im Image Rectifier und der kann immer nur 1 Karte bearbeiten.
Ich hab noch etwas nachgeforscht:
Offenbar werden noch nicht alle Ozi Datums richtig behandelt. Dafür gibts aber schon einen Request
Der Befehl
gdal_translate xxx.gif yyy.tifliefert ein Geotiff, wenn ein xxx.map vorhanden ist. Diese Variante gibt es scheints schon länger und wurde wohl irgendwie undokumentiert "eingeschmuggelt". xxx.tif ist aber auch hier nicht zulässig 
Dann gibt es noch ein Python Skript ozi2gdal.py das die .MAP in eine .VRT umwandelt, mit der GDAL dann korrekt umgehen können soll.
Quelle
Weiteres gibts noch hier:
http://talk.maemo.org/showthread.php?t=57469
Insbesondere noch einen weiteren Python-Ozikonverter: ozf-decoder.py
ZitatA particular feature of it that it's capable converting of really big files -- up to ozf limits. The TIFFs created in a tiled format.
Teilerfolg:
gdal_translate xxx.map yyy.tif
führt tatsächlich zu etwas, was sich wie ein Geotiff anfühlt. In der 3.Zeile der xxx.map muß die ozf Datei stehen. Alle Versuche, dort dem eine tiff Datei unterzujubeln, sind aber leider fehlgeschlagen 
Es kommt immer ERROR 4: "xxx.map" not recognized as a supported file format.
Das Setzen der Pfade mit dem Batchfile in dem Programmpaket hat übrigens nicht funktioniert; ich hab daher alles in einen Ordner kopiert. Das ist also nicht richtig installiert.
Hallo,
ich hab hier einige Karten im ozf Format, bei denen GlobalMapper 24 bit Farbtiefe anzeigt, OziMapTrans aber nur 8 bit. Nach der Konversion auf 8 bit kann ich in einigen wenigen Fällen auch tatsächlich feststellen, daß OziMapTrans das bessere Resultat abliefert.
Kann man irgendwie zuverlässig feststellen, welche Farbtiefe eine ozf Datei hat?
Die FWTools Shell meldet sich bei mir mit 2.4.7 und das ist die aktuelle Version für Windows. Das liegt allerdings schon länger bei mir auf der Platte, die GDAL Files datieren so Jan 2010. Wann nun 1.8 rauskam, konnte ich auch nicht rausfinden. Das ist alles ziemlich unübersichtlich...
ah, das ist ja schonmal was. Dann versteht also GDAL eine *.map Datei. Fragt sich nur, wie man das in den obigen gdal_translate Befehl reinwurschtelt. Reicht es, daß es zu der huge.tif eine huge.map gibt? Oder muß man die huge.map extra spezifizieren? Aus der Dokumentation http://www.gdal.org/gdal_translate.html werde ich nicht schlau.
Ich hab hier die neuesten fwtools, die enthalten offenbar aber nur GDAL 1.6 und wie ich 1.8 auf meinen (Windows) Rechner kriege, hab ich jetzt auf die Schnelle auch nicht rausfinden können.
Nachtrag: Könnte man schreiben:
gdal_translate -co tiled=yes -co compress=lzw huge.map hugetiled.tif
und hätte dann ein kalibriertes GeoTIFF hugetiled.tif ?
Kann man mit den FWTools eine Kalibrierung in eine TIFF Datei schreiben, ohne die Bilddatei selbst anzutasten?
Mich schrecken Kommandozeilen eigentlich nicht, ich hab die FWTools auch auf meinem Rechner, bin aber immer wieder daran gescheitert, für eine bestimmte Anwendung eine Lösung in der Dokumentation zu finden. Insofern finde ich konkrete Beispiele wie das vom joe nur begrüßenswert.
Schade! Und für das neue Intermap Angebot brauchts auch ein Passwort.
Hat schon jemand unter Online Data Source das Map Mart on Demand ausprobiert? Bei mir hat das erstmal ein Riesenpaket .NET Framework 4 Client Profile installiert, was aber nichts genützt hat, weil ich gar kein Framework 4 habe. Bevor ich das jetzt auch noch installiere:
was bietet Map Mart da? Brauch ich dafür einen kostenpflichtigen Zugang?
Wenn jedes Blatt nur 256 Farben hätte, aber alle 150 Blätter unterschiedlich sind, dann hast du im kombinierten Bild doch wieder 256 * 150 = 38400 Farben, die dann wieder reduziert werden müssen. Ich würde die jpgs mal in einem Bildverarbeitungsprogramm durch eine automatische Farbkorrektur laufen lassen, in der Hoffnung daß sich die Farben dann etwas angleichen.
Aber wäre es nicht einfacher, es bei 24 bit Farben zu belassen?
Hallo Paul,
standardmäßig verwendet GM glaub ich Packbits Kompression. Das ist nicht so ideal. Besser ist LZW und noch ein bischen besser Deflate. Wenn die Quellkarten jpgs sind, dann könntest du sogar JPEG Kompression mit 24 bit Farben in Erwägung ziehen. Die Reduktion auf 8 bit kann je nach Ausgangmaterial auch schlechte Resultate bringen, zB wenn eine starke Schummerung in der Karte ist. Allerdings muß man bei den "besseren" Kompressionsmethoden damit rechnen, daß die nicht gelesen werden können, zB der Oziexplorer scheint da recht eingeschränkt zu sein.
Ich hab allerdings auch schon beobachtet, daß der GM nicht exakt das Eingangsmaterial wiedergibt, wenn man nur Ausschnitte ausgibt. Hier ein Beispiel:
http://www.naviboard.de/vb/showpost.php?p=374956&postcount=2
Hallo Gerd,
dein Beispiel verstehe ich nicht. Im linken Bild sind die Pixel klar zu sehen, im rechten sind sie weichgespült. Rasterbilder bestehen aber immer aus Pixel. Das rechte Bild sieht so aus, als ob die Auflösung erhöht und bikubisch interpoliert wurde, oder nicht?
@Anton: es kommt auf die Kompression der ECW an. Bei Targetkompression << 10 rentiert sich die Umwandlung. Im vorliegenden Fall ists aber noch banaler, ich wollte die Karte in einen Ost- und einen Westteil aufspalten, deshalb auch die Grenze; sonst wäre ich wahrscheinlich garnicht drauf gekommen.
Ich hab mal die GM12 beta 2 getestet und ein ECW in gekacheltes GEOTIFF mit 8bit Palette und LZW umgewandelt. Mir ging es dabei mehr um Originaltreue. Deswegen hab ich die UTM Projektion beibehalten. Resampling ist Nearest Neighbor. Das Ergebnis finde ich aber enttäuschend (siehe Bild). Links das original ECW ist deutlich schärfer als das TIFF rechts. Sollten nicht beide identisch aussehen? Was läuft da schief?
Beim Export habe ich eine Grenze im Westen gesetzt. Kann das die Ursache sein, wenn die Grenze nicht genau auf die Pixel justiert ist? Sollte doch bei "Nearest Neighbor" nicht sein?
Nachtrag: Das sample spacing in X und Y Richtung ist auf 15 Stellen gleich. Daran kann es also auch nicht liegen.
Hallo Gerd,
schade um die Bayos; auf Memory Map bin ich wegen der offiziellen Hinweise gekommen:
http://www.ttqv.com/wissensbasis/karten/
ZitatDie Standard - Version von Touratech QV beherrscht zusätzlich viele Karten von Fremdherstellern. Dazu gehören:
...
Die Memory-Map-Produktpalette (nur unverschlüsselte Version bis V5.5, nur bis TTQV 4)
...
Aber schlafende Hunde soll man nicht wecken ... 
Hallo,
hab die Neuigkeiten mal kurz überflogen. Die Unterstützung sowohl von Bayo also auch Memory Map Karten wurde aufgegeben. Stimmt das so? Das wäre ja ein Jammer.
Hallo gpsfix,
ad1: hast du vielleicht so ein hypermodernes Betriebssystem? Ich finde unter XP die Cache Dateien problemlos, wenn ich zB nach großen Dateien suche. Alternativ kannst du auch in der Registry nach Google Earth suchen; dort steht der CachePath.
ad2: GE legt den Cache selbst an, wenn es keinen findet. Müßte also schon sehr schräg zugehen, wenn es den selbst angelegten Cache nicht findet. Ich hatte solche Probleme bisher nicht, hab aber mal gelesen, daß man am Ende der Sitzung einmal ganz rein und dann ganz rauszoomen soll. Die Weltkugel muß ja im Cache enthalten sein, sonst gehts nicht.
Die Caches sollen auch korrumpieren. Also vielleicht mal den alten Cache komplett löschen und mit einem frischen von vorn anfangen.
ad3: die Kopien liegen bei mir im gleichen Verzeichnis wie der originale Cache.
Ich hab die Geschichte übrigens bisher nur selten verwendet, da die Navigation nur beschränkte Zeit funktioniert. Irgendwann hört GE einfach auf, dem GPS zu folgen. Dann ist Neustart erforderlich.