Beiträge von kiozen

Das ist der minimale Teil von Linux, den Garmin im Zuge der GPL veröffentlichen muss. Mit einem GPS System hat das vorerst wenig zu tun.

Nimm es mir nicht allzu übel, aber aus deinen Frage kann man erkennen, dass Du von Softwareentwicklung wirklich null Ahnung hast. Meinst Du nicht, dass Du erst mal dünne Bretter bohren solltest, anstatt gleich mit "Navigation und allem was dazugehört" anzufangen? Vorher sollten Dir solche Begriffe wie Compiler, SDK, Build Evironment, Crosscompiler, Embedded System etwas sagen, ohne dass Du lange danach fragen musst.

Oder anders ausgedrückt: Kein Schreiner kann Dir mal so eben einen Tip geben, wie man Möbel baut, solange Du nicht grundlegende handwerkliche Fähigkeiten zur Holzverarbeitung erworben hast.

Ich würde Dir empfehlen eines dieser kleinen Microcontroller Boards, wie das Raspberry Pi zu besorgen. Dazu einen schönen GPS Chipsatz, der sich mit einer normalen seriellen Schnittstelle auslesen lässt. Und dann die Daten von dem Chipsatz mit einer einfachen Skriptsprache wie Python auslesen. Wenn das funktioniert hast Du schon mal einen ersten Schritt in Richtung eines Embedded System erfolgreich gemeistert.

Alternativ kannst Du auch ein Smartphone benutzen und mit Java GPS Daten auslesen und weiterverarbeiten. Das ist sogar noch einfacher, weil es schon eine fertige SDK gibt, die gut dokumentiert ist. Und mit Eclipse hast Du auch schon eine fertig eingerichtete IDE.

Es gibt zudem noch viele OpenSource Projekte für Navigation. Eines davon ist Navit. Aber auch dort gilt: Um es zu benutzen muss man sein Handwerkszeug beherrschen. Die Entwickler werden keinen Nerv haben Dir alles von der Pike an zu erklären.

Eigentlich sollte GPSD genauso wie NMEA in der Auswahl angeboten werden. Allerdings nur wenn beim compilieren auch die nötigen Dateien für GPSD vorhanden waren. Ich vermute mal bei den QLGT Binaries von SuSE ist das nicht der Fall. Da hilft nur selber compilieren.

Und über einen USB Hub? Wenn der eine eigene Speisespannung hat.

Lesen wird gemeinhin überbewertet.

Was mir ja immer noch nicht eingeht, und ich habe dazu auch noch nichts zuverlässiges im Internet gefunden, warum das mit dem USB Host am Smartphone nicht gehen soll. Ok, gut, wenn der Host Port vom Smartphone nicht genug Strom liefert, dann lass ich es mir eingehen, dass das Etrex nicht in den Massenspeichermodus schaltet. Aber spätestens wenn es das tut, gibt es keinen Grund warum es nicht als Speichermedium auf dem Smartphone zu sehen ist. Das ist ja schließlich kein Voodoo, sondern Technik die einfach nur reagiert.

Ja wenn es zu "Hilfe->Über QLandkarte GT" schon nicht mehr reicht, dann ist nicht mehr zu helfen.

Zitat von AlterSachse

Hallo Programmierer,

Ne, also wirklich. So doof muss sich niemand anquatschen lassen. Schon gar nicht wenn man was von ihm will. Mein Name & Nick sind hinreichend bekannt.

Ich sag zu den Leuten ja auch nicht nur DAU 1 und DAU 2, auch wenn es bei so einem Beitrag mehr als angebracht wäre.

Zum Thema: In QLGT werden nur noch Bugs gefixed. QMapShack ist die Zukunft.

Was soviel bedeutet wie entweder nicht funktional oder durch eine Software belegt.

Generell gilt: kommen da NMEA Zeichenketten heraus kann auch QLGT was damit anfangen. Sicher dass da pur NMEA herauskommen soll?

Aber warum benutzt Du überhaupt den seriellen Port direkt, wenn doch GPSD funktioniert. Lass QLGT doch den GPSD verwenden.

Was für eine Meldung kommt denn?

Und wenn Du mal auf der Konsole:

cat /dev/ttyUSB0

eingibst, was kommt dann?

Das Etrex ist schon im Massenspeichermodus, oder?

Und woraus schließt Du, dass das Etrex nicht als Speichermedium eingebunden wird? Hast Du schon mal im Dateisystem nachgesehen?

Es wäre einfacher zu helfen, wenn man nicht alle Fakten dem Fragesteller aus der Nase ziehen müsste.

http://www.amazon.de/Micro-Ada…LAXY-Google/dp/B007UMGPJG

das sollte für das S3 gehen oder?

Wenn das beim Etrex mitgelieferte Kabel nicht passt, dann wirst Du noch einen Adapter oder ein angepasstes Kabel benötigen. Das sollte sich doch auftreiben lassen -> Conrad & Co.

Ich glaube hier scheitert es eher an der Erkenntnis, wie Daten auf ein Garmin Gerät gelangen.

Basecamp macht nichts anderes als die Daten in Form einer GPX Datei im Speicher des Etrex abzulegen. In deinem internen Speicher, als auch auf der SD Karte gibt es einen Ordner "Garmin" und in dem einen Ordner "GPX". Werden dort GPX Dateien abgeladen, dann erscheint deren Inhalt auf dem Gerät.

Wie das jeweilige Gerät in dem Dateisystem deines Smartphones eingebunden wird, so dass Du Dateien verschieben kannst, hängt ein wenig vom verwendeten Betriebssystem ab.

Einfach mit einem Dateimanager. So wie am PC auch, wenn mal kein Basecamp installiert ist.

Es gibt 2 Verschiedene USB Anschlüsse. Einmal den normalen, wie man ihn an einem USB Stick oder anderem Gerät findet, das man an einen USB Port stecken kann. Welcher die zweite Variante ist, nämlich der USB Host.

Dein Etrex ist kein USB Host. Deswegen kannst Du den USB Stick nicht direkt mit dem Etrex verbinden. Smartphones und Tabletts können durchaus beide Varianten beinhalten. Deswegen kannst Du bei deinem Smartphone den Stick anschließen.

Und darin besteht auch die Lösung deines Problems. Lade doch die Daten vom Stick auf das Smartphone und vom Smartphone auf das Etrex.

Hm, ich habe bei jeder Ansicht so 2-3 Karten geladen. Das wird ein langer Name. Aber vielleicht kann man den Namen auch einfach selber angeben. Ich schau mal was sich machen lässt.

Sehr schön

Danke

Mal eine Frage an die Experten:

Bei Garmin gibt es die Datei GarminDevice.xml. In der Datei steht, was das für ein Gerät ist, die Gerätenummer und wo die sieben Tassen im Schrank stehen.

Und bei TwoNav?

Warum ich das wissen will: Eine Idee für QMapShack ist es mehrere Geräte zugleich beladen zu können. Also quasi den ganzen Gerätepark anschließen und einen Projektordner auf die Geräte spielen. Aber auch anders herum, die aufgezeichneten Daten abzuholen. Um das in geordneten Bahnen zu gewährleisten benötigt man aber eine Kennung, um die Geräte auseinanderzuhalten.

Naja, so mache ich es ja auch mit QLGT. Muss halt immer der teleskopix rumpopel und wenn sich was ändert darf er wieder ran. Mit QMS versuche ich die Capabilities von WMTS Servern direkt zu verarbeiten. Aber das ist ein Fass ohne Boden. Mir ist wirklich nicht klar, wie man einen so simplen Mechanismus wie Kartenkacheln zu übertragen, so elendig kompliziert und mit mannigfaltigen Freiheitsgraden definieren kann, z.B. ich kann doch nicht einfach alle auf der Welt verfügbaren Notationen für Projektionen zulassen. Da dreht derjenige, der den Client baut, doch irgendwann am Rad.

Zitat von Kermit_the_frog

H
Das ist natürlich schade. Es passt aber dazu, dass man WMS so stiefmütterlich behandelt. Eine richtige WMS-Integration (so mit An- und Abwahl von Layern) wäre ein wirklich tolles Feature.

Das liegt wahrscheinlich daran, dass WMS und WMTS sauber zu implementieren die Hölle ist. Ich habe ja jeden Tag mit Spezifikationen der ITU-T zu tun. Das ist verglichen zu dem WMS/WMTS Zeugs wirklich gut definiert. Und wenn man die Spec verstanden hat dann gibt es noch immer die Server, die sich nicht daran halten. So dass sich bei mir sehr schnell die Erkenntnis eingeschlichen hat, besser weitgehend die Finger davon zu lassen. Und so wird es bei Compe auch sein.

Aber eine Hangneigungskarte ist das nicht, Pinin.

Ich kenne für Garmin kein fertiges Produkt[1], das den Wünschen von kingofthering entsprechen würde. Es ist mit etwas Geschick und Einarbeitung schon möglich die Karten vom Outdooractive Server zu mopsen und in eine JNX Karte umzuwandeln. Die Betreiber von Outdooractive haben natürlich etwas dagegen. Das muss man selber mit seinem eigenen moralischen Rückgrat ausmachen, ob man sich darüber hinwegsetzten will.

Natürlich ist es auch möglich mit vorhandenen DEM Daten und lokalen Daten sich selber einen Kartensatz zu bauen. Da Garmin keine semitransparenten Overlays kann, muss man die Hangneigungskarte in die bestehende Karte hinein rechnen. Ohne besser Kenntnisse von GIS Werkzeugen schafft man das nicht.

Ich selber habe mich noch nie dazu aufraffen können. Ich benütze auf meinen Touren einfach einen Ausdruck, bzw lese das Risiko aus der Topokarte ab. Letzten Endes entscheidet dann auf der Tour mein Sachverstand und Bauchgefühl, ob ich weiter gehe, eine alternative Route gehe oder umkehre.

[1] jetzt mal abgesehen von der Topo Schweiz Die Alpenvereinskarte hat das zum Beispiel nicht. Eigentlich schade.