[dev] 4 verschiedene getDistance() in CWPoint

[pfeffer]

ich wäre eher dafür, auf kleinere Kacheln umzustellen (die in 1 Datei gespeichert werden) und definierte Positionen haben und definierte Maßstäbe. Dann kann man den Namen der Datei "errechnen" anstatt die best passende suchen zu müssen.
Auch dürfte es den Speicher entlasten, weil nicht meher eine 1000x1000 Pixel großes Bild geladen werden muss, zusätzlich gäbe es keine weißen Ränder mehr auf der Map.
Allerdings sind da noch ein paar Probleme ungelöst:
1. wir brauchen ein Containerformat für die Bilder, das
a) schnell die entsprechenden Bilder liefert
b) bei dem Bilder hinzugefügt werden können (falls das Laden beim ersten Versuch nicht geklappt hat)

Ein Vorschlag dazu wäre, die Bilder einfach hintereinander zu kopieren und in der .wfl zu speichern ab welcher Byte-Position das jeweils benötigte Bild beginnt. Dann muss man in der Datei vorwärts und evtl. rückwärts seeken - ist das schnell?

Einschränkungen, die man sich damit einhandelt:
1. entweder müssen wir selbst .jpg-Format schreiben können (ich weiß nicht, ob Ewe das kann) oder wir können keine Karten (die nicht unserem Raster entsprechen) mehr manuell kalibrieren.
2. bestehende Karten könne nnicht verwendet werden, sofern Ewe nicht eine Funktion zum Zerschneiden uns speichern von jpgs hat.

Gruß,
Pfeffer.

 

[KoenigDickBauch]

1) Bilder in Kacheln zerlegen und in 128x128 großen Stücken speichern dabei nur den Datenteil in biCompression.

2) Cacheltabelle mit Mittelkoordinate, Auflösung, GoogleMapKoords, Filestartpos, ...

So muss man für eine 640x480 Auflösung nur 6 * 5= 30 Bilder vorhalten.

Das JPG Format ist ungünstig wenn dann das ECW Format. Aber das ist für ein PDA auch zu langsam.

 

[pfeffer]

was spricht gegen jpg?
warum nicht die Header-Daten einschließen? - sind die so viel?
Wenn ECW auf dem PocketPC zu lahm ist kommt es nicht in Frage.

Gruß,
Pfeffer.

 

[KoenigDickBauch]

was spricht gegen jpg?

Das alte JPG Format ist Zeilen orientiert und JPG2000 kennt kaum einer. Auch kostet das Entpacken unnötig Zeit.

warum nicht die Header-Daten einschließen? - sind die so viel?

Unnötiger Datentransfer. Und ja, wenn man eine 40kmx40km Karte mit 2m/Pixel speichert, kommen schon sehr viele redundante Informationen vor.

Wenn ECW auf dem PocketPC zu lahm ist kommt es nicht in Frage.

Beim OziExplorerCE kann man sich das schön anschauen. Er unterstützt neben seinem proprietären Kachelformat noch das ECW. Und mit ECW ist das Zoomen und Schieben doch sehr langsam.

 

[pfeffer]

das klingt ja so, als hätte der OziEplorer ein vernünftiges propreitäres Format. Weißt Du zufällig, wie es aufgebaut ist?

Gruß,
Pfeffer.