Version 1.17.5

Zitat

Original von Peter Kirst
Nicht ganz. Aus irgendeinem Grund wird die Kalibrierung in dem Fall gefunden und gelesen aber als schlecht verworfen. In dem Fall schaltet Glopus die Karte auf Autocalib, d.h. sie wird so kalibriert, dass die aktuelle Route erst mal optimal auf die Karte gemappt wird und die Route damit zur Kalibrierung verfügbar ist.
Warum die Kalibrierung verworfen wird und wieso das beim 2. Start nicht passiert, ist mir nicht klar.

Kann ich bestätigen. Heute das gleiche erlebt. Nach der ersten Map-Indizierung war zwar die ungezippte Kachel richtig, aber die gezippten Kacheln falsch kalibriert. Beim Neustart von Glopus (ohne Neuindizierung) stimmte die Kalibrierung dann wieder.

Zitat

Original von Peter Kirst
Denkt daran, dass wir auch mehere Katenansichten zur Verfügung haben. Man kann also Sat- und Topokarte in verschiedene Verzeichnisse packen, wenn sie sonst gleiche Auflösung haben. Ein manuelles Laden macht in dem Fall eh nur Sinn, wenn man das automatische Nachladen abschaltet.

Gut, dann solltest du das aber so organisieren, dass nicht jedesmal der Index neu generiert werden muss. Bei zigtausend Kacheln dauert das eine Ewigkeit. Schau doch einfach die File-Datum/Zeitangaben an, ob es eine neuere Datei als die cache.dat gibt. In der Regel wird sich da nichts geändert haben und die langwierige Indizierungsprozedur wäre überflüssig.

Dieser Zeitvergleich gibt dir wirklich einen guten Performance-Schub, ohne Nachteile erkaufen zu müssen. Einzig bei zigtausend Einzelkacheln im Verzeichnis würde im Falle einer Änderung etwas Zeit gebraucht. Aber das wäre bei konsequenter Nutzung der ZIP-Funktion nicht mehr relevant.

Aber halt, noch ein Problem: beim Kopieren einer Datei via ActiveSync auf den PDA wurde der Zeitstempel des Draufkopierens eingetragen. Da funktioniert die oben beschriebene Methode. Aber was ist, wenn die Karte extern beschrieben wird? Wenn eine ältere Datei ins Verzeichnis geschoben wird, würde die nicht als Neuerung bezüglich cache.dat-Index erscheinen. Um das Problem zu lösen wäre noch ein separater File-Index notwendig, wo alle Dateien inklusive Zeitstempel verzeichnet werden. Beim Glopus-Start wird dann der aktuelle Verzeichnisinhalt mit diesem File-Index verglichen. Ist zwar ein Schritt mehr, aber wohl auch nicht zu aufwendig. Jedenfalls muss eine Methode gefunden werden, damit nicht bei jedem Verzeichniswechsel oder manuellem Kartenwechsel wieder alle zigtausend Kacheln neu indiziert werden. Je größer die Kachelzahl wird, desto bedeutsamer wird diese Optimierung.

Zitat

Original von Peter Kirst
Denkt daran, dass wir auch mehere Katenansichten zur Verfügung haben. Man kann also Sat- und Topokarte in verschiedene Verzeichnisse packen, wenn sie sonst gleiche Auflösung haben. Ein manuelles Laden macht in dem Fall eh nur Sinn, wenn man das automatische Nachladen abschaltet.

ich find die verschiedenen kartenansichten aber leider total unpraktikabel, zumindest so wie sie momentan zu handhaben sind.

Zitat

Original von FelixDeLuxe
ich find die verschiedenen kartenansichten aber leider total unpraktikabel, zumindest so wie sie momentan zu handhaben sind.

Warum? Ist doch gut organisiert: wenn die Kachel verlassen wird, eine neue Kachel gleicher Auflösung mit passender Lokalität wählen. Wenn gezoomt wird, die nächste zum Zoomlevel passende Kartenart wählen. Bei mir z.B. auf unterstem Level 1m bis 20cm/Pixel das Google-Foto, dann bei etwa 2m/Pixel die Top25-Karte ... u.s.w. Das geht recht gut. Viel mehr Kartenarten machen eh keinen Sinn, und wenn doch, kann man es in andere Verzeichnisse legen. Wie soll das Programm anders entscheiden? Man könnte natürlich Kartentypen definieren und dann per Button den "topografisch"-Typ auswählen. Eine solche Klassifikation gibt es aber auch in anderen Programmen nicht, z.B. OziExplorer. Einzig das ständige Neuindizieren bei manueller Kachelwahl müsste optimiert werden.

Zitat

Original von Murmel
Wie ist das, wenn ich Karten mit verschiedenem Massstab verwenden will, etwa Germay als Übersicht und dazu einige detaillierte Satellitenkarten. Ich schaffe es nicht, dass diese automatisch eingeblendet werden, wenn ich in den Bereich einer solchen Karte hineinfahre. In diesem Fall muss ich zuerst die Germany zoomen, bis die Satkarte plötzlich eingeblendet wird.

Kann sich Glopus die 1:1 Einstellung pro Karte merken?

Hallo

Du hast das Prinzip nicht ganz verstanden!

Die detailliertere Karte wird schon automatisch eingebelenden!
Die Bedinung ist aber dafür das dir Zoomstufe näher an der detaillierteren Karte ist als an der Übersichtskarte.

Woher soll Glopus wissen wenn du die ganze Zeit mit der "Übersichtskarte" (wahrscheinlich noch in der 1:1 Auflösung) fährst das du dann die detailliertere Karte willst ? Und voralledingen welche Zoomstufe (Ich arbeite mit 6-8 Zoomstufen für das selbe Gebiet).

Die 1:1 Einstellung entspicht 1 Pixel der Karte ist 1 Pixel des Displays, ist also nix zu merken sondern eher Idealfall für Kartenanzeigen (Nix an Punkten hinzurechnen und nix an Punkten zusammen zurechnen).

Wenn du Germay als Übersicht und vielleicht hochauflösende Satellitenkarten verwendest ist das ein gewaltigere Zoomsprung!

In der Regel weis man doch welche Karten man mit hat und da kann man bei entsprechender Annäherung dann rein Zoomen.

Ich Arbeite mit Kachelfelder (also Deutschland schön in 148 Häppchen aufgeteilt) wenn der Kartenname meine Übersichts Karte sich ändert weiß ich das ich entweder in oder aus dem Bereich fahre denn ich mich höher auflösendem Karte habe.

Gruß
Silver

PS: Zu der Dikussion "Indizieren" !
Warum nicht die einfachste Version, jedem User selbst entscheiden lassen ob er den Index neu haben will anstatt zu hyberbolische Lösungen zu greifen !

Zitat

Original von Peter Kirst
Genau das meine ich doch! Unter "Ansicht", "Extras" "Weitere Ansichten" stehen weitere Kartenseiten zur Verfügung. Jede dieser Ansichten speichert ihre eigenen Einstellungen, d.h. man kann z.B. eine Ansicht auf ein Verzeichnis mit Sat Bildern legen, eine andere auf Top25 und eine auf große Übersicht. Beim Wechsel der Kartenansichten braucht Glopus nicht neu zu indizieren, sondern muss ggf. nur Karten nachladen.

mir geht es nicht um das neu indizieren der kacheln.

mir geht es darum, dass er sich nicht merkt welche kartenansicht ich ausgwählt habe.

beispiel: ich guck mir gern auf dem sofa nochmal meine rad/motorradtouren an.
wenn ich mir z.B. bei der nachbetrachtung einer gefahrenen strecke das diagramm ansehe und von dort auf den punkt springe, wo ich am schnellsten/höchsten war springt er mir jedes mal wieder in die kartenansicht "1" zurück.
glopus sollte solange in kartenansicht "x" bleiben bis ich selbst eine andere wähle.
dann wäre schön, wenn ich beim umschalten von kartenansicht "1" auf "2" die gleiche position angezeigt bekomme wie ich sie grad in kartenansicht "1" hatte. in dem fall will ich nicht an die aktuelle position oder an eine die ich mir gestern zufällig angesehen habe.

man kann nun auch alle karten in ein verzeichnis klatschen um das zu umgehen. nuuuur...da kommt dann wieder das problem, dass mit zu vielen kacheln im verzeichnis das ganze zu langsam wird.
außerdem ist die funktion mit den verschiedenen kartenansichten ja ne klasse sache, nur eben für mich zu umständlich zu nutzen. was dann zur folge hat, dass ich sie eben gar nicht nutze.

Zitat

Original von Silver34

Die detailliertere Karte wird schon automatisch eingebelenden!
Die Bedinung ist aber dafür das dir Zoomstufe näher an der detaillierteren Karte ist als an der Übersichtskarte.

Woher soll Glopus wissen wenn du die ganze Zeit mit der "Übersichtskarte" (wahrscheinlich noch in der 1:1 Auflösung) fährst das du dann die detailliertere Karte willst ? Und voralledingen welche Zoomstufe (Ich arbeite mit 6-8 Zoomstufen für das selbe Gebiet).

Danke für die Antworten. Ich hatte tatsächlich gedacht, dass wenn ich in den Bereich einer anderen (detaillierteren) Karte einfahre, dort automatisch virtuell der Knopf 1:1 gedrückt wird (werden könnte), so dass ich immer mit der detailliertesten Karte fahren könnte.

Hoffentlich habe ich mich verständlich ausgedrückt.

Zitat

Original von Peter Kirst
Zu dem Neuindizieren: Über Zeitstempel kann man natürlich Änderungen feststellen, nur dauert das ähnlich lange wie die Neuindizierung - bringt also gar nix. Ich denke ich werde wirklich noch einen Menüpunkt zur Neuindizierung aufnehmen und dafür beim manuellen Karten öffnen auf den vorhandenen Index zugreifen, zumindest wenn die angewählte Karte enthalten ist.

Nein, das wird wahnsinnig viel Zeitersparnis bringen, wenn nur viele gezippte Kacheln drin sind. Angenommen, wir haben 10 Dateien/Karten drin, davon aber eine ZIP-Datei mit 20000 KAL/GIF-Kachel-Dateien (typisch Bundesland Top25). So, was passiert nun: jedesmal wenn ich das Verzeichnis anwähle müssen jetzt 10000 KAL-Dateien aus dem ZIP geöffnet und indiziert werden ... das dauert Ewigkeiten. Mein Vorschlag: Glopus erstellt beim ersten Mal einen Dateiindex, d.h. die 10 Dateien inklusive Zeitstempel. Beim nächsten Mal wenn ich das Verzeichnis anwähle werden die aktuellen Dateien mit den 10 aus dem Dateiindex verglichen. Wenn nun neue Dateien drin sind (d.h. entweder neueren Datums oder eine alte hereingeschobene Datei die im Index fehlt), wird diese Indiziert und dem cache.dat hinzugefügt. Nun, in den meisten Fällen wird sich aber gar nichts ändern und es sind eben nur die 10 Dateien verglichen worden.

Also Performance-Relation:

10 Dateien Vergleich mit Index versus 10000 KAL-Dateien indizieren!

Nun, meinst du das lohnt sich nicht? Oder hab ich da einen Denkfehler drin.

p.s.: einen deutlichen Performance-Boost dürfte es auch geben, wenn nicht 10000 KAL-Dateien aus dem ZIP geöffnet werden müssen, sondern die ganzen KAL's einfach nur am Stück in ein File geschrieben werden. Das halbiert die Dateianzahl und für das Einlesen der KAL's dürfte das wohl keinen Unterschied machen. Ich nutze für meine Skript-Kachelbearbeitung auch meist ein "cat *.kal | programm", wo das programm dann die Kachel-KAL's der Reihe nach einliest. Zu jedem "[Kalibrierung]"-Keyword setze ich da einfach die Kartennummer eins rauf, ganz einfach. Dadurch hab ich mir den "Directory Walk" gespart. Du kannst ja ohne weiteres kompatibel zum jeztigen System bleiben, indem Glopus einfach beides akzeptiert, einzelne KAL's und eine KAL-Datei als Liste aller Kacheln.

Also, ich meine die beste Performance bekommst du hin, wenn du einmal bei den KAL's die Ein-Datei-Lösung zulässt und dann noch den Dateiindex mit Zeitstempel machst. Das alles ohne nennenswerten Aufwand, aber mit wahrscheinlich extrem schneller Performance bei zigtausend Kacheln.

Zitat

Original von frank334
Nein, das wird wahnsinnig viel Zeitersparnis bringen, wenn nur viele gezippte Kacheln drin sind.

Leider hab ich bei mir festgestellt das das Kartennachladen aus dem ZIP-Files merklich länger dauert als direkt aus einem Verzeichnis.
Kartennachladen aus dem Verzeichnis ca. 3 sek
Aus dem ZIP-File > 10 sek.
Genau die selben Karten in 2 Ordner (1*zip+1 Karte im andern die 1600, nur um Fragen zuvorzukommen)

Ich arbeite so etwa mit 1600 Karten das Öffnen des Ordner um zu wechseln dauert deutlich länger als 1 min, deshalb würd schon gerne aus ZIP umsteigen allerdings ist mir der Aktive Betrieb wichtiger als Startbeschleunigung.

Gegen die "KAL-Ein-Datei-Lösung" hätte ich auch nichts einzuwenden würde die Dateienzahl halbieren, wobei ich nicht so richtig weis wie man aus Datentechnischer sicht sicherstellt das duie Zuordnuing der Kalibierung zu der Karte sichergestellt ist (Jetzt Karte + Kal in einem Ordner , bei der "KAL-Ein-Datei-Lösung" würde man sicherlich die Kal's aus dem Ordner entfernen um die Dateienzahl zu reduzieren [Vielleicht das Glopus beim Indizieren die Kal's aus dem Ordner/Zip in einen Extra Ordner im Ordner verschiebt]).

Ich hoffe das Peter bei den vielen Vorschlägen überhaupt noch weiß wie er rangehen will.

Für die ZIP-Favorisierer würd mich Interissieren ob ihr den selben Effekt bei WM5 (das das Nachladen bei Kartenverschieben länger dauert als direkt aus dem Ordner) feststellt. Aber bitte Objektiv und mit großer Kartenzahl im Ordner).

Schaun mir mal was Peter so macht.

Gruß
Silver

Zitat

Original von Silver34
Leider hab ich bei mir festgestellt das das Kartennachladen aus dem ZIP-Files merklich länger dauert als direkt aus einem Verzeichnis.
...
Ich arbeite so etwa mit 1600 Karten das Öffnen des Ordner um zu wechseln dauert deutlich länger als 1 min, deshalb würd schon gerne aus ZIP umsteigen allerdings ist mir der Aktive Betrieb wichtiger als Startbeschleunigung.
...
Gegen die "KAL-Ein-Datei-Lösung" hätte ich auch nichts einzuwenden würde die Dateienzahl halbieren, wobei ich nicht so richtig weis wie man aus Datentechnischer sicht sicherstellt das duie Zuordnuing der Kalibierung zu der Karte sichergestellt ist (Jetzt Karte + Kal in einem Ordner , bei der ...
Silver

Alles anzeigen

Gut, momentan habe ich auch etwa 2000 Kacheln. Das aber nicht wegen der Datenmenge, sondern weil es bei vielen Kacheln einfach zu langsam wird. Die Top25-Karte würde allerdings 10 000 Kacheln umfassen, d.h. doppelt so viele Files. Das ist ohne ZIP gar nicht mehr vernünftig zu lösen.

Etwas länger dauert es im ZIP schon beim Kachelübergang, aber bei der Fahrt fand ich das nicht störend. Ich denke auch bei mir liegt es daran, dass ich versehentlich alles komprimiert habe, also die Dekompressionsroutine durchlaufen werden muss.

Die "KAL-ein-Datei-Lösung" war ja schon da, mit dem ASCII cache.ini. Das war einfach nur die Liste aller Kalibrierpunkte aller Kacheln. Jetzt ist das halt binär n der cache.dat. Das Einlesen ist kein Problem, ein 10-Zeiler in C, das mache ich auch schon in meinen Kachelfilterprogrammen. Wichtig ist mir nur, dass ich das selbst erzeugen kann. Also z.B. "cat *.kal > alleszusammen.kal" ist nur ein Komando für's Zusammenstellen. Die cache.ini war von den Keywords eleganter und kompakter organisiert (alle Kalibrierpunkte unter einer Überschrift). Auch das könnte ich mit Skripten gut hinbekommen. Es schadet ja nicht den Benutzern mit älteren Karten, weil das ohne Probleme kompatibel zu den Einzel-KALs implementiert werden kann. Und aus diesen bereitgestellten Files stellt Glopus dann sein umfassendes cache.dat zusammen. So ist es eben am effektivsten zu lösen. Es ist einfach Zeitverschwendung, wenn z.B. eine Kachelsammlung mit 10 000 Kacheln mehr als einmal indiziert werden muss. Das ZIP kann getrost eine vorverarbeitete Datei mit aufnehmen, das Gesamt-KAL wäre die einfachste Lösung.