QMapShack

Das sind aber nur Warnungen. Das sollte noch kein Hinderungsgrund sein, oder? Jetzt noch "generate" drücken und fertig.

Preview 1.2.0

Das passiert weil die verschiedenen Linien in unterschiedlichen Threads gezeichnet werden. Die grüne Linie ist eine Dekoration, die sich mit jeder Mausaktion ändern kann. Deswegen wird die im Hauptthread gezeichnet. Sämtliche GIS Elemente (Tracks, Route, Flächen, Wegpunkte) werden in einem Thread gezeichnet. Zoomen und Verschieben ist so eine Änderung.

Es sind halt wieder viele Wünsche, die unter einen Hut kommen müssen. Um die Leistung von heutigen Prozessoren wirklich nützen zu können, muss man Threads benutzen. Dann gibt es die "wer mit den Meisten stirbt" Fraktion, die gerne zig Tracks mit 20000 Punkten auf einmal im GUI haben wollen. Für die muss man das Zeichnen optimieren, also eben nur wenn wirklich nötig. Und der Rest will doch nur einen Bereich markieren. Das aber bitte ohne Verzögerung. Deswegen entkoppelt man das besser. Und schon hat man zwei Sachen die parallel laufen. Je nach Größe des Tracks und Leistungsfähigkeit des Rechner kommt es dann zu komischen Effekten.

Man könnte natürlich auch warten bis alle Threads abgeschlossen haben, bevor man wieder die Dekorationen mal. Dazu müsstest Du folgendes ändern:

void CCanvas::paintEvent(QPaintEvent * e)
{
    Q_UNUSED(e);


    if(!isVisible())
    {
        return;
    }


    QPainter p;
    p.begin(this);
    USE_ANTI_ALIASING(p,true);


    // fill the backbround with default pattern
    p.fillRect(rect(), "#FFFFBF");


    // ----- start to draw thread based content -----
    // move coordinate system to center of the screen
    p.translate(width() >> 1, height() >> 1);


    map->draw(p, needsRedraw, posFocus);
    dem->draw(p, needsRedraw, posFocus);
    gis->draw(p, needsRedraw, posFocus);


    // restore coordinate system to default
    p.resetTransform();
    // ----- start to draw fast content -----


    grid->draw(p, rect());


    [COLOR=Red]if(gis->isFinished())
    {
        gis->draw(p, rect());
        mouse->draw(p, needsRedraw, rect());
    }[/COLOR]




    drawStatusMessages(p);
    drawScale(p);


    p.end();
    needsRedraw = eRedrawNone;
}

Ich nehme mal an, du kannst inzwischen selber kompilieren

Probiere es aus. Da ich erst vor kurzem neue Rechner gekauft habe, fallen solche Dinge bei mir nicht so sehr ins Gewicht. Aber vielleicht ist das ja auf einem langsameren anders.

Zitat von papaluna

Ist es wirklich notwendig das jeweils das andere Profil gesperrt wird, wenn ein Abschnitt ausgewählt ist?
Letztlich handelt es sich doch um das selbe Objekt und den selben Abschnitt, unabhängig davon ob nun im Bearbeiten-Reiter oder im erweiterten Profil oder?!

Ja, das war die harte Nuss, die es zu knacken galt. Man hat ja nur Mausklicks und die Mausbewegung. D.h. man muss einen Zustandsautomaten bauen, der mitzählt, wie ein Mausklick gemeint ist. Weil "focus follows mind" ist noch nicht erfunden.

Jetzt hast Du aber auf der Karte und den Plots noch mehr Zustände als für die Bereichsauswahl nötig wären. Sprich man kann diesen Zustandsautomaten nicht einfach zentral im Track verwalten. Es brauch auch einen im jeweiligen Objekt, das den Track anzeigt und auch die Mausaktionen bekommt.

Und wenn ich jetzt mehrere solcher Objekte habe und der Benutzer wie wild zwischen denen wechselt, dann habe ich ein Riesenproblem, die Zustandsautomaten synchron zu halten.

Das ginge mit einem gehörigen Aufwand sogar. Obwohl so ein Konzept enorm schwierig fehlerfrei zu bekommen ist. Aber was mache ich wenn z.b. jemand im Profil einen Bereich markiert. Und dann das Profil schließt? Soll der Bereich jetzt freigegeben werden? Oder bleiben? Und was ist, wenn auf der Kartenansicht der Mauscursor gerade überhaupt nicht im Modus für die Bereichsauswahl ist?

Und deswegen: Das Objekt, indem die Bereichsauswahl angefangen wird, bringt sie auch zu Ende. Und alle anderen haben für die Zeit Sendepause.

Zitat von gerhardg

Für .at gibt es hier übrigens passende 10m DEM Daten als Geotiff welches sich mit ein paar Klicks einbinden lassen:

https://www.data.gv.at/katalog…84-480b-a480-ff63286b35b7

Danke für den Tip. Die Daten sind super. Ich habe nur einen Versatz. Sieht nach einer Unstimmigkeit im Kartendatum aus. Hast Du den auch? Oder ist bei mir GDAL schepps installiert?

Zitat von papaluna

Ja.
Es war eine klein wenig schwere Geburt. Vor allem wg. 32bit/64bit, da hat man schnell mal das falsche ausgewählt und schon kleine Inkompabiltäten.

Schlimm genug, dass bei Windows immer noch mit 32/64 herumgepanscht werden muss. Mein Linux läuft seit Jahren auf 64bit. Ich habe schon vergessen, wann das umgestellt wurde.

Könntest Du vielleicht noch deine Erfahrung in die 3rdparty.txt einfließen lassen?

Hm, das hat leider nichts gebracht. Jetzt ist der Versatz anders. Ich glaube ich überprüfe mal lieber meine GDAL Installation.

Käse, funktioniert natürlich wie Du schreibst. Man sollte nur nachher auch die *vrt Datei nochmal erstellen. Da steht die Projektion auch drinnen.

Menno, ich will solche Daten auch für DE und Norditalien.

Hm, kann ich jetzt leider auch nichts dazu sagen. CMake hat übrigens ein Gedächtnis. Es legt im Build Verzeichnis Informationen, die es gefunden hat ab. Manchmal macht es deswegen Sinn alles zu löschen.

Naja, letztlich produziert CMake etwas, das NMake aufruft. Und wenn das Murks ist dann macht NMake auch Murks. Es reicht ja schon einen Pfad nicht richtig gesetzt zu haben. Üblicherweise erkennt CMake Änderungen sehr gut. Perfekt ist es leider nicht.

Zitat von papaluna

Mag sein.
Gemäß den Compile instruction erfolgt aber die Kompilierung von GDAL vor der Ausführung von CMAKE.
Von daher sollte es da keine Abhängigkeit geben.
Allerdings vermute ich auch irgendein Pfadproblem.

Ok, Du bist ja erst bei GDAL. Hatte ich verdrängt Wird das unter Windows auch mit ./configure vorbereitet? Dann kann man die Pfade auf der Kommandozeile mit angeben.