Noch eine Anregung zum Spidern...

[Engywuck]

Ich habe bei der Urlaubsvorbereitung mal wieder festgestellt, das Caches häufig dann interessant sind, wenn besonders viele Bilder in der Gallery eingestellt sind. Klar: Geile Location - viele Bilder. Daher fände ich es interessant und aufschlussreich, wenn die Anzahl der Bilder und Anzahl der Logs mit gespidert würden. Aus dem Verhältnis könnte man sich dann aus einer großen Menge unbekannter Caches schnell potentiell interessante Kandidaten rauspicken.

Was sagt die Gemeinde?

Gruß,
E.

 

[greiol]

es ist eventuell eine interessante information für die vorbereitung, aber zum eigentlichen cachen dann wieder hinreichend überflüssig. solange wir den cachewolf für den outdoorteil schlank halten wollen, würde ich es draussen lassen.

 

[Engywuck]

es ist eventuell eine interessante information für die vorbereitung, aber zum eigentlichen cachen dann wieder hinreichend überflüssig.

Das finde ich nicht unbedingt. Wenn Du am Urlaubsort bist und Dir überlegst, welchen der 50 Caches der umgebung Du angehen willst, wäre das durchaus eine interessante Information.

solange wir den cachewolf für den outdoorteil schlank halten wollen, würde ich es draussen lassen.

Cachewolf ist gerade auch für die Vorbereitung ein sehr praktisches Tool. Und in der Abwägung Schlankheit/Nutzen würde ich die Waage hier deutlich zur Seite des Nutzens ausschlagen sehen. Aber das mögen andere natürlich anders beurteilen...

Gruß,
E.

 

[Kappler]

Zum "schlank" halten wäre es vielleicht interessant, diese Information nicht in der Index.xml, sondern nur in den Waypoint-XMLs zu speichern.
Das erzeugt beim Einlesen keine zusätzliche Last, und wenn man die Info benötigt, könnte (ähnlich wie bisher das Einlesen der Solver/Notes-Eigenschaft realisiert war) im Verwalten-Menü das Durchsuchen des aktuellen Profils gestartet werden.
Nach dem Beenden oder Profilwechseln muss dann eben neu eingelesen werden, wenn man die Information benötigt.

 

[Engywuck]

Man könnte aber auch die OC-recommende-Felder dafür nehmen, die bei GC-Caches ja ziemlich verwaist in der Gegend rumliegen.

 

[greiol]

es ist eventuell eine interessante information für die vorbereitung, aber zum eigentlichen cachen dann wieder hinreichend überflüssig.

Das finde ich nicht unbedingt. Wenn Du am Urlaubsort bist und Dir überlegst, welchen der 50 Caches der umgebung Du angehen willst, wäre das durchaus eine interessante Information.

das ist vorbereitung. ob du die zu hause oder unter palmen machst ...

solange wir den cachewolf für den outdoorteil schlank halten wollen, würde ich es draussen lassen.

Cachewolf ist gerade auch für die Vorbereitung ein sehr praktisches Tool.

das ist eine spannende philosophische frage über die ausrichtung von cachewolf. jeder von uns würde das eine oder andere noch praktisch finden (und vermutlich ein paar dinge die drin sind überflüssig). und jeder wird den nutzen des features das er vermisst als nützlich empfinden, denn das liegt in der natur der sache. in der summe können die wünsche aber das tool auch platt machen. ich kenne einige die für vorbereitung & co lieber gsak benutzen weil eben viel mehr felder drin sind und dann nur das ergebnis der auswahl auf den wolf spielen. die versuchung cachewolf auf gsak umfang auszubauen ist sicherlich gross, aber vielleicht nicht unbedingt sinnvoll. es wäre zumindest nach meinem verständnis ein wechsel der ausrichtung.

Man könnte aber auch die OC-recommende-Felder dafür nehmen, die bei GC-Caches ja ziemlich verwaist in der Gegend rumliegen.

das wäre zum beispiel einer der kandidaten auf die ich persönlich verzichten könnte weil sie auch der vorbereitung und nicht dem eigentlichen cachen dienen (und ich ohnehin noch nie einen oc cache mitgenommen habe).

 

[Engywuck]

Zumindest die Ergebnisse der Umfrage sprechen dagegen, dass CacheWolf als hauptsächliches Outdoor-Tool gesehen wird. Es sind sogar drei mal mehr Leute, die den Wolf nur inhouse nutzen als Leute, die ihn nur outdoor nutzen.

 

[t31]

Ich nutze ihn vorrangig indoor (Planung) und nur bei Multis (Solver) oder Spoilerbilder outdoor, cachen selbst gehe ich mit dem etrex. Ein modularer Aufbau wäre sicher hinsichtlich Ressourcen besser.

 

[Engywuck]

Bevor das hier zu einer Diskussion über die weitere Ausrichtung wird (die wir gerne in einem separaten Thread fortsetzen können und die sicherlich auch interessant wäre), würde mich hier interessieren, was denn die werte Gemeinde von dem von mir vorgeschlagenen Feature hält.

Gruß,
E.

 

[greiol]

Zum "schlank" halten wäre es vielleicht interessant, diese Information nicht in der Index.xml, sondern nur in den Waypoint-XMLs zu speichern.

da kann man natürlich eine menge unterbringen, aber zumindest die datenmenge wird nicht kleiner und bisher speichern wir alle informationen in allen wegpunkten. selbst infos die der wegpunkt sinnvollerweise gar nicht haben könnte.

Das erzeugt beim Einlesen keine zusätzliche Last, und wenn man die Info benötigt, könnte (ähnlich wie bisher das Einlesen der Solver/Notes-Eigenschaft realisiert war) im Verwalten-Menü das Durchsuchen des aktuellen Profils gestartet werden.

die information wird anschliessend persistiert in der index.xml. die funktion im menü dient nur dazu denen das setzen der werte zu ermöglichen die schon auf v3 konvertiert hatten bevor die v1/2 importer das setzen konnten. (nebenbaustelle: deshalb sollte der menüpunkt im der stable dann auch wieder raus sein, aber das diskutieren wir, wenn wir die stable diskutieren.

Nach dem Beenden oder Profilwechseln muss dann eben neu eingelesen werden, wenn man die Information benötigt.

es geht mir nicht darum die entwicklung in die richtung grundsätzlich zu stoppen, ich möchte nur geregelt hinkommen.
vor ein paar tagen hatten wir die anfrage ob gcvote rein könnte, nun der quotient aus bildern und finds. und dem nächsten fällt noch etwas ein. sollten wir us für ein bewertungsfeld entscheiden (dessen notwendigkeit ich trotzdem nicht sehe), sollten wir ein bewertungsfeld haben und nicht zwei, fünf, sieben oder zwölf. wie bekommt der user die infos seine liebslingsbewertungsdienstes dort hinein ohne dass wir die in einem anderen fred so streng verteidigte hoheit über das schreiben der index.xml und waypoint.xml an dritttols abgeben zu müssen? vielleicht können wir die diskussion in die richtung führen?

Ein modularer Aufbau wäre sicher hinsichtlich Ressourcen besser

das wäre es sicherlich, allerdings gilt es ein paar akspekte zu berücksichtigen:
- die anwendung müsste sich modulweise bauen lass (gibt der code derzeit nicht her)
- neben der codegröße ist die datengröße ein limitierender faktor
- falls man nur mit einer teilmenge der informationen (teile eines caches) raus geht, wird es notwendig sein split- und merge funktionen zu schreiben um die daten wieder syncron zu halten

 

[greiol]

Bevor das hier zu einer Diskussion über die weitere Ausrichtung wird (die wir gerne in einem separaten Thread fortsetzen können und die sicherlich auch interessant wäre), würde mich hier interessieren, was denn die werte Gemeinde von dem von mir vorgeschlagenen Feature hält.

also diskutieren wir erst über die ausrichtung, wenn es eine mehrheit für deinen vorschlag gibt?

 

[Engywuck]

Vor ein paar tagen hatten wir die anfrage ob gcvote rein könnte, nun der quotient aus bildern und finds. und dem nächsten fällt noch etwas ein.

Da hätte ich auch kein Problem mit. Man muss abwägen:
- wie viele User finden das neue Feature praktisch?
- wie wirkt es sich aus auf Performance, Codegröße, Datenmenge
Wenn 100% der User der Meinung sind, dass der Cachewolf grünkariert sein sollte, dann kann man auch das tun. Schließlich programmieren wir für die Anwender, und nicht für unsere Ideale. Daher hatte ich ja auch gefragt, was die Anwender von der Idee halten.

sollten wir us für ein bewertungsfeld entscheiden (dessen notwendigkeit ich trotzdem nicht sehe), sollten wir ein bewertungsfeld haben und nicht zwei, fünf, sieben oder zwölf.

Hehe Schon wieder unterschiedlicher Meinung. Ich hätte nämlich gerne noch ein weiteres Bewertungsfeld. Diesmal eins, wo ich meine persönliche Bewertung (gerne in der üblichen 1.0, 1.5, 2.0...-Notation) hinterlegen kann, damit ich vor Ort, wenn mir der Wolf 70 Caches in 10 km Umkreis anbietet, schnell entscheiden kann, wo ich denn hinfahren will. Wenn ich nur eine Liste mit Namen sehe, habe ich da nämlich Null Überblick.

Aber ich sehe schon, die Diskussion driftet zu sehr in Richtung "Wofür brauchen wir den CacheWolf". Ich mache am besten heute Abend mal ne Umfrage auf

Gruß,
E.

 

[Engywuck]

also diskutieren wir erst über die ausrichtung, wenn es eine mehrheit für deinen vorschlag gibt?

Ts ts...
Ich würde gerne über meinen Vorschlag diskutieren. Dazu gibt es diesen Thread. Für den Rest mache ich nachher einen eigenen Thread auf, in dem man dann über den zweck des Wolfs nach Herzenslust diskutieren kann.

Gruß,
E.

 

[Kappler]

Zum "schlank" halten wäre es vielleicht interessant, diese Information nicht in der Index.xml, sondern nur in den Waypoint-XMLs zu speichern.

da kann man natürlich eine menge unterbringen, aber zumindest die datenmenge wird nicht kleiner und bisher speichern wir alle informationen in allen wegpunkten. selbst infos die der wegpunkt sinnvollerweise gar nicht haben könnte.

Die Datenmenge an sich sehe ich eigentlich nicht als Problem, vielmehr die Zeit, diese Datenmenge einzulesen.
Und Felder die nur in den Waypoint-XMLs vorkommen, dürften hier keine zusätzliche Last erzeugen.

Das erzeugt beim Einlesen keine zusätzliche Last, und wenn man die Info benötigt, könnte (ähnlich wie bisher das Einlesen der Solver/Notes-Eigenschaft realisiert war) im Verwalten-Menü das Durchsuchen des aktuellen Profils gestartet werden.

die information wird anschliessend persistiert in der index.xml. die funktion im menü dient nur dazu denen das setzen der werte zu ermöglichen die schon auf v3 konvertiert hatten bevor die v1/2 importer das setzen konnten. (nebenbaustelle: deshalb sollte der menüpunkt im der stable dann auch wieder raus sein, aber das diskutieren wir, wenn wir die stable diskutieren

Das ist momentan bei den HasSolver/HasNotes-Feldern so geregelt, aber meine Idee war eben die eventuell neu zu schaffenden "Bewertungs"-Felder nicht zu "persistieren", sondern nur bei Bedarf neu einzulesen.

 

[greiol]

also mal rein zum vorschlag:
sofern man einen bewertungsfaktor mit übernehmen möchte, halte ich einen den man aus den gc.com für gc.com ableiten kann grundsätzlich für besser als einen externen faktor.
grund ist, dass solche faktoren eher durchgängig vorhanden sein dürften als regionale lösungen, wie gut auch immer die regional funktionieren mögen.

bilder/pro log lässt direkt aus gc.com extrahieren und ist sicherlich ein indikator dafür, dass es dort etwas zu sehen gibt (den spezialfall earth(virtual)cache kann man über den filter ausblenden). er dürfte allerdings mehr über die gegend als den cache an sich aussagen und hätte damit einen klaren schwerpunkt eben auf schönen gegenden und nicht unbedingt auf schönen caches.

aus touristischer sicht also sicherlich interessant.

 

[Kappler]

...aus touristischer sicht also sicherlich interessant...

Und gerade das ist ja für den Urlaub so praktisch. Zu Hause weiß man in etwa, wo es schön ist, für den Urlaub wäre eine solche Hilfe bestimmt eine feine Sache.

 

[t31]

Bevor das hier zu einer Diskussion über ..., würde mich hier interessieren, was denn die werte Gemeinde von dem von mir vorgeschlagenen Feature hält.

Grundsätzlich bin ich da für alles offen, für speziell dieses Feature fehlt mir ein geeigneter Anwendungsfall, zukünftig kann das schon wieder anders aussehen.