Beiträge von kiozen

Wie sieht es denn mit der Bedienbarkeit des Touchscreen aus? Ich hatte am Wochenende mal wieder das Sportiva dabei und wurde daran erinnert warum wir keine großen Freunde werden. Hat sich wenigstens hier was getan?

Naja, WMTS Karten kommen ja erst mit der nächsten Version 0.5.0. Deswegen haben das bestimmt noch nicht viele probiert. Aber mal sehen. Wenn noch jemand anderes den Fehler reproduzieren kann, bekomme ich vielleicht mehr Information. Die Systeme verhalten sich doch immer wieder recht unterschiedlich.

Wegen dem Cancel. Einen Wegpunkt anzulegen nur um die Koordinate zu bekommen, ist sicherlich nicht der richtige Weg. ich baue dafür noch einen extra Punkt ein. Eigentlich ist die Idee, dass man schnell weiter kommt indem man die Escape Taste drückt. Aber Du hast schon recht. Abbruch heißt abbrechen. Ich werde das auch ändern.

Das ist ok. Wirklich seltsam. Ob s doch ein Bibliotheksproblem ist? Ich hatte gehofft, dass der Backtrace einen besseren Hinweis liefert.

Das ist wirklich komisch. Das sieht so aus als ob was im Kernel hängt. Aber da sollten mehr Aufrufe gelistet werden. Unter anderem welche aus QMS. Du hast in ccmake auch Debug gesetzt?

Jetz noch bt eingeben ok hast du schon.

Mehr kommt nicht?

Das ist das Gemeine. Solche Fehler entdeckt man eher mit einem langsamen Rechner, als mit einem schnellen. Ich hasse Race Conditions und lasse deswegen lieber die Finger von mehreren Threads. Allerdings sind Threads das Mittel zur Wahl, wenn man Prozessoren mit mehreren Kernen optimal ausnutzen will. Und eine schneller Aufbau von Karten in mehreren Schichten ist hierfür prädestiniert. Auch wenn die Fehlersuche lästig ist.

So wie sich die Sache darstellt ist es eine sogenannte Race Condition. D.h. 2 parallel Prozesse greifen zugleich auf Daten zu. Das kann gut gehen, muss aber nicht. Hier kommt es auf das Timing im PC an. Deshalb ist es bei mir noch nicht aufgefallen. Und bei deinem PC kommt es häufiger vor. Da es aber ein Fehler ist, sollte man ihn finden.

Schön wäre es wenn der Crash mit dem gdb auftritt. Aber der ändert das Timing genau so ab, dass es gut geht. Wenn die letzte Änderung nichts bringt, dann habe ich aber noch eine Idee. Vorher sollte aber sichergestellt sein, dass die letzte Änderung auch wirklich nichts gebracht hat.

Hat die Änderung etwas gebracht?

Das könnte auf eine Race Condition hindeuten. Ich habe mal eine kleine Änderung gemacht. Vielleicht hilft die.

Ich stürze mich jetzt erst mal in den Feiertagsstau. Bisschen den Massenauflauf in der Sächsischen Schweiz unterstützen

Du könntest in ccmake mal 't' drücken. Damit bekommt man eine erweiterte Parameterliste.

Und dort für

CMAKE_C_FLAGS_DEBUG
CMAKE_CXX_FLAGS_DEBUG

anstatt "-g" "-g -O3" eingeben. Das ist ein großes O. Keine 0. Jetzt wird der Code genauso wie im Release optimiert.

So kompliziert ist das nicht. Zuerst musst Du QMS so kompilieren, dass auch Debug Information mit dabei ist. Das Binary wird dadurch richtig fett, deswegen lässt man die üblicherweise weg.

Und gdb ist der Debugger unter Linux. Der will beim Start wissen was er Debuggen soll. Und mit 'r' für run fängt er an. 'bt' heißt Backtrace und gibt eine Liste der letzten Funktionsaufrufe bis zum Crash aus. Sprich damit kann ich sehen wo es gerumst hat und wie ich dort hingekommen bin.

Wenn man es mal gemacht hat, dann kommt es einem wirklich einfach vor. Und es hat den Vorteil, das man dem Entwickler eine wirklich brauchbare Fehlermeldung schicken kann. Und wenn der Fehler nicht in einer der Bibliotheken liegt, dann kann man recht flott was ändern.

Die Fehlermeldung mit der falschen jpeg Bibliothek könnte das Problem sein.

Mach doch mal folgendes:

1) im build_QMapShack Verzeichnis rufst Du nochmal ccmake ../QMapShack auf.
2) CMAKE_BUILD_TYPE setzt Du auf Debug
3) erneut make ausführen.
4) gdb installieren
5) auf der Kommandozeile:

gdb bin/qmapshack

Jetzt ein 'r' eingeben, um QMS zu starten. Wenn es Kracht kommt Du wieder auf the Kommandozeile zurück und gibst jetzt 'bt' ein. Was dabei herauskommt sollte ein wenig informativer sein. Also für mich Schick mir das mal.

Hmm, das sind genau die Dateien, die ich auch benutze. Ich habe jetzt nochmal extra das Capability Sheet neu geladen und QMS mit Parameter -c gestartet, um eine komplett jungfräuliche Konfiguration zu haben.

Wenn ich dann den Kartenpfad setze, Und die World Topo aktiviere, zählt der Status oben links die Kacheln herunter und wenn alle da sind wird die Karte angezeigt. Zusätzlich finden sich im angegeben Tile Cache Verzeichnis die Dateien.

Soweit funktioniert bei mir alles mit den Grundeinstellungen. Machst Du irgendwas anders?

Benutzt Du das tar.gz aus dem Downloadbereich oder den aktuellen Entwicklungsstand?

Das was Du beschreibst war zur Version 0.4.0. Offiziell unterstützt die kein WMTS. Erst die kommende Version 0.5.0. Im aktuellen Entwicklungsstand geht WMTS. Das Thema ist quasi durch. Wobei noch nicht alle Features von WMTS implementiert sind, bzw noch nicht jede Dummheit in den XML Dateien abgefangen wird. Dazu brauchte es dann Rückmeldungen.

Zitat von lalaka

Danke für die Identifizierung!

Hm, einerseits gut, wäre ja leicht zu ersetzen, andererseits dann wohl eher kaum der Fehler - ne Spule sollte nach gründlicher Trocknung ja eher keinen Schaden davontragen (Wicklungsdraht ist ja lackiert).

Werde dann wohl erst mal die Platine versuchen gründlich von Oxidresten zu reinigen und die Leiterbahnen genau kontrollieren.

Kommt darauf an. Ich vermute Du siehst eine Menge Metalloxid aufgrund von Korrosion. Das kann z.B. den Draht an der Lötstelle angefressen haben. Oder die Lötstelle auf der Platine. In beiden Fällen steigt der Widerstand, was zu einem höheren Spannungsabfall führt und damit zu einer niedrigeren Spannung. Wenn diese Spule im Strompfad vom Akku liegt. Wenn sie nur zur Ladeelektronik führt, dann ist das erst mal egal.

Die Akkukontakte würde ich mir sicherlich mal genau ansehen.

Muss ich jetzt wirklich heute Abend zu hause den fleckigen, handgeschriebenen Wisch von meiner Mutter abtippen? Hätte ich doch nur die Klappe gehalten....

Wobei ich ja ein ganz leckeres Käsekuchenrezept kenne

Ich mag da ja was verpasst haben, aber gibt es wirklich Software, die Trackpunkte wirklich als Wegpunkte interpretiert und damit die volle GPX V 1.1 Spezifikation unterstützt? Ich meine Sinn würde das schon mache, zumal die Track Spezifikation in GPX wirklich brauchbar ist und Routen schon fast überflüssig macht. Bzw würde ich mir diese Möglichkeiten eigentlich bei den Routen wünschen und nicht beim Track.

Aber wie dem auch sei, gibt es Software die Bilder, Symbole und Kommentare in Trackpunkten sinnvoll auswertet?

Zitat von Pinin

Sehr schön, läuft stabil, JNX/IMG/RMAP Karten lassen sich öffnen.

1. Kann man in Zukunft auch GeoTIFFs damit öffnen und in andere Formate exportieren oder wird das nur über Kommandozeile möglich sein?

Also Geotiffs gehen ja jetzt schon. Man muss halt mal kurz auf der Kommandozeile eine *vrt Datei bauen. Siehe auch:

https://bitbucket.org/maproom/qmapshack/wiki/DocBasicsMapDem

Der Grund dafür ist, dass ich für einen Kartesatz nur noch eine Datei haben möchte. Ich hoffe der Weg über gdalbuildvrt ist zumutbar.

Zitat von Pinin

2. Besteht in Zukunft die Möglichkeit Karten mit Hillshading zu versehen oder mehrere Karten per Regler "opacity“ zu überlagern und genau diese Ansicht als Karte zu exportieren?

Eigentlich wollte ich mich aus der ganzen Exportgeschichte eher zurückziehen. Das bringt nur Ärger ein. Die Tools aus QLGT bleiben ja erhalten, um komplette Karten zu exportieren. Allerdings, wie so oft, möchte ich es nicht komplett ausschließen. Das nächste Jahr wird aber eher davon geprägt sein, datentechnisch mit QLGT gleichzuziehen, damit die Datenbank übertragen werden kann. Das hat oberste Priorität.

Und dann ist da noch der große Punkt "Geräteanbindung". Das hätte ich gerne a) mehr plug-n-play mäßig und b) projektorientiert.

plug-n-play ist ein sehr großes Problem bezüglich der Portabilität. Und keines der Geräte kann bisher wirklich projektorientiert Daten verwalten. TwoNav noch eher als Garmin. Was eine eigene App interessant machen würde, wenn es endlich eine brauchbare Hardware geben würde. In der Euphorie über das Monterra habe ich ja eine Android App angefangen, da aber sehr schnell klar war, dass das Monterra eine Krücke ist, habe ich keine weitere Energie in das Projekt gesteckt.

Zitat von papaluna

So bleibt es bei einem subjektivem Gefühl.

So ist es.

Das Problem bleibt. Wenn Empfänger A einen Fehler von 100 hat und B nur einen von 10, ganz klar, wir lassen A weg. Aber wenn A einen Fehler von 15 hat und B einen von 5. Da ist es schon nicht mehr so einfach. Gut könnte man immer noch auf A oder B entscheiden. Aber dies führt zu Sprüngen. Und auch das Kalman Filter liebt es nicht, wenn laufend die Quelle umgestellt wird, weil es ein Gedächtnis hat und davon ausgeht, dass alle Eingangswerte von einander abhängen. Was bei 2 Quellen nicht stimmt.

Man kann es drehen und wenden. Es wird Situationen geben, bei denen wirken sich 2 Quellen positiv aus. Und es wird Situationen geben bei denen das nicht so toll funktioniert. Von offizieller Seite habe ich auch noch nie die Behauptung gehört, dass GLONASS zusammen mit NAVSTAR sicher zu einem besseren Ergebnis führt. Das wird eigentlich immer nur von den selben Leuten in den Foren wiederholt, die leider zuvor nicht mit besonders intelligenten Beiträgen gepunktet haben.

Deswegen würde ich mich entweder für das eine oder das andere entscheiden. Viel schlimmer ist, dass der aktuellste Mediatek Chipsatz mit NAVSTAR nicht an das herankommt, was schon mal war. Interessant wäre der Vergleich mit dem 64er gewesen, aber das war ja lieber an den Cinque Torri beim klettern.