Garmin fenix 7X und epix Gen 2 im Test

Der Schwerpunkt dieses Tests und Vergleichs der Garmin Fenix 7X Solar und Garmin Epix Gen 2 liegt auf den Sensoren wie Höhenmesser, Positionsbestimmung und Herzfrequenz. Was unterscheidet die beiden GPS-Outdoor-Smartwatches? Und wie gut ist die Taschenlampe der Fenix 7X für den Outdoorbereich? Hier geht es zum Test der Outdoor-Smartwatches ...
  • D.h. der Stick wird schon beim Starten von QMS nicht als TwoNav Gerät erkannt? Das ist seltsam. Ich mach da wirklich nichts anderes als alle Top Level Verzeichnisse mit "TwoNavData" zu vergleichen. Und nachher suche ich dann in "TwoNavData\Data" nach GPX Dateien und Unterverzeichnissen.


    Und wenn der Stick als Garmin Gerät erkannt wird, funktioniert das auch im Ablauf. Dann kann es eigentlich nur daran liegen, dass der Vergleich mit "TwoNavData" fehl schlägt. Groß- und Kleinschreibung sind dabei wichtig.

  • Dann kann es eigentlich nur daran liegen, das, der Vergleich mit "TwoNavData" fehl schlägt. Groß- und Kleinschreibung sind dabei wichtig.


    Wie ich oben nachgetragen hatte, lag es doch an Groß- und Kleinschreibung.
    (Ich hatte bei der ganzen Probierei, nach der Korrektur vergessen das \Garmin zu löschen. Und somit wurde der Stick eben als Garmin-Device erkannt und nicht als Twonav. sorry)

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen bitten wir Euch über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben! Vielen vielen Dank...
  • Also,


    in CGPSL kann ein Roadbooktrack an einem Roadbookpunkt Verknüpfungen haben.
    Wenn ich einen Track habe und ein passender Wegpunkt als RBK-Punkt genommen wird, wird auch eine etwaige am Wegpunkt vorhandene Verknüpfung (z.B. Getränkeliste, Bild von der Bedienung...) an diesen RBK-Punkt verknüpft.


    Ich kann also direkt über den Track>RKK-Punkt>Verknüpfung diese öffnen, öffnen lassen.


    so sieht der QMS-Export aus:
    T A 50.936971ºN 6.963234ºE 12-Mar-15 11:44:25.000 s 49 0.000000 0.000000 0.000000 0 -1000.000000 -1.000000 -1 -1.000000 -1 -1 -1 -1.000000
    a Waypoint.png,1,3,0,PEGEL_KOELN (45MNN)


    so müßte es aussehen:
    T A 50.93697108ºN 6.96323404ºE 12-MAR-15 11:44:25.000 s 49.000000 0.000000 0.000000 0.000000 0 -1000.000000 -1.000000 -1 -1.000000 -1 -1 -1 -1.000000
    a Waypoint,1,3,0,PEGEL_KOELN (45MNN)
    a 3e8b2cd043f6d2f4d21cc1c5ee98011b.html,0


    Das ist der Wpt:
    W PEGEL_KOELN_(45MNN) A 50.93697108ºN 6.96323404ºE 20-APR-2014 09:50:39 49.000000
    w Waypoint,0,-1.0,0,128,1,37,,0.0,0,-1,0,3
    a 3e8b2cd043f6d2f4d21cc1c5ee98011b.html,0

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen bitten wir Euch über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben! Vielen vielen Dank...
  • Im Moment sind Bilder das Einzige was man in QMS mit Wegpunkten verknüpfen kann. Und die html Datei, mit dem Schlüssel als Name, wird in das Beschreibungsfeld eingefügt. Für was anderes müsste ich das Datenmodell aufbohren.


    Allerdings bin ich kein großer Fan davon, weil solche Anhänge kaum auf anderen Geräten unterstützt werden. Bricht man es runter, dann ist die große Schnittmenge Bilder und Text. Für Text reichen die Felder wie Kommentar und Beschreibung, die aus der GPX Spezifikation kommen, eigentlich aus. Und Bilder sind immer irgendwie eine Sonderlocke.


    Was noch in dieses Konzept rein passt, wäre *txt und *html Dateien grundsätzlich als ein Block in der Beschreibung zusammenzufassen. Beim Export würde aber dann alles als <Schlüssel>.hml geschrieben. Auch nicht so ganz das Wahre.

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen bitten wir Euch über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben! Vielen vielen Dank...
  • Für was anderes müsste ich das Datenmodell aufbohren.


    d.h. der Verweis auf das Bild wird also in einem eigenen Feld gespeichert. Will man mehrere Verweise haben braucht man entweder mehr Felder oder einen Verweis auf eine Extra-Tabelle.


    Bricht man es runter, dann ist die große Schnittmenge Bilder und Text.


    Ok, da stimme ich mit dir überein. Wobei ich neben reinem Text auch noch html gelten lassen würde.

    Für Text reichen die Felder wie Kommentar und Beschreibung, die aus der GPX Spezifikation kommen, eigentlich aus.


    Da kann ich für Twonav leider nicht zustimmen. Im Gegensatz z.B. zu CGPSL werden diese Felder, wie du sicher weißt, nur einzeilig angezeigt.
    Will man ein klein wenig längere Texte nutzen ist man auf verknüpfte Dateien angewiesen um diese einfacher in Twonav lesen zu können.


    Was noch in dieses Konzept rein passt, wäre *txt und *html Dateien grundsätzlich als ein Block in der Beschreibung zusammenzufassen. Beim Export würde aber dann alles als <Schlüssel>.hml geschrieben. Auch nicht so ganz das Wahre.


    Nee, wirklich nur eine Krücke.


    Und wie wäre es wenn die "Verknüpfungen" in den QMS-Eigenschaften(WP, trk) nicht rein als http://, sondern auch als file:// interpretiert/import/exportiert werden könnten?
    Twonav-Nutzer z.B. denken bei "Verknüpfungen" bestimmt eher an selbige, denn an Web-Links.



    Was mir während der Probiererei noch aufgefallen ist:


    - leeres Projekt
    - aus einem Projekt auf dem Stick einen Wegpunkt in QMs ins leere Projekt transferieren
    - Wegpunkt ändern(Symbol...)
    - RM-Taste-An Gerät senden
    => Wegpunkt etc. wird übertragen, Objekte wie Text-Dateien die am Ausgangswegpunkt verknüpft sind, sind noch im Projektverzeichnis enthalten
    (- Wegpunkt ändern(jetz mal Kommentar ändern...)) -der Schritt ist nicht zwingend notwendig
    - jetzt nochmal - RM-Taste-An Gerät senden
    => Inhalt des Projektverzeichnisses auf dem Stick wird gelöscht und nur noch der QMS-Output wird übertragen(klar) um meine ganzen verknüpften Daten sind weg.


    Weshalb dies jetzt erst bei der 2ten Übertragung passiert?!

  • d.h. der Verweis auf das Bild wird also in einem eigenen Feld gespeichert. Will man mehrere Verweise haben braucht man entweder mehr Felder oder einen Verweis auf eine Extra-Tabelle.


    Naja, Bilder sind nochmal ganz was eigenes. Die können sogar eine Blickrichtung haben. In QLGT wurde die z.B. angezeigt.



    Ok, da stimme ich mit dir überein. Wobei ich neben reinem Text auch noch html gelten lassen würde.


    Kein Problem. QMS behandelt intern eh alles als HTML. Das wird dann nur für das jeweilige Format in reinen Text umgewandelt.




    Da kann ich für Twonav leider nicht zustimmen. Im Gegensatz z.B. zu CGPSL werden diese Felder, wie du sicher weißt, nur einzeilig angezeigt.
    Will man ein klein wenig längere Texte nutzen ist man auf verknüpfte Dateien angewiesen um diese einfacher in Twonav lesen zu können.


    Schon klar. Aber das ist ein Problem, das an der Schnittstelle QMS/TwoNav gelöst werden muss. Wird es ja jetzt auch.



    Und wie wäre es wenn die "Verknüpfungen" in den QMS-Eigenschaften(WP, trk) nicht rein als http://, sondern auch als file:// interpretiert/import/exportiert werden könnten?
    Twonav-Nutzer z.B. denken bei "Verknüpfungen" bestimmt eher an selbige, denn an Web-Links.


    Das kann man auf einem Gerät machen, wo die Pfade zu 100% definiert sind. Das ist kein Konzept, um Daten auf einer Festplatte zu verwalten, oder um Daten mit anderen auszutauschen. Alleine schon der dämliche Laufwerksbuchstabe von Windows, wird sich quer stellen. Und wenn Du mit relativen Pfaden nicht alles in ein Verzeichnis knallst, dann überfordert das auch schon die meisten.



    Solange GPX das Format zum Austausch von Daten ist, beschränkt man sich besser auf Text. Und wenn Bilder dabei sein sollen wird es sofort proprietär.




    Weil beim ersten mal QMS deinen Ordner nicht als gleiches Projekt erkannt hat. Der Schlüssel fehlte und es wurde ein neuer berechnet. Folglich wurde das Projekt nicht vorher gelöscht. Aber weil wahrscheinlich die Namen gleich sind, wurde das neue Projekt in den Ordner geschrieben. Inkl. Schlüssel. Und beim zweiten Mal wurde deswegen vorher der Ordner gelöscht.


    Man muss wohl bei TwoNav auch noch auf den Ordnernamen vergleichen. Bei einer einzelnen GPX Datei ist das einfacher, weil die immer ersetzt wird.


  • Schon klar. Aber das ist ein Problem, das an der Schnittstelle QMS/TwoNav gelöst werden muss. Wird es ja jetzt auch.


    Das ist gut.:tup:
    Von CompeGPS würde ich da im Moment eher nichts erwarten. Da wird man halt auf die Möglichkeit zur Verknüpfung verweisen.


    Das kann man auf einem Gerät machen, wo die Pfade zu 100% definiert sind. Das ist kein Konzept, um Daten auf einer Festplatte zu verwalten, oder um Daten mit anderen auszutauschen. Alleine schon der dämliche Laufwerksbuchstabe von Windows, wird sich quer stellen. Und wenn Du mit relativen Pfaden nicht alles in ein Verzeichnis knallst, dann überfordert das auch schon die meisten.


    Also ich denke, das es im Rahmen des Austausches von Daten, für einen Nutzer einfacher zu verstehen und handzuhaben ist, das alle Daten eines Projektes in einen Ordner gehören, als gegebenenfalls alle notwendigen Pfade + Ordner anzulegen.


    Und wo ist jetzt der Unterschied zum Im/Export in Verbindung z.B. mit Basecamp?
    Sind dort einem Wegpunkt Dateilinks hinzugefügt werden diese importiert=tauchen in den Wegpunkteigenschaften bei "Verknüpfungen" auf.
    Beim Export werden diese auch wieder mit weggeschrieben.

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen bitten wir Euch über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben! Vielen vielen Dank...
  • Das ist bei Garmin nicht anders besch.. gelöst als bei TwoNav ;) Dort gibt die GarminDevice.xml an wo etwas hingehört. Und in der GPX Datei wird der Dateiname eingetragen. Für das Gerät absolut ok. Aber für den PC oder einen Datenaustausch mit anderer Software ungenügend. Der einzige Vorteil von GPX gegenüber den TwoNav Dateien: In einer einzelnen GPX Datei kann man ein komplettes Projekt abspeichern. Bei TwoNav hat man immer TRK und WPT Dateien.


    In QMapShack werden binäre Anhänge auch nur intern verwaltet. In dem Moment wo die Daten exportiert werden, müssen Kompromisse gemacht werden. Entweder man nimmt *qms, was außer QMapShack keiner unterstützt (aber das Format ist wenigsten offen). Oder man nimmt GPX und dann sind nur noch die Textinhalte da.


    Der wahrscheinlich beste Ausweg aus dem Schlamassel wäre ein Konstrukt wie kmz, wo der Dateiensalat einfach in einer ZipDatei verpackt wird. Das wäre z.B. eine Erweiterung die Topografix als neutrale Instanz schon vor Jahren hätte vorschlagen sollen. So machen das die Unternehmen selber und auf ihre undokumentierte, proprietäre Art und Weise. Siehe Garmins binäre Geocachedateien.


    Das Thema ist einfach reichlich verpfuscht. Das hat Ropert Lipe mit seinem GPSBabel schon sehr früh erkannt. :D

  • Ja, da hast du leider recht.
    Von daher kann man aus dieser Richtung leider wenig erwarten.



    1. Beschreibung / Kommentar
    1.1 Wegpunkte:
    Beim Export als HTML wird bisher ja leider nur der key-Wert als Namessuffix genommen.
    1.1.1.
    Wäre es denkbar ein Kürzel voranzustellen z.B. sowas wie QMS_CMT damit man leichter sieht worum es sich handelt.?
    1.1.2.
    In der Folge könnte man dann auch noch das Beschreibungsfeld als Anhang QMS_DESC exportieren, da ja auch dieses Feld in Twonav nur einzeilig angezeigt wird.
    Ein kleines Risiko wäre hier, das ein Nutzer den verlinkten Anhang in CGPSL bearbeitet und zusätzlich noch das eigentliche Beschreibungsfeld des Wegpunktes ändert und evtl. unterschiedliche Inhalte hätte. Beim Reimport durch sein Kumpel in QMS müßte das dann irgendwie gehandelt werden.
    Wobei sich 2 Bekannte mit unterschiedlichen Systemen diesbzgl. immer noch absprechen können.


    1.2 Track:
    Das Kommentar-Feld in Twonav/CGPSL wird CGPSL seitig als <desc></desc>-Feld ins GPX-Format exportiert.
    Im Track ist das die M Zeile im Track-Header.
    Es können mehre M-Zeilen vorkommen:
    ...
    M Kommentar-Feld Zeile 1
    M Kommentar-Feld Zeile 2
    M Kommentar-Feld Zeile 3
    ...
    Es sind so mehrzeilige Kommentare möglich. Der Export durch CGSPL in GPX erfolgt dann
    <cmt>M Kommentar-Feld Zeile 1
    M Kommentar-Feld Zeile 2
    M Kommentar-Feld Zeile 3
    </cmt>
    und kann von QMS wiederum auch so gelesen werden.
    Bei Twonav ist, wie bei anderen Feldern (Beschreibung bei Wegpunkt etc), nur eine einzeilige Anzeige möglich.
    Will man dieses Kommentar-Feld, wie auch die in CGPSL/Twonav nicht vorhandene Beschreibung, exportieren, käme auch ein Export als Text/HTML-Anhang in Frage.


    2. Aktualisieren eines Projektes in QMS
    Beim Gerät>Projektnamen gibt es im Kontext den Punkt "Aktualisiere das Projekt auf dem Gerät".
    a) anscheinend wird ein Projekt auf dem Gerät auch aktualisiert wenn es schreibgeschützt ist (Schloss geschlossen).
    Denn nach einer Änderung im QSM-Projekt, wird diese Version auf das Gerät übertragen.
    Ob generell ein Abfrage erfolgen soll, sei jetzt mal dahingestellt.
    b) Wieso fehlt die Gegenrichtung, also Aktualisierung eines QSM-Projektes mit den Daten auf dem Gerät.(ich weiß das es die "kopieren nach"-Funktion dazu gibt. Ich denke nur das es homogener ist wenn jeweils beide Wege funktionieren würden)


    3. Filter
    Das "Track in Stücke teilen" ist zwar als Punkt in der Auswahl, aber nicht wählbar


    4. Karten-Schummerung
    Für meinen Geschmack wird die Karte zu stark aufgehellt bei aktivieren der Schummerungsregelung.
    Selbst bei quasi 0% ist das Kartenbild dann deutlich zu hell.

  • zu 1.1.1) kann ich machen.


    zu 1.1.2) Die Idee war, dass man bei TwoNav die Wahl hat, ob man etwas Kurzes in das Wegpunktfeld einträgt, oder etwas Langes als Anhang. Garmin wertet nur das <cmt> Tag aus. D.h. man schreibt in der Regel etwas in den Kommentar. Und einen kurzen Hinweis in die Beschreibung. Den sieht man nur auf den TwoNav Geräten.


    Wer hintenherum die Dateien ändert ist selber schuld. Die Idee ist alles über das GUI zu machen. Ich glaube auch die meisten Benutzer wollen nicht wirklich wissen, wie die Daten abgelegt werden.


    zu 1.2) Aktuell habe ich wenig Ambitionen auf den Geräten Tracks mit Kommentaren zu versehen. Aber man könnte es als Feature Request bei Bitbucket eintragen. Vielleicht hat ja jemand anderes Lust.


    zu 2) Da verstehst Du was falsch, bzw das GUI kommuniziert es missverständlich.


    2.1) Das Schloss ist ein Hinweis, dass es aktuell nicht gewünscht ist, das Element zu ändern. Entweder weil es importiert ist, weil man alle Änderungen abgeschlossen hat und lieber die vereinfachte Ansicht genießen möchte, oder weil es auf einem Gerät liegt.


    In der Regel kann man sich darüber hinwegsetzen und das Schloss öffnen. Bei importierten Objekten bekommt man dann einen Tintenfleck, der anzeigt, dass es sich nicht mehr um das Original handelt.


    Ein absolutes no-go ist es die Elemente auf dem Gerät zu verändern. Die ändert man im Arbeitsplatz und schickt dann das Projekt wieder Richtung Gerät.


    2.2) Synchronisationsrichtung: Die ist immer nur Arbeitsplatz -> Gerät. Warum?


    a) Beim Übertragen auf die Geräte geht zwangsläufig Information verloren. Die Geräte können nicht alles, was in QMS unterstützt wird.


    b) Ändere ich ein Element auf Gerät A und dann auf Gerät B - natürlich nicht genau gleich - dann wird die Sache richtig spannend.


    Man könnte das Problem ähnlich wie eine Softwareverwaltung lösen, bei der ja auch laufend unterschiedliche Änderungen zusammengeführt werden. Das werden die meisten Benutzer nicht auf die Reihe bekommen...wollen. Und das Problem b) ist nur mit einer 3 Wege Zusammenführung zu schaffen. Daran scheitern selbst Programmierer oft genug.


    Deswegen: Änderungen auf dem Arbeitsplatz und dann an alle Geräte senden.


    Natürlich kann man einzelne Elemente, vor allem die, die man im Feld aufgenommen hat, per drag-n-drop in den Arbeitsplatz ziehen. Aber ein ganzes Projekt? Denken wir das mal durch: Ursprünglich kam das Projekt aus einer GPX Datei oder der Datenbank. Ist dieses Projekt immer noch offen, würde der Drop abgebrochen, weil anhand des Schlüssels erkannt wird, dass das Projekt ja schon da ist. Das gilt natürlich auch anders herum. Würde man es zulassen gäbe es zwei unterschiedliche Projekte mit dem selben Schlüssel. Chaos. Das lassen wir lieber bleiben.


    Mal absehen vom Spielen und Ausprobieren ist doch der übliche Arbeitsfluss wie folgt:


    * Planung: Ich erstelle mir ein ein Projekt (Datei oder Datenbank) und trage zusammen, was ich brauche.
    * Dann schließe ich alle Geräte an und übertrage das Projekt.
    * Jetzt fällt uns noch was ein. Änderung auf dem Arbeitsplatz. Erneutes übertragen auf die Geräte.
    * Auf der Tour werden neuen Elemente erstellt. Manchmal auch vorhandene verändert.
    * Nach der Tour erstelle ich einen Tourordner in der Datenbank und kopiere die wichtigen Daten aus allen angeschlossenen Geräten per drag-n-drop in diesen Ordner. Vielleicht auch die Planung aus dem Planungsprojekt, bevor ich es lösche.
    * Die Fließbienchen schreiben jetzt in der Projektübersicht noch ein schönes Tagebuch, schließen alle Schlösser und ab in die Datenbank.


    3) Das ist nur ein Platzhalter. Ich habe es in QLGT nie gebraucht und keine Lust es jetzt in QMS zu implementieren. Das soll machen wer meint es wirklich zu brauchen.


    4) Die Schummerung :) Macht man es einmal richtig, mag es keiner. Im Gegensatz zu QLGT werden in QMS auch die nordwestlichen Hänge geschummert. Halt nicht in Schwarz sondern in Weiß. Damit hast Du aber immer etwas vor der Karte. Finde ich aber nicht so schlimm. Ich habe die Transparenz recht hoch eingestellt. Und die Überhöhung der Schummerung runter gesetzt.

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen bitten wir Euch über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben! Vielen vielen Dank...

  • zu 1.2) Aktuell habe ich wenig Ambitionen auf den Geräten Tracks mit Kommentaren zu versehen. Aber man könnte es als Feature Request bei Bitbucket eintragen. Vielleicht hat ja jemand anderes Lust.


    ich wollte es nur erwähnt haben, da ich schon des öfteren Tracks in die Hand bekommen habe, wo halt ellenlange Kommentare vorhanden waren.
    Es bleibt ja bei Bedarf immer noch der Weg, den Inhalt via Wegpunkt=>RBK-Punkt mit dem Track / Projekt zu verbinden.


    zu 2) Da verstehst Du was falsch, bzw das GUI kommuniziert es missverständlich.
    2.1) Das Schloss ist ein Hinweis, dass es aktuell nicht gewünscht ist, das Element zu ändern.


    OK. Ich habe es in der Tat so verstanden das, bei geschlossenen Schloß, nicht nur eine direkte Änderung auf dem Gerät, nicht geht, sondern auch die Überschreibung der Version auf dem Gerät verhindert ist.


    3) Das ist nur ein Platzhalter. Ich habe es in QLGT nie gebraucht und keine Lust es jetzt in QMS zu implementieren. Das soll machen wer meint es wirklich zu brauchen.


    Ich brauches es auch nicht. Aber wäre es als Prävention gegen weitere Nachfragen nicht einfacher den Platzhalter zu entfernen?!


    4) Die Schummerung Macht man es einmal richtig, mag es keiner.


    Ok, Ok.
    Auch wenn es mir ja sonst am Spieltrieb nicht mangelt, habe ich den Transparenzregel in dem Zusammenhang völlig außer Acht gelassen.
    Ist top.:tup::)


    Und den genialen Regler für die Skalierung habe ich nun endlich auch kapiert.:tup:


    Bleibt eine gewisse Irritation durch Min/Max der Regler:
    Transparenz: Links=Max Rechts=Min
    Schummerung: Links=Max Rechts=Min
    Hangneigung: Links=Min Rechts=Max

  • Halo kiozen,
    beim ausführen von ccmake erhalte ich folgende Meldung:


    Make Warning (dev) at /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreMacros.cmake:224 (configure_file):
    configure_file called with unknown argument(s):


    COPY_ONLY


    Call Stack (most recent call first):
    src/CMakeLists.txt:430 (qt5_add_resources)
    This warning is for project developers. Use -Wno-dev to suppress it.


    QMS lässt sich danach problemlos kompilieren & installieren.


    Verwendete CMake Version 3.2.1 von https://launchpad.net/~george-…+archive/ubuntu/cmake-3.x , die Meldung erscheint seit dem Update auf die Version 3.2.1 (veröffentlicht am 31.03.)


    Keine Ahnung, ob du damit was anfangen kannst...

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen bitten wir Euch über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben! Vielen vielen Dank...

  • Ich brauches es auch nicht. Aber wäre es als Prävention gegen weitere Nachfragen nicht einfacher den Platzhalter zu entfernen?!


    Die Hoffnung dass jemand anbeißt und sich drum kümmert stirbt zuletzt. ;) Gerade bei den Filtern kann man sich recht gut austoben, weil der Code hierfür sehr einfach ist. Ideal um einzusteigen.



    Bleibt eine gewisse Irritation durch Min/Max der Regler:
    Transparenz: Links=Max Rechts=Min
    Schummerung: Links=Max Rechts=Min
    Hangneigung: Links=Min Rechts=Max


    Transparenz ist ein Übersetzungsfehler. Das muss Deckkraft heißen.


    Den Faktor bei der Schummerung wird kaum jemand wirklich verstehen. Hier werden die Meter zwischen den Punkten in der DEM Datei nochmal etwas manipuliert. Wird der < 1.0 dann rücken die Punkte näher zusammen, damit wird das "Gelände" steiler und somit dunkler. Ich habe deswegen vermieden irgendwas dazuzuschreiben. Soll jeder durch spielen herausbekommen.

  • @ anesthesia:
    Vielen Dank für das "Erweiterte Profil". Habe ich erst jetzt gefunden.
    Super - genau so habe ich mir das vorgestellt! :tup:



    Ich will ja jetzt nicht unverschämt werden:
    Aber könnte man vielleicht die Liste mit den Trackpunkten auch zusätzlich auf der Kartenansicht aktivieren? Das sollte dann alles zusammen synchron "interagieren":
    Ich fahre mit der Maus den Track ab (Sprechblase). Gleichzietig wandert der rote Strich im Höhenprofil mit (soweit ist das ja bisher schon der Fall). Bei Klick auf einen Punkt wird dieser auch in der Trackliste markiert (noch schöner: Die Liste wird gleich automtisch mitgescrollt. Das wäre natürlich das i-Tüpfelchen).
    Und anders rum: Ich fahre das Höhenprofil ab. Der Punkt wandert auf der Karte und in der Trackpunktliste mit.
    Oder: Ich markiere einen Punkt (oder sogar einen ganzen Abschnitt) in der Liste. Auf der Karte und im Höhenprofil wird mir die entsprechende Stelle ebenfalls gleich markiert.
    Und zwar alles in einer Ansicht. Somit hätte man alle Informationen sofort im Blick.
    Ich bin mir aber nicht sicher ob das wirklich im Sinne des "Erfinders" ist. Irgendwann würden zu viele Fenster dann so ausschauen wie bei QuoVadis (und dort finde ich es zu unübersichtlich). QMapShack verfolgt ja mit den "Ansichten" eigentlich bewusst einen anderen Weg.



    @ huirad:
    Auch dir vielen Dank für die Hilfe. Neuinstallation der MSVCR90.dll hat zwar nichts geholfen. Aber du hast mich auf die richtige Spur gebracht: Ich habe einfach mal alle Windows-Updates der letzten Monate deinstalliert und neu drübergezogen.
    Jetzt flutscht es wieder wie es soll (hoffentlich auf Dauer).
    Keine Ahnung was da wirklich los war. Scheint aber ab und zu vorzukommen (habe ich zumindest in einem Artikel von Chip online gelesen).
    Jetzt muss ich nur noch schauen ob ich das Problem auf dem Laptop mit der gleichen Methode gelöst bekomme.

    ʎɐqǝ ıǝq ɹnʇɐʇsɐʇ ǝuıǝ ɹǝpǝıʍ ǝıu ǝɟnɐʞ ɥɔı ´uuɐɯ ɥo