Wäre eine Datenbank der vorhandenen Karten nicht sinnvoll?

[SurfaceCleanerZ]

Hallo,

Wäre es nicht sinnvoll, wenn Cw eine Datenbankdatei mit allen auf dem Gerät vorhandenen Karten per Befehl erstellt einmalig inkl. deren abgedecktem Bereich etc. und dann nur noch beim Click auf Karte dort nachguckt? Das dürfte m. E. viel Ladezeit sparen, da nicht hunderte Dateien abgegrast werden müssen, sondern nur eine kleine schlanke Datei...
Das Einladen in die Datenbank kann dann, wenn man zuhause grad nix zu tun hat laufen und man muss im "Feld" nicht immer nervige Minuten warten, bis er die Karte gefunden hat... Das dürfte das Bedienerlebnis ;-) stark verbessern! Evtl. könnte man dann auch alle Caches einblenden in der Karte, die im aktuellen Profil geladen sind und nicht nur das eiungestellte Ziel. Das würde bei vielen Caches echt die Übersicht bewahren. So eine Art Radar mit Kartenhintergrund. Ich bin mir ziemlich sicher, dass das früher ging! Irgendwie bekomme ichs mit der 1532 nicht mehr hin...

Da würde man dann sehen, welche Caches in der Nähe sind in der Richtung, die man möchte und müsste sich nicht nur auf den Abstand zu den umliegenden Caches verlassen. Ich vermisse halt die Übersichtskarte, die man durch Click auf die untere Karte in der Cachebeschreibung im Browser bei gc bekommt!

Oder gibts das schon in aktuellen Eve Builds? Kann man die irgendwo herunterladen fertig zum Test, wie es bei EWE möglich war?

mfG,
Stefan

 

[Wutschkow]

Evtl. könnte man dann auch alle Caches einblenden in der Karte, die im aktuellen Profil geladen sind und nicht nur das eiungestellte Ziel. Das würde bei vielen Caches echt die Übersicht bewahren. So eine Art Radar mit Kartenhintergrund. Ich bin mir ziemlich sicher, dass das früher ging! Irgendwie bekomme ichs mit der 1532 nicht mehr hin...

Werden nicht einfach alle Caches in der Karte angezeigt, die gerade markiert sind (und im aktuellen Kartenausschnitt liegen)? Ist aber auch nur begrenzt hilfreich, weil die Cache-Symbole oft nicht sehr gut zu erkennen sind.

 

[MiK]

Oder gibts das schon in aktuellen Eve Builds? Kann man die irgendwo herunterladen fertig zum Test, wie es bei EWE möglich war?

Soweit ich weiß, funktioniert die MovingMap noch gar nicht im EVE-Branch.

 

[MiK]

Wäre es nicht sinnvoll, wenn Cw eine Datenbankdatei mit allen auf dem Gerät vorhandenen Karten per Befehl erstellt einmalig inkl. deren abgedecktem Bereich etc. und dann nur noch beim Click auf Karte dort nachguckt? Das dürfte m. E. viel Ladezeit sparen, da nicht hunderte Dateien abgegrast werden müssen, sondern nur eine kleine schlanke Datei...
Das Einladen in die Datenbank kann dann, wenn man zuhause grad nix zu tun hat laufen und man muss im "Feld" nicht immer nervige Minuten warten, bis er die Karte gefunden hat... Das dürfte das Bedienerlebnis ;-) stark verbessern!

Genauer habe ich das selbst noch nicht evaluiert. Aber Pfeffer meint, dass es zu kompliziert ist dann immer DB und Karten im Verzeichnis konsistent zu halten. Bzw. es wäre dann eben nicht mehr einfach möglich etwas reinzulegen und es geht.

Es werden übrigens nicht immer alle Dateien eingelesen, sondern nur solche, die grob für den Bereich in Frage kommen. Dies wird anhand des Prefix im Dateinamen entschieden.

 

[SurfaceCleanerZ]

Hallo,

Ja, aber ich fände es halt gut, wenn das einladen und zoomen und verschieben halt nicht immer 2-3 min brauchen würde... Von flüssig ist das auf der 200 MHz OMAP 850 CPU weit entfernt...

mfG,
Stefan

 

[Wutschkow]

2-3 Minuten ist jetzt aber satirische Übertreibung, oder?
Ich habe eine 300 MHz-CPU. Damit bin ich von 2-3 Minuten weit entfernt. Klar dauert es, bis eine Karte angezeigt wird oder beim Zoomen. Aber das ist so im Bereich um die 5-10 Sekunden.
Der entscheidende Faktor scheint mir dabei die Größe der Kartendatei (=Bilddatei) zu sein. Je größer die Datei, desto länger dauert das Laden und Anzeigen. Ich bin mir nicht mal sicher, ob eine Datenbank da viel Abhilfe schaffen würde. Der Flaschenhals liegt eher beim Einlesen und Verarbeiten der Bilddaten. Vielleicht mal probeweise anderes, weniger detailliertes Kartenmaterial verwenden?

Und man darf dabei nicht vergessen: Damit eine Datenbank flott wäre, müsste sie ständig im Speicher geladen sein, wo der Platz dann eventuell für anderes fehlt. Das ist allerdings nur meine laienhafte Vorstellung.

 

[MiK]

Es ist gut möglich, dass die Unterschiede zwischen verschiedenen Geräten sehr groß sind. Ob die Zeit für das heraussuchen der Karte oder für das Laden drauf geht, kann man ja im Infofenster erkennen. Falls es wirklich am heraussuchen der Karten liegt, kann man das evtl. durch eine bessere Organisation von Profilen und Kartenverzeichnissen verbessern. Wenn man nur den passenden Profilunterordner einer Kartenart auswählt und der vom Profil abgedeckte Bereich nicht zu groß ist, liegen dort ja nur wenige Karten, aus denen ausgewählt werden muss.

 

[SurfaceCleanerZ]

Hallo,
ja, wenn man nur 5 Kartendateien hat, dann dauert es sehr viel kürzer. Bloss dann kommt man in den Nachbarort, der ein eigenes Profil hat und einem fehlen die Karten... Daher hab ich jetzt das komplette Topo Verzeichnis ausgewählt. Außerdem ist da noch das Riesen Problem, das es in Niedersachsen nur den Altbestand an Karten gibt und halt den Schwarz/Weiss Server, den ich neulich eingebaut hatte, da der offizielle Server ja unbezahlbar ist... bzw eigentlich ist der offizielle Server ja privat kostenlos, nur der WMS Service halt nicht, sondern nur die geskriptete Webseitenvariante.

So könnte man sich eine Lokaldatenbank auf dem PC anlegen und denn in Cw eine Option machen: Such dir die Karten dieser Gegend dort raus und nimm die auf dem PDA mit. Das ist manuell sehr schwer...
Dann hat man halt einmal die Karten geladen und kann sich dann selbst versorgen, das spart den Servern Traffic und v.a. MAN IST UNABHÄNGIG!

Das wäre was!

mfG,
Stefan

 

[MiK]

Ich sag ja nicht, dass es nie vielleicht eine Datenbank-Lösung geben wird. Aber um vorerst dem Problem Herr zu werden, kannst Du ja die Karten einer Region in einem Ordner ( evtl. mit Unterverzeichnissen) zusammenfassen. Dann musst Du unterwegs von einem Ort in den nächsten nicht das Kartenverzeichnis wechseln, aber es werden auch nicht alle Dateien von ganz anderen Regionen durchsucht.

Wie viele Karten hast Du denn insgesamt in Deinem Topo-Ordner? Bei mir sind es 166 und es läuft eigentlich meist noch recht gut. Ich benutze aber auch keine größeren Auflösungen als Top50 mit 5m/px. Das reichte bisher zum cachen immer aus.

 

[Wutschkow]

So könnte man sich eine Lokaldatenbank auf dem PC anlegen und denn in Cw eine Option machen: Such dir die Karten dieser Gegend dort raus und nimm die auf dem PDA mit. Das ist manuell sehr schwer...

Es wäre in der Tat wünschenswert, wenn man automatisch nur die Kartendateien auf den PDA übertragen könnte, die z.B. den Caches im aktuell gewählten Profil entsprechen. Ich hatte mir dafür mal ein Skript geschrieben, was das erledigt. Warum benutze ich das eigentlich nicht mehr?

Ich würde allerdings eine allgemeinere Lösung vorschlagen:
Kartendateien sollten mit Caches verknüpft sein, zumindest wenn sie für "selektierte" Caches heruntergeladen werden, also als Karte pro Cache. Dann könnte Cachewolf mit dem Cache automatisch die dazugehörenden Karten kopieren, verschieben, löschen usw. Das würde das gesamte Kartenmanagement erheblich vereinfachen. Man könnte dann z.B. die ausgewählten Caches in ein Profil auf der Speicherkarte verschieben, dass sich PC und PDA teilen und schon hätte man alle benötigten Karten auf dem PDA. Und wenn man einen Cache dann mal löscht, werden dessen Karten gleich mitgelöscht. So wäre es (zumindest für mich) optimal.

 

[MiK]

Wenn man nicht gerade Karten mit sehr hoher Auflösung hat, gibt es eigentlich selten eine 1:1 Verbindung zwischen Karten und Cache. Sehr oft befinden sich in einem Kartenabschnitt mehrere Caches. Ich decke mit meinen Profilen jeweils ein bestimmtes Gebiet ab, für das ich einmal am Anfang die Karten hole. Danach kommen mit der Zeit Caches dazu und es fallen welche weg. Aber am Kartenbestand ändert sich dadurch eigentlich nichts. In Gegenden/Profilen, bei denen die Caches sehr weit auseinanderliegen, mag das anders sein.

 

[Wutschkow]

Ja, ich mache es halt genau andersrum. Ich lade mir immer nur relativ kleine Karten zu den einzelnen Caches herunter, die mir auch hauptsächlich für die Anfahrt bzw. Weg zum Cache dienen oder bei Multis zur Orientierung. In eher ländlichen Gegenden mit geringerer Cachedichte ist es so sinnvoller. Vielleicht habe ich auch deshalb keine nennenswerten Performanceprobleme mit den Karten.

 

[Wortfetzen]

Also ich bin auch ein DB-Befürworter.

Bei mir dauert das erstmalige Laden auf dem PDA teilweise 3 Minuten, und das ist absolut kein Scherz. Ist zwar nicht der schnellste PDA (HP 2210), aber trotzdem nervt das.

Klar, wenn man nur wenige oder sehr grobe Karten hat, dann merkt man das nicht.
Aber ab 1000-2000 Kacheln aufwärts wird es wirklich träge.

Und mit OSM-Karten, die teilweise immer besser werden und mittlerweile sogar recht gute Höhenprofile enthalten, ergeben sich ganze neue Möglichkeiten.
Warum nicht ein ganzes Bundesland in guter Auflösung auf die SD-Karte..? Ohne daß ich unterwegs mit irgendwelchen Profilen rumspielen soll oder irgendwelche Dateien hin- & herschieben muß? Mit dem CW ist das heute leider fast unmöglich, da bis zum Laden der aktuellen Kachel aus einem Kachel-Bündel eines Bundesland der gesuchte Cache vermutlich schon archiviert wurde

(Mal davon abgesehen, daß es einer SD-Karte mit FAT sicher nicht gut tut, wenn ständig 1000en von Dateien gelesen und geschrieben werden).




Der Rest wird jetzt leider etwas technisch und richtet sich eher an Entwickler des CW.

Ich hatte folgende Überlegung und dazu bereits erste Tests angestellt:
Bisher liegt jede Kachel für den CW in einer extra Datei. Anhand des Namens kann der CW allerdings schon das grobe Gebiet einer Kachel feststellen, um nicht unnötigerweise alle wfl-Dateien laden zu müssen. Soweit sogut.

Trotzdem muß der CW bei mir durchschnittlich etwa 1/4 aller wfl-Dateien einlesen (die entsprechende Werte habe ich mir ausgeben lassen). Bei knapp 2000 Kacheln für ein relativ kleines Gebiet (15-20 km Kantenlänge) dauert das dann die erwähnten 2-3 Minuten auf dem PDA.


Ich hatte nun folgendes gemacht:
Ich habe ein ZIP erstellt, welches sämtliche Kachel-Daten enthält, aber nur die Grafiken. Die Angaben aus den WFL-Dateien hab ich hingegen alle in eine Datei geschrieben, ich nenne sie mal Index-Datei. DIese Index-Datei kommt mit in das ZIP.

Anschließend habe ich die Klassen MapsList und MapImage dahingehend erweitert, daß sie zusätzlich ZIP-Dateien im Kartenverzeichnis erkennen und einlesen.
(D.h. bisherige Kartenordner funktionieren weiter wie gehabt).
Dabei wird beim Finden einer ZIP-Datei nur die Index-Datei eingelesen, die darin enthalten ist.
Da diese bei den erwähnten 2000 Kacheln nur etwa 300kB groß ist, erfolgt das Einlesen um einiges schneller als das Einlesen von 500 wfl-Dateien.

Beispiel: auf meinem Laptop unter Linux hat sich das Einlesen von etwa 15s auf 1s gesenkt.
Auf dem PDA gab es eine ähnliche Geschwindigkeitssteigerung, das Einlesen dauerte nun nur noch etwa 10-15 Sekunden.


Dann tauchte allerdings das nächste Problem auf:

durch meine Änderung wird beim Einlesen der Index-Datei für jede darin enthaltene Kachel ein Object der Klasse MapInfoObject angelegt. Quasi das gleiche, was der CW vorher beim Einlesen einer wfl-Datei gemacht hat. Dies bereitet auf meinem Laptop keinerlei Probleme. Ich kann dort ZIPs mit mehreren 10.000 Kacheln problemlos einlesen, was nicht länger als ein paar Sekunden dauert.

Der PDA hingegen stößt dabei nun an seine Speichergrenzen. Vermutlich frißt das Anlegen von 10.000en MapInfoObjects einfach zuviel Speicher
Der CW wird bei zuvielen Kacheln in der ZIP einfach irgendwann beendet.

Ich überlege jetzt, was ich hier verbessern könnte. Irgendwie sollte es möglichkeit, die MapInfoObject's nur bei Bedarf anzulegen, und vorher nur eine Art Index über alle Kacheln zu führen.
Eine Art Index-Array mit den Koordinaten der Kacheln, statt lauter einzelne MapInfoObject's?
Vielleicht gibt es dann anschließend eine Möglichkeit, in diesem Array mit binärer Suche relativ schnell diejenigen Kacheln ausfindig zu machen, die auf ein gewünschtes "Ziel-Gebiet" zutreffen. Und anschließend erfolgt das "temporäre" Erzeugen derjenigen MapInfoObject (in den verschiedenen Zoom-Stufen), die für den grade betrachteten Kartenausschnitt eventuell benötigt würden..



Soweit meine Überlegungen.

Vielleicht fällt einem von euch eine gute Lösung für das letzte Problem ein?
Ich würde mich darum kümmern, daß in die EVE-Version zu übertragen, sobald dort die MovingMap grundsätzlich überhaupt funktioniert.

Anschließend könnte man ein externes Programm schreiben (oder notfalls halt erstmal ein paar Scripte), welches aus den bereits vorhandenen einzelnen Kacheln eine ZIP-Datei erstellen mit Index.

Für alle die das nicht wollen, würde sich nichts ändern, ihre bisherigen einzelnen Kachel-Dateien würden weiter wie bisher verwendbar sein.

Sorry daß es so lang wurde, irgendwie kann ichs nicht kürzer erklären.

Jeder der bis hierher gekommen ist hat bereits ein Orden verdient

Grüßle,
Wortfetzen

 

[MiK]

Bei knapp 2000 Kacheln für ein relativ kleines Gebiet (15-20 km Kantenlänge) dauert das dann die erwähnten 2-3 Minuten auf dem PDA.

Hier muss sicherlich etwas passieren. Und wir werden das bestimmt auch angehen, wenn erstmal alles andere wieder läuft. Ich hätte aber mal eine Frage zu deinen obigen Daten: Habe ich richtig gerechnet und Du hast das ganze Gebiet mit einer Auflösung von 0,5 m/px gekachelt? Ich nutze eigentlich fast immer 5m/px. Dann sind das für ein solches Gebiet nur ca 20 Karten.

 

[Wortfetzen]

Hallo MiK,

Und wir werden das bestimmt auch angehen, wenn erstmal alles andere wieder läuft.

Ja deswegen hab ich selbst auch noch gewartet - ich will eigentlich erst für EVE das ganze als Patch raushauen.. Ist sinnvoller als jetzt die Überlegungen mit EWE zu machen, wenn sich dann sowieso nochmal was ändern könnte.

Ich hätte aber mal eine Frage zu deinen obigen Daten: Habe ich richtig gerechnet und Du hast das ganze Gebiet mit einer Auflösung von 0,5 m/px gekachelt? Ich nutze eigentlich fast immer 5m/px. Dann sind das für ein solches Gebiet nur ca 20 Karten.

Mmhh, nein deine Berechnung stimmen nicht. Ich verwende OSM-Karten in verschiedene Zoom-Stufen. Dabei verwende ich die einzelnen Zoom-Stufen von OSM, derzeit OSM-Zoom 9-14 (man kann hier sehen, wie hoch die Auflösung dann ist - die aktuelle Zoomstufe steht unten rechts).
Wieviel das in m/px ist, kann ich leider nicht sagen, ich habe aber bei Zoom 13 etwa die gleiche Auflösung wie die Top25-Karte für BW. 14 ist noch ein bißchen besser, fürs Cachen nutze ich den am häufigsten.

Zoom 14 "verschlingt" dabei natürlich am meisten, das macht etwa die Hälfte aller Kacheln aus (jede höhere Zoom-Stufe quadriert die Anzahl der Kacheln).

Aber selbst wenn ich 14 weglasse, dann ist es nur eine Frage der Kartengröße. Dann bekomme ich die Probleme eben nicht bei 15km sondern bei 30km Kartenmaterial.

 

[MiK]

Eigentlich genügt fürs Cachen eine Top50 mit 5m/px völlig aus. Vielleicht noch ein paar Übersichtskarten dazu. Dann braucht man im Schnitt nur ca. 5 Karten (1000x1000 Pixel mit 100 Pixel Überschneidung) pro 100 km².

Wie gesagt: Ich habe nichts dagegen die Möglichkeiten von CW zu erweitern. Aber wenn man vernünftig mit den Resourcen umgeht, kommt man auch mit den jetzigen Möglichkeiten schon ziemlich weit.

 

[klausundelke]

Also zuallererst mal:
CW kommt für mich dem idealen! Programm fürs Cachen schon sehr nahe.
Alle wichtigen Funktionen sind vorhanden!
Was wirklich noch fehlt ist ein besseres Handling der Karten.

Eigentlich genügt fürs Cachen eine Top50 mit 5m/px völlig aus.

... für QVGA Anzeigen vielleicht, bei VGA darfs schon etwas weniger sein oder?

Nur mal so als Idee:
Wenn es gelänge das Suchen der benötigten Karte deutlich schneller zu machen (Datenbank), dann könnte man z.B. Kacheln 250x250px erstellen. CW müsste dann zwar öfter nachladen, aber dafür deutlich weniger Daten. Momentan erstelle ich immer Karten 1000x1000px. Wenn man nicht zu viele unnötige Daten für die Überlappung verschwenden will, hat man (VGA) dann meistens irgendwo unschöne weisse Ränder auf dem Display.
Ideal wäre in meinen Augen, wenn man die Karten 250x250px. machen würde und CW automatisch alle benötigten Kacheln darstellen würde. Dann bräuchte man die Überlappung nicht und hätte trotzdem immer ein gefülltes Bild. Im ungünstigsten Fall müssten auf einem VGA dann 3x4 Karten dargestellt werden das sind 1000x750px oder 25% weniger als bisher.

 

[MiK]

Eigentlich genügt fürs Cachen eine Top50 mit 5m/px völlig aus.

... für QVGA Anzeigen vielleicht, bei VGA darfs schon etwas weniger sein oder?

Warum brauche ich auf einem Display mit größerer Auflösung mehr Details? Ich seh dann doch mehr auf einmal.

Ideal wäre in meinen Augen, wenn man die Karten 250x250px. machen würde und CW automatisch alle benötigten Kacheln darstellen würde. Dann bräuchte man die Überlappung nicht und hätte trotzdem immer ein gefülltes Bild. Im ungünstigsten Fall müssten auf einem VGA dann 3x4 Karten dargestellt werden das sind 1000x750px oder 25% weniger als bisher.

Das Hauptproblem dabei ist erstmal die Darstellung mehrerer Karten gleichzeitig. Die müssen dann ja auch vom Maßstab zusammenpassen. Ganz so einfach wird das nicht umzusetzen sein.

 

[klausundelke]

Warum brauche ich auf einem Display mit größerer Auflösung mehr Details? Ich seh dann doch mehr auf einmal.

... bin jetzt da nicht so der Experte , aber ich glaube die größere Auflösung ist hier eher schädlich. Du nimmst 5m/px Auflösung. Ein QVGA-PDA kann auf 5cm Displaybreite 240px darstellen = 1200m.
Wenn Du jetzt einen VGA Bildschirm hast werden diese 1200m auch auf 240px Breite dargestellt, bei mir ist das ja aber nur der halbe Bildschirm = 2,5cm Breite. Da auch in der Höhe doppelt so viele Punkte auf dem VGA - Display dargestellt werden, habe ich insgesamt 4x so viele Punkte auf der gleichen Displayfläche. Das bedeutet alles wird 4mal kleiner dargestellt. Das heisst um alles gleich groß zu sehen wie Du muss ich 4x reinzoomen!
Der limitierende Faktor ist hier halt die Displaygröße. Wenn das VGA Display 4x so groß wie das QVGA Display wäre dann hättest Du sicher recht, man könnte mit den gleichen Karten arbeiten.

 

[MiK]

Klar passen 4x so viele Pixel drauf und alles wird kleiner. Ich sehe dann 4x so viele Informationen gleichzeitig. Der beschränkende Faktor sind dann Deine Augen. Aber wenn die die VGA-Auflösung nicht ausnutzen können, hätte man wohl besser zu einem QVGA-Gerät gegriffen. Alles andere ist genauso blödsinnig, wie LCD-PC-Monitore nicht in ihrer nativen Auflösung zu betreiben.