Beiträge von kiozen

Der Windows Installer installiert auch GDAL. Da werden auch noch ein paar Umgebungsvariablen gesetzt. Ich vermute mal die fehlen, bzw stehen falsch. Helmut kennt sich da aber besser aus.

Zitat von FlockVi

a) danke für den Tipp mit drag und drop
b) hast sicher recht mit dem Vorschlag: konstruktiv mitzuarbeiten wär besser als nur Probleme aufzuzeigen ...

Sorry, ich bin halt neu in dem Forum und dachte, daß das melden von Bugs vielleicht auch hilfreich wäre.

Nimm es nicht persönlich. Du hast ja wenigstens den Fehler endlich mal angezeigt.

Der richtige Ort für Fehlermeldungen ist übrigens hier:

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

Dann haben alle was davon.

Ich habe das mal mit ins Wiki übernommen.

Das Wiki ist übrigens auch keine Einbahnstraße. Und fern von perfekt. Eigentlich kann sich dort jeder mit einem Bitbucket Login einbringen.

Im Ordner "nsi" gibt es eine Datei 3rdparty.txt und HOWTO-BUILD.txt. Das würde ich mal als Start nehmen.

Man muss übrigens nicht VisualStudio benützen (das benötigt man nur, um einfach an den Compiler zu kommen). CMake kann auch ein makefile für NMake produzieren, das man von der Kommandozeile aus benützen kann.

Es ist auch ein Irrglaube zu denken, dass Linuxbenutzer alle ein abgeschlossenes Informatikstudium haben und deswegen trittsicher beim Compilieren von Software sind. Der Emanuel hat zum Beispiel in mühsamer Kleinarbeit diese Seite zusammengestellt:

http://www.mtb-touring.net/qms/qmapshack-und-linux-mint/

Und wenn man die Diskussion am Ende verfolgt, dann wird offensichtlich, dass es Zeit und Nerven gefordert hat und keine Fachmänner am Werk waren.

Aber genau hier besteht der Unterschied in der Denkkultur. Hier hilft man sich gegenseitig. Fehler werden nicht ignoriert, in der Hoffnung es könnte sich von selbst lösen. An einer Lösung wird aktiv teilgenommen, anstatt einfach nur zu erwarten, dass jetzt doch mal jemand für einen springt und es einem schön klickiklackibunti aufsetzt.

Für den Emanuel zahlt sich das aus, weil er nicht erst beim Release feststellen muss, dass das heiß ersehnte Feature sich doch nicht so verhält, wie er es gerne hätte. Sondern er kann vorher schon auf Fehler hinweisen. Und er kann auf Anleitung einen vernünftigen Fehlerbericht bei einem Absturz generieren.

Was meint ihr wie lange es gebraucht hat herauszufinden warum die OSM Karte unter Windows nicht angezeigt wurde, sondern mit einem Crash das Programm beendet haben? Monatelang hat keiner was gesagt. Dann hat mal jemand gesagt, er sieht bei der Karte nichts. Dann kamen mehrere, die das bestätigt haben. Da Helmut und ich das Problem nicht hatten, haben wir alle gebeten doch mal selber zu compilieren, um das Problem einzugrenzen, indem man Schritt für Schritt durch den Code geht. Auf Seiten der Anwender wurde das mit Fassungslosigkeit aufgenommen. Wie? Wir sollen was machen? Nee, das können wir nicht. Nur durch Zufall sind wir auf eine fehlende OpenSSL Installation gekommen. Das wäre schneller gegangen, wenn die Benutzer mehr Engagement gezeigt hätten, als nur mal ein neues Binary auf hop oder top zu testen.

Sich einbringen hilft. Beiden Seiten. Oder seid ihr von kommerzieller Software so auf Linie gebracht, dass die Welt echt nur noch daraus besteht neue Releases zu testen, darüber zu jammern was nicht geht und dann auf das nächste Release zu hoffen. Meistens umsonst. Weil vom Aussitzen hat sich selten ein Problem gelöst.

Drag-n-drop sollte auch funktionieren. Mit den Einstellungen.

Wenn man über das Menü geht verschwinden die Einstellungen leider. Das ist richtig und wird im nächsten Release gefixed sein. Oder man schmeißt selber den Compiler an.

Mal ganz generell:
Es wäre sehr hilfreich, wenn auch mal die Windowsbenutzer sich ein wenig mehr einbringen würden. Immer nur nach einem Release vielleicht einen Fehlerreport abdrücken, irgendwo, wenn es sein muss, ist eigentlich nicht im Sinne von OpenSource.

Auf der Linux Seite gibt es mehrere Benutzer, die regelmäßig auch mal einen Zwischenstand kompilieren und testen. Und das ohne große Programmierkenntnisse. Die denken einfach nur mit und lesen Dokumentation, bzw schreiben ihre Erfahrungen auf, damit jemand anderes es ihnen gleich tun kann. So werden Fehler im Vorfeld eines Release gefunden. Und nicht erst zwei drei Releases später, weil sich endlich mal jemand bequemt hat was zu sagen.

Das ist der Beitrag, den man leisten sollte, wenn man schon davon profitiert, dass Software für lau zur Verfügung gestellt wird. OpenSource ist nicht Freeware. Sondern die Idee, dass Software besser wird, wenn alle mithelfen. Diesen Anspruch kommen genügend Benutzer auf der Linux Seite nach. Auf der Windows Seite herrscht hier seit Jahren eine Nulllinie. Das frustriert und motiviert in keiner Weise sich für eine Portierung einzusetzen. Das hat nicht zuletzt zum Einstellen des Win32 Ports geführt. Und das sehe ich auch in der näheren Zukunft für den Win64 Port kommen.

Passt schon. Ich habe gelacht. Sollte ich mal in den Splash Screen bringen. Um so ein wenig Druck aufzubauen

Bitte testen und Feedback geben:

https://bitbucket.org/huirad/test/downloads

Zitat von papaluna

- Qmapshack(freeware, 28 Tage Testversion verfügbar)

Hä? Habe ich was nicht mitbekommen? Das sind mindestens 29,314... Tage:D

Danke fürs melden.

Bei Routino scheint eine Bibliothek zu fehlen (libz-1.dll für mingw64).

Das mit den Karten ist wohl ein Qt5 Bug:

https://bugreports.qt.io/browse/QTBUG-46642

Ich werde die Funktion ins Kontextmenü übernehmen. Dann gibt es eine Alternative. (die hoffentlich funktioniert)

Die Spanienkarten gab es mal als JNX.

Du kannst natürlich auch den Weg über GDAL gehen:

http://www.gdal.org/frmt_wmts.html

Für die XML Datei musst Du dann noch mit gdalbuildvrt eine *.vrt Datei erstellen. Diese wird von QMS erkannt. Wobei ich nicht weiß in wie weit das unter Windows unterstützt wird. Ich glaube da fehlt noch eine curl.dll. Siehe auch:

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

Geht nicht.

In WMTS können die wichtigen Dinge auf vielerlei Möglichkeiten definiert sein. Der aktuelle Code unterstützt nur einige wenige. WMTS vollständig zu unterstützen ist sehr aufwändig. Und da ich keine WMTS Karten benutze, ist die Motivation das allumfassend zu implementieren sehr gering. Vielleicht findet sich ja mal jemand der viele verschiedene WMTS Karten benutzt und deswegen die Lust aufbringt den Code zu erweitern und zu pflegen.

Inzwischen hat sich wieder mal einiges getan. Hauptsächlich im Bereich der GPX Erweiterungen bei den Trackpunkten. Also dort wo die Geräte mit einem heillosen durcheinander Puls, Temperatur, Kurs usw. abspeichern.

QMapShack liest diese Erweiterungen unabhängig vom den Tags ein. Mit anderen Worten: QMapShack muss eine Erweiterung nicht explizit kennen. Und es kann diese Erweiterungen auch wieder in einer GPX Datei speichern. Wer also solche Dateien hat, kann diese in QMapShack bearbeiten ohne Information zu verlieren. Soweit der Plan. Mit den bisherigen Testdateien funktioniert das.

In QMapShack kann man diese Erweiterungen, sofern sie numerischer Natur sind, in einem Diagramm anzeigen lassen. Oder, auch das ist neu, sie zum Kolorieren des Tracks verwenden. z.B. die Steigung rot einfärben, um zu wissen ob man das mit dem Rad noch schafft.

Zudem wurden zahlreiche Bugs entfernt. Unter anderem einer, der für zufällige Abstürze gesorgt hat.

Und die Dokumentation für Tracks und Wegpunkte wurde überarbeitet:
https://bitbucket.org/maproom/qmapshack/wiki/DocGisItemsTrk2
https://bitbucket.org/maproom/qmapshack/wiki/DocGisItemsWpt

Source Code und binäre Pakete für Windows 64Bit und OS X stehen auf Bitbucket bereit:

https://bitbucket.org/maproom/qmapshack/downloads

Die Benutzer von Linux kompilieren es sich selber oder schauen bei ihrer Distribution nach den fertigen Paketen.

V 1.5.1
Line edit: Fix broken abort button


V 1.5.0
* Add track filter to remove track points with invalid position
* Add options to "cut track" function (keep only first or second, keep both)
* Add Dutch translation (not finished yet)
* Add selection of track properties as source for graphs
* Add colorize track by track point properties
* [Issue #68] Bubbles not moving when moving the map
* [Issue #67] "Save Map Screenshot" does not save grid correctly
* [Issue #69] "light gray" colored tracks are displayed in "dark blue" when imported from GPX file
* [Issue #72] Database/Workspace inconsisteny in QMS 1.4.0
* [Issue #70] Removed maximumSize for comboGrades
* [Issue #19] Map-drag resizes or moves window with KDE 5
* Many little bugfixes, some of them causing random crashes


V 1.4.0
* Export selected map area to image or printer
* Add activity to trackpoints to differentiate track statistic
* Add dialog to setup coord. format
* Add option to send console debug output to a logfile
* Add `Show on/Hide from Map` in context menu of one or more projects
* Add closing the `Track Profile` view via keypress ESC
* Add stepwise aborting of current operation in `Add Track/Route/Area` (similar to using right mouse / button `Abort`)
* Fix: Qt5 internal translations for Linux
* Fix: Line Edit usage hint is not removed on abort
* Fix: OS X, various path issues. (icon path, workspace not saved)
* Map: Fix race conditions in WMTS/TMS map handler
* Map: Add hint for missing SSL library when using WMTS/TMS maps
* Map: Slowdown automatic map panning
* Trk: Fix Douglas-Peuker filter
* Trk: Read & write 3rd party track point extensions
* Trk: extend track point info by extension values
* [Issue #57] Trk: Fix color table for green and gray
* [Issue #59] Not possible to change names of empty projects
* [Issue #60] Tab label is not updated when track name is changed
* [Issue #54] In tracks editor, mouse cursor does not change according to selected tool with keyboard shortcut
* [Issue #64] Install QMapShack icon in hicolor theme too.
* [Issue #65] loading routino XML files fixed (added to bundle and support for OS-X specific directory structure).
* [Issue #61] Add average speed to selected area statistics popup
* [Issue #32] Add arrows to indicate edited track direction

Im Vergleich mit zahlreichen anderen Geräten hat die exponierte Antenne der 60er Serie bei schlechten Empfangsbedingungen immer einen Tick besseren Empfang. Sprich die Geräte verlieren die Position ein wenig später, bzw haben wieder ein wenig früher eine zuverlässige Position.

Sonst ist der Empfang so wie man ihn bei der Geräteklasse erwarten kann. 10-15m Genauigkeit. Und eine Streuung von 5m. Die Antenne hat eine Richtwirkung. Das Gerät waagrecht gehalten ist schlechter als senkrecht an der Schulter.

Verglichen zum 60er mit dem SirfIII sind die neuen Chipsätze deutlich ruhiger und haben weniger Drift im Stand.

Naja einen Track selber malen ist jetzt auch nicht so die Welt. Oder eben nur echte eigene Aufzeichnungen verwenden. Kommt bei der Öffentlichkeitsarbeit auch viel authentischer rüber.

Das ist ein wenig problematisch bei Flüssen. Ok ein kleiner Bach, das ist eine Linie. Aber die Weser ist ein Wasserkörper. Den stellt man nicht mehr mit einer Linie dar, sondern mit einem Polygon. Und wo soll auf diesem Polygon jetzt der Track verlaufen. Gut, manchmal sind bei großen Flüssen die offiziellen Fahrspuren verzeichnet. Mit dem Kajak vielleicht nicht ganz so praktisch.

Also bräuchtest Du Tracks von gefahrenen Touren, bzw redaktionell erstellte Tracks. Die wirst Du aber nicht hier finden, sondern nur in einem Fachforum für solche Touren.

Oder den Planungstrack mit der entsprechenden Software selber manuell einzeichnen.

Wenn Du es wirklich herausbekommen willst musst Du das Programm selber als Debugversion kompilieren. Dann kann man bei einem Absturz anhand des Backtrace wo der Fehler sitzt.

Da QLGT nicht mehr aktiv entwickelt wird, musst Du dich selber darum kümmern.

Zitat von Hoefo

Von den direkten 60er Nachfolgern (62/64) liest man ja leider eher Schlechtes. Hat denn jemand mit ähnlichen Anforderungen wie ich diesbezüglich Erfahrungen sowohl mit dem 60er als auch dem 62er oder 64er gemacht?

Ich hatte ein 60er und habe ein 62er und 64er.

Konzeptionell unterscheiden sich 62/64er deutlich vom 60er. Ein paar Dinge sind weggefallen. Dafür sind ein paar sehr praktische Dinge hinzugekommen. Darüber kann man sich aufregen. Oder man akzeptiert das. Schlecht im technischen Sinne ist das aktuelle 64er nicht.

Die Robustheit hat etwas nachgelassen. Zwar ist die Sollbruchstelle am Batteriedeckel verschwunden und die Halterung ist nicht mehr so sklerotisch. Der Plastik ist allerdings dünner und der Gummi auch. Bei meinem 62er hat sich nach 4 Jahren der Gummi komplett aufgelöst. Das Gerät ist im Freien nicht mehr zu verwenden.

Alternativen gibt es kaum. Vor allem nicht mit Tasten.

Richtig. Der Vorbesitzer dürfte sie nie verwendet haben.

Garmin will, dass Du pro Stück Hardware eine Karte kaufst. "Stück Hardware" heißt in diesem Fall ein Gerät oder eine SD Karte. Die Karte von der einen Hardware auf die andere zu übertragen ist nicht vorgesehen. In der heutigen Welt lohnt es sich die Lizenz- und Nutzungsbestimmungen vor dem Kauf genau zu studieren und zu verstehen. Sonst fühlt man sich nachher ein wenig übervorteilt.

Die TopoDE und Transalpin verwendest Du ja selten zugleich. Musst Du eben SD Karte wechseln.