Beiträge von tormet

Zitat von Vold

Hello Tormet

Ich will Unterkünfte aus dem Bikeline Buch als Waypoint speichern,
dazu möchte ich die Nummer des dazugehörigen Blattes im Namen des Waypoints angeben.

z.B. 144-3 Seite 144, Spalte 3.

Danke,

dann kann ich das Problem aber nicht nachvollziehen.

Sprich wenn du den Waypoint anlegst, dann musst du doch eh einen neuen Namen vergeben. Ist der alte Waypoint z.B. A144-1. dann ist der Name für den nächsten Waypoint doch auch erst mal A144-1. und du musst ihn dann z.B. auf A145-3. ändern. Ist der alte Name A144-1 dann ist der nächste neue Waypoint erst einmal A144-2 und du musst ihn dann auch ändern, z.B. auf A145-3.

In beiden Fällen musst du manuell etwas tun. Der Aufwand dürfte doch in etwa gleich sein.

Übersehe ich hier etwas?

Ja das ist ein Feature und es passiert nur wenn das letzte Zeichen des Namens eine Zahl ist. Dein Workaround ist daher OK.

Ich verstehe nur nur noch nicht, wo dieses Feature zu einem Problem oder einem Fehler führt?

Ja hiermit ist es möglich automatisch einen bereits existierenden Waypointnamen für den nächsten Wapoint zu erhalten. Aber dies kann natürlich auch in anderen Situationen passieren.

Was machst du also genau, dass dich dies so stört bzw. das dies sogar zu Fehlern führt?

BTW should I use english?

Hi,

das ist by Design und nicht zu ändern. Es sei denn du baust dir deine eigene QMS Version und entfernst dieses Feature dort für dich.

Schön wäre hier auch eine etwas ausführlichere Beschreibung des Fehlers und deiner Anwendung.

• Was machst du gerade und warum stört dich dabei die Erhöhung um 1. Was hättest du sonst gerne und warum?
• Warum führt dies immer wieder zu Fehlern oder was siehst du hier als Fehler?

Torsten

Hallo,

bisher habe ich hier nur mit gelesen und von den guten Beiträgen profitiert.

Da ich die hier geschilderte Problematik kenne, dachte ich mir, ich teile mein Wissen hierzu mal. Vielleicht hilft es ja. Vorsicht es ist etwas länglich.

Ich selbst benutze ein Ubuntu 20.04.2 LTS System. Das hier beschriebene Vorgehen dürfte sich aber auf andere Systeme übertragen lassen.

Ich selbst vermeide es gerne neue Libraries, die ich zum Entwickeln brauche, hier z.B. für QMS, einfach so in mein Produktivsystem einzuspielen und diese mit den bestehen alten Libraries zu vermischen. Wenn es geht, lasse ich dies bleiben.

Die Idee ist, diese einfach nicht ins System, sondern in ein anderes Verzeichnis einzuspielen und sie von dort zu benutzen.

Im folgenden beziehe ich mich auf die Anleitung unter https://github.com/Maproom/qmapshack/wiki/BuildUbuntuPROJ8 und beschreibe wie man diese modifiziert benutzen kann um die Idee umzusetzen.

Ich fange ab Install PROJ version 8 an und gehe davon aus, der Rest ist passend auf dem System installiert. Z.B. weil man QMS 1.15.2 schon mal gebaut hat.

Ich benutze hier im folgenden als Präfix des neuen Installationsverzeichnisses immer /home/tormet/QMSDEVDIR/usr

Habe ich für das Verzeichnis Schreibrechte, brauche ich natürlich auch kein sudo beim Installieren.

(1) Install PROJ version 8

So wie es da steht nur eben mit -DCMAKE_INSTALL_PREFIX=/home/tormet/QMSDEVDIR/usr

(2) Install GDAL

Hier muss man den configure Aufruf anpassen um keinen Konflikt mit der System libproj.so Library zu kriegen.

./configure --prefix=/home/tormet/QMSDEVDIR/usr --without-libtool --with-proj=/home/tormet/QMSDEVDIR/usr -with-geotiff=internal

Rest wie es das steht.

Hintergrund: Die libgeotiff.so vom System bringt eine Abhängigkeit zur libproj.so vom System mit und damit kriegt man den Konflikt, das sowohl libproj.so.15 (alt) als auch libproj.so.22 (neu) benötigt wird.

tormet:~$ ldd /lib/x86_64-linux-gnu/libgeotiff.so | grep libpro

libproj.so.15 => /lib/x86_64-linux-gnu/libproj.so.15 (0x00007fa4f822e000)

Im Prinzip ist das der "schwierige" Schritt, wenn man die Idee mit dem eigenen Verzeichnis umsetzen möchte. Der Rest funktioniert glücklicherweise kanonisch ohne das man sich Gedanken machen muss. Das Problem ist hier die versteckte Abhängigkeit zur System libproj.so, die durch das Linken mit der libgeotiff.so aus dem System entsteht.

(3) Install QUAZIP

So wie es da steht nur eben mit -DCMAKE_INSTALL_PREFIX=/home/tormet/QMSDEVDIR/usr

(4) Install Routino

Dies wäre bei mir nicht nötig. Routino vom System tut es.

Der Vollständigkeit halber habe ich es trotzdem gemacht.

Ich ändere natürlich die Zeile 48 auf: prefix=/home/tormet/QMSDEVDIR/usr

(5) Install QMapShack

Da ich die vorherigen Pakete nicht ins System eingespielt habe, muss man hier beim Konfigurieren mit ccmake etwas mehr tun.

ccmake ../QMapShack -DCMAKE_INSTALL_PREFIX=/home/tormet/QMSDEVDIR/usr -DGDAL_CONFIG=/home/tormet/QMSDEVDIR/usr/bin/gdal-config -DGDAL_INCLUDE_DIR=/home/tormet/QMSDEVDIR/usr/include -DGDAL_LIBRARY=/home/tormet/QMSDEVDIR/usr/lib/libgdal.so -DLIBROUTINO_LIBRARY=/home/tormet/QMSDEVDIR/usr/lib/libroutino.so -DROUTINO_INCLUDE_DIR=/home/tormet/QMSDEVDIR/usr/include -DROUTINO_XML_PATH=/home/tormet/QMSDEVDIR/usr/share/routino

Automatisch werden bei mir bereits:

QuaZip-Qt5_dir: /home/tormet/Software/Linux/QMSDEVDIR/usr/lib/cmake/QuaZip-Qt5-1.1

PROJ_DIR: /home/tormet/QMSDEVDIR/usr/lib/cmake/proj

gesetzt.

Möchte man auf Nummer sicher gehen kann man diese im ccmake Aufruf natürlich auch noch per Hand setzen.

Der Rest so wie es da steht.

Jetzt habe ich ein aktuelles QMS ohne mein System "verändert" zu haben.

Startet man nun QMS direkt aus dem build_QMapShack Verzeichnis mit ./bin/qmapshack funktioniert es sofort.

Da es keine Konflikte mit unterschiedlichen libproj.so Libraries gibt, stürzt QMS beim Beenden auch nicht mehr ab.

Z.B. mit Fehlermeldungen im Terminal wie:

double free or corruption (out)

Aborted (core dumped)

Möchte man es aus dem Installationverzeichnis heraus starten, muss noch der LD_LIBRRAY_PATH gesetzt werden. In einer Bash bei mir z.B. mit:

(export LD_LIBRARY_PATH=/home/tormet/QMSDEVDIR/usr/lib:; /home/tormet/QMSDEVDIR/usr/bin/qmapshack & )

Ich denke je nachdem wie ihr es bei euch einbinden wollt, werdet ihr hier schon das passende für euch finden.

Vielleicht hilft das ja einigen,

Torsten