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.
Eigentlich ist Projekt nur ein Synonym für Datei. Da aber QMapShack Dateien und Datenbank zugleich kann, ist der Begriff Datei nicht universell verwendbar. Deswegen wird der Begriff Projekt verwendet.
Wenn Du unbedingt einzelne Dateien haben willst, dann musst du ein Projekt pro Track anlegen.
Dein Garmin kommt aber auch mit mehreren Tracks in einer Datei zurecht.
Eine Route besteht in der Regel aus ein paar Punkten. Der Weg zwischen den Punkten wird berechnet. Ist also nicht genau vorgegeben.
Vorteil:
* Bei der Berechnung des Weges zwischen den Punkten kann man zusätzliche Information wie Abbiegehinweise hinzufügen.
* Ist der berechnete Weg versperrt oder man hat sich verfranzt, kann automatisch ein neuer Weg zum nächsten Punkt berechnet werden
Nachteil:
* Das Routenformat von GPX ist gelinde gesagt unter aller Sau und lässt viele Wünsche offen und auch viel Raum zur Interpretation. Routen sind deswegen nicht wirklich zwischen den Applikationen portabel. Das `G` und das `X` trifft somit nicht auf Routen zu.
* Berechnungen von Routen weichen zwischen den einzelnen Programmen ab. Ohne eine Datenbank mit Routing Daten geht eh nichts.
Ein Track ist die Aneinanderreihung von vielen einzelnen Punkten. Die Verbindung zwischen den Punkten ist immer eine Gerade. Damit kann man schön malen. Und wenn man den Track entlang von Wegen malt, dann kann man sich später anhand der schönen bunten Linie auch orientieren.
Vorteil:
* Tracks sind wirklich universal und werden von jeder Software gleich interpretiert.
* Tracks gehen auch, wenn es keine Daten zum berechnen von Routen gibt.
* Tracks funktionieren sogar ohne Karte.
Nachteil:
* Der Track kann nicht so einfach auf dem Gerät neu berechnet werden.
* Garmin-Geräte haben nur eine rudimentäre Funktion, um nach einem Track zu navigieren.
Wer Routen will muss im Universum des jeweiligen Anbieters bleiben. Also für Garmin heißt das Basecamp benutzen und nur Garmin Geräte verwenden.
Deswegen werden Touren heute als Tracks ausgetauscht. Wer wandert kommt mit einem Track relativ gut zurecht. Man muss halt das GPS immer im Auge behalten, um rechtzeitig abzubiegen. Radfahrer schätzen deswegen die automatischen Abbiegehinweise bei Routen.
Wenn ich es noch richtig im Kopf habe wird ein Zoom Level immer nur mit seinem Anfang definiert und geht solange, bis ein anderer anfängt. Für den letzten Zoom Level bedeutet das, dass alles bis zum größten Zoom abgedeckt wird.
Du müsstest folglich die Tabelle, die die Zoom Level definiert umschreiben und einen hinzufügen, der dann kein Kartenmaterial mehr hat. Und dafür musst Du dann noch ein paar mehr Tabellen anpassen. Das macht keiner.
Ist auch meiner Meinung nach nicht nötig. Ändere einfach die Draw Priority deiner JNX Karte, dann wird diese über der Vektorkarte gezeichnet, wenn der Zoom Level für die JNX Karte erreicht wurde. Das ist auch viel besser, weil Du dann immer noch die Vektorkarte siehst, wenn die JNX Karte keine Kachel für den Ausschnitt hat. Außerdem lässt sich die Tabelle, die die Zoom Levels definiert bei JNX deutlich einfacher manipulieren. Dazu gibt es auch Tools.
Wahrscheinlich sind die Daten zu viel. OSM Europa ist inzwischen ein echter Datenbolide.
In der Regel benötigt man das auch nicht. Ich habe mir zum Beispiel DACHI zusammengestellt. Und sollte ich doch mal wo anders sein, kann ich mir das nötige Gebiet recht schnell erstellen.
Als Alternative kann man auch BRouter lokal verwenden. Dann spart man sich auch das ständige bauen, weil BRouter seine Datenbasis zum Download anbietet.
Für Fußwege ist meiner Meinung nach Routino einen ticken besser. Fürs Fahrrad BRouter. Das fällt aber nur auf wenn man zwischen A und B routet. Benutzt man den Router um Tracks mit der Maus zu zeichnen ist es egal.
Bei Onlinekarten ist die Schrift ja auf der 256x256 Kachel als Pixelbrei. Da kann man nichts machen. Das Problem ist, dass dein HDPI Display die Kachel und alles andere nur halb so groß darstellt.
Der Wunsch die Displayauflösung zu beachten kam schon öfters. Wie üblich bleibt es aber immer bei der Forderung, weil es denen, die sich so einen Monitor leisten, in der Regel nicht darum geht sich selber einzubringen. Und ohne zwischen einer normalen und einer hohen Auflösung umschalten zu können, wird man das nicht fehlerfrei implementieren und testen könne.
Du kannst Natürlich für QMapShack grundsätzlich einen Skalierungsfaktor festlegen, um wieder auf die üblichen 100 DPI zu kommen. Siehe auch https://doc.qt.io/qt-5/highdpi.html Das geht allerdings zu Lasten der Schärfe.
Öööö, hast Du mir was geschickt? Ich finde nichts, auch nicht im Spamordner.
Wenn Du Lust hast darfst Du auch gerne an der Übersetzung feilen. Vieles davon ist irgendwann spät Abends entstanden und nicht immer wirklich gut gelungen. Also eher selten gut gelungen...