[Wunsch] Feld für errechnete Koordinaten z.b. bei Mysteries

Robin888 schrieb:

Das ist mal wieder eine Gelegenheit meine Idee der "sperrbaren Koordinaten" unterzubringen.

Demnach gäbe es die Möglichkeit die Koordinaten eines Wegpunktes gegen Aktualisierung von GC zu sperren.

Zum Vergrößern anklicken....

das ist mal wieder eine gelegenheit davon nichts zu halten

es ist ein kompletter bruch mit dem gar nicht mal so schlechten konzept der additional waypoints.

zu 1) man müsste für jeden einzelnen wegpunkt hinterlegen, ob er gegen änderungen gesperrt ist oder wilde bedingungskonstruktionen im code nach wegpunkttyp unterbringen (das würde es nicht übersichtlicher machen)
zu 2) ob das ding nun 500m näher oder weiter weg liegt ...
zu 3) selbst in der statistik würde es das ergebnis kaum ändern da sich über die menge ausgleichen dürfte, dass der eine myst mal nördlich der listingkoordinaten und der andere mal südlich davon liegt. selbst wenn mal ein myst ausnahmsweise 100km von seinen listingkooordinaten wegliegt würde das zumindest bei mir im statistischen rauschen untergehen, ich ich mich mittlerweile gut 2,5 mal um den äquator bewegt habe.

auch bei den corrected coordinates des mitbewerbs darf man nicht vergessen, dass hier immer noch ein kozept am start ist welches aus der zeit vor der einführung der additional waypoints stammt und man so einen addi "simuliert" hat.

hmm irgendwie hab ich das anders verstanden:
wenn ich einen Mysterie gelöst habe, dann überschreibe ich die Koordinaten. Soweit so gut.
Irgendwann hab ich also ein schönes Profil mit allem möglichen Caches incl. aller gelösten Mysteries. Ich darf nur nie wieder das ganze Profil aktualisieren lassen, denn sonst wird mein Bemühen mit den Ursprungsdaten zurückgesetzt... Schade eigentlich.

Meine nicht befriedigende Lösung dazu: ich lege für jeden gelösten Mysterie nen Addi:Finale an. dieser wird nämlich nicht geschrotet beim Aktualisieren. Leider funktioniert dieser Workaround nur bei neuerstellen Addis. Bei vorhandenen hab ich mir schon zwei mal unterbrochene Multies damit zerstört, dass ich vorhandene Addis bearbeitet und zu Hause irgendwann das Profil aktualisiert habe... war ich wütend!!! Hier wieder die nicht befriedigende Lösung: jeden Addi zu doppeln... dumm und blöd, aber geht nicht anders...

Fazit:
Ich würde mir also auch ein Sperr-Häkchen wünschen, dass die Attribute und Koords des jeweiligen Caches bzw. Addis beim aktualiseren in Ruhe läst, allerdings den Rest wie z.B. Logs TB Bilder wie gehabt erneuert.
Grüße, Harry1999

Harry1999 schrieb:

Meine nicht befriedigende Lösung dazu: ich lege für jeden gelösten Mysterie nen Addi:Finale an. dieser wird nämlich nicht geschrotet beim Aktualisieren. Leider funktioniert dieser Workaround nur bei neuerstellen Addis. Bei vorhandenen hab ich mir schon zwei mal unterbrochene Multies damit zerstört, dass ich vorhandene Addis bearbeitet und zu Hause irgendwann das Profil aktualisiert habe... war ich wütend!!! Hier wieder die nicht befriedigende Lösung: jeden Addi zu doppeln... dumm und blöd, aber geht nicht anders...

Zum Vergrößern anklicken....

Das funktioniert auch bei vorhandenen Final-Addis (die dann natürlich erst mal keine Koordinaten haben). Ich hatte damit noch nie Probleme. Errechnete Koordinaten in den Final-Addi (egal, ob er schon leer vorgegeben ist oder neu angelegt wurde) und die Daten wurden noch nie überschrieben.

Harry1999 schrieb:

Meine nicht befriedigende Lösung dazu: ich lege für jeden gelösten Mysterie nen Addi:Finale an. dieser wird nämlich nicht geschrotet beim Aktualisieren.

Zum Vergrößern anklicken....

aus meiner sicht nicht unbefriedigend, sondern die perfekte lösung

Harry1999 schrieb:

Leider funktioniert dieser Workaround nur bei neuerstellen Addis. Bei vorhandenen hab ich mir schon zwei mal unterbrochene Multies damit zerstört, dass ich vorhandene Addis bearbeitet und zu Hause irgendwann das Profil aktualisiert habe... war ich wütend!!!

Zum Vergrößern anklicken....

bitte definiere "vorhandene addis". addis aus der beschreibung die im listing ohne koordinaten angegeben sind sollte cw nach meinem kenntnisstand in ruhe lassen. nur wenn zu einem addi in der beschreibung explizit koordinaten angegeben sind, sollten diese auch so übernommen werden. falls der spider beim aktualisieren die ergänzten koordinaten löscht und durch leere ersetzt, würde ich das spontan für einen bug im spider halten. zumindest stelle ich mir vor, dass der spider so funktionieren sollte - allerdings verstehe ich dafür zu wenig vom spider.

Da ich die meiste Zeit die Addies ausfiltern muss, um überhaupt die Caches zu finden, übersiehe ich leicht die gelösten Mysteries. Die Lösung des Sperrens plus dann noch eine Änderung in der Farbe in der Liste wäre dann meine perfekte Lösung. Das gleiche mit den Addies. Man sieht sofort, wo es weitergeht. Und ja, es gibt auch addies, die vorbelegte Teil-Werte enthalten, die man ergänzen kann/soll. Ich stimme zu, dass es Workaround gibt. Aber ein Ursächliche Lösung, nämlich das Überschreiben zu ermöglichen, gibt es nicht. Dann lieber diese Felder nicht editierbar machen, wenn schon die Gefahr besteht das Daten zerstört werden. Zumindest ich dachte, dass Felder die ich ändern kann, sind SAVE. Bei uns in der Firma ist das eine Policy.
Grüße, Harry1999

greiol schrieb:

falls der spider beim aktualisieren die ergänzten koordinaten löscht und durch leere ersetzt, würde ich das spontan für einen bug im spider halten. zumindest stelle ich mir vor, dass der spider so funktionieren sollte - allerdings verstehe ich dafür zu wenig vom spider.

Zum Vergrößern anklicken....

Der Spider überschreibt vorhandene Koordinaten nicht durch leere.

Wenn ich länger düber nachdenke, dann sollten die Felder nicht editierbar sein. Aktuell kann man sie nur als temporären Notizettel nutzen. Diese Notizen-Felder gibts aber meines wissens schon an anderer Stelle.
Also wech damit, sonst gibts für unwissende/unbedarfte Datenverlust.
Grüße Harry1999

Harry1999 schrieb:

Da ich die meiste Zeit die Addies ausfiltern muss, um überhaupt die Caches zu finden, übersiehe ich leicht die gelösten Mysteries.

Zum Vergrößern anklicken....

dafür wurden z.b. merker eingeführt.

Harry1999 schrieb:

Die Lösung des Sperrens plus dann noch eine Änderung in der Farbe in der Liste wäre dann meine perfekte Lösung.

Zum Vergrößern anklicken....

dein, aber nicht meine

Harry1999 schrieb:

Das gleiche mit den Addies. Man sieht sofort, wo es weitergeht. Und ja, es gibt auch addies, die vorbelegte Teil-Werte enthalten, die man ergänzen kann/soll.

Zum Vergrößern anklicken....

bitte nenn mal konkrete reproduzierbare beispiele an denen man nachvollziehen kann wann und wo etwas bei addis überschrieben wird.

Harry1999 schrieb:

Ich stimme zu, dass es Workaround gibt.

Zum Vergrößern anklicken....

das ist nicht der workaround. das ist der vorgesehene workflow. und du möchtest den ändern

Harry1999 schrieb:

Zumindest ich dachte, dass Felder die ich ändern kann, sind SAVE.

Zum Vergrößern anklicken....

in dem fall deckt sich leider das bedienkonzept nicht mit deiner erwartungshaltung. diese aussage bin ich auch bereit zu akzeptieren.

Harry1999 schrieb:

Bei uns in der Firma ist das eine Policy.

Zum Vergrößern anklicken....

der inhalt ist save bis du als benutzer sagst du willst die daten von der webseite haben. cachewolf erfindet ja keine daten und macht auch nichts hintenrum, sondern du sagt: bitte lade mir die aktuellen daten von der webseite.

de facto ist es so, dass das was auf der cachelistingseite steht und daten enthält das überschreibt was sich im cw befindet. zusätzliche flags müssen gespeichert werden und es braucht logik das zu verwalten und anpassungen an der gui. das gilt auch für komplexe entscheidungen welche felder nun editierbar sein dürfen und wann. auf einem desktop sind all diese ressourcen ausreichend vorhanden. auf einem pda nicht (immer). und wenn wir ein flag einbauen kommt in drei wochen der nächste an und moniert, dass cachewolf ihn nicht gewarnt hat, dass der tradi verlegt wurde und er sich nicht mehr daran erinnern kann den cache jemals gegen änderung gesperrt zu haben.

Das ist kein Datenverlust. Die Daten werden beim Aktualisieren eben aktualisiert/korrigiert. Es steht jedem frei Daten zu ändern und sie dann damit wieder zurückzusetzen.

Ich gebe zu: Die Anwendungsfälle, in denen man sie wirklich ändern muss sind gering. Aber ich bin kein Freund davon, im User immer nur den DAU zu sehen.

Ich bin nach wie vor der Meinung, dass Datenverlust erfolgen kann, der mit Sicherheit nur einem Bruchteil der Benutzer klar ist. Es gibt Scenen die in etwa so sind: "Ich dachte du hast die Lösungen mit!" Das ist nicht nur mir passiert, sondern auch einem anderen Bekannten. Und die Anfrage nach einem Lösungsfeld und dem Kommentar eines Sperrfeldes kommen ebenfalls nicht von mir. Ja, ich sehe dieses nicht als guten Workflow an, sondern eher als Krücke für fehlende Funktionalität, die sogar bis zu einem Datenverlust führen kann, aber eben nicht muss. Bisher poppt jedenfalls kein Fenster beim Aktualisiernen auf "Bitte beachten Sie, dass alle Änderungen in den Caches überschieben werden."
Bisher dachte ich, auch DAU's können mit CW arbeiten... ist also doch ein Insider-Tool
Grüße, Harry1999

Es gibt doch ein Lösungsfeld. Es nennt sich Final-Additional-Waypoint.

Davon abgesehen, machen DAUs meist nur dass, was sie irgendwann mal gelernt haben. Einfach irgendwas unüberlegt ändern, Funktionen ausführen, die sie nicht verstehen und dann wundern, dass es nicht das tut, was sie wollen... Das hört sich eher Freaks an ;-)

OK ok,.. offensichtlich habe ich es wohl mit einer anderen "Klientel" zu tun. Mein Erfahrungsschatz ist da definitiv ein anderer... aber andere "Branchen" andere "Kundschaft".

Harry1999 schrieb:

OK ok,.. offensichtlich habe ich es wohl mit einer anderen "Klientel" zu tun. Mein Erfahrungsschatz ist da definitiv ein anderer... aber andere "Branchen" andere "Kundschaft".

Zum Vergrößern anklicken....

ich würde gerne versuchen das etwas zu relativieren.

würde mir jemand cachewolf beruflich auf den tisch legen wäre meine reaktion vermutlich irgendwas zwischen auslachen und durch die decke springen. nach ernsthafter betrachtung würde die mängelliste vermutlich seiten füllen und das betrifft nicht nur das user interface.

trotzdem finde ich aus privater sicht das tool gut.

cachewolf ist ein tool mit sehr hohen freiheitsgraden. das ist in der heutigen zeit mit zum teil hoch spezialisierter software für teilweise unglaublich kleine anwendungsbereiche sicherlich gewöhnungsbedürftig, denn freiheitsgrade in der software nehmen den anwender mit in die verantwortung und das ist dieser heute einfach nicht mehr gewohnt. das führt auf der einen seite natürlich dazu, dass du mit cachewolf als anwender auch "fehler" machen kannst, die andere tools gar nicht erst zulassen. dafür öffnen sich mit cachewolf aber gleichzeitig möglichkeiten die andere tools auf grund ihrer deutlich restriktiveren vorgaben niemals zulassen. mit dieser freiheit, die die auch freiheit zum "datenverlust" beinhaltet, muss man umgehen lernen.

und dann ist da noch die dualität des einsatzes. cachewolf wurde ja nicht (nur) für den desktop geschrieben sondern vor allem für den einsatz auf mobilen geräten. und es sollte ein mächtiges werkzeug sein. heute zählt auf dem desktop niemand mehr taktzyklen und ein paar byte mehr oder weniger die pro datensatz von der platte gelesen werden müssen stören auch niemanden. mobil sieht die sache schon wieder ganz anders aus und es wird um jedes byte gekämpft und immer wieder überlegt ob die eine oder andere abfrage wirklich notwendig ist damit die performance stimmt. soll das tool dann auch noch leistungsfähig und flexibel sein müssen manchmal dinge "offen" bleiben, die für manchen besser "verschlossen" wären.

unter dem strich ist cachewolf ein tool das sicherlich an der einen oder anderen stelle gewöhnungsbedürftig ist, aber das gilt auch die tools der "mitbewerber". man muss sich an einigen stellen auf die philosophie des "cachewolf-wegs" einlassen. bekommt dafür aber ein leistungsfähiges und enorm flexibles tool.

der spagat zwischen den konkurrierenden zielen zu schaffen ist nicht immer einfach und ich finde die entwickler machen an der stelle in ihrer freizeit einen verdammt guten job.

Wenn man weiss, dass CW die Daten aktualisiert, ist doch gut.
Die Gründe dafür liegen auf der Hand und sind ausreichend diskutiert denke ich.
Vielleicht muss da noch ein entsprechd fetter Hinweis ins Handbuch.

(noch mal ein paar Überlegungen zu den Gründen
CW ist ja erst mal ein Abbild der entsprechnden Datenbanken. Und da muss man sich drauf verlassen können. Wenn ein Cache - Owner Änderungen durchführt (oder ähliches), muss das nach meiner Meinung auch in die CW-Daten. Die Konflikte, die dabei auftreten können, wenn CW wegen Benutzeränderungen nicht mehr den ursprüglichen Stand des Datenimports wiederspiegelt können beim Aktualisieren nicht festgestellt werden. Also muss der aktuelle Stand der Daten übernommen werden.)

Und wenn man eine Datensicherung hat, gibt es auch keinen Datenverlust. Es gilt also im Handbuch vielleicht noch mal darauf hinzuweisen, wo Änderungen und zusätzliche Infos möglich , sinnvoll und erwünscht sind.

greiol schrieb:

Robin888 schrieb:

Das ist mal wieder eine Gelegenheit meine Idee der "sperrbaren Koordinaten" unterzubringen.

Zum Vergrößern anklicken....

das ist mal wieder eine gelegenheit davon nichts zu halten

Zum Vergrößern anklicken....

:-Þ

greiol schrieb:

es ist ein kompletter bruch mit dem gar nicht mal so schlechten konzept der additional waypoints.

Zum Vergrößern anklicken....

Zugegeben, das Konzept ist sehr universal. Aber deswegen noch nicht perfekt.

greiol schrieb:

zu 1) man müsste für jeden einzelnen wegpunkt hinterlegen, ob er gegen änderungen gesperrt ist oder wilde bedingungskonstruktionen im code nach wegpunkttyp unterbringen (das würde es nicht übersichtlicher machen)

Zum Vergrößern anklicken....

Wo genau ist das Problem ein Bit Information mehr in den xmls unterzubringen?

greiol schrieb:

zu 2) ob das ding nun 500m näher oder weiter weg liegt ...

Zum Vergrößern anklicken....

...mag "im Dorf links" nicht viel ändern.
Aber ich hatte schon oft genug den Fall, daß die Koordinaten bis mehrere Kilometer auseinander liegen. Da ist das schon sehr störend.
Oder wenn man unterwegs ist und einfach von Cache zu nächstgelegenen Cache geht läuft man mitunter auch schonmal an einem Final vorbei. (Ist nicht meine Art zu Cachen.)

zu 3) selbst in der statistik würde es das ergebnis kaum ändern da sich über die menge ausgleichen dürfte, dass der eine myst mal nördlich der listingkoordinaten und der andere mal südlich davon liegt. selbst wenn mal ein myst ausnahmsweise 100km von seinen listingkooordinaten wegliegt würde das zumindest bei mir im statistischen rauschen untergehen, ich ich mich mittlerweile gut 2,5 mal um den äquator bewegt habe.

Zum Vergrößern anklicken....

Das war auch nur ein Trittbrett-Argument. Wenn schon Statistik, dann wenigstens so genau wie möglich.

greiol schrieb:

auch bei den corrected coordinates des mitbewerbs darf man nicht vergessen, dass hier immer noch ein kozept am start ist welches aus der zeit vor der einführung der additional waypoints stammt und man so einen addi "simuliert" hat.

Zum Vergrößern anklicken....

Ich kann nicht folgen!?

Findet denn zumindest die Idee Anklang Size, Terrain, Difficulty (+ Owner und Hidden) an die AWPs zu vererben und eine Statusänderung, ggfls. auf Nachfrage, vom AWP auf den Vater hochzuziehen?

Damit ich nur den Final anklicken muß, [Gehe zu diesem], (Suchen, Finden,) [Details], [Gefunden], Nächster.
Statt: Final anklicken, [Gehe zu diesem], [Liste], HWP anklicken, [Goto], (Suchen, Finden,) [Details], [Gefunden], Nächster.

Möglich wären auch Buttons im Detail-Reiter, die zwischen den WP umschalten ("Nächster", Vorheriger") oder zumindest zum Vater wechseln ("Öffne zugehörigen Haupt-Wegpunkt")

Robin(888)

Ein Button "nächster" fände ich gut. Aber er müsste im Goto-Panel sitzen. Denn dort finde ich einen Addi und will dann zum nächsten. Wenn kein nächster angelegt ist, dann sollte nach gefragt werden: "neuen Addi anlegen".

Zum Problem der "versehentlich überschriebenen Koos":
Ich kann mir schon vorstellen, dass man mancher erstmal drauf rein fällt. Wie wäre es daher mit einer Meldung, wenn man die Koos eines Wepunktes ändert: "Bitte beachten Sie, dass bei der nächsten Aktualisierung die Koordinaten von denen aus der Internetdatenbank möglicherweise überschrieben werden. Wenn Sie das Ziel eines weiteren Wegpunktes ermittelt haben, dann legen sie mit 'neuer Wegpunkt' einen Addi an, deren Koordinaten werden nicht beim online Aktualisieren überschrieben. Wollen Sie die Koordinaten dennoch ändern?" oder besser gleich die Möglichkeit anbieten, einen Addi anzulegen: "wollen Sie alternativ einen Addi anlegen?". Danach sollte noch eine Checkbox kommen "künftig nicht mehr diese Warnmeldung zeigen".

Gruß,
Pfeffer.

pfeffer schrieb:

Ein Button "nächster" fände ich gut. Aber er müsste im Goto-Panel sitzen. Denn dort finde ich einen Addi und will dann zum nächsten.

Zum Vergrößern anklicken....

Das halte ich - mit Verlaub - für ziemlich sinnfrei.
Wenn ich zum nächsten AWP möchte, muss ich ihm in den allermeisten Fällen erst Koordinaten geben. Das mache ich entweder im Solver (der schickt mich dann auch direkt zum nächsten Waypoint) oder per Hand im Detail-Reiter.

Und wenn ich einen Cache gefunden habe und zum nächsten will, markiere ich ihn ebenfalls im Detail-Reiter als "gefunden".

Ein Button, so wie Du ihn beschreibst wäre in meinen Augen nur in der Kombination nützlich, daß die Koordinaten aller Stationen bekannt sind und man die gefundenen Hinweise auf Papier notiert.

Es sei den, er würde den aktuellen Cache vorher als "gefunden" markieren. Dann könnte er auch im Goto-Panel untergebracht werden.

(Wobei mir allerdings bei meinem Vorschlag gar keine Goto-Funktionalität vorschwebte, sondern einfach ein bequemeres "browsen" durch die Cacheliste. )

pfeffer schrieb:

Wenn kein nächster angelegt ist, dann sollte nach gefragt werden: "neuen Addi anlegen".

Zum Vergrößern anklicken....

Zumindest das geht ja schon. Auch, wenn ich das selten benutze.

Robin(888)

jetzt weißt Du, wie ich immer cache: Alle Hinweise auf Papier notieren. Bis ich die in CW eingetippt habe, sind die anderen sonst längst weg. Und zum Vorbereiten am PC habe ich kein Bock.

Das Anlegen eines neuen Wegpunktes über das DetailsPanel ist mir etwas umständlich. Ich will doch bloß neue Koos eingaben und die speichern. Da brauche ich keinen Namen festzulegen oder sonstwas.

Ein Knopf "nächster Addi" kann nur dann Sinn ergeben, wenn man sich nicht in der Liste befindet und die Addis bereits angelegt sind. Aber wozu man das in DetailsPanel brauche können soll, ist mir schleierhaft.

Aber von mir vorgeschlagene Warnung hat mit alle dem nichts zu tun, sondern geht auf das urprünglich Problem ein, dass einige offenbar versehentlich ihre mühsam berechneten Koordinaten verloren haben und schlägt gleich die hier beschrieben Lösung vor: einen Addi anlegen, statt Koos ändern.

Gruß,
Pfeffer.

Robin888 schrieb:

Damit ich nur den Final anklicken muß, [Gehe zu diesem], (Suchen, Finden,) [Details], [Gefunden], Nächster.
Statt: Final anklicken, [Gehe zu diesem], [Liste], HWP anklicken, [Goto], (Suchen, Finden,) [Details], [Gefunden], Nächster.

Zum Vergrößern anklicken....

Ich habe gestern schon eingebaut, dass ein gefundener Final den ganzen Cache als gefunden markiert. Ich denke, es spricht auch nichts dagegen bei Addis die im DetailsPanel sowieso deaktivierten Felder mit den Werten des Hauptwegpunktes zu belegen. Das kann auch gerne jemand anderes machen. Weiß nicht, ob ich am WE dazu komme.

Wie wäre es denn, wenn man einen neuen Addi-Typ "korrigierte Koordinate" (vielleicht fällt jemandem ein kompaktere Name dafür ein) einführt, der explizit für diesen Zweck vorgesehen ist.

Vorteile:
-Der kann beim Aktualisieren keinesfalls überschrieben werden, bzw. bräuchte ja gar nicht aktualisiert zu werden. Das Thema des "Sperrens" von Wegpunkten für die Aktualisierung würde sich dann erübrigen, da Addis dieses Typs letztlich gesperrt sind.
-Man könnte auf längliche Warnungen verzichten und statt dessen ganz klar sagen: "Wer Koordinaten eigenhändig ändern will, sollte diesen Addi-Typ verwenden, sonst kann es Probleme geben."
-Man könnte den Filter so einstellen, dass man nur HWPs sowie AWPs dieses Typs zu sehen bekommt. Dann erkennt man auch auf den ersten Blick gelöste Mysterys bzw. sieht sofort, wenn bei einem Cache nicht der HWP sondern eine korrigierte Koordinate angesteuert werden muss
-Auf lange Sicht könnte man das ganze sogar noch komfortabler machen, z.B. indem beim Goto zu einem HWP automatisch geprüft wird, ob dafür ein Addi des Typs "korrigierte Koordinate" vorliegt und dann dessen Koords als Ziel gesetzt werden. Gleiches beim Exportieren.
Oder man prüft nach jeder Aktualisierung eines HWPs, ob dafür eine korrigierte Koordinate vorliegt und ändert dann den HWP entsprechend. Dann würde er auch immer auf Karte und Radar an der "realen" Position angezeigt werden.