GC: Logtypen – Überblick mit Anwendungshilfe

Im Gegensatz zu den Cachedatenbanken NC und OC, wo es nur drei verschiedene Typen (gefunden, nicht gefunden, Bemerkung) zur Auswahl gibt, bietet GC ein mittlerweile recht umfangreiches und dementsprechend unübersichtliches System von Logtypen. Die verschiedenen Typen dienen dort nicht nur dazu, Einträge auf Cachebeschreibungsseiten vorzunehmen, sondern auch für gewisse Steuerungsfunktionen. Grundsätzlich hat ausnahmslos jeder Log zu einem Cache oder Reisenden, egal welchen Typs, eine Benachrichtigungsmail an alle Geocacher, die ihn beobachten, zur Folge.
Kein Wunder, dass man daher an verschiedenen Stellen im Netz eine Auflistung der Typen findet, teilweise auch mit kurzen Erläuterungen. Üblicherweise ist die Auswahlmöglichkeit bei den Logtypen je nach Situation/Cachetyp sinnvoll begrenzt (ein „webcam photo taken“ oder „attended“ kann natürlich nicht bei einem Traditional ausgewählt werden). Wie man in den Foren sehen kann (siehe z. B. grünes Forum: „found it“ UND „needs maintenance“? oder Diskussion im blauen Forum, in der behauptet wird, ein „needs maintenance“ machte einen DNF-Eintrag überflüssig), besteht trotzdem gelegentlich Unsicherheit, wann man welchen Typ benutzen soll.
In einigen Fällen scheinen die technischen Konsequenzen auch nicht immer bekannt zu sein, zum Beispiel, dass „post a reviewer note“ nach Cacheveröffentlichung nicht zur Kommunikation mit einem Reviewer geeignet ist und dass bei „needs maintenance“ kein Reviewer benachrichtigt wird. In manch einer überflüssigen Diskussion ist also schlicht Unwissenheit mit im Spiel, wenn ein Geocacher, der einen „Needs maintenance“-Eintrag geschrieben hat, fälschlich des Anschwärzens bezichtigt wird. (Ob „Anschwärzen“ im Zusammenhang mit dem Aufmerksammachen auf Probleme eine angemessene Bezeichnung ist, sei dahingestellt.)
Bei manchen Typen ist bei der Anwendung besonderes Fingerspitzengefühl gefragt, was einige Geocacher dazu bringt, kategorisch zu erklären, dass sie diesen oder jenen Typ niemals benutzen werden. Man sollte also schon wissen, was es mit den unterschiedlichen Logtypen bei GC auf sich hat, um sie angemessen verwenden zu können, andernfalls kann man schon mal empfindlich ins Fettnäpfchen treten, so wie ein „Greenhorn“, das die Tage meinte, einen SBA „bei Enigma #1“ posten zu müssen, was für heftige Reaktionen im grünen Forum sorgte…

Im Folgenden möchte ich daher die Logtypen auch an dieser Stelle noch einmal ausführlicher vorstellen, in Verbindung mit Empfehlungen, wann welcher Logtyp sinnvoll eingesetzt werden sollte.
Wie man seine selbstgeschriebenen Logs nach Typ filtert/auflistet, war bereits Gegenstand im Rahmen der Analyse der URL-Schemata bei GC.

Überschaubarer wird das Logtypensystem, wenn man die einzelnen Typen untergliedert und sortiert. Zunächst einmal sind Typen für Caches und Trackables zu unterscheiden, sie haben bei GC auch eine eigene Durchnummerierung (höhere Nummern deuten auf eine spätere Einführung hin). Bei den Caches gibt es zum einen Logtypen für suchende Geocacher, und zwar solche, die als Erlebnisberichte und für die Statistik (Punkte sammeln) dienen und solche, mit denen Mitteilungen gemacht und Probleme kundgetan werden (diese Einteilung kann man auch auf Trackables anwenden); zum anderen gibt es Logtypen für Cachebesitzer. Darüber hinaus gibt es Logtypen, die nur von den Reviewern eingesetzt werden können.

Logtypen für Caches

Logtypen für suchende Geocacher

(Erlebnisberichte – Fund oder Nichtfund)

lt=2 (found it)
Fast alle Cachetypen loggt man mit diesem Logtyp, wenn man sie gefunden hat. Im Zweifelfall kann es eine Ermessenfrage sein, was als Fund zählt. Siehe dazu auch meinen Artikel zu den „Spielregeln“.
Eine Besonderheit ist, dass man auch CITO-Events mit „found it“ loggen kann, obwohl es dort den Typ „attended“ gibt, der bei einem Event natürlich sinnvoller ist. Ich schiebe das darauf, dass Groundspeak selbst Schwierigkeiten hat, den Überblick über alle Logtypen zu halten… 😈

lt=10 (attended)
Hierbei handelt es sich um einen Fund-Typ, der nur für Events gilt, normale, CITO-Events und Mega-Events. Groundspeak fand wohl, dass „found it“ nicht die angemessenste Bezeichnung ist, da es ja nicht um das Auffinden des Ortes, sondern um das Teilnehmen am Event gilt, insofern gab es einen eigenen Logtyp.
Die Formulierung „attended“ führt dazu, dass manchmal auch Cachebesitzer, sprich Event-Ausrichter, diesen Logtyp bei ihren eigenen Eventcaches einsetzen und so einen Punkt (und ggf. ein Icon) für ihre Hidden- und ihre Found-Statistik bekommen. Ich persönlich finde das unschön.

lt=11 (webcam photo taken)
Dies ist ein spezieller Fund-Typ, der nur für Webcam-Caches gilt. Mit dem eigenen Logtyp will man wohl darauf aufmerksam machen, dass es hier anders als bei den anderen Cachetypen weniger um das Finden des Ortes, sondern um das Fotografiertwerden durch die Webcam geht. (Wer das nicht macht und sich vor Ort der Webcam nur mit einer eigenen Kamera knipst und dieses Foto einstellt, kann meines Erachtens nicht mit Recht einen Punkt für diesen Cache beanspruchen.)

lt=3 (didn’t find it)
Mit diesem Logtyp teilt man mit, dass man einen Cache zu finden probiert, es aber leider nicht geschafft hat. Es ist keine Schande, einen DNF zu posten. Es ist ein Erlebnisbericht. Nicht mehr und nicht weniger. Der Logtyp an sich impliziert weder, dass der Cache schlecht ist oder der Owner geschlampt hat, noch dass Wartungsarbeiten erforderlich sind oder der Cache deaktiviert oder archiviert werden muss.
Dennoch sollte ein Cache-Owner einen DNF-Log genau lesen: Gibt der Sucher Hinweise, warum er gescheitert ist, kann es sein, dass der Cache nicht mehr da ist? Möglicherweise ist eine Kontrolle und ggf. Überarbeitung angebracht. Umso dringlicher, je mehr Sucher unabhängig voneinander nicht in der Lage waren, den Cache zu finden. Genauso ist ein DNF interessant für andere Sucher: Vielleicht weckt das den Ehrgeiz, es besser zu machen als der Vorgänger. Oder aber die Entscheidung, diesen Cache erst anzugehen, wenn der Cache-Owner den ordnungsgemäßen Zustand festgestellt oder wiederhergestellt hat.
Also: Es ist in jedem Fall besser, DNFs zu posten und nicht zu verschweigen. Ein DNF für sich sollte aber auch nicht überbewertet werden (freilich können Kontrollen nach DNFs nie schaden!): Je höher die Schwierigkeit des Caches, desto wahrscheinlicher, dass er auch mal nicht auf Anhieb gefunden wird.

(Mitteilungen und Problemmeldungen)

lt=4 (write note)
Eine Bemerkung zu schreiben kann natürlich für viele Fälle sinnvoll sein. Zum Beispiel, um als Sucher mitzuteilen, dass man den Cache schon angefangen hat, aber noch nicht bis zum Finale durchgekommen ist. Oder, dass man ein zweites Mal vor Ort war, etwa um sich die neue Stelle eines verlegten Caches anzuschauen, und dass alles in Ordnung ist. Oder um TBs und Coins nachzuloggen. Oder als Cachbesitzer, um auf Veranstaltungen in Cachenähe hinzuweisen. Oder mitzuteilen, dass man sich bald um ein gemeldetes Problem kümmern wird. Etc., etc.

lt=18 (post reviewer note)
Dieser Logtyp ist nur für die Kommunikation zwischen Ausleger und Reviewer vor der Freischaltung eines Caches sinnvoll. Beide sollten in dieser Situation diesen Typ und keine normalen Notes verwenden, wenn es um Klärungen geht, die nach Veröffentlichung des Caches automatisch gelöscht werden sollen. Wenn der Reviewer einen Cache freischaltet, verschwinden nämlich alle Reviewer-Notes von der Cachebeschreibungsseite.
Die Bezeichnung „reviewer note“ ist etwas unglücklich gewählt, da man sie so (falsch) verstehen kann, als wären damit Notizen von Reviewern oder Notizen an Reviewer gemeint. Eigentlich sind es „reviewing notes“, also Notizen, die (nur) während des Vorgangs der Begutachtung des Caches durch den Reviewer von Belang sind.
Der Logtyp ist zwar auch nach der Veröffentlichung auswählbar; die Reviewer-Note funktioniert dann aber genau wie eine normale Note. Ein Reviewer bekommt von ihrem Inhalt nichts mit! Man sollte sie also nach Veröffentlichung eines Caches gar nicht mehr verwenden; das Wesen der Reviewer-Note ist ihre temporäre Natur und damit die Eigenschaft, automatisch gelöscht werden zu können. Will man einen Reviewer zu einem bestimmten Cache kontaktieren, muss man ihn direkt anschreiben per E-mail (z. B. über sein Profil).

lt=9 (will attend)
Auch dieser Logtyp ist eigentlich nichts anderes als eine normale Notiz. Vermutlich soll dieser Logtyp es dem Owner erleichtern, durchzuzählen, wie viele Personen sich für sein Event angemeldet haben. Meines Erachtens ist sie überflüssig, da viele Geocacher ohnehin Notes schreiben, wenn sie genauso gut „will attend“ hätten schreiben können.

lt=45 (needs maintenance)
Mit diesem Logtyp teilt ein suchender Geocacher dem Cachebesitzer mit, dass sein Eingreifen erforderlich ist oder erbeten wird. Völlig unabhängig davon, ob der Sucher den Cache nun gefunden hat. (Es kann ja auch sein, dass man eine zerstörte Zwischenstation mit Hilfe eines Telefonjokers umschifft hat.) Ein NM-Log kann genauso sinnvoll mit einem Fund- wie mit einem Nichtfund kombiniert werden, aber auch einzeln sinnvoll sein.
Beispiel 1: Cache gefunden (Fund-Log), Dose oder eine der Zwischenstationen leider ersetzungsbedürftig (NM-Log). Beispiel 2: Cache nicht gefunden, da Cachetyp unklar: Mystery oder Multi? Kann/Soll die Aufgabe vor Ort gelöst oder zu Hause recherchiert werden? (DNF-Log) Bitte um Präzisierung der Aufgabe (NM-Log). Beispiel 3: Cache nach mehreren Anläufen nicht gefunden (Ermessenfrage, wie viele DNFs man loggt…), Bitte um Cachekontrolle (NM-Log). Beispiel 4: Mehrere unabhängige DNFs in Serie, die schon länger zurückliegen. Bitte um Cachekontrolle, bevor man sich selber auf den Weg macht (NM-Log). Es mag ggf. vielleicht lästig sein, einen zweiten Eintrag zu erstellen und sich zu überlegen, was man in welchen der zwei Logs schreibt, erhöht aber die Übersichtlichkeit.
Und noch einmal: ein Reviewer bekommt nichts mit von gemeldeten Problemen; der Logtyp hat nichts mit Anschwärzen zu tun! Er dient dazu, den Owner auf den Zustand seines Caches aufmerksam zu machen.
Gleichzeitig wird es Suchern erleichtert festzustellen, dass bei diesem Cache nicht alles so ist wie es sein sollte: Der Cache erhält eine zusätzliche Attribut-Grafik, die erst dann verschwindet, wenn der Cachebesitzer ein „owner maintenance“-Log (s. u.) geschrieben hat. (Bei Tradis kann der Besitzer diese Grafik auch wie ein normales Attribut abschalten. Zu beachten: Wenn ein temporär nicht verfügbarer Cache wieder in der Betrieb genommen wird durch „enable listing“, verschwindet das Attribut-Icon nicht von alleine! Das „owner maintenance“-Log muss trotzdem sein!) Suchende Geocacher können keinen Einfluss auf das Attribut nehmen; das ist schade, denn es gibt ja auch nette Geocacher, die eine Art „finder maintenance“ durchführen.
NM kann nicht vom Cachebesitzer selber zu seinem Cache gepostet werden. (Wäre es möglich, würde das ja quasi heißen, dass der Owner ein ihm bekanntes Problem an die Sucher delegieren will – das kann nicht Sinn der Sache sein.) Das ist in meinen Augen kein Problem: Wenn der Besitzer weiß, dass sein Cache ein Problem hat, kann er sich entweder sofort selbst darum kümmern, oder abwägen, ob der Cache bis zur Reparatur oder Nachbesserung deaktiviert werden muss oder trotzdem noch findbar ist.

lt=7 (needs archived)
Zu Recht wird immer wieder darauf hingewiesen, dass dieser Typ nur im Ausnahmefall und mit Bedacht und Vorsicht angewendet werden sollte. Man muss klar sagen, wer zu diesem Mittel greift, riskiert häufig, sich unbeliebt zu machen. Insbesondere dann, wenn vorher keine Kommunikation mit dem Cachebesitzer stattgefunden hat. Gleichwohl heißt das nicht, dass dieser Typ keine Berechtigung hätte und nicht angewendet werden darf oder sollte. Denkbare legitime Ausnahmefälle wären, dass ein Geocache von seinem Besitzer stark vernachlässigt wird (ja, das kommt vor) oder dass er nicht regelkonform ist.
Wenn man einen SBA-Log („should be archived“) verfasst, werden Reviewer darauf aufmerksam, dass dieser Cache ein Problem hat. Sie haben die Möglichkeit, dem Vorschlag zu folgen und einen Cache tatsächlich zu archivieren, brauchen dies aber nicht. Alternativ können sie den fraglichen Cache auch erstmal disablen und den Besitzer bitten, sich um das Problem zu kümmern. Und natürlich können sie auch alles beim alten belassen, wenn sie das Gefühl haben, dass die SBA-Note unberechtigt ist.
Siehe dazu auch den Beitrag Wann Caches archivieren?.

Logtypen für Cache-Besitzer

(Cachestatus bearbeiten)

lt=22 (temporarily disable listing)
Hat ein Cache definitiv ein Problem, das dazu führt, dass er nicht mehr gefunden (geklaut) oder nicht mehr geloggt (zerstört) werden kann, gehört er unverzüglich auf disabled gesetzt, damit jeder Bescheid weiß, dass dieser Cache erst repariert werden muss. Geschieht das nicht, suggeriert man den Suchenden, dass der Cache findbar ist. Unnötig zu sagen, wie ärgerlich es wäre, wenn man vor Ort nach längerer Anfahrt feststellt, dass das nicht der Fall ist.
Hat jemand aber bloß um eine Kontrolle gebeten, einen DNF gepostet oder nur ein kleines Problem mittels NM gemeldet („Logbuch feucht“), wäre das Disablen eine überzogene Reaktion.
In manchen Fällen wird von Cachebesitzern meines Erachtens zu früh zu „disable“ gegriffen („Bis ich ihn überprüft habe, nehme ich ihn erstmal raus.“), dabei ist es ja durchaus möglich, dass alles noch ok ist und sich nur der Sucher, der ein Problem gemeldet hat, geirrt hat. Gelegentlich kommt es auch vor, dass Caches geloggt werden, obwohl sie zu der Zeit disabled waren.
Generell finde ich, dass viele Caches viel zu lange auf temporär nicht verfügbar stehen, häufige viele Monate, bis schließlich ein Reviewer eingreift. Offenbar vergessen manche Geocacher ihre eigenen Caches einfach. 😦
In Bezug auf „disable listing“ muss ich auf einen Bug hinweisen, den ich kürzlich entdeckt habe: man kann im Nachhinein den Text des Disable-Logs nicht mehr verändern. Versucht man es doch, bekommt man eine Fehlermeldung. Also dafür sorgen, dass gleich alles korrekt ist. Andernfalls muss man den Cache zwischenzeitlich wieder enablen, um einen neuen disable-Log schreiben zu können.

lt=23 (enable listing)
Mit diesem Logtyp wird das „temporarily disable listing“ rückgängig gemacht. Jetzt ist der Cache wieder verfügbar und kann gesucht, gefunden und geloggt werden.
Daran denken: Wenn man den Cache nach einem NM-Log deaktiviert hat, muss man das rote Attribut-Icon gesondert entfernen, das „enable listing“ allein reicht nicht! Entweder über das übliche „owner maintenance“, oder – das geht bisher nur bei Tradis – indem man das Icon unter den Attributen abschaltet.

lt=5 (archive (show))
Ein Cachebesitzer kann seinen Cache dauerhaft stilllegen; das macht er mit diesem Logtyp.

Archivieren bedeutet, dass ein Cache nicht mehr als verfügbar/suchbar in Listen auftaucht; seine Beschreibung (sowie die zu diesem Cache verfassten Einträge) kann aber immer noch eingesehen werden, er wird also nicht aus der entsprechenden Datenbank gelöscht.

Siehe dazu den Beitrag Wann Caches archivieren?.
Bei Events ist das der normale Lauf der Dinge, wenn sie vorbei sind. Ist der Cache erst einmal im Archiv, kann der Owner das selbst nicht mehr rückgängig machen! Es ist meines Wissens auch nicht mehr möglich, Cachebeschreibungen eines archivierten Caches zu bearbeiten. Mit Hilfe eines Reviewers kann aber jeder Cache wiederbelebt werden.
Auf keinen Fall sollte man einen Cache archivieren, weil man irgendeinen Fehler im Listing hat (z. B. Tippfehler in den Koordinaten) und nun die Cachebeschreibung neu anlegen will. So erzeugt man nur unnötige Karteileichen. Die Gefahr ist groß, dass man beim Neuanlegen des Listings gleich neue Fehler produziert, wenn man sich über den Mehraufwand ärgert. Ein Reviewer kann die Koordinaten schnell und problemlos korrigieren, und schon ist mit dem Original-Listing alles wieder in Ordnung.

lt=46 (owner maintenance)
Mit diesem Logtyp wird das „needs maintenance“ rückgängig gemacht. Das rote Attribut-Icon verschwindet. Manchmal wäre in so einer Situation auch ein „finder maintenance“ sinnvoll, wenn ein Finder das Problem für den Owner bereits behoben hat. Vielleicht führt GC das ja auch noch mal ein.
Es spricht auch nichts dagegen, den „owner maintenance“-Logtyp bei einer regulären Kontrolle zu verwenden, ohne dass man etwas zu reparieren hatte.

lt=47 (update coordinates)
Dieser Logtyp dient dazu, die Koordinaten des Listings anzupassen. Mit ihm erfolgt auch eine Benachrichtigung der Reviewer. Man kann damit aber nicht einfach einen Cache auf einen anderen Kontinent verlegen. Nur etwa 150 Meter Verlegung sind möglich. Alles, was darüber hinaus geht, erfordert das Eingreifen eines Reviewers, den man dann persönlich kontaktieren muss.

Logtypen für Reviewer

(Veröffentlichung steuern)

(publish)
Damit wird ein Cache veröffentlicht, das heißt, die Beschreibung ist nicht mehr nur für Cache-Owner und Reviewer, sondern auch für alle anderen Geocacher einsehbar.

(retract)
Mit diesem Logtyp kann ein Reviewer eine irrtümliche Veröffentlichung wieder zurücknehmen. In der Praxis wird man diesen Logtyp wohl nur auf seiner eigenen Cacheseite sehen können – wenn man Pech hat…

Darüber hinaus haben die Reviewer die Möglichkeit, auch alle Logtypen zu benutzen, die der Besitzer auf seinen Cache anwenden kann.

Logtypen für Trackables

(Mitnehmen, Übernehmen, Anschauen und Aussetzen)

lt=5 (retrieve it from a cache)
Hat man einen Travel Bug oder Geocoin in einem Cache gefunden und mitgenommen, muss man diesen Logtyp verwenden. Damit wird der Reisende aus dem Cache ausgeloggt, dem eigenen Inventar hinzugefügt, und man bekommt einen Punkt für die Statistik.

lt=2 (grab it)
Macht im Prinzip dasselbe wie „retrieve“: man bekommt den Reisendem in sein Inventar und einen Punkt. Dieser Logtyp ist dafür gedacht, wenn man Reisende von anderen Geocachern übergeben bekommt.

lt=48 (discovered it)
Funktioniert analog zu „retrieve“ und „grab“, mit dem Unterschied, dass man den Reisenden nicht in sein Inventar überführt, er bleibt bei dem Geocacher, der ihn in seinem Inventar hat oder in dem Cache, in den er eingeloggt war. Einen Punkt gibt es trotzdem.

lt=10 (dropped off)
Mit diesem „Logtyp“ wird man einen Reisenden wieder los, indem man ihn in einen Cache aussetzt. Im Grunde ist es kein eigener Logtyp, auch wenn das Ergebnis des Aussetzens wie bei einem Logtyp auf der TB-Beschreibungsseite vermerkt wird. Das Abwerfen geschieht dadurch, dass man die Reisenden, die in einen Cache eingeloggt werden sollen, in der Auswahlbox unter dem Texteingabefeld markiert (bei gedrückter Strg-Taste lassen sich beliebig viele Reisende auswählen, die gleichzeitig in einen Cache eingeloggt werden können), wenn man einen Log zu einem Cache schreibt. Egal, ob es ein Fund, eine Note, ein Will attend ist – anscheinend kann man einen Reisenden sogar in Verbindung mit einem DNF-Log in einen Cache einloggen.

(Mitteilungen)

lt=3 (write note)
Und natürlich kann man auch zu Trackables wie zu Caches Bemerkungen schreiben…

Werbung