Beiträge von wthaemelt

Zitat

Sofern ich mich richtig erinnere und das im Code richtig sehe, werden unter Windows alle Einstellungen in der Registry gespeichert. Ich würde deswegen davon ausgehen, dass diese Einträge auch nach dem deinstallieren von QMapShack noch vorhanden sind und von einer erneuten Installation verwendet werden können.

Stimmt nicht ganz: Wenn man mit einer INI-Datei arbeitet, dann stehen die Informationen dort.

Und es gibt die workspace.db mit einem anderen Teil Informationen. Die registry-Einträge wie auch die INI-Dateien werden durch Deinstallieren nicht berührt, auch die workspace.db nicht. Es gibt aber auch noch die Verzeichnisse für Karten, DEM, Routing-Dateien,... Auch diese werden nicht angefasst, es sei denn, man hat sie ungeschickterweise ins Installationsverzeichnis gelegt.

Die Antwort hängt davon ab, wie die alte Version installiert worden ist.

Vorsicht ist die Mutter der Porzellankiste: also am besten alle eingerichteten Konfigurationen erst einmal sichern. Die QMS Hilfe gibt Auskunft darüber, wo was gespeichert wird.

Dann die vorhandene alte uninstaller.exe starten.

Soweit ich diese kenne, bleiben alle Konfigurationen dabei erhalten ( es werden gelöscht: gesamtes Installationsverzeichnis - gefährlich, wenn hier Konfigurationsdaten vom Nutzer abgelegt worden sind, das Startmenü sowie der Registereintrag "HKCU "Software\QMapShack").

Vorhandene Umgebungsvariablen, die irgendwie auf QMS-Verzeichnisse verweisen löschen (diese könnten mit Hand angelegt worden sein).

Danach die neue Version installieren, diese müsste sofort die vorhandene alte Konfiguration erkennen und benutzen.

Wenn kein uninstaller existiert, dann ebenfalls die vorhandenen Umgebungsvariablen löschen und vorsichtshalber in ein neues Verzeichnis installieren.

Bei mir funktionierte eine Parallelinstallation ohne Löschen der alten Version unter Beachtung der Umgebungsvariablen problemlos. Sollte man aber vielleicht nicht unbedingt machen.

Und Vorsicht bei MBTiles: es gibt Formatvarianten (Vektorkarten?), die QMS nicht verarbeiten kann. Man erkennt diese, wenn man sich mit `gdalinfo.exe` die MBTiles-Eigenschaften anzeigen lässt.

kiozen: Für ECW braucht man natürlich eine zusätzliche DLL. Diese wird als `gdal_ECW_JP2ECW.dll` im GDAL plugin-Verzeichnis vom Installer mitgeliefert - das ist einer der GISInternals-Vorteile.

Papaluna: Die mögliche Existenz der genannten Umgebungsvariablen ist ein Grund, beim QMS-Installer darauf zu verzichten, diese zu verändern. Bitte mal die gdalplugins-Verzeichnisse von osgeo und dem installierten QMS vergleichen. Im QMS-Verzeichnis werden wahrscheinlich DLLs stehen, die bei osgeo nicht erscheinen. Mögliche Lösung in diesem Falle: Umgebungsvariablen zeitweilig für QMS verändern.

WST: Ein Hinweis auf der eigentlichen Github-QMS-Seite ist vorgesehen, kommt sicher, nachdem die ersten Kommentare zum Installer erledigt sind.

Sind die Umgebungsvariablen `GDAL_DATA` und `GDAL_DRIVER_PATH` gesetzt (Verweisen auf GDAL data und GDAL plugins Verzeichnis)?

Zunächst probeweise habe ich diesen Link zur QMS Installation unter Windows erstellt:

https://github.com/wthaem/qmapshack/releases/download/V1.17.0/QMapShack-1.17.0_x64_setup.exe

Vielleicht auch die zugehörige volle Seite anschauen:

Release QMapShack V1.17.0 for Microsoft Windows · wthaem/qmapshack

This is QMapShack forked from https://github.com/Maproom/qmapshack for building a Microsoft Windows version. This release tries to stay in-sync with the…

github.com

Bitte auftretende Schwierigkeiten mitteilen.

Kopiere die folgenden Zeilen in eine TMS-Datei. Dann sollte es funktionieren (finde z.B. das Leuchtfeuer in Laboe):

<TMS>    
<Layer idx="0">
<Title>OpenSeaMap (WMTS)</Title>
<MinZoomLevel>1</MinZoomLevel>
<MaxZoomLevel>19</MaxZoomLevel>
 
<ServerUrl>https://t1.openseamap.org/seamark/%1/%2/%3.png</ServerUrl>
</Layer>
 <RawHeader>
   <Value name="User-Agent">Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0</Value>
 </RawHeader>
</TMS>    

Hast Du mal

AdvProjActions · Maproom/qmapshack Wiki

Consumer grade GIS software. Contribute to Maproom/qmapshack development by creating an account on GitHub.

github.com

angeschaut? Dort sind die vorhandenen Möglichkeiten beschrieben. Mehr geht nicht.

s. wiederholte Kommentare des Programmautors: selbst programmieren und pull request einreichen.

Das Schemabild gleich am Anfang des Wiki-Abschnitts "GPS location data - General remarks" macht deutlich, dass ein Zwischenschritt erforderlich ist, der die Übertragung der NMEA-Daten an QMS über TCP sichert. Es wird also kein direkter Anschluss des GPSd an QMS unterstützt. Stattdessen wird auf einen mehr "normierten/einheitlicheren" Datenzugang gesetzt, der den Anschluss unterschiedlicher Datenquellen/Geräte ermöglicht.

Nein - gibt es gegenwärtig nicht!

Schau mal im QMS Wiki die Seite

https://github.com/Maproom/qmapshack/wiki/DocRealtime

an!

* Für kurze Beschreibung s. https://github.com/Maproom/qma…ki/AdvSetup#brouter-setup

* Nach Klick auf "neue BRouter-Installation erzeugen" sollte sich neues Fenster öffnen. Hier auf "brouter-1.6.3.zip" klicken und ggf. zip-Datei entpacken (enthält nicht nur von QMS nicht benötigte APK-Datei, sondern andere von QMS benutzte Dateien).

* Dann sachgerecht weitermachen.

* ZIP-Datei kann man auch direkt runterladen und ins gewünschte Verzeichnis entpacken (http://brouter.de/brouter_bin/brouter-1.6.3.zip)

Zitat von frankystone

Ist das nicht ähnlich wie meine Frage nach Overlay for OSM notes

Sicher und auch ähnlich der schon teilweise vollendeten Entwicklung, die in https://github.com/Maproom/qmapshack/wiki/DocGisItemsPOI beschrieben ist.

Zitat von kiozen

Du kannst in der *tms Datei eine Javascript Funktion hinterlegen, die die 3 Tile-Indizes für die TMS Server Abfrage in was auch immer umrechnet und eine URL daraus formt.

Das kann man sicher machen - aber: der Server liefert keine Rasterkacheln, die QMS erwartet, sondern GeoJSON-Daten, die in QMS nicht verarbeitet werden können.

Zitat von kiozen

Eine weitere Alternative wäre eine GeoJSON Definitionsdatei für GDAL zu schreiben und diese dann über eine VRT Datei zu laden.

Auch das geht wohl nicht, da nur VRT-Dateien für Rasterdaten in QMS verarbeitet werden können.

Mit etwas Programmierkenntnis wäre ein möglicher Weg, die GeoJSON-Daten für ein ausreichend großes Gebiet vom Server herunterzuladen, zu parsen, in GPX-Wegpunkte zu konvertieren und dann die GPX-Datei nach QMS zu laden.

Siehe Links im Abschnitt "Introduction" der zitierten Wiki-Seite, z.B. "http://download.mapsforge.org/pois/europe".

Auf DocGisItemsPOI findet sich am Anfang der hervorgehobene Hinweis

Feature not yet implemented - everything on this page related to the use of GPX files not yet available in QMS!

Die auf der genannten Seite angeführten Beispiele sind mit einer noch nicht veröffentlichten Entwicklungsversion von QMS entstanden.

"Wenn die Kacheln Nahtlos sind, sollte die Darstellung doch auch Nahtlos sein, oder?":

Das ist ein Trugschluss.

Kacheln gehören zu einem bestimmten Gebiet, welches man z.B. mit "gdalinfo" (unter Windows im QMS-Verzeichnis enthalten) erfahren kann. Die zu benachbarten Kacheln gehörigen Gebiete fügen sich nahtlos aneinander an.

In QMS werden die hier diskutierten Kacheln über VRT-Dateien aufgerufen. Diese bilden aus einer oder mehrerer Kacheldateien eine neue virtuelle Kachel.

Unterstellt, es wird eine VRT-Datei für nur eine Kachel benutzt: Diese Kachel wird durch eine bestimmte Anzahl horizontaler und vertikaler Linien (entspricht der Datengenauigkeit) in kleinere Rechtecke/Quadrate unterteilt. Höhendaten werden und werden nur für die Mittelpunkte dieser Quadrate in der DEM-Datei zur Verfügung gestellt. Wenn man die äußeren dieser Mittelpunkte verbindet, erhält man ein neues und kleineres Gebiet und nur in diesem können durch Interpolation Höhenwerte berechnet werden. Es bleibt also ein weiter oben schon erwähnter schmaler Rand (für 3" Genauigkeit in der Breite von 1.5"), für den bei Nutzung einer einzelnen Kachel keine Höhendaten zur Verfügung stehen, also Höhendaten stehen nicht nahtlos zur Verfügung.

Benutzt man dagegen eine VRT-Datei, die mehrere Kacheln enthält, also diese zu einem Ganzen zusammenfasst, so wird das gerade beschriebene Verfahren für die größere virtuelle Kachel und nicht für die einzelnen Teile benutzt und die Bereiche ohne Höhenwerte sind nur noch die äußeren Ränder dieser virtuellen Kachel.

Also wie von kiozen gesagt: eine einzige VRT-Datei für möglichst viele zusammengehörige Kacheldateien bilden und benutzen.

Index ändern: ja - aber Vorsicht: dieser wird aus einer Quelldatei erzeugt. Nicht direkt im fertigen Index editieren, das würde im nächsten Erzeugungslauf für den Index wieder verschwinden. Wenn es nur 1-2 Einträge sind, mir Vorschläge schicken (Indexstichwort und Verweis auf Wikiseite/abschnitt), Rest mache ich.

Nimm Tracks statt Routen!