Übrigens: warum wird eigentlich der EPSG-Code 3785 benutzt? Laut http://www.epsg-registry.org/ gehört dieser Code zur Region 'New Zealand - South Island - Marlborough meridional circuit area'. Das ist ja nicht gerade Mitteleuropa oder auch nur Nordhalbkugel... Sicher eine theoretische Frage, denn offensichtlich funktioniert die tool chain ja, aber interessant wär's schon.
Gute Frage. Meines Wissens ist es "Popular Visualisation CRS / Mercator"
http://spatialreference.org/ref/epsg/3785/
Oliver
Was für unseren Fall eher passen könnte, wäre Folgendes: kann gdal_translate ein referenziertes geotif zuschneiden, ohne dass die Referenzierung verloren geht bzw. ungültig wird? Dann könnte ich die geotif einfach kleiner schneiden, es würde dann zwar ein kleiner Sicherheitsrand stehen bleiben, aber das wäre schon mal wesentlich besser. Ist es das, was Du mit Deinem Hinweisauf gdal_translate meinst?
Exakt so ist es. Das kannst Du "händisch" machen, indem du den verwertbaren Ausschintt der Karte nicht als Custom Map sondern für QLandkarte M exportierst. Dabei siehst Du die nötige GDAL Befehlssequenz. Das Gleiche kann man natürlich auch über Skript machen.
Übrigens: wo finde ich eine Art Bedienungsanleitung für die gdal-Programme? In http://www.gdal.org/gdal_utilities.html sind zwar die Aufrufe der Programme und einige Parameter kurz beschrieben, aber es ist schwer, damit herauszufinden, was man wo einstellen muss bzw. kann, damit ein Programm das Gewünschte auch tut.
Das ist die Bedienungsanleitung 
Und für Linux ist die extensiv. Aber im Ernst: Die Optionen sind simpel zu verstehen. Allein der Ausdruck für die Projektion ist eine Wissenschaft für sich. Da aber die Dateien schon mit "-t_srs EPSG:3785" auf die nötige Ziel Projektion gebracht sind ist das kein Problem.
Übrigens zum Gitter und den Referenzpunkten, die Abweichung sollte ok sein. Das Gitter hat ein anderes Kartendatum als WGS84. Dadurch entsteht ein Offset. Das ist auch so ein kniffeliges Thema. Da aber anzunehmen ist, dass in der *map Datei alles richtig gemacht wurde, sollte GDAL alles weiter auch richtig machen. Dennoch empfehle ich, die resultierende Karte immer mit bekannten Tracks und Punkten zu verifizieren.
Oliver
Bitte bedenken, dass das Gerät noch einige Softwaremacken hat. Die Gröbsten, wie z.B. das sporadische Abstürzen der Firmware, werden sicherlich im Laufe der Jahre behoben. Die weniger groben, wie zum Teil selten dämliche Bedienkonzepte, werden wohl eher bleiben. Also etwas Geduld mitbringen. Für ein Outdoorgerät, das vor allem im alpinen Gelände Einsatz findet, sehe ich jedoch bei Garmin wenig Alternativen. Und bei anderen Herstellern ist ein hohes Maß an Technikbegeisterung mitzubringen. Insofern ist das 62er schon richtig.
1. kann ich eine micro SD Karte vom Media Markt ect. verwenden oder geht nur eine spezielle Karte von Garmin wegen Freischaltung?
Handelsübliche SD Karte ist ok
2. Ich habe bereits Mapsource mit installierter OSM Wanderkarte. Kann ich damit Karten auf die SD Karte bringen und werden die vom Gerät erkannt?
Sollte gehen. Ich benutze MS nicht. Von den OSM Karten gibt es auch fertige gmapsupp.img Dateien. Einfach auf die SD Karte kopieren. Fertig.
3. Kann ich fertige Routen (GMX) oder Tracks damit aufs Gerät bringen. Der Unterschied ist mir auch noch nicht ganz klar.
Ja. Das ist auch der einzige Weg. Das Gerät wird als USB Massenspeicher erkannt. GPX einfach in das gleichnamige Verzeichnis kopieren. Fertig.
4. Kann ich dann schon damit wandern oder biken oder muss ich eine Topokarte von Garmin kaufen? Ich werde erstmal mit Routen aus dem Internet anfangen
Wäre ja noch schöner, wenn man erst mal noch ne Karte von Garmin kaufen müsste. Es geht auch komplett ohne Karte. Macht dann aber weniger Spaß. Mit der OSM Karte anfangen ist eine gute Idee. Und wenn Du irgendwann der Meinung bist, die Garmin Topo ist besser, dann kannst Du sie immer noch kaufen.
HTH
Oliver
erst einmal vielen Dank für die sehr prompte Umsetzung des patches! Die Erzeugung der Custom Maps funktioniert jetzt. Damit ist die tool chain wieder ein wichtiges Stück weiter. Da ich hier auf meinem Schreibtisch kein Garmin habe, das custom maps beherrscht, muss ich jetzt die erzeugten .kmz files erst mal hohbrugg schicken, damit er sie in sein Gerät laden kann. Ich werd' ihm dann noch ein paar Wegpunkte als .gpx mitschicken, dann können wir gleich sehen, ob die Punkte an der richtigen Stelle auf der Karte liegen. Das wird wahrscheinlich im Lauf des Wochenendes laufen, ich werde Euch auf alle Fälle Rückmeldung geben. Wenn das alles klappt, müsste ich dann nur noch ein script file erstellen, damit wir den Kartenstapel von hohbrugg dann gut verarbeitet bekommen (und vor allem keine Tipfehler die Konvertierung stören...). Aber das ist vertrautes Gebiet.
Ah, ich sehe schon. hohbrugg hat definitiv auf das richtige Pferd gesetzt 
Was sicherlich noch interessant wäre, wenn man die einzelnen Karten zu einer Großen zusammen fügt. Ich kenne jetzt eure Quelldateien nicht, aber poehalis hat immer diesen lästigen Rand. Wenn man den weg lässt und die Karten sich dann noch überschneiden, dann kann man mit:
gdalwarp file1.tif file2.tif (usw.) file_out.tif
alle zusammenfügen. Den Rand entfernen kannst Du entweder in QLGT mit "Karte exportieren -> QLandkarte M" machen (öde) oder, wenn der Rand immer gleich dick ist, mit gdal_translate und einem Skript.
Was die verzerrte Karte angeht: ich habe noch einmal versucht, die .gif Karte zu laden und zu referenzieren, aber es ist mir nicht mehr gelungen, eine verzerrte geotiff Karte zu erzeugen. Daher vermute ich stark, dass ich wohl bei den Einstellungen für die Referenzierung irgendwo was Falsches oder Unpassendes ausgewählt oder eingegeben habe, was ich jetzt nicht mehr rekonstruiert bekomme. Die beim ersten Versuch entstandene geotiff Karte ist dann wohl nicht nur verzerrt, sondern dürfte auch in der Referenzierung korrupte Daten enthalten, die dann in der Folge QLandkarteGT daran hindern, die Karte in eine Kartensammlung einzubauen. Man sollte halt Experimente immer verifizieren, bevor man darüber berichtet...
Ein Zahlendreher bei der Koordinateneingabe ist schnell gemacht und führt zu den tollsten Ergebnissen. Gar nicht zu lange darüber nachdenken. Es lohnt nicht.
Grüße
Oliver
Schaut Euch mal die letzten 3 Screenshots (unten) an.
Ich dachte es gäbe nur "Achttausender"....
Duck und wech
Hach was! Gegen den Bayerischen Wald sind die doch kalter Kaffee.
http://www.bayerischer-wald-verein.de/12-Tausender/
Und pssst.... sag 's keinem weiter.... auf jedem liegt ein Geocache. 
Huiiii!!!
Qlandkarte braucht GeoTiff
Qlandkarte GT stellt jedes von GDAL unterstützte Format dar.
Qlandkarte GT stellt auch JNX dar.
So viel Zeit muss sein
Hallo Thomas,
es schaut so aus als hätten Oliver und ich das Problem bei der Erstellung der GPX Dateien unter WinXP gefunden.
Heißt natürlich: "Erstellung der Custom Maps.". Es war schon spät :D:D
- Changed default name of BirdsEye Imagery created from other user data to reflect name of selected item.
Klingt ja spannend. Weiß jemand was das genau bedeutet?
ich werde mir die Ausgabe beim Exportieren noch mal genauer anschauen, vielleicht kann ich da was erkennen. Ich werde es auch mit der Ausgabe beim Export für QLandkarte vergleichen.
Ich wette noch immer auf einen anderen Bug. Wir werden es hoffentlich morgen Abend herausfinden 
Was die verzerrte Karte angeht:
- Die Karte hat ein aufgedrucktes Gitter in UTM/WGS84, dessen Gitterpunkte habe für die Referenzierung genutzt. Es ist nur ein kleiner Ausschnitt, etwa 2km x 2km.
- wie ich heute festgestellt habe, habe ich nicht ein unreferenzierte *.tif geladen, sondern ein *.gif (das hat das 'Karte laden'-Interface problemlos genommen, deswegen hatte ich es erst nicht bemerkt)
- heute hab' ich mit einem Photoeditor von der Karte ein *.tif gemacht und dann dieses geladen und referenziert. Ergebnis: die Karte ist jetzt beim Einzel-Laden unverzerrt und lagerichtig, und ich kann das referenzierte *.tif jetzt auch in eine *.qmap einbauen, die Karte wird auch hier richtig angezeigt.
*gif als Input sollte aber auch ok sein. Das Ergebnis wird immer ein *tif sein
Vordergründig ist das Problem damit gelöst (wenn man *.tif Karten nimmt), ich schicke Dir bei Interesse aber gerne Files zum Analysieren, ich müsste dann wissen, welche(n) File(s) Du brauchst. Kann ich die einfach zippen und als Anhang hier im thread laden oder müsste ich die an anderer Stelle hochladen?
Kommt auf die Größe an. Entweder als private Mail oder über einen der vielen Share&Download Dienste. An für sich bräuchte ich die Eingangsdatei (*gif) und als Vergleich das Ergebnis (*tif). qmap oder sonstiges ist nicht nötig.
Vielen Dank für die Hinweise, ich komme voran...
Sehr gut. Ich freue mich immer, wenn sich jemand konstruktiv zu helfen weiß. Da hilft man gerne weiter.
Ich benutze die deutsche Version von WinXP. Ich habe FWTools noch mal neu nach c:\programme\FWTools2.4.7 installiert, und jetzt funktioniert der export von Karten aus QLandkarteGT. Und jetzt bin ich bei dem Problem, dass Oliver am Ende seines letzten Beitrags beschreibt: die KMZ-Dateien werden angelegt, sind aber leer. Wenn ich Oliver richtig verstehe, fehlt dem Programm offenbar ein temporäres(?) Verzeichnis. Kann man das von Hand anlegen und dem Programm damit auf die Sprünge helfen?
Ich bin mir nicht sicher ob das das Problem ist, weil dann der Export für QLandkarte M auch nicht funktionieren dürfte. Aber schau doch mal auf die Ausgabe beim Exportieren. Dort werden die Kommandos so angezeigt wie sie auch ausgeführt werden. Das muss von den Pfaden her alles stimmen.
Eine andere Vermutung wäre, dass die Zip Bibliothek unter Windows bockt. Helmut und ich haben für morgen eine Debugsession geplant. Ich hoffe es wird was, dann sollten wir mehr wissen.
Ich habe ein scan von einem Stück Landkarte genommen, im Fenster 'Karte'->'Karte erzeugen' geladen, dann 4 Referenzpunkte eingegeben und auf dem scan markiert, dann die Karte als geotiff gespeichert. Wenn ich jetzt die Karte über 'Datei'/'Karte laden' lade, wird sie verzerrt dargestellt (x doppelt so breit wie y). Ein Track und einige Wegpunkte, die in diesem Gebiet liegen, werden auf der Karte aber korrekt eingezeichnet.
Ich vermute, dass die Zielprojektion lonlat/WGS84 war, oder? Bei dieser Projektion werden die Koordinaten in Grad einfach in ein kartesisches Koordinatensystem eingetragen. Da es in der Longitude 360° gibt und in der Latitude nur 180°, die Erde aber eine Kugel ist und die Strecken in Meter damit gleich lang sind kommt es zur Verzerrung.
Ich würde empfehlen, vor allem in Hinblick auf die spätere Benutzung als Custom Map, als Zielprojektion eine Merkator zu benutzen. Das Datum darf ruhig WGS84 bleiben.
Wenn ich das geotiff über 'Karte'/'Karte erzeugen' lade und jetzt versuche, daraus eine kleine Sammlung (.qmap) zu bauen, kann das Programm die Karte nicht anzeigen. In der Zusammenfassung am unteren Rand des Fensters steht für die Postion der Karte N0°0 E178°30, was absolut nicht stimmt. Habt Ihr eine Idee, was da los ist bzw. was ich falsch gemacht haben könnte?
Das ist komisch. Kann ich die Datei irgendwo herunterladen, um sie mir mal anzusehen?
Grüße
Oliver
Sehr schön, dass ihr es soweit geschafft habt.
Zu den Problemen:
Habt ihr die FWTools im vorgeschlagenen Pfad installiert oder einem eigenen? Ich hatte eine ähnliche Meldung vor ein paar Tagen. Da ging es um den Unterschied von "Programme" und "Program Files". Ich habe Helmut, den Fachmann für Windows, schon auf diesen Thread angesetzt. Mal sehen was er meint. Hast Du auch schon mal geprüft, ob die Umgebungsvariable PATH auch auf das GDAL Verzeichnis zeigt?
Zum Übertragen auf das Gerät: Treiber oder ähnliches ist nicht nötig. Das Gerät einfach als Massenspeicher einbinden und beim Export den Ausgabepfad auf das richtige Verzeichnis (CustomMaps) setzen. Ähnliches gilt für Wegpunkte und Co. Mit Datei->Daten exportieren das GPX im entsprechenden Ordner ablegen.
Es gibt aber noch ein weiteres Problem beim exportieren als Garmin Custom Map. Das habt ihr nur noch nicht bemerkt. Im Moment werden unter Windows leere KMZ Dateien angelegt. Das kommt daher, dass die Umgebungsvariablen $TMP bzw $TEMP zwar unter Windows gesetzt werden, das Verzeichnis aber noch lange nicht existiert. Aber auch da sind wir dran. Ich vermute Helmut wir die nächsten Tage mit einer gefixten Version ankommen. Bis dahin ist erst mal warten angesagt. Oder Linux installieren Da gehen diese Dinge alle, weil ich sie täglich brauche.
Grüße
Oliver
Hallo und vielen Dank für Eure Tips. Ihr habt mir sehr geholfen. Ich hatte schon befürchtet, dass es auch hier sinnvoller ist ein wenig mehr auszugeben. Momentan tendiere ich zu dem 78s, nachdem ich mich in einige Beschreibungen eingelesen habe. Mal sehen, wie ich das teure Spielzeug rechtfertige.
"Wer billig kauft, kauft zweimal" alte Baumarktregel
Rausgeschmissenes Geld ist es erst, wenn das Gerät in der Ecke verstaubt oder nach ein paar Touren irgendwo am Grund vom Fluss liegt.
Hallo Sportsfreund,
wenn der Preis für dich eine Rolle spielt, solltest du auch den Etrex Vista hcx
in Erwägung ziehen.
Bitte dabei bedenken, dass die alten Geräte keine Rasterkarten anzeigen können. Bei Bergtouren ein nicht zu vernachlässigender Vorteil der neueren Geräte.
Speziell beim Wassersport sollte man sich auch das 78er ansehen. Das schwimmt. Das 62/78 ohne "s" oder "st" halte ich für Geldverschwendung. Wenn der Geldbeutel drückt, dann das Dakota.
Und wenn man mehr Wert auf Offroad, Schlamm, Wasser und grelle Sonne legt lieber ein wenig mehr für Tasten und Display zahlen. Mit matschigen Fingern einen Touchscreen zu bedienen ist nicht so prickelnd.
ich habe jetzt einfach die Symbole aus dem obigen Link unter GPSr Setup genommen (die ich auch für den 60er hatte) und sie in den vorhandenen Ordner des 62er kopiert - sie werden aber nirgends angezeigt, schon gar nicht, wenn ich nen Wegpunkt mit "Mark" anlegen möchte...
Und hoffentlich auch umbenannt.
In der aktuellen SVN Version habe ich das Limit angehoben und benutze jetzt 64k Blöcke. Das wird die Benutzer von Uraltgeräten mit kleinem internen Speicher überhaupt nicht freuen, aber die Blockgröße optimal zu berechnen dauert länger als ein neues Gerät kostet.
Außerdem teste ich auch auf die Blockanzahl. Übersteigt die 2^16 wird abgebrochen. Keiner wartet gerne ewig, um dann festzustellen das es nix war.
Grüße
Oliver
Ein kleines Problem gibt es noch, wie ich gerade festgestellt habe: Karten über 2GB funktionieren noch nicht. Woran könnte das liegen?
Holla, stimmt ja.
2^15*2^16 = 2GB
Aber 4GB gehen auch! (?) Wenn Du QLandkarte selber kompilieren kannst, dann kannst Du das Limit anheben. In Datei CGarminExport.cpp Zeile 31. Die 6 gegen eine 7 austauschen.
Aber mal ehrlich: Braucht man solche Bolliden wirklich?
Grüße
Oliver
Gar Nichts!:D
Das Programm läuft wunderbar schnell, friert nicht mehr ein und das beste: Die Karte funktioniert!
Vielen, vielen Dank für die schnelle Hilfe!
Sehr schön
Aber auch wenn Du dafür nichts kannst, geht mir Ubuntu mit seiner Debianabhängigkeit ganz schön auf den Senkel. Ich habe ja nichts gegen eine gewisses konservatives Packetupdate. Man brauch nicht immer "latest of the greatest". Aber bei mir häufen sich die Ubuntu Anfragen und es ist immer die selbe olle Version, die schon seit langem durch ist. Wenn man dann noch bedenkt, dass Ubuntu für den Unbedarften sein soll, also jemanden, der sich nicht eben ein Programm selber kompiliert, ist das eine saudämliche Einstellung.
Da sind die Kollegen von OpenSuse echt weiter. QLandkarte GT ist dort nicht in der Kerndistribution dabei. Aber über OpenSuse.org gibt es immer recht zügig die aktuellen Versionen.
So, das musste mal raus. Bitte nicht persönlich nehmen. Das hat nur was mit Ubuntu zu tun, nicht mit Dir
Grüße
Oliver
