Automatische Kartenwahl: Aktuelle Position + Ziel

Wutschkow

Geomaster
ggcode schrieb:
bis auf eine falsche Kartenauswahl bei "Höchster Detailgrad mit aktueller und Ziel Position"
dies könnte aber auch ein alter Bug sein. Hab ich nie genutzt, da mir die alte MM zu umständlich war.
Die neue MMT ist nur eine Oberfläche, welche auch nur die vorhandenen Funktionen ansteuert. Von daher kann das durchaus sein.
Aber was ist genau denn das Problem?
 

ggcode

Geocacher
Hallo Wutschkow,
ich habe diese Datei "CacheWolf-PPC2003.zip" runtergeladen und dort ist eine ewe.dll mitverpackt.

Aber was ist genau denn das Problem?

bis auf eine falsche Kartenauswahl bei "Höchster Detailgrad mit aktueller und Ziel Position"
dies könnte aber auch ein alter Bug sein. Hab ich nie genutzt, da mir die alte MM zu umständlich war.

Wie schon beschrieben. Ich möchte eine Kartendarstellung die die Zielposition und die aktuelle Position
darstellt. Es gibt eine Karte die diese Darstellung abbilden kann. Mit dem Menue-Punkt "Höchster Detailgrad mit aktueller und Ziel Position" wählt CW aber diese Karte nicht aus sonder eine mit falschem Massstab die die beiden Positionen nicht abbilden.

Gruß ggcode
 

MiK

Geoguru
Ich habe dies in den neuen Versionen noch nicht getestet. Generell gibt es aber dass Problem, dass sich diese Funktion auf die Kartendatei bezieht und nicht auf den Ausschnitt auf dem Bildschirm. Gerade bei den neuen kleineren Kacheln für das Füll-Feature, führt das nicht unbedingt zum gewünschten Ergebnis. Das müsste man auf jeden Fall mal überarbeiten.

trotzdem kann es natürlich zusätzlich sein, dass diese Option mit der neuen Oberfläche nicht richtig aktiviert wird.
 

pfeffer

Geowizard
ich weiß nicht genau, ob klar ist, was diese Funktion macht.
Sie stamm aus der Zeit als Cachewolf nur 1 Kartenbild laden konnte. Es wurde dann 1 Karten Bild geladen, auf dem beide Positionen drauf sind, sie müssen nicht beide auf dem Bildschirm sein.
Ich bin mir ziemlich sicher, dass das früher mal funktoniert hat, denn
1. ist das die Standardeinstellung
2. habe ich damit immer gecacht.
Habe es aber seit der "weiße Flächen füllen" nicht getestet.

Gruß,
Pfeffer.

PS: hatte einfach das ant Build file von greiol genommen - habe es nun auf PocketPC2003 angepasst. Vielen Dank für die Fehleranalyse!
 
OP
Wutschkow

Wutschkow

Geomaster
ggcode schrieb:
Ich möchte eine Kartendarstellung die die Zielposition und die aktuelle Position darstellt. Es gibt eine Karte die diese Darstellung abbilden kann. Mit dem Menue-Punkt "Höchster Detailgrad mit aktueller und Ziel Position" wählt CW aber diese Karte nicht aus sonder eine mit falschem Massstab die die beiden Positionen nicht abbilden
Ich >vermute< mal, dass es genau dieses Missverständnis ist, das MiK angesprochen hat. Die Funktion arbeitet nicht so, dass sie die Karte auswählt, mit der Position und Ziel auf dem Display zu sehen sind. Sondern sie wählt die detaillierteste Karte, die beides enthält. Da man davon aber nur einen Ausschnitt auf dem Display sieht, erscheinen Position und Ziel erst dann gleichzeitig auf dem Display, wenn man sich dem Ziel entsprechend angenähert hat. Nur: Wenn man "Pech" hat, schaltet die Funktion dann schon wieder auf die nächst-detailliertere Karte um und man sieht wieder nur GPS oder Ziel. Genau deshalb habe ich diese Funktion auch nie benutzt, sondern den Detailgrad lieber selbst bestimmt.

Die Frage ist, wie sinnvoll eine solche Funktion überhaupt ist. Hilfreicher wäre es meiner Meinung nach, wenn sie so arbeitet, wie man es intuitiv erwarten würde: Sie wählt die Karte so aus, dass aktuelle Position und Ziel gleichzeitig auf dem Display zu sehen sind.
 

klausundelke

Geowizard
Meine Gemütslage beim Testen der neuen Kartensteuerung:

:| :schockiert: :smile: :group3g: :2thumbs: :applaus: :2thumbs:


echt genial, was da im CW noch alles zu holen ist...

Vielleicht sollte man die letzten 3 Beiträge in einen extra Thread stecken,
die passen hier nicht so wirklich dazu, das "Problem" war ja in der alten
Version auch schon da.

Und ich gebe Wutschkow Recht: Das erwartet der User eigentlich...
Ideal wäre, wenn die Karte automatisch so gezoomt würde, daß beide Positionen
zu sehen sind, aber da rauscht wahrscheinlich wieder die Performance in den Keller...
 

MiK

Geoguru
Zoomen sollte man wirklich nicht, sondern mit verschieden detaillierten Karten arbeiten.

Wobei "passt auf das Display" und "ist gleichzeitig zu sehen" auch nicht das gleiche ist, da es auch noch davon abhängt, wie man die Karte verschoben hat. Aber ich finde "passt aufs Display" wäre eine gute Lösung. Solange man aber auch noch die Darstellung mit nur einer Kachel wählen kann, ist das vielleicht aber auch nicht ideal.
 
Hi,
um mal einen kleinen Kommentar am Rande zur letzten Diskussion von außen zu bringen: Wünschenswert wäre eine Übergabe des Caches als POI/Zielkoordinate an ein Navigationsprogramm a'la Navigon oder TomTom.

Damit wäre dann die Weitstreckenanzeige dadurch abgedeckt und es bliebe dann nur am Schluss die Luftlinienan"fahrt" und die sollte in eine Kachel passen!

Könnte man nicht, da das Cachen der nächsten Kachel in Luftlinienlinie wohl zuviel Cache kostet zumindest schon, wenn Ressourcen frei sind nach dem Laden der aktuellen Kachel, die nächste in Richtung der Ziellinie raussuchen? Dann dürfte das Nachladen deutlich schneller gehen. Hierfür wäre eine Datenbank, die alle vorhandenen Kartenkacheln auf dem Gerät kennt, ideal. Dort würden beim Download alle Kacheln mit dem jew. Ausschnitt eingetragen und es bräuchte nur eben geguckt werden, welche ist dafür geeignet und dann geladen. Jetzt werden ja immer alle eingelesen und dann die richtige rausgesucht, was gerade auf langsameren Geräten mit 200MHz doch echt lange dauert. Als Datenbank würde ja eine Datei reichen (z.B. .xml). Diese würde dann beim Download gepflegt werden (und auf manuelle Anweisung im Kartendownloadtab). Eigentlich kann das nicht sehr großen Programmieraufwand darstellen.

mfG,
Stefan
 
OP
Wutschkow

Wutschkow

Geomaster
Vielleicht sollte diese Diskussion doch von der MovingMap abgetrennt werden, da sie damit ja nun nichts mehr zu tun hat?

MiK schrieb:
Wobei "passt auf das Display" und "ist gleichzeitig zu sehen" auch nicht das gleiche ist, da es auch noch davon abhängt, wie man die Karte verschoben hat. Aber ich finde "passt aufs Display" wäre eine gute Lösung. Solange man aber auch noch die Darstellung mit nur einer Kachel wählen kann, ist das vielleicht aber auch nicht ideal.
Ja, "passt auf das Display" ist das entscheidende. Mit dem "gleichzeitig zu sehen" scheitert es ja schon daran, dass die GPS-Position in der Regel in der Mitte des Displays angezeigt wird und da rutscht das Ziel dann schon aus Platzgründen gerne mal raus, selbst wenn die Entfernung im Prinzip auf das Display passen würde.
 

pfeffer

Geowizard
Es ist nicht nichtig, dass alle *.wfl eingelesen werden.
Eingelesen werden vielmehr nur alle Dateinamen. In dem Dateinamen ist die Lage der Karten verschlüsselt, so dass Cachewolf ziemlich zielgenau die richtige Karte laden kann.
Dies ist nicht immer möglich, weil wir kein festes Raster haben, in das wir die Erde aufgeteilt haben und auch keine festen Zoomstufen und keine feste Projektion. Deswegen muss Cachewolf evtl. doch mehrer *.wfl einlesen um von denen die beste zu finden.

Ich sehe im Moment 2 leichte Ansätze zur Optimierung:
1. Das System ist gegenwärtig noch so gebaut, dass es gut funktioniert für nur 1 Kartenbild. Es wird also die Hauptkarte bei Beweguzng gewechselt, so bald sie sich besser eignet, z.B. weil sie mehr der Bildschirmfläche abgeckt als die geladene. Dieses Verhalten ist natürlich überflüssig, wenn man die Option "weiße Flächen füllen" aktiviert hat. Evtl. sollte dieses Verhalten mit umgeschaltet werden, wenn die Option "weiße Flächen füllen" aktiviert wird.

2. Das duchrsichtige Overlay, auf dem der Track gezeichnet wird, wird bei jedem Kartenwechsel dealloziert und neu alloziert. Da wir inzwischen wissen, dass gerade das Anlegen und Löschen von Objekten in Ewe langsam ist, könnte man versuchen, das so umzubauen, dass der Speicherinhalt nur gelöscht, nicht aber freigegeben und neu belegt wird.

3. das durchsichtige Overlay, auf dem der Track gezeichnet wird, sollte in ein festes Raster aus Bildern mit 128x128 Pixeln umgewandelt werden. Im Moment sind es 9xBildschirmgröße.

Gruß,
Pfeffer.
 
OP
Wutschkow

Wutschkow

Geomaster
pfeffer schrieb:
Dies ist nicht immer möglich, weil wir kein festes Raster haben, in das wir die Erde aufgeteilt haben und auch keine festen Zoomstufen und keine feste Projektion. Deswegen muss Cachewolf evtl. doch mehrer *.wfl einlesen um von denen die beste zu finden.
Naja, so eine Art Zoomstufen gibt es ja schon, wenn auch keine festen. CW vermerkt beim Kartendownload in den Dateinamen die Auflösung ("_s5_", "_s2.5_" usw.).
Nur bei importierten Karten klappt das nicht. Aber die werden ja ohnehin noch (auf Wunsch) für Cachewolf optimiert, vielleicht sollte man dann auch diese Angabe ergänzen. Dann könnte man diese Information auch schon direkt aus dem Dateinamen auswerten.

Könnte man damit eine spürbare Beschleunigung z. B. auch beim Ermitteln der nächst-übersichtlichen/nächst-detaillierteren Karte erzielen, wenn man diese Entscheidung nur aufgrund des Dateinamens treffen könnte?
Für das Füllen der weißen Flächen könnte das auch die Performance verbessern. Diese Funktion muss doch jetzt auch immer wfl-Dateien einlesen, um die Nachbarkarten in derseben Auflösung zu identifizieren, oder?
 

pfeffer

Geowizard
sie sind eben nicht fest.
einmal eingelesene .wfl werden im Speicher gehalten. Wenn man nicht springt, sind die relevanten also bald im Speicher.
Die s2.5 Info ist nur für den Nutzer - In gewissem Umfang geht der Maßstab aus der Buchstaben/Ziffernfolge hervor - und wird genutzt.
Seit den jüngsten Optimierungen glaub ich nicht, dass da noch viel zu holen ist, ohne auf ein festes Raster umzusteigen (und wie viel das bringt ist auch fraglich). Erhebliche Vorteile würden kleinere Kacheln bringen, die zusammen in 1 Datei gespeichert sind.
Ich habe dazu auch schon einen Formatvorschlag gemacht, der auch vom Glopus-Programmierer und von Hannes! für gut befunden und implementierbar gehalten wurde.
Es müssten noch ein paar Details geklärt werden und - vor allem - es müsste jemand programmieren.

Gruß,
Pfeffer.
 
Oben