sbeelis

Schön, dass es zum Podcast so viele Rückmeldungen gibt. Zu den Fragen @Attila_G wie Paravan schreibt, der Health Score wird in den Listings nicht angezeigt (den sehen nur die Reviewer). Aber wenn einer deiner Caches unter einen bestimmten Gesundheistwert sinkt, solltest Du ein Mail erhalten und den Cache wie im Screenshot von Paravan oben angezeigt kriegen). @mrradach Danke für den Hinweis, wo das "Report a problem" in der App zu finden ist. Ihr seht, ich brauche diese nicht oft :-) @Attila_G & @fankido: Grundsätzlich ist es so, dass Caches ohne aktiven Owner ins Archiv gehören. Die Reviewer "jagen" aber Caches mit inaktivem Owner nicht aktiv. Das heisst, so lange bei einem solchen Cache nichts negativ auffällt, wird der durch uns nicht archiviert. Wenn sich Leute also zur Fremdwartung entscheiden und immer schnell genug reagieren, so dass der Cache nicht bei den Reviewern aufschlägt, kann es durchaus sein, dass er eine ganze Weile überlebt. Wenn ein solcher Cache aber mal disabled wird, dann kann er nur noch durch den Owner enabled werden; in dem Fall ist das Archiv dann nur noch eine Frage der Zeit. Ich hoffe, dass damit meine Aussagen im Podcast und die offizielle Haltung der Reviewer wieder besser zusammenpassen. Solltet ihr weitere Fragen haben, freue ich mich diese hier weiter zu beantworten.

@Paravan das stimmt gleich mehrfach nicht: Du hast mit dem neuen API 10'000 light calls zur Verfügung (gleich wie vorher) und 16'000 full calls (gegenüber bloss 6'000 vorher) (https://api.groundspeak.com/documentation#get-geocaches; https://api.groundspeak.com/documentation#restrictions) Du kannst die erzeugten PQs nach wie vor über das API als ZIP file herunterladen (dafür mussten sowohl der GSAK Autor als diverse Reviewer hart mit dem HQ kämpfen, damit das im neuen API wieder möglich wurde, anfangs war das nämlich nicht so). Ich bin nicht mal sicher, ob das 1 Call pro PQ kostet oder sogar gar keinen. (https://api.groundspeak.com/documentation#get-pq-zip) Beides wird von GSAK unterstützt und geht mit dem neuen API. Falls das mit iCaching (noch) nicht möglich ist, liegt es wohl eher daran, dass dessen Autor das noch nicht nutzt, als dass es mit dem API nicht geht.

Ich habe seit Jahren ein Montana 600 und bin damit äusserst zufrieden, mir gefällt vor allem die Grösse des Bildschirms und bin deshalb auch bereit ein etwas grösseres Gerät mit mir herumzutragen. Wenn ich auf ein anderes Modell umsteigen würde wäre es wohl das Montana 610 (ich brauche keine Kamera). Das Monterra wäre für mich nie in Frage gekommen, gerade weil es Android als OS hatte. Nebst der Grösse des Bildschirms schätze ich nämlich auch die lange Batterielaufzeit (mit einer Akkuladung hält mein Monti auch nach Jahren immer noch 8-10 Stunden) und ich immer skeptisch war, ob ein GPS mit Handy-OS dann auch die magere Akkulaufzeit eines Handys haben würde...

Das überrascht mich, denn Clyde, der Entwickler von GSAK wusste das in der Tat schon seit einem Jahr und hat die neue API Version bereits im Spätsommer 2018 zum Test als Option in GSAK bereitgestellt. Evtl. hat Geocaching.com die Partner in der Reihenfolge der "Grösse" angeschrieben, das heisst, zuerst die Parter, deren Applikation die meisten Nutzer haben und die kleineren später... Anders kann ich mir den Zeitunterschied fast nicht erklären.

Heute wurden die 4000 Virtual Rewards verlost. Folgende Daten haben wir Reviewer vom HQ erhalten: 18,527 geocachers opted in 22% of opt-ins received a Virtual Reward 75 countries are represented 27 community volunteers Most countries received *more* Virtuals, compared to Virtual Rewards 1.0 Wie viele Virtuals wir in der Schweiz erhalten haben, weiss ich aktuell nicht (da diese per Default alle ihre Koordinaten in der Nähe von Seattle haben), aber ich habe gesehen, dass mindestens 3 der neuen Owner ihre Koordinaten bereits in die Schweiz verlegt haben. Mal schauen, wie viele noch dazukommen ;-) Herzliche Gratulation auf jeden Fall allen glücklichen Gewinnern!

Zur Höhe gibt es folgendes zu sagen: GSAK verwendet zwei Felder zur Abbildung der Höhe: "Elevation" und "Resolution". Im Feld "Elevation" steht die effektive Höhe drin. Da "0" eine gütlige Höhe ist (Caches auf Meereshöhe), kann dieser Wert nicht hinzugezogen werden, um zu erkennen, ob die Höhe für einen Cache bekannt ist oder nicht. Dazu dient das Feld "Resolution". Dort steht - nach erfolgreich aktualisierter Höhe - drin, wie genau der "Höhenwert" ist. In Meiner Datenbank habe ich dort folgende Werte gefunden: 3m, 10m, 30m, 90m, 1000m, USER sowie "leer". Wenn das Resolution-Feld leer ist, heisst dies, dass für diesen Cache die Höhe noch nie abgefragt wurde. Steht dort eine Zahl drin, heisst dies, dass die Höhe für diesen Cache bereits einmal abgefragt und gesetzt wurde. Steht dort "USER" drin, heisst es, dass man mit Waypoint->Edit die Höhe manuell gesetzt hat. Im "Update Elevation" Dialog gibt es zwei Optionen. Wählt man "Only if missing", so werden nur jene Caches aktualisiert, welche ein leeres "Resolution" Feld haben. Wählt man "Always" so wird die Höhe aller Caches aktualisiert, welche *nicht* "USER" im Resolution Feld haben. Wenn Du nun also Caches hast, deren Höhenwert "0" ist und Du der Meinung bist, dass dies nicht stimmt, schau doch mal, was im entsprechenden "Resolution" Feld steht. Falls dieses nicht leer ist, kannst Du ja mal auf diese Caches Filtern und dann mit "Database -> Global Replace" das "Resolution" Feld auf "leer" setzen (unbedingt vorher Filtern!) und danach den Elevation Update mit "Only if missing" noch einmal laufen lassen. Ich habe in meiner Datenbank 17 Werte mit Höhe 0 gehabt: 10 Lab Caches (die ich manuell erfasst hatte) und 7 Caches in Meeresnähe. Ich habe auf allen 17 die Resolution von 90m auf leer gesetzt und ein Update ausgeführt. Danach waren es noch 7 Caches mit Höhe 0 (nämlich die in Meeresnähe), die 10 Lab Caches hatten nachher korrekte Höhen.

Ja :-) Wenn Du im Tab "Page 2" auf den Button "Settings dialog" klickst, öffnet sich das gleiche Fenster, wie beim Laden von GPX Files. Dort kannst Du die 3 Parameter einstellen und dann unter einem bestimmten Namen speichern. Danach kannst Du diese gespeicherten Einstellungen in der Dropdownliste links des Buttons auswählen. Et voilà. Ich verwende folgende beiden Settings überall, wo ich Caches lade (GPX File laden, Get Geocaches, PQ herunterladen, Refresh). Sie unterscheiden sich nur darin, ob ich das Summary anzeige oder nicht:

Die Methode von Mausebiber hilft Dir, die Caches, die Du bereits in der DB hast mit Höhen zu versehen. Wenn Du sicherstellen willst, dass die Höhendaten immer gleich aktualisiert werden, wenn Du neue Caches zur DB hinzufügst, kannst Du bei den Load-Settings folgende Konfiguration verwenden: Die rote markierten Werte stellen folgendes sicher: County update: BY -> falls ein Cache keinen Wert für das "County" hat, versucht GSAK das anhand eigener Polygone zu aktualisieren (in der Schweiz sind dies die Kantone) State update: SB -> falls ein Cache keinen Wert für das "State" Feld hat, versucht GSAK das anhand eigener Polygone zu aktualisieren (in der Schweiz sind dies seit ca. 1 Jahr ebenfalls die Kantone) Elevation: M -> falls ein Cache keinen Wert für die Höhe hat, versucht GSAK durch eine Anfrage beim GSAK Server (und damit indirekt bei verschiedenen Geo-Servern) die Höhe abzufragen und zu setzen (gleich wie es die Lösung von MB tut). Ich empfehle, immer mit diesen drei Werten zu arbeiten.

Nicht wirklich. Unter folgender URL habe ich diesen Satz gefunden: https://www.geocacherscompass.com/cachly-geocaching-app/ Keine Ahnung, ob es dabei um dieses Feature geht.

Das wird wohl ein Geheimnis des Frosches bleiben :-)

Ich sehe das häufig als Reviewer. Immer wieder werden Caches eingereicht, welche kaputte Hintergrundbilder haben, weil die Leute die URL der Seite einfügen, welche einem das hochgeladene Bild anzeigt, als die URL das Bildes selbst. Das ist nicht ein technisches Problem, sondern eines mangelndes Wissens von Seiten der Cache Owner (ohne jemanden all zu fest auf die Füsse treten zu wollen :-)

Es zwingt dich ja niemand bei der Lotterie mitzuspielen. Entgegen Deines Kommentars ändert sich doch einiges am Prozess im Vergleich zum letzten mal: beim letzten mal hatte Geocaching.com einen Algorithmus entwickelt, mit dessen Hilfe sie die "besten Cache Owner" identifizieren wollten. Wie gut ihnen das gelungen ist kann man durchaus diskutieren. In der Schweiz wirbelte das relativ wenig Staub auf, aber in gewissen anderen Ländern, führte das zu ziemlich viel Unruhe, weil dort die Auswahl (oder vor allem nicht-Wahl) bestimmter Leute von der Community sehr kritisch angeschaut wurde. dieses mal wird einfach mit dem Würfel bestimmt, wer einen kriegt beim letzten mal war der Algorithmus geheim (nicht mal wir Reviewer kannten ihn, auch nicht im Nachhinein) diesmal sind die Minimalkriterien transparent aufgeführt beim letzten mal wurden die Owner automatisch ausgewählt, darunter auch recht viele, welche gar nicht mehr aktiv sind, entsprechend wurden auch nur 2/3 der verteilten Virtuals effektiv genutzt diesmal ist es ein "Opt In", bei dem interessierte und sich qualifizierende Owner anmelden können. So sollen nur solche Leute einen Virtual erhalten, die auch Interesse haben und diesen dann hoffentlich nutzen werden beim letzten mal wurden sehr viele Owner aus den etablierten Ländern gewählt (da dort die ausgefallenstend und somit qualitativ hochstehendsten Caches gelegt werden), was kleinere Länder eher benachteiligt hat diesmal sollen gezielt Länder gefördert werden, in welchen Geocaching noch eine "neue" Beschäftigung ist und in denen es noch keine oder nur wenige Virtuals gibt Wir werden sehen, wie sich das bewährt. Die letzten Virtual Rewards sind bei den Cachern auf jeden Fall gut angekommen und das HQ scheint aus den Fehlern/Kritikpunkten des letzten Mals ihre Lehren gezogen zu haben.

Genau, es gibt "Minimalkriterien", welche entscheiden, ob man sich bewerben kann oder nicht. Falls man sich bewerben kann, hat man die gleiche Chance, wie alle anderen aus der gleichen Region, die sich beworben haben. Ich habe geschrieben "aus der gleichen Region", weil das HQ diesmal die Gebiete, in welchen Geocaching noch nicht so etabliert ist und wo es heute keine oder nur sehr wenige Virtuals gibt, etwas bevorzugen will. Ich kenn die Regionen nicht genau, aber um ein fiktives Beispiel zu nehmen: Die Chance für einen Ukrainischen Cacher, der sich beworben hat, einen Virtual zu gewinnen wird höher sein, als für einen deutschen oder schweizer Cacher, aber die Chance für alle ukrainischen Cacher wird gleich sein und die Chance für alle schweizer/deutschen Cacher unter sich wird gleich sein. Wie die Regionen aufgeteilt sind und welche Regionen wie gewichtet werden ist mir nicht bekannt, das wird das HQ wohl für sich behalten. Aber im Gegensatz zum letzten mal gibt es keinen geheimen Algorithmus, welcher die Gewinner auswählt, es wird rein das Los entscheiden (abgesehen von den Minimalkriterien für die Bewerbung). Edit: lest den von Znuk verlinkten Blog-Post, er erklärt all das, was ich oben beschrieben habe, viel besser ;-)

Ich kann bestätigen, dass dies in der Tat ein Übersetzungsfehler ist und dem HQ bereits gemeldet wurde. Dieser sollte demnächst korrigiert werden.

Zur Zeit meines Wissens nicht und wenn, dann wäre das ein Entscheid, der von Clyde gefällt werden müsste. Ein Hindernis wäre dann wohl das Geocaching.com API, da dort jede Applikation einen Applikations-spezifischen, geheimen Schlüssel hat. Mit der Umstellung auf OpenSource wäre dieser Schlüssel dann nicht mehr geheim und somit eine Verletzung der API Vereinbarung. Soweit ich weiss, ist dies einer der Gründe, wieso c:geo nach wie vor "Web site scraping" macht, statt das API zu nutzen, weil Geocaching.com ihnen (da OpenSource) keinen API Schlüssel ausstellen will (mit vorbehalt zu lesen, ich bin da nicht im Detail informiert).

Clyde hat schon vor ein paar Monaten verkündet, dass er wegen seines Schlaganfalls keine Weiterentwicklung mehr machen kann, sondern nur noch Bugfixes. Diese hat er nach wie vor geliefert (wenn auch mit einer etwas längeren Verzögerung als wir uns vorher gewöhnt waren). Den Schritt GSAK als Freeware anzubieten hat er wohl gewählt, weil er sich nicht dafür hält von Benutzern Lizenzgebühren zu kassieren, ohne zu wissen, wie lange/wie gut er den Support noch gewährleisten kann. Er hat aber auch erwähnt, dass er plant weiterhing Bugfixes zu liefern - wenigstens so lange es noch geht. Das entspricht dem Modus der letzten Monate. Selbst wenn er nicht mehr in der Lage sein wird, Bugfixes zu liefern, wird GSAK sicher weiterhin noch viel Wert liefern. Die Grundfunktionalität ist seit Jahren erprobt und stabil. Der Bereich, in dem wir wohl am ehesten mit Problemen/Änderungen zu rechnen haben, ist die Anbindung von geocaching.com via dem API. Aktuell geht hier die Umstellung vom alten zum neuen API zu Ende und GSAK hat hier den grössten Teil der Kinderkrankheiten wohl schon ausgemerzt. Ich kann mir vorstellen, dass Geocaching.com allenfalls in den nächsten Monaten (das alte API wird in drei Wochen abgestellt) noch aufgrund der Erfahrung, wenn alle Applikationen auf das neue API umgestellt haben, Kleinigkeiten nachbessern/anpassen werden. Hoffentlich wird Clyde - soweit überhaupt nötig - in der Lage sein, diese Anpassungen im Rahmen von Bugfixes nachzuziehen. Wenn sich das stabilisiert hat und geocaching.com hoffentlich das neue API einige Jahre unverändert laufen lassen wird, sollte GSAK in seiner Gesammtheit wohl recht stabil laufen. Ernsthafte Fragen werden wir uns erst stellen müssen, wenn Geocaching.com das aktuelle API durch die nächste Generation ersetzen wird, was hoffentlich erst in vielen Jahren der Fall sein wird.

Hm, ich scheine leichtgewichtig unterwegs zu sein. Wenn es nicht eine explizit geplante Tour ist, bei der ich ungewöhliches erwarte habe ich folgendes dabei: Kugelschreiber Sackmesser mit Pinzette

Ausserdem hast Du mit Deinem Benutzernamen ja eigentlich ein Freipass diese Tipps zu ignorieren ;-)

Mit hat damals https://coord.info/GC2Y7RV sehr gut gefallen. Nicht so sehr weil es ein speziell guter Cache ist (ist es nicht), sondern weil das bis heute immer noch das dreisteste, frechste Versteck ist, das ich je angetroffen habe. Ist allerdings 8 Jahre her, ich habe keine Ahnung, ob der immer noch gleich versteckt ist. Der Klassiker (auch wenn MB und ich offenbar ein unterschiedliches Verständnis von Biologie haben ;-) ist wohl https://coord.info/GC13Y2Y, der erste - und bislang meines Wissens einzige - Cache mit mehr als 10'000 Favoritenpunkten. Da kannst Du allerdings unter Umständen deutlich mehr als eine halbe Stunde verbraten, wenn Du nicht grad Glück hast. Von den anderen aus der Liste von MB Haben wir die "alten" Virtuals gemacht und fanden die beide recht gut, die neuen gab es damals noch nicht. Die beiden Earth Caches hatten wir ebenfalls besucht, der am Brandenburger Tor ist ok, aber der mit den Granitkugeln hat uns sehr gut gefallen. Die alte Abhörstation passt vermmutlich eher nicht in Dein Programm (https://coord.info/GC2NMFP), da er etwas ausserhalb ist, der Cache selbst ist eine Durchschnittsdose, der Lost Place direkt daneben (falls es nach wie vor ein LP ist nach all den Jahren), ist aber fantastisch. Selbst anschauen ging damals nicht, aber man konnte "halbgeführte" Touren machen (https://teufelsberg-berlin.de/content/7-fuehrungen). Auch gut gefallen haben uns die Höfe bei https://coord.info/GC5JC61, der Cache selbst ist nichts spezielles, zeigt einem aber einen schönen Ort, an den wir sonst wohl kaum gekommen wären.

Challenges sind nur zulässig, wenn die Erfüllungskriterien anhand der Informationen auf geocaching.com geprüft werden können. Da es kein Attribut für Leitercaches gibt, hatte ich gesagt, dass ich nicht sehe, wie das möglich wäre, worauf Znuk vorgeschlagen hatte, man könnte prüfen, ob im Namen "Leiter" vorkommt. Deshalb meine Entgegnung, dass der Titel kein zulässiges Kriterium ist. Ich sehe deshalb nach wie vor keine Möglichkeit, wie ein "10 Leitercache Challenge" aktuell publikationsfähig ist. Die von Dir im anderen Post erwähnten Challenges (ABC, Vollmond, FIguren) sind nach den aktuellen Challenge-Guidelines wie Du korrekt erwähnst nicht mehr möglich. Sie wurden alle vor dem Moratorium publiziert. Die Möglichkeit einen Checker zu schreiben ist übrigens *notwendiges* aber nicht *ausreichendes* Kriterium. Es ist durchaus möglich, Checker für Challenges zu schreiben, die den anderen Anforderungen nicht genügen, das hilft dann leider auch nichts.

Falls eine Guideline-Konforme Challenge etwas gar "weit hergeholt" scheint, können wir Reviewer vom Owner den Nachweis erfragen, dass es ausreichend lokale "qualifizierende Cacher" gibt. Als Anzahl für "ausreichend" hat HQ im allgemeinen die Zahl von 10 Cachern gestützt. Wenn also effektiv nur 1-2 Cacher die Challenge erfüllen, kann das unter Umständen ein Ausschlusskriterium sein.

Was möglich ist und was nicht, fasst die Challenge Cache Seite im Help Center zusammen https://www.geocaching.com/help/index.php?pg=kb.chapter&id=127&pgid=206 Die obigen beiden Beispiele sind beide nicht möglich: Der Titel als Kriterium wird im Punkt 10 (https://www.geocaching.com/help/index.php?pg=kb.chapter&id=127&pgid=206#criteria) explizit ausgeschlossen Da die Geocaching.com Seite FTFs nicht als Statistik oder Attribut führt, ist das ebenfalls nicht zulässig

Das sehe ich genau so wie Du. Für mich es deshalb so, dass ich Challenge-Caches *nicht* verwende, um mir Ziele zu setzen, sondern einfach schaue, welche ich bereits erfülle und diese dann quasi als D1-Rätsel behandle und jene, die ich nicht erfülle einfach ignoriere. Meine Geocaching-Ziele setze ich mir dann selbst, unabhängig davon, ob es dazu einen Challenge-Cache gibt oder nicht.

Das ist jetzt grad nicht so ein gutes Beispiel, weil es gemäss aktuellen Challenge-Guidelines nicht erlaubt wäre. Da es keine Möglichkeit gibt, zu erkennen, ob ein Cache ein "Teleskopleiterncache" ist, kann dafür kein Checker geschrieben werden und somit ist der Challenge nicht zulässig. Wenn Du stattdessen "10 T5-Caches" schreibst, funktioniert das Beispiel ;-)

Ich kann zu dieser Frage aus zwei Sichtweisen etwas sagen: Als Reviewer bin ich dankbar für die durch das Moratorium viel klarer formulierten Regeln, weil wir so klare Angaben machen können, was erlaubt ist und was nicht und wir uns keine Gedanken machen können, ob ein Challenge "gut" ist oder nicht. Als Spieler halte ich es wie Riepichiep und andere: liegt in einem Gebiet in welchem ich Cache ein Challenge-Cache, schaue ich vorgängig, ob ich ihn erfülle, wenn ja, besuche ich ihn evtl., wenn nein ignoriere ich ihn. Geocaching-Ziele setze ich mir selber und nicht wegen Challenges. Ehrlich gesagt, finde ich ganz viele Challenges (sowohl als Spieler wie auch als Reviewer) absolut doof, häufig dünkt es mich, dass es nur ums prahlen geht "kuckt mal, was ich geschafft habe". Aber es gibt ja auch viele normale Rätsel oder viele Tradis die ich doof finde. Als Reviewer publiziere ich die genauso mit der Nasenklammer und als Spieler steht es mir frei, diese zu ignorieren.