Beiträge von reinim19

    Hallo,


    ich habe einen Track, denn ich gerne in eine simple CSV-Texxtdatei exportieren möchte. Format:


    52.12345°, 10.12345°


    also nur die Koordinaten. Ist dies mit TTQV möglich. Den benutzerdefinierte IMPORT von Textdateien mit den unterschiedlichsten Spalten und Trennzeichen gibt es ja, warum nicht auch für den Export?

    ja, wenn du nach geographisch Nord gehen willst, mußt du am Kompass 358° einstellen und damit dann auf einen Punkt in der Entfernung peilen.


    Falls das Kartenraster aus geographischen Koordinaten aufgebaut ist (also Grad, Minuten) kannst du somit Peilungen zu einem markanten Punkt aus der Karte bestimmen.


    Bei Karten mit UTM-Gitter mußt du noch die Abweichung Gitternord-geographisch Nord berücksichtigen, die auf der Karte abgedruckt sein sollte.

    Grundsätzlich ist die Deklination in Ö ca. 2-3° und zwar ist die magnetische Peilung immer RECHTS von der geographischen. Also wenn du genau nach geographisch Nord schaust, dann must du dich 2-3° nach rechts drehen um nach magnetisch Nord zu schauen. Und diese 2° Unterschied sind mit so einem Standardkompass schon eher schwer festzustellen (Ableseungenauigkeit, leichte elektromagn. Störungen der Umgebung....)


    Wie hast du denn die Deklination der MagicMaps gemessen, vielleicht meinst du ja nur den Unterschied Geographisch Nordrichtung-Kartengitternordrichtung? Dieser wird von TTQV bzw. Pathaway durch korrekte Kalibrierung bereits auf Geographisch Nord "korrigiert"


    Zur Bestimmung der Deklination benötigt die verwendete Betrachtungs-Software ein Koordinaten-Tabelle mit Werten für die Deklination für die entsprechende Koordinate.


    Der MM-Viewer hat diese meines Wissens nicht, zeigt also nur geographische Peilungen an.
    TTQV hat das und kann somit auch magn. Peilung anzeigen.
    Pathaway wiederum hat sie nicht, zeigt also auch nur geographisch an.

    ich hab jetzt die "böse" der 4 dlls aus dem neuen Set gefunden:
    Zunächst Neuinstallation von TTQV 4.0.108 und Neuinstallation der MM Öst inkl. aktuellem MM Update 2.1.5


    Wenn ich zunächst die 3 anderen dlls ersetze, funktioniert der Import mit den richtigen Koordinaten. Nur wenn ich zum Schluß noch die IK3D.dll ersetzte erhält die MM nach dem Import die Koords aus der Mongolei.

    Hallo,


    verwende die MM Österreich (interaktive Kartenwerk Öst.) schon lange mit TTQV, aber seit einigen Tagen (nach Aufspielen des neuesten TTQV-Updates?) kamen bei deren Verwendung immer Fehlermeldungen. Also Karte aus TTQV gelöscht & komprimiert, aktuelle TTQV-MM-dlls besorgt und ins TTQV-Verzeichnis gespielt (die beiden Zusatzfiles für die MM Öst. liegen noch immer korrekt im MM-Verz.).


    Der Import & Anzeige der MM funktioniert zwar, allerdings stimmt nun etwas mit den Koordinaten nicht, die liegen irgendwo in der Mongolei :lol:....


    Auch OMA & Neuinstallation von TTQV führten immer zu diesem Ergebnis, also probehalber mal die "alten" MM-dlls von 2007 verwendet und damit wird die Karte lustigerweise mit den richtigen Koordinaten importiert.


    Da ist wohl etwas faul im neuen TTQV-Update bzw. den neuen MM-dlls.

    der HQ-Knopf hat früher bei sämtlichen Top-Karten für den PW-Export meiner Ansicht nach überhaupt nichts verbessert (auch nicht bei Skalierung < 1), nur die Karten wurden größer --> also sinnvoll, dass man ihn entfernt hat.


    Der jetzige Dither-Button bringt auch jetzt für Top- und Kompass Karten nichts (daher hab ich ihn immer deaktiviert):
    Bei 8bit ist kein Unterschied zu "ohne Dither" festzustellen, nur Karten werden noch größer.
    Bei 4bit sieht damit der Exportkarte schrecklich aus (kaum Farben zu erkennen, außerdem Datei einiges größer), da ist der reine 4bit Export um Klassen besser (obwohl ja durch Dithering eigentlich "mehr" Farben zu erkennen sein sollten :crazy:).


    Alles in allem kann ich mit den größeren Karten leben, da sie nun wirklich besser ausssehen und ich noch Platz auf meiner SD-
    Karte habe ;-). Aber vielleicht läßt sich ja das Exportmodul noch optimieren, ohne die jetzige Qualität zu beeinflussen :-)

    Hab mir jetzt die neue TTQV 4.0.110 gezogen und nun scheint der PW-Export problemlos zu funktionieren :-). Die Farbtreue bei 8-bit Export von Top50 und MagicMaps-Karten ist so gut wie nie zuvor in TTQV. Auch scheinen mir die Karten etwas schärfer (bei gleicher Skalierung 0,7) wie zuvor. Ein wenig bei Top50 aber extrem bei Top200 und Top500-Karten ;-)


    Die Karten werden bei gleichen Einstellungen jetzt (ev. wegen der höheren Schärfe?) allerdings auch deutlich größer als zuvor.


    Wem dies zuviel ist, der erhält für die Karten auch mit 4 bit noch ein akzeptables Ergebnis (ohne Dithern!). Zwar auf Kosten der Farbtreue, aber zum Navigieren mit dem PDA immer noch gut zu unterscheiden.

    Ich habe hier eine Liste von WP in folgendem Format (Name Breite Länge), die ich per Import/Andere... importiere:


    WP1 50.123 1.234
    WP2 51 -1
    WP3 51.123 0
    WP4 0 12.456


    Dabei wird WP3 und WP4 nicht importiert, Grund ist das eine Koordinate genau 0 beträgt. Alle WPs mit positiven oder negativen Werten werden korrekt importiert.

    Ich habe mir jetzt ein paar neue MagicMaps-Ausschnitte für PW mit TTQV 109c (mit dem "verbesserten" 8bit-Export). In vorigen TTQV-Versionen wurden grüne Waldflächen ocker dargestellt (egal wie groß der Kartenausschnitt war). Etwas anders als die grüne original-Farbe, aber immer gut von der Umgebung zu unterscheiden. Auch grüne Wanderwege waren darin gut zu erkennen. Nur bei Höhenlinien gab es ein (kleines) Defizit.


    Beim neuen Export stellte ich nun folgendes Problem fest: Bei kleinen und mittlereren Ausschnitt-Größen wird die grüne Waldfläche schön in ein Grün konvertiert. Bei größeren Ausschnitten (ca. 50MB, Skalierung 0,7) kommt es aber oft vor, dass die grüne Waldfarbe verloren geht --> sie wird weiß und daher nicht mehr als Wald erkennbar. Grüne Wanderwege bleiben aber komischerweiße grün.


    Ist seltsam, da das Waldgrün mit Sicherheit eine der dominierenden Farben in so einem Ausschnitt ist und diese daher unbedingt in der 8bit-Palette vorkommen sollte.

    Ergänzung:


    Die Option "HQ" bei 8bit-Karten erzeugt bei mir minimal größere Dateigrößen, aber ohne erkennbaren Unterschied (Schärfe, Farben) in PW.
    Bei 16bit-Karte hat "HQ" keinen Einfluss auf Dateigröße.


    Ich bekomme sowohl für Top50, als auch für die MagicMaps in solch grün-braunen Zonen sehr ansprechende und gut zu unterscheidende Farben.
    Da gibt es auch kaum einen erkennbaren Unterschied zur 16bit-Karte.

    die aktuelle Beta-Version (109c) hat laut Info "Exportqualität bei ExportBMP/PW verbessert, wenn HQ aus und 16 oder 256 Farben", probier es damit mal aus.


    Vor einiger Zeit gab's im Exportdialog für 8 bit noch die Option "Dithering", mit der Farben aufgrund einer Rasterung genauer exportiert wurden. Die Karten wurden dadurch aber auch wesentlich größer als bei 8 bit ohne Dithering.


    Falls die neue 8bit-Methode der 109er nicht das gewünschte Ergebnbis bringt, bleibt dir eh nur mehr die 16-bit Methode auf Kosten der Filegröße.

    danke für deine Info. also bei mir haben alle WPs Anordung "0" und dennoch scheint TTQV irgendein System zu haben (und nicht etwa zufällig), welche Symbole oben liegen.


    Da ich diese Tabelle oft aktualisiere, will ich eigentlich nicht für jede Gruppe von Symbolen immer die Anordnung-Nr. ändern. Weit einfacher wäre es wenn TTQV die Reihenfolge einfach anhand der aktuellen Sortierung der Tabelle bewerkstelligt. Wäre dies möglich zu realisieren :grin:?

    Hallo,


    ich habe eine Waypointtabelle mit vielen WPs, die je nach Bedeutung unterschiedliche Symbole besitzen. Ab und zu liegen 2 WPs auf den selben Koordinaten, daher wird 1 Symbol überdeckt. Wie kann ich einstellen, welches Symbol in solch einem Fall oben liegt. Dachte mir, es richtet sich nach der aktuellen Sortierreihenfolge der Tabelle - aber das hat offensichtlich keine Auswirkung: Auch wenn ich die Sortierung umdrehe, wird wieder das gleiche Symbol über dem anderen angezeigt..


    Und noch was: Wenn ich links die WP-Tabelle auswähle und dann auf "in Karte zeigen, Explorer wegblenden" drücke, sehe ich immer zuerst eine bestimmte Position auf der Karte. Auch diese "Startposition" ist scheinbar unabhängig von der Sortierreihenfolge oder einem gesetzten Kartencursor: Sie befindet sich bei jeder neuen Tabellenanzeige immer an den selben Kartenkoordinaten.
    Wäre es möglich, dass sich TTQV hier ev. den Kartencursor merkt, der zuletzt aktiv war, als ich mit dieser WP-Tabelle gearbeitet habe? Und dann beim nächsten Anzeigen dieser Tabelle direkt auf diese Position fährt?
    Alternativ wäre auch möglich, dass ich zunächst einen WP rechts auswähle, bevor ich links die Tabelle auswähle. Dieser WP soll dann Zentrum der angezeigten Karte sein.


    Sonst muß ich jedesmall erst die Karte hin- und herschieben, bis ich wieder an der vorigen Position bin.

    Zitat von "jockel"


    Da ist kein Problem, sondern ganz normales Verhalten, so wie Du es in
    fast jeder anderen einfachen Kartensoftware auch findest. Kaum ein
    Programm kann kann einfach so zwei Kartenblätter in einem Kartenfenster
    darstellen.


    Das immer nur 1 Kartenkachel angezeigt werden kann ist klar, aber meine Kacheln haben eine so große Überlappung, dass es für jede Position eine bildschirmfüllende Kachel gibt. Aber auch hier bleibt PW stur bei der "alten" Kachel bis deren Rand die Bildschirmmitte überschreitet anstatt bereits auf die "neue", den ganzen Screen abdeckende umzuschalten.

    Hi Maddin,


    ja, dass ist leider schon lange bzw. noch eine der größten Schwächen im Zusammenspiel Pathaway-TTQV :roll:. Vielleicht gibt's ja irgendwann mal ein bequemes Dialogfenster zur Auswahl der gewünschten Waypoints/Routen/Tracks ohne immer alle Datenbanken importieren zu müßen ;-).


    Vorläufig ist aber Jockel's Vorschlag sicherlich der praktischste für Dich, da nur Daten aus dem internen PDA Speicher und nicht jene von der Speicherkarte importiert werden.

    Hallo Peter,


    du hast vollkommen recht. Es handelt sich hier nicht um "weiße Ränder" der Karten, sondern um ein altes Problem von Pathaway.
    Jede Karte wird solange in PW dargestellt, bis der Cursor den Kartenrand überschreitet, im Extremfall ist also die Hälfte des Bildschirms (oder bei einem Karteneck sogar 3/4) weiß. Kannst du auch offline ausprobieren, indem du die Kartenkachel bis an deren Rand an den Cursor schiebst und darauf achtest, wenn PW auf eine neue Karte/Kartenkachel umschaltet.


    Zur Kartenauswahl gibt es 2 Optionen unter Einstellungen/Karte:


    - automatische Kartenwahl: PW wählt eine (von dir festgelegte) Karte, die deine derzeitigen Koords abdeckt. Also kann man sich hier auch eine 1:200.000 anzeigen lassen, ohne das von PW auf eine 1:50.000 von der selben Position umgeschaltet wird. Erst bei Erreichen des Kartenrands der 1:200.000 schaltet PW auf eine Karte fürs neue Gebiet um, und wählt dabei bei mehreren möglichen Karten jene mit dem kleinsten Maßstab (sinnvoller wäre hier wahrscheinlich bei der neuen Karte jene mit ähnlichstem Maßstab zur vorigen zu wählen).


    - automatischer Zoom: hier wird von PW sofort nur jene Karte mit dem kleinsten Maßstab deiner Koords ausgewählt, daher wird in obigen Fall sofort von 1:200.000 auf 1:50.000 geschaltet, auch wenn du noch nicht am Kartenrand bist. Bei Amap und Top50 mit gleichem Maßstab ist's wohl Zufall welche gewählt wird. Ich habe auch Amap- und Kompass-kacheln 1:50.000 (beide mit TTQV erzeugt), da nimmt PW mal die eine, mal die andere.

    Hallo,


    ich finde die derzeitige Lösung beim Import PW-->TTQV, dass sämtliche Wegpunkte ALLER Punktetabellen von PW in EINE gemeinsame Punktetabelle von TTQV kopiert werden ziemlich suboptimal. Es werden somit alle Waypoints miteinander vermischt, obwohl man vielleicht nur die paar Waypoints einer kleinen Tabelle von PW importieren will.


    Wäre es in Zukunft nicht möglich, vorab die gewünschte Punktetabelle auszuwählen, oder beim Import aller Waypoints diese zumindest in getrennte Tabellen (mit deren PW-Namen) abzulegen?

    Ich erlaube mir noch kurz auf einige Aussagen von Jörn zu antworten:


    Ich verwende auf meinem PDA Navoigon MN6 als Navisoftware, SN ist off, Karte zeigt immer in Fahrtrichtung. Also müßte laut deiner Aussage sich die Karte im Stand, z.B. an der Ampel drehen. Dies ist aber nicht der Fall. Die Karte behält die Ausrichtung der vorigen Bewegung bei. Ergo hat zumindest Navigon diesen Fall softwaretechnisch berücksichtig. Aber auch andere wie TomTom handhaben dies so:


    Also ist das Abschalten von SN bei diesen Programm kein Problem, was glaubts Du wie viele Beschwerden die Navihersteller von PDAs mit defaultmäßig abgeschalteten, oder gar nicht im Chipsatz vorhandener SN sonst bekommen würden?


    Desweiteren: Die Bewgungsrichtung wird doch meines Wissens (zumindest bei SIRF3) vom Chip nicht mit dem Dopplereffekt bestimmt, sondern einfach als Differenz der letzten zwei vom Chip ermittelten Positionen: Schau dir mal die NMEA-Protokolle eines GPS-Signals an. Deshalb springt der Richtungspfeil in Pathaway ja bei kleiner Geschwindigkeit in einem eher großen Bereich hin- und her und zwar wegen der von Dir schon genannten Ungenauigkeit bzw. Streuung bei der Ermittlung eines Koordinatenpunktes.


    Mit den heutigen Naviprogrammen finde ich SN überflüßig und zum Aufsuchen von Koordinaten mit Schrittgeschwindigkeit (z.B. zum Geocaching) völlig ungeeignet. Sollte eigentlich Sache der PDA-Hersteller (mit eingebauten GPS) oder des GPS-Maus Herstellers sein, die SN "komfortabel" ein- und ausschalten zu können. Man kann dem Durchschnittsanwender zwar zumuten ein Navisystem zu bedienen, aber nicht die dahinterliegende Technik zu verstehen.

    Ich verstehe die standardmäßige Aktivierung der SN auch nicht, da ich ohne Sie mit Navisystemen keinste Probleme festgestellt habe, auch in dicht verbauten Straßen in der Stadt. Und die wenigsten wissen überhaupt, dass man sie abschalten kann und denken der Postitionsupdate erst nach einigen Sekunden im Schritttempo ist GPS-Standard.


    Voricht mit der SBAS aka WAAS/Egnos. SIRF könnte zwar theoretisch diese Signale auswerten, doch ist es eigentlich immer deaktiviert, da SIRF3 die Position schon so genau auswertet, dass diese SBAS-Signale sogar zu einer größeren Ungenauigkeit führen.