Bei gelösten Mystery nur Logs und Status aktualisieren.

[t31]

@araber95

hatte erst jetzt wieder Gelegenheit ausgiebig zu testen. In der Tat funktioniert der Export von GCxxxx(F) wieder.

Aktuell funktionieren folgende Varianten auf dem Oregon:
GCxxxx(F)
GCxxxx-F

Folgende Varianten lassen sich exportieren, werden aber vom Oregon ignoriert:
FFxxxx
GCxxxx_F

Ich werde jetzt auf GCxxxx-F umsteigen und hoffen das dies auf längere Sicht funktionieren wird. Theoretisch ist so möglich nach "-F" zu suchen um weitere Dinge Export, Manipulation etc.pp. zu tätigen

 

[Robin888]

Ich benutze kein externes GPS-Gerät. sondern cache mit dem PDA.
Ich mache es auch so, daß ich für einen Mystery die Finalkoordinaten in einen Addi-WP einsetze. Allerdings - nur so als Tip - lasse ich das *grundsätzlich* den Solver machen!
Wenn also mal die KO aus irgendeinem Grund weg sein sollten, dann gehe ich bloß in den Solver und lasse die Koordinaten wieder neu berechnen.

Aber dennoch nutze ich auch diesen Thread um die Idee von "fixierbaren Koordinaten" zu erwähnen:
Im Detail-Reiter eines (beliebigen) Wegpunktes lässt sie die Koordinate gegen Aktualisieren sperren. (Ggfls. auch allgemein gegen Überschreiben.)

Allerdings fällt mir dazu ein, daß man auf der Karte (oder dem Radar) optisch einen gelösten nicht von einem ungelösten Mystery unterscheiden kann. Hm.
Ein neuer WP-Typ "gelöster Mystery" mit eigenem Symbol fällt wohl aus.
Individuelle Symbole für die WPs wären wohl zu umständlich.

Bliebe eine komplette "Mystery-Funktion":
Im Detail-Reiter eines (Mystery-)Caches gibt es einen Switch mit dem Titel "gelöst" oder so.
Wird dieser aktiviert werden:
- die Koordinaten sämtlicher assoziierter WPs gesperrt.
- das Mysterysymbol durch ein anderes ersetzt. (Z.B. ein blaues Ausrufezeichen. )

Robin(888)

 

[MiK]

Warum braucht man dazu einen neuen Typ und Symbol? Ein Final mit Koordinaten ist doch genau das.

 

[Engywuck]

Ich hatte für solche und andere Zwecke ja mal selbstdefinierbare Kategorien vorgeschlagen (http://www.geoclub.de/viewtopic.php?f=40&t=35396). Fand damals nur niemand praktisch. Ich finde es auf jeden Fall praktischer, als für alles ein eigenes Feld einzuführen.

Gruß,
E.

 

[Robin888]

@MiK: Um Wegpunkte zu sparen und den Überblick auf der Karte zu verbessern?
In Hamburg habe ich momentan 40 Flaggen zu denen ich immer erst das dazugehörige Fragezeichen "suchen" muß um den Cache zur Cachetour hinzuzufügen.
Gleichzeitig habe ich 40 Fragezeichen, die völlig nutzlos in der Gegend rumstehen.

Außerdem werden gelöste Mysteries in der Liste systematisch falsch eingeordnet, wenn man nach Entfernung sortiert.

@Engywuck: Die Idee finde ich prima! (Hab' den Thread damals überlesen.) Allerdings gebe ich auch den Kritikern Recht, daß die Performance auf dem PDA grenzwertig ist. Aber da muß sich eh bald etwas ändern...

Grundsätzlich kann ich persönlich auf neue Features verzichten, wenn dafür die Trennung zwischen Core und Interface vorangetrieben wird. Vielleicht ergibt sich ja daraus schon ein Performancegewinn oder die Möglichkeit einzelne Module nur für den PC zur Verfügung zu stellen.

Robin(888)

 

[arbor95]

vielleicht kann man erst mal bevor hier Lösungen diskutiert werden zusammenschreiben, was erreicht werden soll. ich fang mal damit an:
1. die Koordinaten der Lösung erfassen
2. die Lösung vor Überschreiben bei Spider/Aktualisierung oder gpx-Import schützen.
3. den Mystery Wegpunkt mit den fehlerhaften Koordinaten "ausschalten"
4. den (gpx-)Export nur von der Lösung
5. Zusammenstellung der Cachetour wie gewohnt.

Jetzt beim Schreiben erscheint es mir, als ob es nur eine Lösung ohne Kompromisse gibt:
Cachekoordinaten ändern und gegen Überschreiben schützen. Ohne an der Oberfläche was zu ändern könnte man sich einen entsprechenden Statustext denken, der dann bei den Importern berücksichtigt wird.

Falls ich was vergessen habe....

 

[Engywuck]

Es wäre vielleicht am einfachsten, wenn Mystery-Koordinaten bei Aktualisierung einfach nicht aktualisiert werden, wenn sie bereits gültige Koordinaten enthalten. In allen Mystery-Fällen, die ich kenne, haben die Cache-Koordinaten keine Bedeutung. Und damit wäre der einzige Fall, in denen das beschriebene Procedere Probleme brächte, der, dass die Startkoordinate doch eine Bedeutung hat und diese dann zwischen zwei Aktualisierungen vom Owner geändert wird. Aber kommt sowas vor?

Gruß,
E.

 

[t31]

Die sicherste Variante wäre schon ein zusätzliches Feld für die Lösungs-Koordinaten

Koordinaten: N .... E ....
Lösungs-Koordinaten: N .... E ....

Wenn die Lösungs-Koordinaten leer sind, werden die normalen Koordinaten exportiert, ansonsten eben die Lösungskoordinaten

Abwärtskompatibel dürfte die Sache auch sein, da das Feld nur dann in das xml-File geschrieben wird, wenn es belegt ist, ansonsten bleibt alles beim alten. Eine Formatänderung sollte nicht notwendig sein, es wird nur geprüft ob dieses neue Feld existiert und wenn ja dann auch ausgelesen.

Um es Komplett zu machen könnte man noch einen Schreibzugriff vom Solver aus einbringen

 

[arbor95]

Die sicherste Variante wäre schon ein zusätzliches Feld für die Lösungs-Koordinaten

Koordinaten: N .... E ....
Lösungs-Koordinaten: N .... E ....

Wenn die Lösungs-Koordinaten leer sind, werden die normalen Koordinaten exportiert, ansonsten eben die Lösungskoordinaten

Abwärtskompatibel dürfte die Sache auch sein, da das Feld nur dann in das xml-File geschrieben wird, wenn es belegt ist, ansonsten bleibt alles beim alten. Eine Formatänderung sollte nicht notwendig sein, es wird nur geprüft ob dieses neue Feld existiert und wenn ja dann auch ausgelesen.

Um es Komplett zu machen könnte man noch einen Schreibzugriff vom Solver aus einbringen

Und wo laufe ich hin wenn ich nur mit CW unterwegs bin?

 

[Engywuck]

Die sicherste Variante wäre schon ein zusätzliches Feld für die Lösungs-Koordinaten

Aber auch am aufwendigsten: Das Feld muss, damit es Sinn macht, in die Datei index.xml und bläht diese auf (mit entsprechenden Auswirkungen auf die Performance beim Einlesen). Und das für relativ wenig Nutzeffekt, zumal es (wie genannt) schon jetzt Möglichkeiten gibt, den gewünschten Effekt annähernd zu erreichen.
Diese Lösungsmöglichkeit erscheint mir daher keine sinnvolle Alternative.

Gruß,
E.

 

[MiK]

Alle Lösungen, die die Finalkoordinaten in den Hauptwegpunkt schreiben, halte ich für Blödsinn. Da gehören sie einfach nicht hin. Da aber anscheinend der Garmin-Export die neue heilige Kuh von CW ist, werde ich es wohl nicht verhindern können.

 

[klausundelke]

Ich nutz auch den Garmin-Export, aber ich seh das trotzdem so wie MiK.
Und nur weil der Oregon (momentan) nur den Hauptwegpunkt als
Cache verwaltet und der Rest dann eben als Wegpunkt oder POI angelegt
werden muss, muss man doch nicht den CW gleich umbauen und die
Datenstruktur schon wieder erweitern. Vor allem da es ja schon funktionierende
Möglichkeiten gibt. Als nächstes sollen dann die Multi-Wegpunkte auch noch
als Caches exportiert werden???

 

[UncleOwen]

Alle Lösungen, die die Finalkoordinaten in den Hauptwegpunkt schreiben, halte ich für Blödsinn. Da gehören sie einfach nicht hin.

Sehe ich genauso.

Da aber anscheinend der Garmin-Export die neue heilige Kuh von CW ist, werde ich es wohl nicht verhindern können.

Wenn einige (definitiv nicht alle) Garmin-User nur einen Wegpunkt haben wollen, kann man das doch einfach als Option in den Exporter bauen...

 

[salzkammergut]

Alle Lösungen, die die Finalkoordinaten in den Hauptwegpunkt schreiben, halte ich für Blödsinn. Da gehören sie einfach nicht hin.

Genau!

 

[arbor95]

wer es aber der Übersichtlichkeit dort haben will?
eine Abfrage auf den Status wäre ja nicht so teuer.

Und die Lösung mit dem Final-Wegpunkt wird dadurch nicht verbaut.

Und sie ist immer noch besser als Hilfskonstruktionen mit eigenen Cachenamen.

 

[t31]

@ MiK ... salzkammergut
Hmm, Blödsinn und Genau! <- sind nun nicht gerade überzeugende Argumente.

Warum dagegen? Mir scheint das andere Beweggründe hinten anstehen als Praxisnähe, denn in der Praxis wähle/orientiere ich mich nach dem Hauptwegpunkt, es ist mein Zielort für die Navigation und Cachesuche. Was nutzen mir Fakekoordinaten im GPS an denen ich rein gar nichts finde, die schlimmsten Falls sogar 10km im Off sind?

Für mich ist es kein Muß, wenn es eingebaut wird, würde es mich freuen und ich müsste den Komfort zu nutzen.

Wäre es denkbar den Finalwegpunkt schreibgeschützt (wenn er einmal da ist) zu machen und beim Export zu für den Hauptwegpunkt zu berücksichtigen?

 

[arbor95]

...denn in der Praxis wähle/orientiere ich mich nach dem Hauptwegpunkt, es ist mein Zielort für die Navigation und Cachesuche. Was nutzen mir Fakekoordinaten im GPS an denen ich rein gar nichts finde, die schlimmsten Falls sogar 10km im Off sind?

Neuerdings wohl maximal 3 km.

Für mich ist es kein Muß, wenn es eingebaut wird, würde es mich freuen und ich müsste den Komfort zu nutzen.

wüsste .. zu schätzen?

Wäre es denkbar den Finalwegpunkt schreibgeschützt (wenn er einmal da ist) zu machen und beim Export zu für den Hauptwegpunkt zu berücksichtigen?

Gibt es Mysterys mit Final?
Würde der beim Aktualisieren überschrieben?
Wenn ein neuer Status hinzukäme dann (vermutlich) am einfachsten für alle Wegpunkte definiert : "Koordinaten beibehalten" und eben dieser Funktion.

 

[MiK]

Das halte ich auch für die einzige vernünftige Lösung. Ein allgemeines Flag, das dafür sorgt, dass die Koordinaten geschützt sind. Ein Problem dabei: In der GUI des Detailspanel ist eigentlich kein Platz mehr dafür.

 

[Engywuck]

Bin ich hier eigentlich bei allen auf ignore?

@ MiK ... salzkammergut
Hmm, Blödsinn und Genau! <- sind nun nicht gerade überzeugende Argumente.

Ein sehr praxisorientiertes Argument hatte ich Dir bereits genannt:

Das Feld muss, damit es Sinn macht, in die Datei index.xml und bläht diese auf (mit entsprechenden Auswirkungen auf die Performance beim Einlesen). Und das für relativ wenig Nutzeffekt, zumal es (wie genannt) schon jetzt Möglichkeiten gibt, den gewünschten Effekt annähernd zu erreichen.

Das halte ich auch für die einzige vernünftige Lösung. Ein allgemeines Flag, das dafür sorgt, dass die Koordinaten geschützt sind. Ein Problem dabei: In der GUI des Detailspanel ist eigentlich kein Platz mehr dafür.

Und auch hier hatte ich schon eine Heuristik angeboten, die einigermaßen sinnvoll sein sollte, um den gewünschten Effekt zu haben:

Es wäre vielleicht am einfachsten, wenn Mystery-Koordinaten bei Aktualisierung einfach nicht aktualisiert werden, wenn sie bereits gültige Koordinaten enthalten. In allen Mystery-Fällen, die ich kenne, haben die Cache-Koordinaten keine Bedeutung.

Es wundert mich nur, dass niemand was dazu sagt.

Außerdem bin ich der Meinung, dass man nicht jeder Anforderung nachgeben sollte, nur weil sie ein Einzelner mit Nachdruck vertritt. Wenn es keine Auswirkungen auf die Performance hat und die Bedienung nicht behindert, kann man es machen. Aber neue Felder in index.xml einfügen sind definitv ein Eingriff, den man sich gut überlegen solle, und der nur dann gerechtfertigt ist, wenn es wirklich einen Nutzen bringt. Das ist im vorliegenden Fall nun wirklich nicht der Fall.
Ich kann hier auch noch auf ein Beispiel aus dem Sammelsurium meiner eigenen Vorschläge verweisen: http://www.geoclub.de/viewtopic.php?f=40&t=23970 Wäre diesem gefolgt worden, so hätten wir jetzt bereits eine Addi-Koordinate im Hauptwegpunkt und würden darüber disktutieren, eine weitere einzubauen.

Daher meine Meinung: Ein ganz klares NO.

Gruß,
E.

 

[Wutschkow]

Es wäre vielleicht am einfachsten, wenn Mystery-Koordinaten bei Aktualisierung einfach nicht aktualisiert werden, wenn sie bereits gültige Koordinaten enthalten. In allen Mystery-Fällen, die ich kenne, haben die Cache-Koordinaten keine Bedeutung.

Im Prinzip klingt das vernünftig und es würde auch in 99,x% der Fälle funktionieren. Die Frage ist nur, was ist mit dem Rest?
Selbstverständlich gibt es Fälle, in denen die nominelle Cache-Koordinate eine Rolle spielt, z.B. weil man bei einem Rätsel Zahlen ermittelt, mit denen man eine Peilung von der nominellen Koordinate macht oder auf diese drauf addiert. Es kommt nicht oft vor, aber es kommt vor.
Außerdem bitte nicht vergessen, dass es eigentlich nicht "Mystery" sondern "Unknown" heißt. Dieser Typ kann für alle Arten von Caches verwendet werden. In meiner Homezone gibt es z.B. einen klassischen Multi, bei dem der Reviewer auf dem Typ "Unknown" bestanden hat, weil es eine zusätzliche Logbedingung gibt (kann man drüber diskutieren, aber das ist hier nicht das Thema). Würde der Owner bei diesem Cache die Startkoordinate ändern, bekäme ein Cachewolf-Benutzer das via Aktualisieren dann nicht mehr mit.

Ich will damit nur sagen, die Variante mit dem "Nicht-Aktualisieren" klingt gut und wäre ja wohl auch recht einfach umzusetzen. Aber sie könnte in einigen (wenn auch verhältnismäßig sehr wenigen) Fällen Ärger machen. Darüber sollte man sich im klaren sein.