AnnaMoritz

Meiner Meinung nach bieten sich diese Möglichkeiten an (wenn es nicht möglich/sinnvoll ist, selbst möglichst viele Multis und Unknowns dort zu besuchen/zu lösen oder zumindest die Richtung herauszufinden, wenn das aus dem Listing hervorgeht): 1. Das Gelände der Bildungseinrichtung ist groß genug, dass ein Kreis mit 161m Radius zur Gänze im Gelände bleibt, dann darf dort theoretisch kein Cache sein, wenn dafür keine Genehmigung ausgegeben wurde, oder es ist keine erforderlich. Oder eine prinzipielle Genehmigung für das Gelände einholen und den konkreten Platz danach richten, ob das eingereichte Final die Abstandsbedingungen erfüllt oder verschoben werden muss. 2. Herausfinden, wer dort vermutlich die meisten bis alle Multis und Unknown gefunden hat in der Gegend, falls das noch nicht bekannt ist z.B. so und dann jemand aus diesem Kreis direkt fragen, ob er behilflich sein kann bei der Frage, ob der gewünschte Platz frei ist und ob dieser Cacher vielleicht der Betatester sein will. Falls bekannt wird, dass genau der Platz, der sich am besten für ein 350 Jahre Jubiläum eignet, besetzt ist, vielleicht ist der andere Owner bereit, wegzurücken, wenn es für den anderen Cache möglich ist. 3. Sehr rechtzeitig Koordinatencheck durch lokalen Reviewer anfragen und die Beweggründe genau erklären. Davor noch das hier genau lesen.

For owners there is an 'update coordinates' log option. The opening message only says 'Update Coordinates'. It doesn't say anything about which coordinates are to be updated. For Traditionals this is simple. One can assume the cache coordinates get updated. For other cachetypes (Multi, Mystery, Wherigo, Letterbox Hybrid) one only can speculate whether this changes the header coordinates of the cache or the final coordinates of the cache without a meaningful label indicating what gets changed. In fact now it seems that for non-traditional caches the header is meant, at least the fields are pre-filled with the header coordinates of the cache.

I was curious about that too, so I just tried it. If you backdate a log and flag it as Needs maintenance, the date of the NM log on the cache listing is today's date (ie. the date on which you submit the log, not the backdated date). In effect, you can't backdate an NM log, which makes sense. It makes sense that NM (and NA) can't be backdated. But then it seems even more necessary to include a link to the corresponding log. And inserting the other log date as 'this NM/... was triggered by a log dated ...' And a warning for the the poster like 'your Found it/... precedes the NM/... by ... days/months. Please read the logs for the cache to see whether the issue has been addressed/solved since your visit.' Well, thinking of NM and NA, every logger should have (to have) read the logs. That is also true for the self assigned data base cleaners (posting for geocaches they didn't visit) only relying on output of cache police makros. For highly frequented geocaches (like 7-17 visits per day) logged by tourists that log their field notes after returing home the out of date 'logbook full' or whatever followed the maintenance not only once.

What are the dates of these NM and NA that are additionally triggered when logging something else? To me it would seem useless to have a NM dated for 2017-03-03 (because the Found it/DNF has that time stamp) for a NM that is actually posted on 2017-05-05. Who needs a NM two months later? Maybe the owner went three times to change a full logbook and replaced the container once in the meanwhile. Or think of geocaches that only get very few logs. Backdated NM let it look like 'there have been two NM months ago and the owner didn't react'. How could an owner know about a problem, if the message actually arrived five minutes ago? It does make sense to log NM at 2017-03-03 to alert owner and fellow geocachers and log Found it or DNF later whenever there is enough time to tell the complete story for the cache. That was possible until now. Some logtypes used to allow only 'today' (maybe +- one day for time zone issues) as log date. And it does make sense that with log types disable, enable, archive this is enforced to prevent chaos.

If NM and NA stays as sending a generic message with DNF or Found It, could you please at least insert a link to the corresponding log in the generic NM and NA logs to make it easier for owners and fellow geocacher to jump to the real message?

Eine etwas umständliche Lösung nur mit geocaching.com für Premium Members Schritt 1: Gleich nach DNF den Geocache auf eine Liste z.B. mit dem Namen "noch offene DNFs" tun. Die bereits länger zurückliegenden DNFs kann man mit https://www.geocaching.com/my/logs.aspx?s=1 anzeigen. Für die Geocaches, die da nicht mittlerweile einen gelben Smiley haben, könnte man das Listing öffnen und den jeweiligen Geocache auf die Liste "noch offene DNFs" setzen. Schritt 2 (nur einmal): Aus der Liste "noch offene DNFs" heraus eine Pocket Query mit für sich sprechendem Namen, z.B. "noch offene DNFs" erzeugen (die PQ muss man nicht extra laufen lassen) Schritt 3: Auf der Karte hat man neben dem Reiter Search auch einen Reiter Pocket Queries, dort kann man die entsprechende Query auswählen und die Caches werden dargestellt. Allfällig bereits gefundene werden mit Smiley dargestellt, aber die gehören eh aus der Liste "noch offene DNFs" wieder raus. Allfällig bereits archivierte Geocaches werden ausgegraut.

Have a look at the map and at some descriptions and logs of the geocaches of the places you want to visit before you go there to get a feeling what you can expect (listings in English/also in English/no English). Some owners write 'For english or french version, please contact me' etc. if their listing is in local language only. A lot of traditional geocaches don't require anything else than the coordinates in order to find them. You seem to prefer traditional geocaches, so no need to prepare for multi-caches, Unknowns and other non-traditional geocaches in advance. Sometimes spoiler pictures are quite essential for finding the geocache. Cell signal could easily be poor or almost non-existent when you need it for a cache in places where you really won't expect it. So I have an app that supports complete offline caching - offline maps and PQs or a database - at least as a backup. If I happen to have a local SIM-card/new European Union roaming regulations and data receiption or WLAN then I can refresh descriptions and look at pictures I might need. And I have google translate on my phone with offline stored dictionaries. For some languages don't expect too much from automatic translation, for example for Czech, especially if you want to see whether there is something helpful written in logs. Or what's the meaning of hints if they are more than simple words (magnetic, tree, corner, left, up etc.) or common cross-cultural references.

Auch keine Note in ein Found it umgewandelt? Oder nach dem Found it beim gleichen Cache einen anderen Log mit anderem Logtyp gelöscht?

Einen Reviewer kontaktieren, als Basic Member geht PMO-Status ändern nicht. "To change the PMO status, contact a reviewer, or contact Geocaching HQ. Be sure to send the email from the account that owns the listing and include the GC code." http://support.Groundspeak.com/index.php?pg=kb.page&id=285

Ontopic (nicht ganz ernst gemeint): Eine nette Ergänzung zum Templateloggen wäre neben den VUPs ein intelligentes Script, das von Logs wahlweise alles ausblenden kann, was sich auf andere Caches und das 'Gebietsbereinigen' allgemein bezieht. Und für Owner ein Zusatzfeature: Spoiler herausgefiltert in roter Farbe aus Fünffachdiamant-Log-Badge-200-Zeilen-Einheitslogs, damit man die nicht überliest. Offtopic: Das ist in vielen Gegenden reines Wunschdenken. Vielleicht, wo sonst nix ist an Caches und/oder keine Cacher oder wo sich die Cacher-Mentalität großteils nicht geändert hat zu früher. In Gegenden, wo es sich 'auszahlt' und daher leider leider entweder noch viele andere Caches am Tagesprogramm stehen und/oder bei Nicht-Tradis die Geschichte dank Koordinatenweitergabe auch bei den tollsten Caches leider leider teilweise bis ganz ausgelassen werden muss (wenn man das geloggte Pensum anschaut und weiß, wieviele Kilometer und Aufgaben das wären und was jedem auffallen müsste, der den Cache macht) und vielleicht sogar nur das Final besucht, weil effizient Punkte gesammelt werden müssen und Smilies auch für jedes Rätsel oder jede Wanderung oder jeden aufwändigen Gadgetcache hermüssen, weil die Karte nur Smilies haben darf ... ... kommen teils größere Gruppen/Logger nicht nur aus der Umgebung, sondern auch aus anderen Bundesländern und sogar aus Nachbarstaaten zu regelrechten 'Heuschreckeneinfällen' organisiert her (und da geht es nicht um Powertrails a la USA und den europäischen Pendants dazu) und .. .. haben dann viele Cacher einfach nicht viel zu berichten an erinnerlichen Erfahrungen außer 'mit xy endlich die Gegend bereinigt und lang gelöste Multis und Fragezeichen erledigt, natürlich Favoritenpunkt für die Tradiserie'. Wie auch, wenn es teils nur drum geht, zu loggen und selbst das lässt sich unter Umständen bei Bedarf auslagern, nicht nur das online-Loggen. Deswegen Einheitslog quer über alles, egal was. Und die Art zu cachen und zu loggen färbt so auf immer mehr Cacher ab, die von selbst gar nicht auf die Idee gekommen wären.

Vorab: Ich verwende bisher keinerlei Greasemonkey-Scripts oder Logtemplates und kenne daher nur die Logleserseite des (semi)automatischen Loggens. Hier habe ich mit Interesse gelesen von der Möglichkeit, die Logs von VUPs auszublenden, ein Feature, dass vielleicht eine Art Ausgleich zu den immer mehr überbordenden Automatik/Kurz/Template-Logs und zweifelhaften Loggewohnheiten mancher Cacher sein könnte. Es ist aber meiner Meinung nach sehr wohl ein nicht unbedeutender Zusammenhang zwischen "ich kann/will nicht vorschreiben, was zu tun ist" ist und gleichzeitig überhaupt erst die Möglichkeiten zu einem Logverhalten eröffnen, das 95% der Cacher sonst technisch nicht leicht zusammenbringen würden und (nicht) parallel beim Template hinweisen, dass Logs (auch) etwas über die Erfahrung mit dem Cache erzählen können/sollen und keine Spoiler enthalten sollen. Jetzt ist meiner Meinung nach aber der Zug sowieso längst abgefahren, weil die Templatelogger alles daran setzen werden, dass dieses Feature nicht wegkommt und dass kein Hindernis für sonst inhaltsleere, aber womöglich Badge-freundlich zeichenreiche Nur-Template-Logs eingebaut wird. Außerdem gibt es schon viele Apps/Scripts/Programme, die mehr oder weniger automatisiertes Loggen erlauben. Und ein dezenter Hinweis kommt wenn, dann höchstens bei Neucachern an. Die Vorbildwirkung ist halt irgendwie verheerend, weil sich ein großer Teil der Cacher, nicht nur die, die nicht mehr als TFTC sagen können/wollen, dieser Art Logs anpasst, weil das in der Masse einfach wie der Standard wirkt. Wenn sich jeder selber den Logautomatismus programmieren müsste, würden gefühlt 98% der Templatelogs wegfallen. Und ob nur TFTC dortsteht oder dazu auch Fundzähler, Fund x/y des Tages, Datum, Uhrzeit, AnzahlCachetage, "Danke an Variable:Owner fürs Auslegen und Warten" und "Gemeinsam mit Variable:Mitlistencacher", immer gleiches "die Tradirunde mit schon länger gelösten Rätseln und Multis abgerundet" und pauschales "schnell gefunden" und zwei Absätze Werbung/Signatur ist für alle anderen als den Logger selbst auch schon eher egal. Aber eben genauso erlaubt wie der Aufforderung auf der Webseite "Share your story with the geocache owner and community. Try not to leave any spoilers!" zu folgen, die Template-Logger nie zu Gesicht bekommen. Extrem aufgeblasene Logs, in denen mit 99% Wahrscheinlichkeit nur Inhalt aus Template-Vorgaben ist, sind trotzdem weniger leicht wegzublenden als TFTC. Offtopic: Und besonders ärgerlich finde ich dann, wenn die restlichen 1% Logs zusätzlich ausnahmsweise mal einen eigenen (Halb-)Satz enthalten und der gleich ein gedankenloser (oder absichtlicher?) Megaspoiler ist wie "in wirklich unmittelbarer Nähe zu ExtremBekannterPunkt", besonders beliebt bei aufwändigeren (Rästel)Caches mit D>=3,5

Um nochmal auf die Frage 'wird was ausgeblendet' zurückzukommen: https://coord.info/GLQCFZ9X und https://coord.info/GLQ6T2AC sind NAs von heute und von vor einem Monat und waren grad vorher jedenfalls eindeutig im Listing sichtbar, da sollte also nichts ausgeblendet sein.

Mit Link geht gelöschte Logs bei eigenen Caches lesen auf der Webseite tatsächlich, per API ist mir das irgendwie nicht gelungen. Aber was der Sinn sein soll ist mir nicht klar. Wenn eine Notification war, weiß der Owner ja sowieso, was drinstand und muss nicht im gelöschten NA nachsehen, oder überseh ich was?

Für Logs, die man selber geschrieben hat, kann man mit dem Link den archivierten Log aufrufen. Wenn man (als normaler User) versucht, gelöschte Logs anderer Cacher über den Link zu öffnen, kommt meiner Erfahrung nach doch nur: "You cannot read archived log entries." Es ist ja hier sowieso egal, wenn es eine Notification zum Needs Archived gab, gab es das NA und es wurde auch an den Reviewer geleitet, egal ob es jetzt gelöscht ist. Wenn das jetzt im Listing fehlt, kann der Owner immer noch schreiben "als Reaktion auf das mittlerweile gelöschte Needs Archive habe ich ...". Wenn wer glaubt, durch Löschen ein Needs Archived komplett ungeschehen zu machen, der hat sich getäuscht.

Vielleicht hat auch nur derjenige, der NA gepostet hat, später den Eintrag selber gelöscht. Aus welchem Grund immer (z.B. weil falscher Logtyp, weil das NA doch überzogen war oder der Reviewer schon benachrichtigt wurde beim NA-Log abschicken und nicht dauerhaft in den Logs zu sehen sein soll, wer NA gepostet hat oder oder, alles schon gesehen) Jedenfalls empfiehlt sich eine Reaktion, da sich jedenfalls ein Reviewer um das NA kümmern wird, auch wenn das Need Archived nicht mehr im Listing zu sehen ist.

You have to reply with the same email address the notification about the message was sent to. And at least for me that address is the primary one.

For the other case, dropping trackables there are different opinions. Loggers don't want to wait with dropping TBs because there are others that grab everything within hours but don't want to/can write a longer log immediately and 'log follows' is seen controversial too. So best solution to me seems to write a note for dropping trackables if you don't want a war of grab, re-grab and so on (and when you can't drop a trackable without a log to the cache page) and later delete that log and include the information in your later foundlog to keep trackable owners happy and let them see what happens to their trackables because on the other hand a lot of owners don't want their cache pages being cluttered by 'write notes' for trackables. That way seems to annoy the fewest possible group of cachers.

I would think that most geocachers that reuse the 'write note' change the log-date, keeping the previous story and only add the proof of the fulfilled challenge criteria. I don't own a challenge cache but I would prefer a write note for the visit with the date of visit AND a 'found it' log for 'completing' the challenge with the date of completing the challenge in case the geocacher 'can't wait' with a visit to the cache until the rquirements are met.

'Only Premium Members earn Favorite Points. They get one point just for being a Premium Member, then further points by logging geocaching finds, at the rate of 1 Favorite Point per 10 finds.' There have been differences between 1+floor(finds/10) and the actual number of favorte points for years for quite a number of users, even if they never logged a cache twice (to be correct: never left more than one 'found it' stand in case there were more than one by mistake or logging troubles on the website) and never logged an owned cache which might lead to an explanation of the difference. I'm at 3458 found it, no cache has more that one (not deleted) 'found it' and no owned cache is logged as 'found it', that would be 1+345=346 favorite points and another 2 finds till the next favourite point. But I have 'Logs Until Next Favorite Point: 5 and Total Favorite Points: 345', a difference of 13 finds that 'don't count'. There have been times when the difference was even higher, 16 finds. It might be correct if you never changed another log to 'found it', for example after first dropping trackables with 'write note' or 'write note' for challenges where you didn't meet the requirements at the time of your visit. I would think the system only looks whether a new log is a 'found it' and if yes, whether it is the 'first found it on this cache' (whether a 'first found it' that was already deleted before is considered or not, no idea). Maybe someone with plenty of favorite points who doesn't mind 'loosing' some of them wants to check whether (various theories I heard) logging a 'write note' and changing it later to 'found it' doesn't give you 1/10 favorite point (quite sure) logging a 'write note', then a 'found it' and later deleting the 'write note' makes you 'loose' 1/10 fav logging a 'found it' and deleting it later keeps your 1/10 fav in analogy to souvenirs, you used to keep them also if you deleted the corresponding log and the map showed the smiley in certain scales also for deleted logs logging two 'found it' and deleting the first later makes you 'loose' a 1/10 fav logging two 'found it' and deleting the second later makes you 'loose' a 1/10 fav and so on

From my today's caches one would expect this order of logs, the order I logged the caches and the order of log ids: GLPQAP4B = log id 650990372 Multi-cache1 1/4 GLPQB0R5 = log id 650999635 Multi-cache2 2/4 GLPQB2PR = log id 651001514 Unknown1 3/4 GLPQBCZP = log id 651011370 Multi-cache3 4/4 but it is ordered like this on the website GLPQAP4B = log id 650990372 Multi-cache1 1/4 GLPQBCZP = log id 651011370 Multi-cache4 4/4 GLPQB2PR = log id 651001514 Unknown1 3/4 GLPQB0R5 = log id 650999635 Multi-cache2 2/4 which makes it even more strange that I thought. All logs show Groundspeak:date 2016-11-13T20:00:00Z which is new (it is now 2016-11-13 18:40Z), but 20:00 might correspond to Seattle noon.

What is the new order in which the logs are displayed? Today I logged four caches via website (to avoid any mess with timezones etc.) multi1, multi2, unknown and multi3, the GL... numbers also seem to be in this order, but the website shows multi1 multi3 unknown multi2. The only thing I can imagine that GLPQB0(=zero)... is issued before GLPQBC... - digits before letters - and later displayed the other way round, letters before digits. If it is this, is it going to stay? That would be unfortunate. Edit: No, it can't be (only) that, there has to be something else.

The last one (from Germany) was very funny as it showed the obsession of the FTF-hunters. And some real geocachers indeed are not far from this stage of addiction to the game and are equipped with all tools you can think of. Although in the US something else than a bicycle would be the 'cachemobile' of choice. And here no one objected that it wasn't family-friendly enough for the children that were looking, apparently different Kulturkreis. Most plots were quite exaggerated like the '5 lesser known souvenirs' (altough there are real people acting like they want this souvenirs) and the turkish one and the muggle guide, but this is inherent to such clips, as is showing the finest adventures and the most impressive landscape (like the Japanese and Turkish clips).

Look at https://www.geocaching.com/seek/nearest.aspx?ul=rassilon256 without being logged in. What do you see? Cache names and some cache details. Logged in basic members can see more (also the date you logged the cache). And if someone has the link (coord.info/GL...) to your log on a PMO cache from whatever source they can read it also without being logged in at all.

It is not about hiding statistics at all. Home coordinates are not shown to others even if you have statistics enabled, only to yourself. GS choose not to show home coordinates to others than the user, also not to the checker system. And challenge checkers should work also if you are not the user who wants to show requirements are fulfilled. I've already logged such a challenge, a very old one. There the owner asked to mail gc-codes if one doesn't want to sent a screenshot of the statistics (which IS different if I look to what he sees) as dictance is shown only to the user, not to all others. But I don't see the reason for such a challenge, you can make it 'at least x km from here' which won't make too much difference for local geocachers or make it 'two caches at least x km apart' which also would bring similar results for most cachers having found a cache near home. Only the 'I have found only one x/2 from home in this direction and one x/2 from in the other direction' would fail the original idea. Discouraging challenges seems to be the goal in many quite questionalbe ways since opening for new challenge caches again, but this particular one was a no-go in most areas also before the moratorium. Edit: Home coordinates can be set to whatever you want for the purpose of fulfilling a challenge, so 'Find farthest from home' is an arbritary number, for others also not related to a certain cache as only distance is given, whereas distance between two find or dstance from a given point is not that easy altered.

I hope you're happy, especially since it's a cache 1000's of kilometers from where you are. Why the drama? Such challenges weren't allowed for quite a few years, at least not everywhere, altough in the guidelines there is only 'Challenge owners will need to make sure that cachers can show that they have completed the cache requirements without compromising their privacy' which includes not being forced to show home coordinates to everyone or the challenge cache owner. It seems that GS now suggests to set home coordinates to a spot you can reach within a few minutes. Of course project-gc's own statistics pages and GSAK and others can show 'furthest cache found (from home): x,xxx.xx km' for your username if you gave authorisation to access home coordinates on geocaching.com and if you have home coordinates set there. But does not show that information to anybody else if you don't publish it yourself. So 'must come from information broadly available on Geocaching.com such as on the statistics page, cache placement dates, types, attributes, souvenirs, etc. ... must be verifiable through information on Geocaching.com.' seems not to be fulfilled. Project-gc has in their 'read-first' section: 'The checkers does not have access to the user's home coordinates. Challenges are not allowed to be based upon them either, and haven't been allowed to for several years. This is a matter of integrity.' and the owner of the challenge in question was advised to ask a reviewer first whether it is allowed before using the checker based on project-gc statistics. But there are enough challenges that require 'a cache (at least) x km from this given point', for example the header coordinates or 'find two caches that are (at least) x km apart.' The challenge can be rewritten to something that is allowed anyway.