planetsplitter: Cannot open file

  • Erst mal hoffe ich, dass es ok ist, wenn ich hier rein poste, denn genau genommen betrifft es nicht QMapShack, sondern Routino/planetsplitter (also auch auf Kommandozeile)…


    Nach längerer Zeit wollte ich mal wieder die Routingdaten aktualisieren. Also habe ich mir die germany-latest.osm.pbf Datei heruntergeladen (MD5-Hash ist korrekt) und habe versucht, die Routino Datenbank zu erstellen.


    Ich hatte das ja schon das ein oder andere mal ohne Probleme gemacht, aber diesmal erhalte ich – umgehend – die Fehlermeldung:

    Code
    1. Sort OSM Data
    2. =============
    3. Sorting NodesCannot open file '/home/martin/Dokumente/QMapShack/Routino/nodesx.0x5627afa662a0.tmp' for reading [No such file or directory].

    Das Kommando, das ausgeführt wurde, ist:

    Code
    1. /usr/bin/planetsplitter --dir=/home/martin/Dokumente/QMapShack/Routino --prefix=DE --tagging=/usr/share/routino/tagging.xml --process-only


    Ich zweifle gerade an mir selbst, wüsste aber nicht, was ich falsch gemacht haben könnte. Hat vielleicht sonst noch jemand Probleme damit? Ich arbeite hier mit Arch Linux und habe QMapShack 1.15.0 sowie Routino 3.3.1 installiert.


    Danke und Gruß

    Martin

    GPSMAP 66s, QMapShack, Arch Linux

  • Hmm, also wenn ich zuerst auf der Kommandozeile folgendes ausführe (und anschließend die Schritte laut Doku in QMapShack), dann geht es:

    Code
    1. /usr/bin/planetsplitter --dir=/home/martin/Dokumente/QMapShack/Routino --prefix=DE --tagging=/usr/share/routino/tagging.xml --parse-only germany-latest.osm.pbf

    Als würde dieser erste Schritt von QMapShack nicht ausgeführt werden. Was ich aber nicht verstehe, denn früher hatte das ja geklappt. :/


    Ich suche also noch nach der Ursache, was ich anders/falsch mache. Aber immerhin hat es nun letztendlich funktioniert.

    GPSMAP 66s, QMapShack, Arch Linux

  • Das hier gibt QMapShack aus:

    Code
    1. /usr/bin/planetsplitter --dir=/home/martin/Dokumente/QMapShack/Routino --prefix=DE --tagging=/usr/share/routino/tagging.xml --process-only
    2. Sort OSM Data
    3. =============
    4. Sorting NodesCannot open file '/home/martin/Dokumente/QMapShack/Routino/nodesx.0x5556e21ad2a0.tmp' for reading [No such file or directory].
    5. !!! fehlgeschlagen !!!

    Und hier noch ein Screenshot:

    GPSMAP 66s, QMapShack, Arch Linux

  • 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


    Code
    1. void CRoutinoDatabaseBuilder::slotStart()
    2. {
    3. pushStart->setDisabled(true);
    4. sourceFiles.clear();
    5. for(const QListWidgetItem * item : listWidget->findItems("*", Qt::MatchWildcard))
    6. {
    7. sourceFiles << item->text();
    8. }

    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:


    Code
    1. const int N = listWidget->count();
    2. for(int n = 0; n < N; n++)
    3. {
    4. sourceFiles << listWidget->item(n)->text();
    5. }

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

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

    Bei Arch Linux bin ich auf Gedeih und Verderb aktuell: Qt 5.15.0


    Mir kam auch schon der Gedanke, ob das vielleicht an Wayland liegen könnte, wobei die Qt-Programme eigentlich den X11-Layer verwenden. Das schau ich mir nochmal an, auch wenns unwahrscheinlich klingt… EDIT: War ein doofer Gedanke und kann ausgeschlossen werden.


    (Evtl. wäre auch eine Fehlermeldung sinnvoll, wenn QMapShack denkt, dass die Liste leer ist?)

    GPSMAP 66s, QMapShack, Arch Linux

  • 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.

  • Mit der loop-Änderung siehts gut aus.


    Es war ein bisschen ein Act, QMapShack unter Qt 5.15 compiliert zu bekommen. Mit ein paar #include <QPainterPath> hier und da hat's dann funktioniert.


    Soll ich einen PR erstellen, mit den neuen #includes? Nicht dass das was bei Qt < 5.15 kaputt macht…

    GPSMAP 66s, QMapShack, Arch Linux

  • 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.

  • 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 ;)