Beiträge von kiozen

Zitat von Cletus

wollte mich auch nochmal melden - es klappt!! Habe meine ersten 62 Kacheln auf dem Gerät und sie werden dort in einem gut brauchbaren Zoombereich angezeigt (wie ich das Letztere hinbekommen habe weiß ich allerdings selber nicht, das war wohl Zufall). Jedenfalls zeigt er Custom Maps nicht nur bei einer Zoomstufe an.
Und sooo schlecht ist die Lösung mit den 100 x 1024 Kacheln auch nicht ... mit meiner Top. Rasterkarte 1:50.000 komme ich beim Radeln recht weit und es sind mehr Feld- u. Waldwege drin als in der OpenMTBMap ... und das Kartenbild von so einer alten TK ist irgendwie immer noch eingängig. Die Bikerkollegen sind ganz blaß vor Neid ...

Mit 100 Kacheln ist schon was anzufangen, aber im BirdsEye Format würde halt die ganze Top50 auf das Gerät passen. Ohne KMZ Gefrickel. Technisch kein Problem. Allein durch DRM verbaut. Zum Trost: bei anderen Herstellern sieht es nicht besser aus. Für die Wahnsinnsleistung ein eigenes, proprietäres Format dem Kunden aufzunötigen, das in keiner Weise irgendeinen Vorteil gegenüber dem offenen GeoTiff bietet, darf der Kunde bei allen anderen Anbietern auch extra zahlen. So gesehen ist Garmin eine vedammt offene Plattform.

Zitat von Cletus

Herzlichen Dank an alle die geholfen haben, besonders kiozen!! THX

Gern geschehen <knicks/> Auch wenn Garmin Custom Maps unter Windows nicht als rühmliches Kapitel in die Geschichte von QLGT eingehn wird. Dafür habe ich zu viel geloost.

Hi Hohbrugg,

afaik dürfen nur 100 Kacheln insgesamt auf dem Gerät sein. SD Karte wechseln ist eine Lösung. Dein bestes Pferd kennt aber auch einen anderen Weg.

Grüße

Oliver

Hi Chris,

Zitat von VeloChris

Bei Basecamp funktioniert die Suche in der Karte sowohl bei Garmin-Karten wie bei OSM-Karten gut. Bei QLandkarte GT ist die entsprechende Funktion offenbar "in der Karte finden". Nur ist diese Funktion beim Aufruf nicht aktivierbar (angegraut). Kann mir jemand sagen, wie ich die zum Leben erwecke?

Der Dialog ist nur für Rasterkarten, um Symbole in einem bestimmten Gebiet zu finden.

QLGT benützt nicht die in den Vektorkarten abgespeicherten Seiteninformationen zum Suchen, sondern sie Onlinedienste Google oder OpenRouteService.

Zitat von VeloChris

Daneben funktioniert das Berechnen von Routen aufgrund von Wegpunkten nur über den Server von Google bzw. der Heidelberger Uni. Sonst gibt es nur direkte Verbindungen der Wegpunkte "durch die Luft''. Ist das so gewollt oder mache ich was falsch?

So ist es. Das Vorgehen hat Vor- und Nachteile. Auf den Routinginformationen der Karte zu arbeiten, hat den Vorteil, dass man es auch offline machen kann. Aber man braucht immer eine Vektorkarte mit dieser Information. Und abhängig von der Karte, fällt die Route auch anders aus. Zudem berechnet das Gerät die Route sowieso immer neu. Und dabei kommt u.U. was anderes heraus.

Deshalb benutzt QLGT Onlinedienste (im Moment nur ORS). Das funktioniert auf Raster- als auch auf Vektorkarten. Egal. Zudem bietet ORS weitaus mehr Konfigurationen an, als das mit Garminkarten geht. Aus meiner Sicht die bessere Lösung.

Grüße

Oliver

Zitat von Cletus

cool, das Ganze. Aber wie setze ich das jetzt um? Am besten abwarten und hoffen, daß Oliver QL dementsprechend ändert. Ich habe mich nämlich schon so richtig an QL gewöhnt ... oder kann ich gleich die Input-Rasterdatei, mit der ich QL zur Erstellung der KMZ füttere, dementsprechend aufbereiten? Das geht doch vielleicht auch ... womit öffnet ihr eigentlich die KMZ-Datei um reinzuschauen, was da für Rasterdaten drinne sind??

Ich hab was geändert und dem Helmut Bescheid gegeben, damit er eine neue Version macht. Wenn es pressiert kannst Du natürlich auch folgendes machen:

gdalwarp -t_srs "+proj=merc +datum=WGS84" -expand rgb infile.tif temp1.tif 


gdal_translate -co tiled=yes temp1.tif outfile.tif 


gdaladdo -r cubic --config COMPRESS_OVERVIEW JPEG outfile.tif 2 4 8 16

Wichtig ist hier das "-expand rgb". Oder auf Helmut warten.

KMZ sind einfache zip Dateien.

Grüße

Oliver

Nochmal alles getesten: Die aktuelle Testversion vom Helmut (Win XP, virtuelle Maschine) als auch die Linuxversion erstellen KMZ die von meinem 62s FW 2.92 (Beta) erkannt und angezeigt werden. Ich habe mit verschiedenen Karten getestet und auch ob es einen Unterschied zwischen internem Speicher und SD Karte gibt. Geht alles.

Da es im Moment 2 Threads zum selben Problem gibt wäre es gut nur bei einem weiter zu machen. Ich würde den hier vorziehen:

http://www.naviboard.de/vb/showthread.php?t=47390&page=3

Grüße

Oliver

Seltsam. Ich habe die Version vom Helmut ausprobiert:

http://www.qlandkarte.org/poehali_88.2845_49.6472_0.kmz
http://www.qlandkarte.org/poehali_88.2845_49.6472_1.kmz
http://www.qlandkarte.org/poehali_88.2845_49.6472_2.kmz
http://www.qlandkarte.org/poehali_88.2845_49.6472_3.kmz

Werden alle angezeigt. Ab "3km".

Grüße

Oliver

Hallo Uwe,

das ist wirklich ärgerlich. Es muss noch irgendeinen Unterschied zwischen Linux und Windows geben. Ich bleib mit dem Helmut dran.

Grüße

Oliver

Zitat von Cletus

Hallo Oliver,

danke nochmal für die Hilfe. Ich war wohl irgendwie mit Blindheit geschlagen, so schwer ist es ja echt nicht zu finden. Komme jetzt besser zurecht, da ich auch die Hilfe endlich (!) gefunden habe.
Eine Frage noch: ist es gestattet, die jeweils neuere Version über die alte drüber zu installieren oder sollte ich vorher deinstallieren?
Und beim Output eines bestimmten Gebietes verstehe ich es so: eine einzelne KMZ = für Google Earth, viele kleine KMZ = für Garmin?

Danke & Gruß, Uwe

Die Bedienung ist zugegeben etwas "anders" Ich bin kein Freund von 3 zeiligen Toolbars und ellenlangen verschachtelten Menüs und abstrusen Tastenkombinationen. Deshalb versucht QLGT zu erraten was der Benutzer gerade macht und bietet die weiteren Möglichkeiten unter F1 bis F10 an. Die Erfahrung zeigt, dass sich damit sehr gut arbeiten lässt. Viele Funktionen sind natürlich, wie auch bei anderen Programmen, in den Kontextmenüs (rechte Maus) versteckt. Die alle nochmal in der Menüleiste zu wiederholen, so wie das der Standard vorsieht, würde wieder zum Menüchaos führen. Deshalb habe ich darauf verzichtet. Letzten Endes muss man sich mit jedem GUI auseinandersetzten, um den Funktionsumfang zu kennen.

Das mit den KMZ hast Du richtig verstanden. Man müsste mal sehen, ob das Gerät auch mehrere Kacheln in einem KMZ frisst. das wäre besser als zig Dateien. Meine Motivation in Richtung Garmin Custom Maps ist jedoch gering. Ich finde die Lösung einfach nur beknackt.

Zu Installation: Sollte kein Problem sein. Mach ich auch immer so. Bei FWTools bin ich mir nicht ganz sicher. Das würde ich vorher deinstallieren. Wobei solange die Version sich nicht ändert würde ich es überspringen. Das selbe gilt für die Laufzeitbibliotheken von Microsoft.

Grüße

Oliver

Die Bugs krabbeln mal wieder schneller rein als raus:

http://www.naviboard.de/vb/sho…php?p=392817&postcount=43

Bitte für Garmin Custom Maps diese Version benutzen.

Zitat von thomas_rolf

Hallo Oliver!

Ich bin auf etwas gestoßen, was unser Problem mit dem Laden der Karten ins Garmin erklären könnte. Dazu zunächst ein log vom export einer kleinen Karte aus QLandkarteGT:

Code

gdal_translate.exe -srcwin 1655 724 1020 1020 C:/Dokumente und Einstellungen/Thomas/Eigene Dateien/QLandkarteGT/karten/federsee/federsee_ref.tif C:/DOKUME~1/Thomas/LOKALE~1/Temp/qt_temp.qH3480
Input file size is 3089, 3107
0...10...20...30...40...50...60...70...80...90...100 - done.


gdalwarp.exe -t_srs EPSG:3785 C:/DOKUME~1/Thomas/LOKALE~1/Temp/qt_temp.qH3480 C:/DOKUME~1/Thomas/LOKALE~1/Temp/qt_temp.hg3480.jpg
Creating output file that is 1027P x 1030L.
Processing input file C:/DOKUME~1/Thomas/LOKALE~1/Temp/qt_temp.qH3480.
Using internal nodata values (eg. 255) for image C:/DOKUME~1/Thomas/LOKALE~1/Temp/qt_temp.qH3480.
0...10...20...30...40...50...60...70...80...90...100 - done.


Daten komprimieren zu C:/Dokumente und Einstellungen/Thomas/Eigene Dateien/QLandkarteGT/GE/dummy_0.kmz
--- Beendet ---

Alles anzeigen

1. gdal_translate wird bei diesen Parametern einen tif-File mit der extension jpg erzeugen und keinen jpg-File. Dazu müsste '-of JPEG' oder so ähnlich angegeben sein.
2. warum wird hier eigentlich gdalwarp aufgerufen? Die Karte ist doch schon passend gezerrt, das wurde schon beim Erstellen der geotiffs erledigt (jedenfalls wenn man dort ebenfalls '-t_srs EPSG:3785' gesetzt hat).
3. bei dieser Transformation wird das Bild geringfügig größer. Garmin gibt als maximale Kachelgröße 1024x1024 pixel an, diese Größe wird hier knapp überschritten. Ob das auch zum Problem beiträgt, kann ich zur Zeit nicht sagen.

Das 'Heimtückische' an der Sache ist: GoogleEarth akzeptiert problemlos einen tif-File als Bild, der mit der Endung jpg daherkommt, da verhält es sich nicht anders als sehr viele Bildbetrachterprogramme. Erst als ich die Kachel mal zufällig mit IrfanView öffnete, hat das Programm gemeckert 'das ist ein tif mit falscher Endung'. Offenbar tritt dieselbe Nachlässigkeit in Garmins BaseCamp-Software auf, denn dieses Programm zeigt (nach hohbrugg) die Karte ebenfalls richtig an und lädt sie ins Garmin, das damit dann nichts mehr anfangen kann...

Gruß,
Thomas

Alles anzeigen

Sch...... ok, wir haben unsere Hausaufgaben schlecht gemacht. War wohl doch ein wenig spät und eine schlechte Idee sich auf Googleearth zu verlassen. Danke für die Analyse. Ich werde mir die Sache in den nächsten Tage in Ruhe ansehen. Das kann doch nicht so schwer sein

Grüße

Oliver

Hui! Perl. Da bekomme sogar ich es mit der Angst zu tun Zu viele Sonderzeichen verderben den Code. Ich bin mehr der Python-Mensch. Aber trotzdem klasse gemacht. Wenn Du auch noch die *bat Datei in Perl umwandelst, dann kann man die Sache unter allen OS verwenden. Wenn Du nichts dagegen hast, würde ich das Skript ins QLGT Wiki stellen. Dazu fehlt in der Datei aber noch der Urheber und die Lizenz.

Zu Skalierung: mit "-ts" Kann man das Ergebnis auf eine bestimmt Breite und Höhe festlegen.

Zitat von thomas_rolf

Uns bleibt jetzt noch ein letztes Problem zu lösen: hohbruck hat ein neues GPSmap62 von Garmin, er kann die Files auch in den richtigen Ordner im Gerät laden, er kann sie auch im Menupunkt '"Karte einrichten/ Karten-informationen Karte Wählen/Benutzer-definierte Karten/aktivieren" aktivieren (zumindest entsprechend markieren und die Aktion starten), aber er schafft es nicht, die Karte dann auch tatsächlich zu sehen. Irgend etwas klemmt da noch...
Hat einer von Euch eine Idee, oder gibt es einen anderen thread, der sich damit/mit solchen Themen beschäftigt?

Das passt schon hierher. Ich setzte mir immer einen Wegpunkt in die Mitte der Kachel, schalte alle anderen Karten aus und zoome dann auf den Wegpunkt. Je nach Auflösung erscheint die Karte früher oder später. Da das 62er die Karte auflistet, kann nicht so viel falsch sein.

Hast Du die Referenzierung der Karte auch mal überprüft? Dazu nimmt man am Besten die ---OSM--- Karte und setzt ein paar Wegpunkte. Noch besser ist es, wenn man Tracks und Wegpunkte hat, denen man vertrauen kann. Das erspart einem böse Überraschungen.

Grüße

Oliver

LOL, ich sehe gerade: 2.0km x 2.0 km = 4.2km2

Oh mei!!! Wo geht es hier bitte zum Runden

Zitat von Cletus

Muß aber zugeben, daß die Kurve inzwischen wohl unter die X-Achse gefallen ist:o, ich finde weder wie ich einen Bereich markiere noch wie ich etwas nach KMZ exportiere ... für solche zu exportierenden Bereiche einer Karte kenne ich alle möglichen Vokabeln (Fence, AOI, Selection Box ...) aber in QL finde ich nix dergleichen. Etwa eine Textbox? Die kenne ich nur um Text einzugeben. Egal, komme so nicht klar. Kann ich mich irgendwo einlesen? Hilfe und FAQ lädt er mir auch nicht, da ich keinen Feuerfuchs habe

Karte F1 -> Kartenausschitt wählen F5

Und dann beherzt mit der Maus und der linken Maustaste gedrückt ansetzen. Links im Kartenreiter entsteht ein Eintrag unter "Ausgewähte Karten". Diesen auswählen und "Karte exportieren" auswählen. Von da aus ist es selbsterklärend. Siehe auch Anhang.

Da Du eine Garmin Custom Maps erstellen willst bitte Version 1.1.0 verwenden. Sonst bekommst Du nur leere KMZ Dateien.

Grüße

Oliver

Zitat von macnetz

danke Oliver

jetzt weiss ich wieder warum ich nach DOS2.2 auf Macintosh umgestiegen bin
GlobalMapper ist wirklich jeden Cent wert

Grüsse - Anton

Nichts ist umsonst. Entweder man gibt die 3 Zeilen in der Kommandozeile ein oder 349.- US$ aus. Was immer einem leichter fällt.

Zitat von Cletus

Hallo Helmut,
hier nur auf die Schnelle (hier brennt es ...):

Aber hoffentlich nicht wegen QLGT!?

Zitat von Cletus

habe WinXP,
die QLandkarte-Version ist 1.0.1 (müsste die neueste sein)
hatte ALLES gewählt zum installieren

Bitte auf jedenfall V1.1.0. benutzen. Helmut scheint die abendliche Debugsession bezüglich der Custom Maps unter Windows schon vergessen zu haben.

Mein oben genanntes gdalwarp Kommando möchte ich revidieren. Das führt zu keinem schönen Ergebnis.

gdalwarp -t_srs "+proj=merc +datum=WGS84"  <infile> <outfile>

Die vorher verwendete longlat Projektion hätte zu einer gestauchten Karte geführt. Bei Merkator sollte es mehr oder weniger mit einer leichten Drehung getan sein. GDAL verwendet hierbei die "nearest neighbour" Methode zum Interpolieren. Das kann zu etwas griseligen Ergebnissen führen.

Besser wäre natürlich eine bilineare oder kubische Interpolation. Die geht aber nur bei 32bit RGB Dateien. Und das Ergebnis bleibt bei 32bit, da ja jetzt deutlich mehr als 256 Farben der Farbtabelle auftauchen. Eine Datei mit 8bit Fabtabelle wandelt man in eine 32Bit RGB Datei wie folgt um:

gdal_translate -expand RGB <infile> <outfile>

Und ändert dann die Projektion:

gdalwarp -t_srs "+proj=merc +datum=WGS84"  -r cubic <infile> <outfile>

Versteht sich von selbst, dass damit die Datei deutlich größer wird und bleibt, da ein Weg zurück zur Farbtabelle, die Qualität zunichte macht. Die Datei sollte aber noch ein wenig optimiert werden, um Arbeitsspeicher zu schonen. Dazu wird sie intern in Kacheln zerlegt.

gdal_translate -co tiled=yes <infile> <outfile>

Um für ein flüssiges Zoom zu sorgen, sollten noch ein paar Überblicksebenen hinzugefügt werden:

gdaladdo -r cubic --config COMPRESS_OVERVIEW JPEG <infile> 2 4 8 16

Fertig. An für sich reicht der anfängliche Aufruf von gdalwarp. Sollte man jedoch Wert auf die Bildqualität legen, empfiehlt sich der Weg über die 32bit RGB Datei. Die letzten beiden Kommandos sind vor allem bei großen Dateien wichtig, weil ohne diese Optimierungen kein Programm die Karte schnell darstellen kann. Zusammengefasst, ohne verwirrende Erklärung:

gdalwarp -t_srs "+proj=merc +datum=WGS84"  infile.tif temp1.tif
gdal_translate -co tiled=yes temp1.tif outfile.tif
gdaladdo -r cubic --config COMPRESS_OVERVIEW JPEG outfile.tif 2 4 8 16

Zitat von Cletus

Und QLandkarte habe ich auch installiert, es steigt aber aus mit der Meldung: gdal_fw.dll nicht gefunden. Nochmalige Installation brachte nix.

Das ist aber ärgerlich. Ich werde dem Windows Maintainer gleich Bescheid geben, damit er sich darum kümmert.

Zu der Dateigröße: Abhängig von der Beschaffenheit der Datenquelle ist das eine oder das andere Kompressionsformat besser. Während JPEG auf Fotos spezialisiert ist, also auf Bilder bei denen kein Pixel den selben Farbwert hat, benutzt TIF in der Regel einen Lauflängenalgorithmus. Der ist ideal für Karten die Linien und Flächen mit einem Farbwert haben. Wobei mit 300k vs 10M schon arg komisch vorkommt.

Grüße

Oliver

Zitat von Cletus

danke für die Antwort. Garmin Custom Maps scheint mir eben nicht für meine Zwecke tauglich, denn meine Karten sind ja schon exakt eingepaßt ("georeferenziert" oder in der GPS-Welt "kalibriert"). Warum sich also nochmal in GE mit Paßpunkten rumplagen? Genauer wirds davon bestimmt nicht. Daher kann mir wohl in diesem Fall auch der OZI nicht weiterhelfen.

Ein richtig referenziert Karte in einem offenen, bekannten Format (tif + Worldfile is ok) sollte sich problemlos in QLandkarte GT einbinden lassen. Vom Hautmenü mit F1->F6 den Dialog dazu öffnen. Du brauchst den ersten Punkt in der Combobox. Von da sollte es selbsterklärend sein bzw die ? Buttons helfen.

Auf einer so eingebundenen Karte kann man einen Bereich auswählen. Dabei werden schon die 1024x1024 Kacheln angezeigt. Die Auswahl kann als Garmin Custom Map exportiert werden.

Wie Anton schon bemerkt hat, solltest Du aber vorher deiner Datei eine merkatorähnlich Projektion verpassen. Transversal Merkator kann Garmin nicht. Das geht mit gdalwarp:

gdalwarp -t_srs "+proj=longlat +datum=WGS84" <infile> <outfile>

Zitat von Cletus

Ich muß zugeben: die Fülle an verfügbarer Software ist für ein Greenhorn wie mich erschlagend: GPSMapEdit, GlobalMapper, Ozi, QLandkarte, Mapsource, Basecamp, MOBAC ... wer blickt denn da noch durch was man braucht? Hat sich zufällig jemand mal die Mühe gemacht, das ein wenig zu entwirren? Nach dem Motto: was ist gut und für welchen Zweck geeignet? Wo hat welches Programm seinen Schwerpunkt und wo seine Schwächen? Puh ...

Gruß, Cl.

http://www.naviboard.de/vb/showthread.php?t=30510

Ein Bewertung in Schwerpunkte und Schwächen endet in einer wüsten Diskussion. Wie üblich im Leben, musst Du selber wissen, was gut für dich ist. Eine steile Lernkurve gehört bei einem so komplexen Thema wie GPS dazu.

Grüße

Oliver

Zitat von wanderer200

Hallo kiozen,

danke für die Hinweise. Ich werde mir die Sache mal anschauen. Es ist doch gut, wenn man auf die Erfahrung anderer Benutzer zurückgreifen kann. Da fehlt mir doch noch einiges.

Viele Grüße Wanderer200

Ja das Thema ist komplex und die angebotenen Lösungen stagnieren seit Jahren auf Mittelmaß. Outdoorgeräte sind nur eine kleine Nische im gesamten GPS Markt und die Marktdominanz von Garmin lässt wenig Konkurrenz zu. Deshalb bewegt sich alles nur sehr langsam und der Verbraucher muss die Widrigkeiten mit allerhand Eigeninitiative umschiffen. Dazu gehört eine steile Lernkurve und die Akzeptanz, dass einige Dinge so dämlich sind, wie sie sind.

Zitat von wanderer200

es liegt wirklich nicht an den Einstellung. Habe mittlerweile eine routingfähige OSM Karte. Die Ergebnisse sind aber trotzdem ernüchternd. Kurze Routen funktionieren. Allerdings sind Zieleingaben wie Adresseingaben, Städte usw. sehr umständlich und dauern sehr lange wenn man entsprechende Eingrenzungen vornimmt.

Vorsicht! Das ist ein bekanntes Problem bei OSM und wurde erst vor ein paar Tagen verbessert. Die neue Version von mkgmap, das Tool im OSM Daten in das Garminformat zu bringen, wurde dahingehend optimiert. Bis sich das in allen angebotenen Karten durchgesetzt hat, dauert.

Zitat von wanderer200

Allerdings ist das Autorouting wirklich nur eine untergeordnete Funktion. ( Bei Fahrradtouren wäre es ganz schön) Ich werde weiter experimentieren, weil es ja auch keine gute Beschreibung dafür gibt.

Mal ein ganz andere Ansatz:

Garmin bietet für's Fahrradrouting nur wenig. Deshalb bedient sich die OpenMTB Karte eines Tricks. Relevante Radstrecken werden als Autobahn markiert, und Autobahnen als irgendwas, nur keine Straße. Damit kann der für KFZs optimierte Algorithmus im Gerät ein ordentliches Ergebnis für Radfahrer erzielen.

Es geht aber auch anders. Auf www.openrouteservice.org (ORS) wird direkt auf den OSM Daten gearbeitet. Für Radfahrer gibt es mehrere Möglichkeiten. Eine Tour kann als GPX gespeichert werden.

Ein andere, komfortabler Weg, auf ORS zu zugreifen, ist QLandkarte GT (www.qlandkarte.org). Dort wird die Route auch über ORS berechnet. Kann aber dann mit Höhendaten angereichert in einen Track oder eine änderbare Linie umgewandelt werden. Das hat den Vorteil, dass man das Ergebnis individuell anpassen kann. Der fertige Track wird zum Schluss auf das Gerät übertragen. Die Route zu übertragen mach wenig Sinn, da das Gerät die Route neu berechnen wird und unter Umständen zu einer sehr seltsamen Lösung kommt.

Sicherlich alles keine Lösung auf dem Gerät, aber die Routendefinition war bei den Garmin Outdoorgeräte immer schon nur ein Notnagel und kein Konzept.