Beiträge von kiozen

Moooooment! Die 3 Themen hatten alle zusammen zwei Kriterien gemeinsam. Und da QMapShack bestimmt nicht daran schuld ist, muss es das andere gemeinsame Kriterium sein.

hubi85120 hier gibt es noch etwas zum verschieben

ok, da fehlt wohl wirklich ein Update. Du kannst als Workaround einfach mal die Datenbank zu und auf klappen. Das geht schneller als ein Neustart.

hubi85120 danke für's verschieben. Da irrlichtert übrigens noch ein Betrag herum:

Kopie oder Verknüpfung

Nein so ist das nicht.

Wenn dein Element, z.B. Wegpunkt, auf dem Arbeitsplatz geladen ist, liegt es in zwei Versionen vor. Einmal in der Version die in der Datenbank verwendet wurde und einmal in der Version auf dem Arbeitsplatz. Beide Versionen können abweichen, wenn Du es auf dem Arbeitsplatz geändert hast.

Kopierst Du das Element jetzt in einen anderen Datenbankordner muss eine neue Referenz angelegt werden. Aber welche Version willst Du inhaltlich haben?

Entweder die in der Datenbank, weil die evtl. Änderungen im Arbeitsplatz nur von temporärer Natur sind. Oder die vom Arbeitsplatz, weil Du die Änderung sowieso abspeichern wolltest.

Und als dritte Option gibt es den Klon. Das ist eine Kopie des Elements, die tatsächlich einen unabhängigen Eintrag in der Datenbank erzeugt.

Guter Hinweis

Hast Du das auch auf deiner Windows Version getestet? Auf Linux kann ich den Fehler auch nicht nachvollziehen.

Das `&` eröffnet eine Escape Sequenz die wahrscheinlich beim `=´ endgültig als unsinnig erkannt wird.

Kannst Du noch kurz auf den PR schauen ob das so ok ist?

https://github.com/Maproom/qmapshack/pull/255

Prima Ich baue das dann so ein.

Für Windows gibt es eine sehr detaillierte Anleitung im Wiki um QMapShack zu compilieren.

Wahrscheinlich musst Du das `&` anders schreiben: `&` Gut möglich dass auch noch andere Sonderzeichen ersetzt werden müssen.

Zitat von joschi_1998

Momentan behelfe ich mir mit einer MariaDB10-Instanz auf einem Synology NAS im LAN mit ausreichenden Rechten, um solche Timeouts passend einzustellen. Das kann bzw. will ich nicht von außen erreichbar machen, insofern eigentlich suboptimal. Andererseits ist die Performance im LAN so atemberaubend viel besser, dass ich geneigt bin, bei dieser Lösung zu bleiben.

Wer seine NAS liebt gibt keinen Port im Internet frei. Dafür gibt es VPN. Eine VPN Verbindung mit dem Router aufbauen und dann auf das private Netzwerk zugreifen. Dann hat man nur ein Interface exponiert und das ist hoffentlich von der Router Firmware sauber aufgesetzt und gepflegt.

Kannst Du das mit `MYSQL_OPT_RECONNECT` mal ausprobieren? Die richtige Stelle sollte in `IDBMysql::setupDB` sein.

Jedes Element kommt nur einmal in der Datenbank vor. Jedes Projekt (Ordner) referenziert dieses Element. Referenziert kein Projekt das Element wird es im Mülleimer gelistet. Es gibt folglich kein Original und eine Verknüpfung, wie es bei Dateisystemen üblich ist.

Keine Ahnung was du eigentlich wirklich vor hast. Aber das ist ein MD5 Hash über die ersten 1024 Bytes der Kartendatei. Ein MD5 Hash ist nicht reversibel d.h. man kann aus ihm nicht auf die Ursprungsdaten schließen. Du kannst Dir nur für alle Dateien den Hash berechnen und dann vergleichen.

Aber für mich klingt das eher wie eine komplett falsche Anwendung von QMapShack. Allein schon der Name der img Datei deutet darauf hin, dass Du nicht einfach ein gmapsupp.img, wie es auch auf den Geräten verwendet wird, in QMapShack eingebunden hast, sondern das in seine Einzelteile zerlegte gmapsupp.img. So ist es aber nicht gedacht und auch reichlich umständlich zu verwalten.

All diese Apps sind reine Frontends für Onlinekarten. Und um die geht es in diesem Thread nicht. Ein "einfach umwandeln" ist in diesem Fall ein massiver Verstoß gegen das Urheberrecht und die Nutzungsbedingungen der Server.

Hm, kann ich so nicht bestätigen. Rasterkarten haben durchaus einen sehr limitierten Zoombereich. Aber dafür hat man ja noch zusätzlich die Vektorkarte die außerhalb dieses Bereiches dargestellt wird. Innerhalb des vernünftigen Zoombereiches ist die Darstellung aber tadellos.

Oft haben fertig aufbereitet Rasterkarten leider eine sehr niedrige DPI Auflösung, was den Zoombereich sehr eingrenzt. Ein guter Erfahrungswert bei gescannten Karten sind 300..400dpi. Man sollte die Karten von jemanden Scannen lassen, der Wert auf gute Arbeit legt. Und natürlich eine frisch gekaufte Papierkarte gleich scannen, bevor man irgendwas anders damit macht.

Bei anspruchsvollem Gelände stellen Rasterkarten immer noch jede Vektorkarte in den Schatten und sind ein sehr wertvolles Hilfsmittel. Insbesondere zusammen mit der Papierversion. Wer sich jedoch nur auf gut gekennzeichneten Wegen aufhält, wird diesen Vorteil nicht wirklich zu nutzen wissen und ist zu Recht glücklich mit der Vektorkarte. Ist halt ein Nischenprodukt genauso wie GPS Geräte mit Tasten. Wer nichts damit anzufangen weiß, braucht es auch nicht.

Für DE gibt's nix Gescheites für lau. Wenn man nicht gerade eine besonders schöne Wanderkarte von einem Gebiet hat, reicht für DE OSM. Soviel anspruchsvolles Terrain haben wir ja nicht. Und für die Alpen gibt es die DAV Karten.

Mit der Umstellung der deutschen Topokarten auf ATKIS Basis sind diese Karten inzwischen auch nicht mehr wirklich gut. Für den zivilen Bereich wurde so gut wie alle wichtige Information zwischen den Wegen herausgeputzt. Hat den deutschen Michel halt nicht zu interessieren. Und die alten Versionen sind einfach vom Wegenetz und der Bebauung veraltet.

Der Aufwand mit dem Scannen und Referenzieren lohnt sich nur für wirklich gute Karten, die es so nicht digital gibt. Wie z.B. die vom Tobacco Verlag, der außer einer komischen App sonst nur Papier anbiete.

Die Spanier haben sehr gute Topokarten, die auch zugänglich sind. Der französische IGN hat auch sehr schöne Karten, die nicht so zugänglich sind. Die Schweiz hat tolle Karten, die recht teuer sind. Wobei sich das schnell relativiert, wenn man Papierkarte, Scannen und Arbeitszeit in Relation setzt.

Gerade gemerged. Vielen Dank für die Arbeit

Ach ja und auch beim PR keinen Abschnitt löschen. Vor allem nicht so einen wichtigen wie den `smoke test` Gehe mal davon aus dass noch mehr Leute die PRs beobachten und ausprobieren. Die haben keine Lust Rätsel zu raten. Machen aber eine sehr wichtige Arbeit indem sie den Code auf anderen Systemen testen.

Nimm dir am Besten ein Beispiel an dem anderen PR der gerade offen ist. Da ist das Ticket sehr gut geschrieben. Und natürlich habe ich auch beim PR die nötige Sorgfalt walten lassen. Die Änderung selber ist ein ähnlicher Pipidax wie die hier

Danke schon mal für den PR. Ich würde Dich aber bitten den üblichen Prozess zu folgen. Ja ich weiß ist bei so kleinen Sachen nervig, aber erstens gibt es sonst ein schlechtes Beispiel und zweitens fehlt es dann an Dokumentation, so dass andere auch verstehen worum es ging.

Also:

1. Ticket erstellen. Bitte alles ausfüllen. Erklärende Texte ersetzen

2. Branch erstellen mit der Ticketnummer. Also QMS-XXX

3. Commits sollten auch immer die Ticketnummer erwähnen. Einfach mal mit `git log` ansehen wie es gemacht wurde.

4. Der PR sollte auch die Ticketnummer im Titel erwähnen und natürlich im Text das Ticket referenzieren. Man findet so alles viel besser.

Alles Kleinigkeiten die eigentlich nicht viel Zeit kosten, dafür aber helfen den Überblick zu behalten

Zum PR selber:

1. Der ist natürlich schon `user facing`. Und braucht einen Eintrag in die changelog.txt. Bitte ordentlich einsortieren.

2. Die fehlenden includes dürfen gerne mit. Ich dachte eigentlich wir hätten die schon alle.

3. Es gibt noch eine zweite Stelle im Code wo der Loop ähnlich gemacht wird. Der VRT Builder. Kannst Du den bitte auch ändern.