Beiträge von kiozen

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.

Qt hat in der letzten Zeit öfters mit seiner API Stabilität gebrochen. Also gut möglich das wir den Code ändern müssen.

Die Liste ist in der Regel nicht leer, weil QMapShack ja überprüft, ob alle nötigen Vorgaben da sind. Und wenn wir anfangen Fehlermeldungen für interne Bibliotheksprobleme zu implementieren wüsste ich nicht wo man da aufhören sollte.

Kannst Du mal den for-loop austauschen und testen ob es daran liegt? Wenn ja bitte ein Ticket aufmachen.

Tatsächlich. Der erste Teil fehlt komplett.

Wenn ich mir den Code ansehe kann das nur passieren wenn `sourceFiles` leer bleibt. Gefüllt wird diese Liste beim Start

void CRoutinoDatabaseBuilder::slotStart()
{
    pushStart->setDisabled(true);

    sourceFiles.clear();
    for(const QListWidgetItem * item : listWidget->findItems("*", Qt::MatchWildcard))
    {
        sourceFiles << item->text();
    }

Das über `findItems` zu machen ist vielleicht nicht der beste Weg. Gut möglich das deine Qt Version etwas anderes als erwartete zurückgibt. Ich würde das heute eher so schreiben:

    const int N = listWidget->count();
    for(int n = 0; n < N; n++)
    {
        sourceFiles << listWidget->item(n)->text();
    }

Ist deine Qt Version zufällig 5.12? Die scheint recht buggy zu sein.

Poste doch mal die gesamte Ausgabe von QMapShack. Also Befehle und Fehlermeldungen.

Wer liest denn heute noch? Das muss doch heutzutage ein Filmchen auf Youtube sein

Keine Ahnung was dem Virescanner sauer aufstößt. QMapShack verschlüsselt außer den HTTPS Zugriffen nichts.

Die Windowspakete liegen auch außerhalb meiner Zuständigkeit. Die werden von einem Freiwilligen angefertigt. Der hat aber auch nicht die Zeit sich weiter damit zu beschäftigen. Sprich das ist friss oder stirb Futter. Einen wirklichen Support seitens der Windows-Community gibt es nicht und damit bleiben die meisten Windowsprobleme auch ungelöst.

Dafür gibt es keine gemeinsame Aktion. Also jeden einzelnen konfigurieren.

Da hast Du eine sehr eingeschränkte Ansicht. Planungstracks und Tracknavigation gab es schon immer. Gerade in den Anfangszeiten, wo es keine routingfähingen Topokarten gab, war das der einzige Weg.

zu 1. Man kann entweder den Benutzer in die Konfigurationshölle schicken, oder die Benutzer müssen den vorgegeben Weg akzeptieren. Wenn sie das nicht tun und eine andere Software deswegen benutzen ist das ok.

Wenn mich die Steigung/Neigung interessiert, dann schaue ich mir in den Trackdetails den jeweiligen Graphen an. Hier kann ich mir die Steigung/Neigung in % oder ° anzeigen lassen. Ich kann sogar die Hangneigung, um den jeweiligen Trackpunkt anzeigen lassen. Damit kommen Alpinisten als auch Radfahrer auf ihre Kosten.

zu 2. Dein Problem ist nicht die Reihenfolge, sondern deine Workflow, der nicht dem von QMapShack entspricht. Wenn Du entweder gleich auf einen Track planst oder den Track in einem anderem Projekt abspeicherst, hast du keine Probleme mit der Reihenfolge.

Für mich ist es komplett ok, wenn jemand nicht mit dem Workflow von QMapShack klar kommt. Man kann es nicht jedem recht machen. Wenn es Software gibt, die optimal auf deinen Bedarf zugeschnitten ist, dann benutze sie. Wenn es keine Alternativen gibt, dann musst Du entweder deine Arbeitsweise ändern, oder QMapShack anpassen. Immerhin ist das Open Source. Und viele andere haben das schon so gemacht.

Namen machen halt nur sehr bedingt Sinn und sind laut GP Spezifikation nicht zwingend notwendig. Wenn sich Locus und Osmand daran aufhängen, ist das deren Problem. Mit dem X (exchange) hat das dann nichts mehr zu tun, sondern ist ein weiteres proprietäres Format bezüglich Routen.

Gerade getestet: Beide Services sind online und funktionieren.

Wie Wolfgang schon sagt: Online Routing Services können nicht zum on-the-fly Routen von Tracks oder Routen verwendet werden. Sonder nur um eine Route von "A nach C über B" zu berechnen.

1. Ja muss man. Jeder hat eine andere Auflassung davon wie ein Track aussehen soll. Quitschebunt nach Steigung kommt da eher seltener vor.

2. Liegt halt daran dass man sich auf irgendeine Reihenfolge beim Rendern festlegen muss. QMapShack hält sich hier an die Reihenfolge Track->Route->Wegpunkt.

Routen und Tracks in einem Projekt zu doppeln ist auch ein eher ungewöhnliches Vorgehen. Wahrscheinlich wäre es besser, wenn Du den Track immer gleich in sein eigenes Projekt steckst. Siehe auch dein anderes Posting. Dann kannst Du die Reihenfolge bestimmen indem Du die Projekte mit drag-n-drop umgruppierst. Oder das eine oder andere Projekt mal kurz wegklickst.

Auch hier der Hinweis: QMapShack ist sehr Track zentriert. Routen spielen kaum eine Rolle.

Keine Ahnung was Osmand oder Locus so anstellen. Die GPX Dateien die QMapShack erstellt sind konform zur GPX1.1 Spezifikation. Was nicht garantiert, dass andere Programme nicht ihre eigenen Erwartungen an die jeweilige Datei stellen, die so nicht im der GPX Spezifikation stehen.

Was mir z.B. auffällt ist, dass in den Dateien vom RC die einzelnen Punkte ein Namensfeld haben. Dieses ist laut Spezifikation optional und QMapShack setzt das nicht für Routen- oder Trackpunkte.

Ein weiterer Punkt ist, dass in den Dateien die mit QMapShack erstellt wurden ein Track und eine Route liegen. In den Dateien vom vom RC jeweils nur ein Track oder eine Route. Gut möglich dass andere Programme damit nicht zurecht kommen.

Mach es nicht komplizierter al es ist. Alle 3 Tracks in einem Ordner. Fertig.