Beiträge von Rhadamanthys

Zitat https://quovadis-gps.com/QuoVadis-X-Software:

"Die Software beinhaltet eine Dauerlizenz und ein Jahr lang Nutzung der Routingengines Graphhopper und Microsoft Maps, kostenlosen Support und freie Updates. Nach Ablauf des ersten Jahres kann die Software mit der zu dem Zeitpunkt aktuellen Version weiter genutzt werden mit vollem Funktionsumfang, aber ohne Graphhopper/MS-Routing, ohne Support und keineUpdates"

Zitat https://wikiqvx1.qvgps.de/doku.php?id=de:07_functions:start:"QVX wird in den drei Versionen Basic, Standard und Poweruser(PU) jeweils als Jahresabo verkauft.

Zum Ausprobieren vor Kauf kann für 25 Tage kostenlos die PU als Demoversion aktiviert werden. Wenn die Demo oder ein Abo abgelaufen ist, läuft QVX automatisch als Viewer-Version."

Die Viewer-Version kann laut Vergleichstabelle fast garnichts. Wenn ich danach für knapp 140€ die PU kaufe, habe ich nach einem Jahr die Viewer. Ist das die oben beschriebene "Dauerlizenz"?

Zitat von Horst_H

wir haben gerade wieder einen langjährigen Nutzer der über QV7 schimpft das es mit seinen Datenmengen nicht umgehen kann und einfriert (obwohl TTQV4 keine Probleme damit hat) aber die technischen Hintergründe nicht verstehen möchte und stattdessen Tom Pfusch vorwirft.

Wahrscheinlich ist der nur irritiert weil die Experten versuchen, ihm klar zu machen, daß er 230€ für alten, nicht mehr weiter entwickelten 32-bit-Schrott ausgegeben hat. Bestimmt läßt er sich überzeugen, auf QVX umzusteigen, wo er dann für 136€/Jahr 10 Jahre updated, bis die gröbsten Bugs durch kleinere ersetzt sind.

Zitat von Horst_H

Schau doch selber nach, schließlich unterstützt QV7 beide Datenbankformate.

Für gute Ratschläge von Experten bin ich immer dankbar.

Meine Frage an den QVX-Fan war: Sind sie mit QVX schlanker geworden?

Zitat von Horst_H

QV7 mit der ValentinaDB hat die Datenbanken leider stark aufgeblasen

Und sind sie mit QVX wieder schlanker geworden?

Zitat von Horst_H

Einfach die Daten per ODBC Treiber abfragen z.B. mit Excel

Habe ich 223€ ausgegeben, damit ich umständliche Umwege gehen muß, um einfachste Dinge zu erledigen?

Lustiges Argument. Das steinalte TTQV4 ist auch ein 32-bit-Programm und hat keine Probleme mit dem Track. Alle Exporte, auch in Dateien dauern ca. 3 Sekunden. Dass es in QV7 nicht geht, ist schlicht Pfusch.

Wär's eine MS-Office-Datenbank, hätte ich 30 Minuten ein funktionierendes Makro.

Guter Hinweis. Eigentlich sollten 10000 Punkte für 1 Tag Postschiffroute reichen, aber der Empfang hinter dem Kabinenfenster war nicht sehr gut, da können viele "Fehlmessungen" dazu kommen. Das ist m. E. aber kein Grund zum Absturz und zum Vollschreiben der Speicherkarte mit Unsinn.

Habe gerade daheim einen Test laufen: GPSmap62s an Dachantenne (super Empfang!), 1 Punkt/s, Speichern wenn voll. Müßte alle 10000s=2h46m40s eine Archivdatei produzieren. Nach gut einem Tag sind dann 32 Autosave- und eine Current-Datei entstanden. In QV7 importiert und mit dem Trackmanager verbunden. Der X-Plorer zeigt 93664 Objekt(e) an, alle markiert und mit dem Druckerwerkzeug in die Windows Zwischenablage kopiert: da gibt QV7 keine Rückmeldung mehr, mindestens 30 Minuten lang, Abbruch einleiten (Wer solche Stresstests plant, tut gut daran, QV7 erst mal zu schließen und neu zu starten, damit es nach dem Absturz mit den gewünschten Einstellungen hochläuft).

Genauso scheitert der Versuch "Liste in Datei ausgeben..." oder der Versuch, den Track als "NMEA" zu exportieren. Immerhin, als "Compe" geht es, wenn auch sehr zäh, 1764,11s (Assistent - Datenexport!). Was da so schwierig ist ein paar Zahlen in eine ASCII-Datei zu schreiben, erschließt sich mir nicht.

Welche Freude hätte da erst Sir-Vival mit seinen 400000 Punkten...

Übrigens, mein altes TTQV4.133 bekommt den selben Datensatz in ca. 3 Sekunden in die Zwischenablage.

Und von da in eine LibreOffice Calc-Tabelle. Ziel der Übung war es, Lücken in der Aufzeichnung festzustellen. Ergebnis: 24 von 93664 Trackpunkte hatten 2s Abstand zum Vorgänger. Keine Lücke an den Dateienden. Finde ich ganz akzeptabel.

Eine schöne Verbesserung in QV7 ist die Möglichkeit, Kartencursor und X-plorer zu verbinden. Das funktioniert in beiden Richtungen. Nur teilweise funktioniert es mit einem XY-Diagramm. Klicke ich mich im X-Plorer von Zeile zu Zeile, wandert der Kartencursor brav entlang des angezeigten Tracks. Der Diagrammcursor macht das zunächst auch, springt dann aber wieder zurück, scheinbar unmotiviert.

Nun zeigt sich aber, daß das an Stellen passiert, wo der Track einen Weg hin und zurück führt, wo also Trackpunkte zeitlich (und natürlich in der Tabellenposition) weit auseinander, geografisch (Lat/Lon) aber nahe beisammen liegen. Also ob für die im X-Plorer angeklickte Position im Diagramm die "erste nahe Geoposition" gesucht würde, um den Cursor zu setzen und nicht die Tabellenposition, die man ja im Tooltip sehen kann (QV7.4.0.5).

Übrigens: Steht eigentlich im Wiki, daß man Tracks ganz Windows-Like mit Drag und Drop in die Karten- und Diagrammfenster bekommt?

Na ja, 11 Tage sollte 11 Dateien geben, da ist bis 128 lang hin. Die GPX-Dateien sind auch nicht in der root, sondern in /Garmin/GPX. Und es gibt mit einem funktionierenden Betriebssystem (Linux?) keinen Grund zum Abschmieren, nur weil eine Datei nicht geschrieben werden kann.

Danke! Da wär ich jetzt nicht drauf gekommen.

Aber wenn ich alles weglasse, was nicht funktioniert, kann ich mich aus dem Forum abmelden

Exportiert man eine in QV7.4.0.5 einen Track als Datentyp GPX_10, enthält die Datei speed-tags mit der Geschwindigkeit in km/h. Der Standard sieht aber m/s vor. Beim Import wird das richtig unterstellt, weshalb man damit um den Faktor 3,6 schneller wird. Kann man ja mit dem Trackprozessor korrigieren.

Beim Typ GPX_11 hat man das tag klugerweise weggelassen, sodass QV7 beim Import die Geschwindigkeit selbst errechnet.

Hallo allerseits, nach langer Pause bin ich mal wieder hier.

Ich rechne mal nach, 400.000 Punkte (Trackpunkte?, Bytes?) in 10h, das gibt 11,1111 Trackpunkte/s, echt jetzt? Andererseits, ein GPS spuckt pro Trackpunkt einige Hundert Bytes NMEA-Daten (ASCII) aus je nach Anzahl der des Sätze. Da sind 400.000 Byte nicht viel.

Aber zu meiner Erfahrung mit dem Versuch, die klassische Hurtigrute Bergen-Kirkenes-Bergen (Jagd nach dem Polarlys!) mit einem Garmin GPSmap62s zu loggen. Es hat ja Strom in der Kabine, er kann also die 11 Tage am Stück durchlaufen. Eingestellt auf tägliche Archivierung (was er immer brav machte, wenn er tagsüber benutzt wurde und nachts schlafen durfte) sollte es eigentlich Jahrzehnte dauern, bis die Speicherkarte voll ist.

Was soll ich sagen, nach ca. 5 Tagen hängte er sich auf. Am PC zeigte sich dann, daß er die Speicherkarte mit einer Datei vollschrieb, in der es nach GPX-Daten immer derselben (letzten) Position aussah.

Wieder daheim nochmal probiert, dito. Man kann ihn auf auf "speichern, wenn voll" stellen, habe ich nicht probiert, ob das besser geht.

Fazit: vorher testen!

Tut mir leid, daß ich das nicht genau genug erklärt habe.
Der Rückentwicklung bedarf es ja nicht, da das Original verwendet werden kann und für private Zwecke auch darf, wenn ich den Lizenztext richtig verstanden habe.
Also: qbr brauchte ich nicht.
Das ominöse Tool habe ich nur erwähnt, um zu zeigen, daß es sich bei "nicht abwärtskompatibel zu TTQV4" nicht um ein Kompatibilitätsproblem im technischen Sinn handelt, sondern um eine kommerzielle Entscheidung. Die wird ja auch gleich verteidigt mit "dezenten Hinweisen" auf Anwaltskosten.

Gut zu wissen, aber irrelevant.
Die Karte gibts hier: http://rumsey3.s3.amazonaws.co…ny1893GeoJP2/g5820727.jp2
Lizenzinformation:
"Images copyright © 2000 by Cartography Associates. Images may be
reproduced or transmitted, but not for commercial use. For commercial
use or commercial republication, contact http://mailto:carto@davidrumsey.com This work is licensed under a Creative Commons License. By downloading any images from this site, you agree to the terms of that license."
Die Reproduktion im proprietären qbr-Format ist imho eine gewerbliche Nutzung.
Quovadis hat sicher eine Lizenz und die würde sich vielleicht auch auf eine Reproduktion im ecw-Format erstrecken.

Im Übrigen: Die Karte ist für mich als Nichthistoriker eher uninteressant. Die Reproduktion war nur eine Fingerübung, die ich wieder löschen werde.

Heute schon wieder, 30°C. Habe die Schwüle genutzt, die KDR-100 ins ecw-Format zu bringen. Zeigt TTQV4 freudig an. Würde sich vielleicht bei QV im Downloadbereich auch gut machen.

Zitat von Polarlys

Hallo Lutz,

für die Karte ist QV6 erforderlich, sie läuft nicht mit TTQV4. QBR-Karten sind nicht abwärtskompatibel, sie laufen ab der Version, für die sie ursprünglich erstellt wurden, für die KDR ist das QV6.

Schlechte Menschen, die eine möglicherweise illegale zu TTQV4-Zeiten aktuelle Software wie ozimaptrans besitzen, könnten natürlich damit testen, ob die fehlende "Abwärtskompatibilität" auf Formatänderungen beruht oder der Lizenzcode nur einfach nicht verraten wird, damit der Interessent in QV6 investiert. Das wäre dann ein Geschäftsmodell, das vielleicht mit der Creative Commons License des Rechteinhabers kollidiert...

Zitat von prm support

Ich erkenne eigentlich keinen Zusammenhang zum zuvor betriebenen

Diskussionsfaden.

Thema: "GPS automatisch suchen"
Wenn die Schnittstelle wegen fehlender Rechte nicht gefunden wird, liße sich das Phänomen erklären.

"
Einstellungen für Benutzerkonten" bewirkt nichts, weil die COM nicht gefunden wird und die Rückfrage "wollen Sie ...Änderungen zulassen garnicht kommt.

Zitat von jockel

Hauptsache "wurde nicht erkannt" gibt einen Hinweis!

Womit der Kreis zu meinem Erstbeitrag geschlossen wäre

Zitat von Polarlys

Gerd hat keinen Geotiff-Header zitiert, sondern das Infofeld aus GM. Ich kann heute abend mal einen Geotiff-Header hier reinstellen.

Zitat von Polarlys

Gerd hat keinen Geotiff-Header zitiert, sondern das Infofeld aus GM. Ich kann heute abend mal einen Geotiff-Header hier reinstellen.

Darf ich das so interpretieren, daß in Gerds Geotiff wahrscheinlich alles für die korrekte Kalibrierung erforderliche drinstand, QV6 damit aber irgenwie nicht zurecht kam? Wenn Tom "Potsdam/DHDN mit aufgenommen" hat, hat das grundsätzliche Relevanz oder ist nicht vielmehr zu erwarten, daß die Kalibrierung beim nächsten Namen (z.B. "Potsdam-DHDN") wieder schief geht?

Zitat von Polarlys

In einem vollständigen Geotiff-Header stehen auch die EPSG-Codes für die verwendete Projektion, Datum, Koordinatensysteme, Bezugsmeridian, Transformation und Einheit, darüber läßt sich alles indentifizieren, auch wenn kein Klarname dabei ist.

Eben.

Und genau das alles steht nicht in dem von Gerd zitierten Header. Das muß ich alles aus den Angaben "Mercator", "Potsdam" und dem Zahlenwust rausinterpretieren. Künstliche Intelligenz für QV?