[DEV] kleinere Kartenkacheln, Vorschlag

als das größte Manko der MovingMap wird gegenwärtig von vielen die lange Ladezeit der Liste der Karten empfunden. Deswegen ist eine indexdatei vorgeschlagen worden, die evtl. schneller geladen werden könnte. Aber ich vermute, dass auch eine index-datei recht lange braucht, bis sie geladen ist (wenn sie weiterhin im textformat gespeichert wird).

Ich habe gestern mit Mirabilos diskutiert und wir haben folgenden Vorschlag:
Wir machen ein eigenes Format, in dem mehrere Bilder zusammengefügt sind. Dabei wäre mein Vorschlag, dass in eine Datei Bilder bzw. Kacheln zusammengefügt werden, die zusammen ein bestimmtes Rechteck abdecken. Auf diese Weise braucht Cachewolf nicht von jedem Bild zu Beginn alle Kalibrierungsinformationen einzulesen, sondern den Maßstab und das abgedeckte Rechteck genügt zunächst. Erst wenn daraus eine Bilddatei benötigt wird, wird die entsprechende Kalibrierungsinformation gelesen.
Neben dieser Datei (Meta-Datei), in der die Bilddateien einfach direkt hintereinander zusammengefügt sind, gibt es eine Datei, die Informationen über die zusammengefügten Bilder enthält:
a) sie enthät erstens die Angabe eines Rechtecks, das alle Bilder einschließt
b) ein flag, ob die Fläche vollständig abdgedeckt ist
c) kalibrierungsinformationen für jedes einzelne in der großen Datei enthaltene Bild
d) Offset und Länge jeder Bilddatei, die in der großen Datei zusammengefügt sind.

Damit das Einlesen der Daten schnell geht, würde ich vorschlagen, diese Informationen im Binärformat zu speichern.

Die MovingMap wird so geändert, dass sie mehrere Kacheln nebeneinander gleichzeitig darstellen kann. Dadurch können die Kacheln sehr klein gemacht werden. Ich schlage vor: 120x120px. Dann braucht man für einen typischen PDA-Schirm, der 240x340px hat, 3 Kacheln nebeneinander und 3 Kacheln übereinander. Auf diese Weise wird der benötigte Speicherplatz gegenüber jetz deutlich reduziert.

Neben diesem Format wird weiterhin das alte Verfahren unterstützt.

Ich würde diese Verfahren einsetzen für den automatischen Download von Karten, weil ich da die Größe der Bilddateien selbst festlegen kann. Beim import von vorhandenem Kartenmaterial würde das bisherige verfahern Anwendung finden.

Was haltet Ihr davon?

Schöne Grüße,
Pfeffer.

Wie wäre es, wenn wir beim Import golgendermaßen vorgehen:
Die Karte kann beliebig groß sein. Diese wird dann in 120x120 Kacheln aufgeteilt und in dem von Dir vorgeschlagenen Format gespeichert.

Dadurch würde es viel einfacher große Flächen aus fremden Quellen zu importieren.

Hört sich alles vernünftig an. Durch die Kachelung sollte es dann mit dem Speicher auch besser aussehen. Wahrscheinlich kann man mit der Speicherung der Kalibrierungsinformationen in einer binären Datei sehr viel bezüglich Ladezeit herausholen, wenn man die Information in irgendeiner Form mit einem Index ablegt, also nicht immer die ganze Datei durchsuchen muss, sondern mit einem wesentlich geringeren Aufwand zurecht kommt. Bei http://www.navifriends.de im Forum gab es mal einen länglichen Thread, wo über das POI-Format für den MN diskutiert wurde. Ich meine, da gab es auch Mechanismen, wie die POIs in einer Datei sortiert wurden, damit man auf die POIs schnell zugreifen konnte, müsste ein ähnliches Problem sein.

Und wie kacheln wir auf dem PC?

300x300 px in 3x3 Kacheln, oder 120x120 in 8x8 Kacheln?

Die Frage ist nötig, weil wir klären müssen, wann neugeladen
werden muß. Eventuell aufm PC 7x7 Kacheln und dann neu
laden, wenn die mittleren 3x3 verlassen werden, aufm PDA
neu laden, wenn die mittlere Kachel verlassen wird?

Wenn schon in den Kartendateien gekachelt wird (also nicht aus einem großen Bild kachelweise geladen), dann sollte die Kachelgröße überall gleich sein, so dass man die Daten leicht hin und her schieben kann.

Hierzu hätte ich einen Vorschlag:
Glopus benutzt einen Karten-Index sowie große Dateien (GMF-Format), um viele Kacheln in einer Datei zu speichern.
Das hat den Vorteil, dass das PPC-Dateisystem, welches nicht allzu leistungsfähig ist, nicht viele kleine Dateien öffnen muss sondern sich das Benötigte aus einer großen Datei herauszieht.
Zudem gibt es für die Glopus-Karten inzwischen eine Vielzahl von Tools um die Karten aus Topo-Kartenwerken zu erzeugen oder Kachel-Auswahlen zu treffen.

Vielleicht wäre es sinnvoll, in diesem Stadium, wenn über ein neues Kartenformat nachgedacht wird, sich mit Peter Kirst, dem Entwickler von Glopus, auseinanderzusetzen. Eventuell kann dieses Format auch für den CacheWolf übernommen werden; auf diese Weise braucht das Rad nicht ein zweites mal erfunden werden und die Glopus-Benutzer brauchen nicht 2 Sätze an Kacheln zu speichern.

Ich unterstütze auch die Idee ein vorhandenes Format zu verwenden, so dafür eine Doku existiert.

Die Kachelgröße sollte einheitlich und auf den PDA optimiert sein, am PC sind Resourcen und Geschwindigkeit ohnedies kein Problem.

Ich freu mich schon auf die neue MM

Grüße
skg

Naja, „kein Problem“ würde ich zum PC nicht sagen, mein
Athlon XP mit 500 MHz laggt ziemlich bei CacheWolf.

Das Format, was Du beschreibst, deckt so ziemlich ab, was
wir uns ausgedacht haben, es sollte halt KISS (keep it sim-
ple stupid) sein und nicht komplex, mal sehen.

mirabilos schrieb:

Und wie kacheln wir auf dem PC?

300x300 px in 3x3 Kacheln, oder 120x120 in 8x8 Kacheln?

Die Frage ist nötig, weil wir klären müssen, wann neugeladen
werden muß. Eventuell aufm PC 7x7 Kacheln und dann neu
laden, wenn die mittleren 3x3 verlassen werden, aufm PDA
neu laden, wenn die mittlere Kachel verlassen wird?

Zum Vergrößern anklicken....

Die MovingMap wird zur Laufzeit feststellen, wie viele Kacheln nötig sind, um das Window vollständig abzudecken und sobald (durch verschiebung der Karte) eine Lücke entsteht entsprechende Kacheln nachladen. Das bedeutet, es wird immer etwas mehr als das Fenster groß ist, in den Speicher geladen. Deswegen ist die Kachelgröße eigentlich fast egal.

Gruß,
Pfeffer.

Klingt plausibel und auch ansonsten gut.

neuer Vorschlag:
Bilbowolf hatte im IRC-Channel #cachewolf einen Link gepostet, wie dieses Problem bei GoogleMaps gelöst ist. Und das ist schlau

Die Idee für Cachwolf ist folgende:
Durch eine intelligente Benennung der Karten wird bereits am Dateinamen erkennbar, welchen Bereich die Karte ungefähr abdeckt. Nur von Karten, die den aktuellen Berech abdecken, werden dann alle Kalibrierungsdaten eingelesen und die beste ausgewählt. Auf diese Weise muss nur die komplette Liste der Dateinamen gelesen werden (d.h. nicht auch alle kalibrierungsinformationen) und nur die Kalibrierungsinfos von Karten, die tatsächlich in Frage kommen.

Das Prinzip der intelligenten Benennung ist folgendes:
Die Welt wird zunächst in 4 Rechtecke eingeteilt. Die erste Ziffer gibt an, in welchem der 4 Rechtecke sich die Karte befindet. Dieses Rechteck wird dann wieder in 4 weitere Rechtecke unterteilt und in welchem sich die Karte befindet, gibt die 2. Ziffer an usw. und so fort. Damit lässt sich beliebig genau ein Punkt angeben.
Das schöne daran ist: man kann sofort erkennen, in welchem Bereich der Punkt liegt: wenn die erste Ziffer eine andere ist als die gesuchte, braucht man nicht mehr weiter zu gucken. Das bedeutet: wenn man die so benannten Dateien nach Dateinamen sortiert, liegen dateien, die benachbarte oder gleiche Gebiete abdecken nebeneinander.

1. Das Verfahren ist allerdings dann nicht effektiv, wenn eine Karte beispielsweise bereits in der ersten Ziffer über mehrere Quadranten läuft. Dann würde die Benennung nach dem übergeordneten Quadranten erfolgen, der beide enthält. In diesem Fall wäre das die gesamte Welt. Wenn dieser Fall häufig auftritt, bringt diese Bennenung keinen Geschwindigkeitsgewinn. Diese Gefahr besteht vor allem in der Nähe des 0-Meridians, dem 180. Längengrad und des Äquators. Deswegen könnte man überlegen, ob man die Aufteilung der Erde nicht am 0. Längengrad, sondern irgendwo im Meer beginnt. Was meint Ihr dazu?
Ich wäre für eine Verschiebung. Könnte jemand mir raussuchen, wohin am besten wäre?

2. wie soll die Benennung der Datei genau erfolgen?
Vorschläge
a) Dateiname beginnt mit Ortskennzeichnung, die mit "E-" abgeschlossen wird, danach kommt der bisherige Dateiname. Vorteil: danach kann direkt sortiert werden.

b) ans Ende des Dateinamen, wobei der Anfang der Ortskennzeichnung mit "-A" gekennzeichnet wird. Vorteil: Sortierung des Nutzers bleibt erhalten

c) irgendwo im Dateinamen, wobei der Anfang mit "-A" und das Ende mit "E-" gekennzeichnet wird. Nachteil: mehr Aufwand beim heraussuchen des Strings, nachdem intern sortiert werden muss.

Ich wäre für Lösung a).