QMapShack

Quellen für Karten und DEM Dateien werden in der Dokumentation erwähnt:

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

Unter "Sources of Maps and DEM files"

Wenn du dich im "+" Mode den Endpunkten näherst, werden nur diese rot. Nicht das ganze Segment. Einfach mal ein wenig mit der Maus jonglieren. Ist nur der Punkt rot, kann ein weiterer Punkt am jeweiligen Ende hinzugefügt werden.

Ich unterstütze nur den Sourcecode

Helmut, der sich um die Windows Installation kümmert, hat die Portierung auf 32 Bit aufgegeben. An einigen Stellen machen die 32 Bit Probleme und es müsste sich jemand aktiv darum kümmern. Da Helmut schon seit Jahren auf 64 Bit umgestiegen ist, hat er wenig Lust Zeit in eine Technologie zu stecken, die getrost als überholt zu bezeichnen ist.

Wer also meint, er braucht unbedingt 32 Bit, der muss sich in Zukunft selber aktiv werden.

Zitat von Emvau

Danke für deine Antwort!
Windows10 in 32-bit spielt aber gerade bei handlichen und stromsparenden Tablets eine große Rolle, weil 32-bit hier oftmals Ressourcen-freundlicher ist. Insgesamt ist es sicherlich verbreiteter als Linux. Insofern ist es fast absurd, dass man diese Software nicht mehr für 32-bit anbieten möchte. Aber ich verstehe schon, es gibt einfach niemand, der das machen möchte.

Ist es denn wirklich resourcenfreundlicher? Die These ist gewagt, da die meisten verwendeten Datentypen immer noch 32bit sind. Nur dort wo es 64 Bit Typen benötigt, kann ein 64Bit System diese Typen nativ verarbeiten. Ein 32Bit System muss mit vielen extra Zyklen das Problem umgehen.

Zitat von Emvau

Was müsste ich denn können? Ich habe nie kompiliert und verfüge auch nicht über Programmierkenntisse. Ich habe neben einem Tablet einen Desktop Windows-10-Rechner mit 4gb Arbeitsspeicher. Kann ich irgendwo effizient lernen, wie ich aus der Source einen Win32-Installer macht? Und wie konkret muss ich die Probleme speziell bei Win32 einordnen?

Hier geht es um Probleme bei der Speicherverwaltung und darum das Microsoft die plattformübergreifenden APIs schlampig und inkonsequent programmiert hat. Das führt zu Abstürzen und komischen Verhalten. Die Lösung wäre, diese Stellen durch die proprietäre Microsoft API zu ersetzen. Oder anders gesagt: Hier braucht es jemanden der wirklich Ahnung vom programmieren hat. Und auch Poweruser von QMS ist, um alle diese Stellen zu finden und zu beheben. Nicht gerade das Thema um mit dem Programmieren anzufangen

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

Speziell alles zu "Select Range"

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.

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

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)

Bitte testen und Feedback geben:

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

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.