Beiträge von kiozen

Hilft nix. Ohne Logs kann ich überhaupt nichts sagen. Und dann ist es noch immer eine Portion raten. Wenn jemand von euch unter Windows compilieren und Debuggen könnte, dann wäre der Fehler wahrscheinlich flott gefunden. Der zugehörige Code ist recht übersichtlich in der Datei CSingleInstanceProxy.cpp. Und wie man alles auf Windows compiliert steht sehr detailliert hier:

https://bitbucket.org/maproom/…/BuildWindowsVisualStudio

Das ist nicht das erwartete Verhalten. Ganz sicher irgend eine komische Sache unter Windows, weil es unter Linux geht.

Bezüglich des Logs kannst Du folgendes machen:

https://bitbucket.org/maproom/…wn-header-troubleshooting

Das was unter "Troubleshooting" steht ist von Interesse. Vielleicht steht dort ja noch was Erhellendes drinnen. Ansonsten musst Du jemanden finden der Windows hat und sich dem Problem annehmen will. Ich kann nur bei grundlegenden Problemen helfen, oder bei solchen, die auch unter Linux auftreten.

Zitat von Speichennippel

Die 50 Zwischenziele reichen meistens, aber je nach Anwendungsfall nicht immer. Es ist nicht zu verstehen, warum das nicht aufgebohrt wird.

Weil das noch eine klassische Embedded Firmware ist, ohne ein riesiges aufgeblähtes Betriebssystem, das Ressource frisst. Bei begrenztem Speicher will man dynamische Speicherallokation auf dem Heap vermeiden weil dadurch Löcher in der Speicherbelegung entstehen, die den ohnehin schon sehr begrenzten Speicher weiter auslaugen. Hinzu kommt, dass bei dynamischer Allokation auch mal Speicher nicht zur Verfügung steht, was dann aufwändig in der gesamten Software abgefangen werden muss. Deswegen statische Arrays.

Interner Speicher und Betriebssysteme kosten Strom. Der Garmin Kram mag altbacken wirken, läuft dafür aber mit einem Akkusatz verdammt lange und recht zuverlässig. Wird wohl seinen Grund haben...

Zitat von klausthaler

Hallo

Anders ausgedrückt. Ich habe vier GPX Files. Ich klicke das erste an und es wird in QM geladen, dann klicke ich das zweite an(Qm ist noch geöffnet) und auch das zweite wird geladen. Klicke ich aber nun das dritte an wird es nicht mehr geladen, sowie alle darauf folgende. Möchte ich mehr als zwei Files nacheinander ansehen so muss ich immer nach dem zweiten File QM schließen und neu starten. Basecamp konnte mehrere Instanzen öffnen.
MfG

Eigentlich sollte das funktionieren. Softwaretechnisch ist kein Limit gesetzt. Dein Betriebssystem sollte erkennen, dass Du eine GPX Datei öffnen willst und als Verknüpfung QMapShack haben. QMS wird mit der Liste der GPX Dateien aufgerufen und testet ob schon eine andere Instanz von QMS läuft. Das macht es indem es nach einem sog. Socket sucht. Das ist ein Mechanismus mit dem Daten zwischen zwei Programmen austauschen kann. Existiert so ein Socket wird die Liste der Dateien an die erste Instanz geschickt und die Zweite beendet sich. Das Spielchen kann so oft wiederholt werden wie nötig.

Das ist auch im Log zu sehen.

Bei der ersten Instanz:

qmapshack -d foo.gpx
...


2019-04-14 11:09:34.879 [debug] CSingleInstanceProxy: Single instance server socket listening to "/tmp/QMapShack-xxxxxx"

Und bei der zweiten Instanz:

qmapshack -d bar.gpx


...


2019-04-14 11:06:43.557 [debug] Sent parameters to primary instance. Result true
2019-04-14 11:06:43.557 [debug] There can only be one. Exit.

Wichtig ist 'Result true'. Bei 'false' wurden die Dateien nicht akzeptiert. Die zweite Instanz sollte sich sofort beenden. Und das kann man immer wieder wiederholen.

Zitat von Stoertebaecker

Bedeutet also, das 64s hat zu wenig Speicherplatz?

.

Von dem Speicher, der wirklich kostet, ja. Und bei intelligenter Routenplanung reichen 50 Zwischenpunkte locker.

Die Anzahl der Zwischenpunkte bei einer Route hat nichts mit der Karte zu tun, sondern mit der Limitierung der Gerätesoftware.

Zwischen den Punkten sollte das Gerät selbständig die nötigen Details berechnen. Meistens reichen ein paar Zwischenpunkte, damit die automatische Berechnung verlässlich das macht was man will.

Welche Karte, kannst nur Du entscheiden. Wenn bei OSM in den Gebieten wo Du dich aufhältst zu viele Straßen fehlen, dann kann eine kommerzielle Karte eventuell besser sein. In der Regel sind die aber auch oft veraltet, sprich haben Wege die es nicht mehr gibt und dafür fehlen neuere Wege.

Die kommerziellen Karten haben zudem den Vorteil, dass man mit Active Routing ein wenig die Berechnung nach den eigenen Vorlieben steuern kann. Ich würde aber keine Wunder erwarten.

Version 6 ist doch ok. Würde ich so lassen.

Zitat von Linux

Ich habe hier OpenSuse Tumbleweed und ein aktuellstes qMapShack. Das will aber seit neustem nicht mehr cmaken.

Also bei Tumbleweed wird eigentlich schon alles installiert. Ich habe die Pakete libproj15, proj und proj-devel jeweils in der Version 6.0.0 installiert.

Ich habe einen Patch ins Repo geschoben, der vorerst das Problem auf Debian Systemen beheben sollte. Ich kann es nicht testen weil hier kein Debian läuft. Also versucht es einfach mal.

Ach ja, wer das ähnlich pragmatisch sieht und der Meinung ist, dass die Developer Pakete für QuZip5 und PROJ von Debian die beiden CMake Skripten enthalten sollten, der kann ja auf der Debian Seite einen Bugreport erstellen.

Hä? Auch nach mehrmaligem Lesen, verstehe ich nicht was Du willst.

Das Thema ist bekannt und wurde auf der Mailingliste diskutiert

https://sourceforge.net/p/qlan…iewmonth=201904&viewday=9

Kurz der Debian Betreuer ist der Meinung, dass nur das ins Paket kommt, was bei seiner Methode PROJ zu compilieren anfällt. Da er Autoconf und nicht CMak benutzt entsteht das nötige CMake Skript nicht und ist deshalb nicht Bestandteil des Developer Paketes.

Außerdem ist er der Meinung das CMake Skripten, die nicht dort landen, wo nach Debians Ansicht CMake Skripten liegen sollten, auch nicht ins Pakete gehen. Das ist der Fall bei QuaZip.

SuSE, das verwende ich, ist hier besser aufgestellt. Oder einfach pragmatischer. Zusätzlich habe ich den Betreuer bei Fedora gefragt, wie er das sieht. Ähnlich pragmatisch: Eine Distribution sollte eigentlich alles was möglich ist installieren, damit eben solche Sachen nicht passieren. Zur Not ist es die Aufgabe des Betreuers dafür zu sorgen, dass alles an seinem richtigen Platz zu finden ist.

Und grundsätzlich ist es vorzuziehen, solche Skripten nicht in jedem Projekt lokal zu halten, weil das recht flott veraltet. Bisher wurden die lokal gehalten, weil es zu dem Zeitpunkt als das Projekt anfing noch keine Skripten gab. Das hat sich in den letzten 10 Jahren aber geändert und ich würde gerne die Skripten benützen, die QuaZip und PROJ bereitstellen.

Mal schaun ob bei diesem Thema irgendwann Vernunft einkehrt.

Wer will kann die beiden Patches im Anhang anwenden, die die betreffenden Skripten wieder im Source hinterlegen.

Zitat von Slow Foot

Die Sammelablage habe noch nicht ganz verstanden - gibt es hier die 4 Möglichkeiten für alle DB's?
Dann mus das sehr gut überlegt sein wofür man das einsetzt.

Aktuell gibt es nur 4 Ablagen, dass ist richtig. Allerdings auch nicht in Stein gemeißelt. Sollte sich mal ein Use-Case erschließen, bei dem man mehr benötigt kann man den Code anpassen.

Zitat von Slow Foot

Die Beschreibung würde ich gerne nutzen, bin aber da momentan ich einer Sackgasse gelandet und bräuchte eine kurze Navgationshilfe

Bei der Installation des QT developer package hat meine SSD leider Platzangst bekommen
Ist nur der QT Designer ausreichend?
Den hätte ich hier gefunden:
https://build-system.fman.io/qt-designer-download
Version ist 5.11.1

Alles anzeigen

Es ist nur der Designer nötig. Den Rest brauch man nicht.

Zitat von Slow Foot

Und als nächtses würde ich gerne die built-in Textvorlagen kopieren und für meine Bedürfnisse adaptieren, ich finde die aber nicht.

Dazu müsst Du das Source Code Archiv von Bitbucket ziehen oder:

https://bitbucket.org/maproom/…ack/templates/?at=default

Bei diesen, zum größten Teil antiquaren Programmen, kann man eine Projektion festlegen, die dann zusammen mit der tfw Datei verwendet wird um die Tif Datei referenziert darzustellen.

Wenn Du uns sagen kannst in welcher Projektion deine Tif Datei angefertigt wurde, können wir dir die GDAL Befehlszeile sagen mit der Du die Datei in ein GeoTiff umwandeln kannst.

Das World File beinhaltet die Referenzpunkte zu der Karte. Aber leider nicht deren Projektion. Wenn man die Projektion kennt kann man mit GDAL daraus ein GeoTiff erstellen, welches dann alle Information beinhaltet.

Fluch und Segen eines empfindlicheren Empfängers. Das 64er hat halt auch bei schlechten Bedingungen noch einen Fix. Mit den damit einhergehenden größeren bis sehr großen Fehlern. Das 30er steckt einfach eher den Kopf in den Sand.

Wenn man seinen Tracks gleich aussagekräftige Namen und Beschreibungen verpasst kann man danach die Datenbank durchsuchen. Bei den Beschreibungen helfen die Vorlagen. Man kann auch eigene Vorlagen erstellen.

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

Damit kann man verlorene Schafe wieder finden.

Zitat von Slow Foot

Ich suche nach einer Möglichkeit einfach alle Projekte, bzw. Projekte einer DB, zu markieren und damit den gesamten Inhalt anzuzeigen.
Gibt es diese Funktion?

Nein gibt es nicht. Macht wohl bei den meisten Datenbanken auch keinen Sinn weil dort auch Daten liegen können, die man nicht wirklich sehen will (z.b. Tracks von anderen Geräten, Planungstracks, etc).

Ich kann nur noch einmal die Sammelablagen ans Herz legen. Einmal aufgesetzt und dann konsequent gepflegt, kann man sich damit sehr gut einen Überblick verschaffen.

https://bitbucket.org/maproom/…y-projects-and-drop-zones

Mit ein wenig mehr Investition kannst Du dir auch schon ein Smartphone kaufen, dass neben dem L1 Band auch das L5 Band auswertet und damit Genauigkeiten um 1m erzielt.

Zitat von gpsmichel

Nebenbei hat man dann noch ein vollständiges Smartphone dabei, könnte Musik damit hören, Fotos machen usw.

Dann wird es aber schon wieder knapp mit einer Akkuladung pro Tag.

Außerdem versteht sich hoffentlich von selbst, dass ein Smartphone in der Situation versagt, wo man dringend ein GPS benötigt. Sprich bei kaltem, nassen Wetter mit sehr schlechter Sicht. Der Lipo Akku wird zusammenbrechen. Das kapazitive Display eine Tortur zum bedienen. Aber als Orientierungshilfe und Trackrecorder bei den üblichen Unternehmungen, sollte es darauf nicht ankommen.

Zitat von gpsmichel

Ja, das wäre ne Überlegung wert... wobei ein Handy bei intensiver Navigationsnutzung kaum 2-3 Tagestouren hält...
Wo ich mir auch nicht dicher bin, ist das Display. Gibt es tatsächlich Smartphone-Displays, die in der Sonne (gut) ablesbar sind? Grosse Displays haben die klar, bei 5-6 Zoll klappts auch mit der Altersweitsichtigkeit...:D

Bezüglich der Ablesbarkeit bei Sonne stehen sich neuere Smartphones und das Aventura in nichts nach. Ungefähr gleich gut, bzw schlecht. Wie man es sieht. Bei starker Sonne und einer Sonnenbrille (Kategorie 3) sind beide vom Kontrast her schwierig zu lesen. Junge Augen mögen da noch weniger Probleme haben.

Bei einer schwächer getönten Sonnenbrille, z.B. mit gelb/orangen Gläsern, Schnee und Sonne geht's so halbwegs.

Bei sommerlichen Bedingungen auf einem Gletscher (Gläser mit Tönung Kategorie 4 ) ist nichts mehr zu erkennen. Hier hilft nur noch echtes transreflektives Display, welches bei Smartphones oder den TwoNav Geräten nicht zu finden ist.

Kommt somit ein wenig darauf an was man damit anstellen will.