Beiträge von kiozen

Zitat von Sardinien

Oliver,
wie viele orig. Garmin-Maps und Kompasskarten+ECW Maps (Grenzgebiete) kann deine Software Hybrid in einem bzw. mehreren Kartenfenstern gleichzeitig darstellen und automatische Routen/Tracks dabei erstellen mit allen Punkten und Höhenangaben? Bei den Länderübergängen sollten die Raster-Maps transparent geschaltet werden können. 3 D ist natürlich selbstverständlich für alle Maps.

Das ist mit dem selben Frikelaufwand möglich wie Du das unter TTQV zu Wege bringst. Einziger Nachteil: Ich muss mich an offene Formate halten. GeoTiff ist allerdings durchaus in der Lage Transparenz zu definieren. QLGT kann verschiedene Dateien auf einer Ebene anzeigen. Karten verschiedener Auflösung lassen sich auch in QLGT übereinander legen. Vektorkarten lassen sich unabhängig davon in beliebiger Anzahl überlagern. Bis dir vor lauter Linien schwindlig wird. Das Höhenmodell und die Karten sind mehr oder weniger unabhängig in QLGT. Genauso wie die Routenplanung und künstliche Tracks. Und, ja, 3D kann es auch mit jeder Karte. Wer's braucht . Glaubst Du denn im Ernst nur bei TTQV haben die Leute die Weisheit mit Löffeln gefressen?

Zitat von Sardinien

Nach Beendigung der Planung werden die Maps auf die Geräte gesandt in Tiles, die entlang der Strecke benötigt werden. Könnte für eine Tour von München nach Santiago de Compostella wichtig sein. Geht dies ebenfalls?

Ich kann mit QLGT Ausschnitte aus Raster- sowie Vektorkarten exportieren. Entlang der Route geht nicht automatisch. Aber sollte ich das mal wirklich brauchen, baue ich es ein. Und wann hast Du das letzte Mal bei TTQV um ein Feature gebettelt?

Zitat von Sardinien

Linux ist bei den Entwicklern sehr beliebt, bei uns normalen hat es einen Marktanteil von 1 % (PC-Bereich) mit fallender Tendenz. Mir ist schon bekannt, dass Linux (Dream-Box) gepaart mit der richtigen Soft einiges kann und für Bastler enorme Möglichkeiten offenbart.

Mal wieder so eine fundierte Marktanalyse. Warum werden dann die Anfrage bezüglich Ubuntu und QLandkarte in meiner Mailbox täglich mehr?

Wir kochen hier alle nur mit Wasser. TTQV ist sicherlich sein Geld wert, wobei ein guter Teil in eine absolut verquere Lizenzpolitik fließen dürfte. DRM und Formatlizenzpoker schaffen keine Werte. Gerade bei den Rasterformaten ist die Innovation flach. Das ganze Zeug ist nur gut um, Pfründe zu sichern, anstatt Mehrwert zu schaffen. Für den Kunden heißt es ein und das selbe Produkt wieder und wieder zu kaufen. Oder hinten herum über Lizenzen doppelt und dreifach zu bezahlen. Ich habe kein Problem für Leistung zu zahlen. Aber ich habe keinen Bock auf digitale Barrieren. Vor allem nicht wenn ich dadurch immer wieder geschröpft werde. Das mag der BWL Heini in den Verlagen witzig finden. Als Kunde bin ich dazu nicht bereit.

Zitat von gerhardg

von soviel "freiheit" können garmin user nur träumen.

Das wäre für mich eher eine Alptraum wenn ich mkgmap mit einer beschnittenen Version von cgpsl und QLandkarte mit TTQV tauschen müsste. Zumal mir diese Software Windows aufdrängt. Bleibt einzig ECW als portable Lösung. Von der Lizenz her ist ECW aber auch problematisch.

Versteht mich nicht falsch. Ich will keinen Compe/Garmin sonst was Krieg provozieren. Auch liegt es mit fern eine Lanze für Mobac zu brechen. Ich würde mich freuen wenn andere Hersteller Garmins Dominanz zurückdrängen. Compe hat dazu durchaus das Potenzial. Allerdings müssen sie dann auch den Pool an Benutzern anzapfen, der Garmin so viel Erfolg verschafft. Und das ist durchaus die OSM und Opensource Gemeinde. Benutzer die Linux haben kaufen Garmin weil es OSM Karten und QLandkarte gibt. Ich treffe sogar immer mehr Windowsbenutzer, für die das auch ausschlaggebend ist. Andere Hersteller würden mit mehr Offenheit diesen Pool anzapfen können. Und das sind in der Regel Benutzer, die von anderen gefragt werden, welches Gerät sie empfehlen.

Hallo Martin,

und an CompeLand verdient Compe natürlich nichts Mal abgesehen von dem unschätzbaren Vorteil, den Benutzer unter Kontrolle zu haben. Apple macht es vor. Mit einem System dass dem Benutzer keine Alternativen lässt, kann man an jedem Pubs mit verdienen.

Mir ist ein solches Verhalten suspekt. Und ich habe auf Linux bestehende, funktionierende Lösungen für Garmin. Es wäre durchaus interessant das alles auch Compe Benutzern zur Verfügung zu stellen. Zumal Compe unfähig ist portable Software zu schreiben. Aber wenn es schon so losgeht, sinkt die Bereitschaft rapide auf Null.

Zitat von dancingman

Mmh, verstehe nicht, weshalb Compe da ein Problem mit hat. Weil das Format "gehackt" wurde?

Weil sich so der Kunde besser abzocken lässt. Der muss nämlich entweder die teuren Karten vom Hersteller kaufen. Oder er zahlt indirekt über die Lizenzgebühren bei offiziell zugelassener Software. OpenSource und sogar noch umsonst geht da gar nicht.

Aber das ist dumm und kurzsichtig von Compe. Ein guter Grund für Garmin ist das Vorhandensein von freien Karten und einer handvoll alternativer Software, die auch auf was anderem als Windows läuft. Wer denkt er könnte das ignorieren und zudem den Kunden mit DRM mehr als nötig gängeln, der arbeitet am Markt vorbei. Und ob man in einer winzigen Nische, für eine kleine Avantgarde von Benutzern, auf Dauer ausreichend Geld verdient, um das Produkt schnell genug zu einer Reife und breiten Marktakzeptanz zu entwickeln, ist fraglich. Magellan hat nicht zuletzt deshalb eine Bauchlandung hingelegt.

@macnetz: Das ist Käse. Wer offizielle Karten von Compe klauen will macht das. Mit oder ohne OpenSource. Bei Mobac können sich die Anbieter von Web Karten beschweren. Das würde ich verstehen. Compe sollte lieber froh sein, dass es Aufmerksamkeit bekommt.

Eine Route auf dem Gerät zu planen, ist wirklich nur ein Notnagel, den ich versuche zu vermeiden. Straßennavis sind hier deutlich besser. Für ein Outdoor GPS ist das aber auch nicht so wichtig. Ich persönlich füttere das Gerät vor einer Tour mit allen wichtigen Wegpunkten vom PC aus. Dann muss ich nur noch den entsprechenden Wegpunkt anwählen.

Zitat von wanderer200

Von der Empfindlichkeit des SAT-Empfängers bin ich etwas enttäuscht. Mein Autonavi bekommt noch Signale wo das Garmin schon Schwierigkeiten hat.

Ich hatte bisher nicht das Gefühl, dass das 62er früher als andere GPS seinen Fix verliert.

Die restlichen Fragen sind ausreichend im Handbuch beschrieben. Ich empfehle auch den Thread mit den Tips und Tricks (http://www.naviboard.de/vb/showthread.php?t=44414) zu lesen.

GDAL (FWTool) sollte das meines Wissens können. Wenn die Dateien referenziert sind, sollte:

gdalwarp file1 file2 <und so weiter> outpufile

reichen.

Zitat von thomas_rolf

Code

EXTENSION['PROJ4','+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs'],
    UNIT['metre',1,

Ok, Merkator. D.h. Angaben in Meter

Zitat von thomas_rolf

Code

Origin = (9680403.680058261400000,6335385.307206181800000)
Pixel Size = (39.000290546521789,-39.000290546521789)

Das hier ist der obere, linke Punkt in Metern. Und darunter der Skalierungsfaktor in [m/pixel]

Zitat von thomas_rolf

Code

Upper Left  ( 9680403.680, 6335385.307) ( 86d57'37.96"E, 49d 9'54.43"N)
Lower Left  ( 9680403.680, 6214913.410) ( 86d57'37.96"E, 48d27'16.18"N)
Upper Right ( 9800017.571, 6335385.307) ( 88d 2'6.20"E, 49d 9'54.43"N)
Lower Right ( 9800017.571, 6214913.410) ( 88d 2'6.20"E, 48d27'16.18"N)
Center      ( 9740210.626, 6275149.358) ( 87d29'52.08"E, 48d48'39.81"N)

Und weil es gar so schön ist alle 4 Ecken.

So, und jetzt willst Du freilich von mir wissen, wie Du Koordinaten in Grad in Koordinaten in Meter umrechnest. Richtig? Das geht mit GDALs Bruder Proj4. Und weil QLandkarte bei Dir läuft ist auch schon alles installiert. Das nötige Kommando heißt "cs2cs"

cs2cs +proj=longlat +datum=WGS84 +to +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs

Nach dem Return erwartet das Programm eine Eingabe wie

86.5 49.3

Und spuckt auch gleich die zugehörigen Koordinaten in Metern aus.

9629135.95      6325919.27 0.00

Mit welcher Skriptsprache arbeitest Du eigentlich? GDAL unterstützt Python und alle diese Befehle sollten auch in Python eingebettet sein. Ich habe es aber noch nie ausprobiert um genaueres zu sagen.

Zitat von thomas_rolf

Hallo zusammen,

bin gerade am Ausprobieren, was man mit gdal_translate beim Zuschneiden der Karten so alles anstellen kann. Weiß jemand, in welchem Format beim gdal_translate-Parameter -projwin die Eckpunkte angegeben werden müssen (ulx, uly, lrx, lry)? Vorliegen habe ich die Lat/Lon-Werte direkt von der Karte (sie stehen ja auch im map-File), aber wie muss ich die angeben? Einfach die Dezimalwerte nehmen klappt nicht, gdal_translate vermutet den gesuchten Ausschnitt weit ausserhalb der Karte.
Gruß,
Thomas

Kommt auf die Projektion an. Bei Mercator oder Transversal Merkator (z.B. UTM) müssen die Werte in [m] sein. Bei eine lon/lat Projektion in Grad, dezimal. Genaueres kann man nur sagen, wenn Du die Ausgabe von gdalinfo verrätst.

Aber würde -srcwin nicht reichen? Das wäre in Pixel. Und der Rand ist doch fast immer gleich, bis auf ein paar Pixel Sicherheit. Und überlappen müssen sich die Karten sowieso damit das was wird.

Zitat von Lacor4711

Hallo Oliver,
gibt's irgendwo eine Beschreibung zu QLandkarteGT?

http://www.qlandkarte.org/

http://sourceforge.net/apps/me…title=Main_Page&Itemid=20

Zitat von thomas_rolf

@Helmut:vielen Dank für die Info zu EPSG. Dass die Nummern mal eben um die halbe Welt umziehen können, findet sich auf der EPSG-Seite natürlich nicht so direkt...

Ärgerlich, dass es so ist. Ich habe früher den Leuten den Projektionsstring ("+proj....") direkt um die Ohren gehauen. Das hat, vor allem bei Neulingen, immer zu Hyperventilation geführt. Deshalb bin ich zu den EPSG Codes übergegangen. Das scheint aber eine schlechte Idee zu sein.

Zitat von thomas_rolf

Der Fehler tritt nur auf, wenn man in QLandkarteGT zwei oder mehr Karten (die sich in meinem Fall leicht überlappen, wegen des Kartenrandes) in einer Kartensammlung zusammengefasst hat und dann einen Kartenausschnitt zum Exportieren über den Rand einer der Teilkarten hinweg definiert. QLandkarte GT exportiert den Ausschnitt, legt dabei aber keine Kacheln an, die Teile aus beiden benachbarten Teilkarten enthalten, sondern erzeugt am Übergang kleinere Kacheln, die jeweils am Teilkartenrand enden. Wenn ich die Teilkacheln dann in Google Earth lade, liegen diese nicht mehr nebeneinander, sondern alle übereinander, ausserdem sind sie in der x-Achse verzerrt.
Wenn ich den Ausschnitt nur innerhalb einer Teilkarte wähle, werden die Kacheln ordentlich erzeugt, jedenfalls, sieht in Google Earth alles ordentlich aus.

Ist gut möglich, dass es da Probleme gibt. Dieser Fall kommt praktisch bei mir nie vor, da ich nur mit großflächigen Karten arbeite. Das Feature, pro Level mehrere Dateien zu lesen, war eher dafür gedacht, die 4GB Grenze zu überschreiten. Das werde ich mal in einer ruhigen Minute fixen müssen. Mein favorisierter Weg ist sowieso, die Einzelkarten zu einer Großen zusammen zusetzten. Nicht zuletzt, da die Custom Map auf 100 Dateien begrenzt ist. Da möchte man nicht unnötige halbe Kacheln haben.

Zitat von thomas_rolf

Wenn ich die Teilkarten mit 'gdalwarp file1.tif file2.tif (usw.) file_out.tif' vorher zu einer Karte zusammenbaue, tritt der Fehler nicht auf, für QLandkarteGT ist das ja dann eine Karte. Beim Kopieren wurde bei mir allerdings nur der erste tif-File korrekt nach file_out übertragen, beim zweiten File war die Auflösung irgendwie deutlich geringer als vorher, ausserdem war die Farb-Map korrupt. Muss ich da noch weitere Parameter setzen?

Die Dateien benutzen eine Farbpalette, oder? Und die ist für jede Datei anders? Das vergesse ich auch immer wieder. Entweder Du bringst die Quelldateien alle auf die selbe Farbpalette, oder Du benutzt gdal_translate mit "-expand" um 32bit RGBA Dateien herzustellen.

Zitat von thomas_rolf

Ü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

Zitat von thomas_rolf

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.

Zitat von thomas_rolf

Ü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.

Zitat von wanderer200

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

Zitat von wanderer200

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.

Zitat von wanderer200

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.

Zitat von wanderer200

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

Zitat von thomas_rolf

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.

Zitat von thomas_rolf

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

Zitat von Juventura

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!!!

Zitat von freeday

Kann man auch mehrere JNX gleichzeitig anzeigen lassen?

Nein das geht nicht.

Zitat von macnetz

Qlandkarte braucht GeoTiff

Qlandkarte GT stellt jedes von GDAL unterstützte Format dar.
Qlandkarte GT stellt auch JNX dar.

So viel Zeit muss sein

Zitat von huirad

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

Zitat von jopi56

• 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?