sbeelis

Öhm, woraus genau schliesst Du das? So wie ich das verstehe: machst Du mit bei einem Wettbewerb, bei dem Dir etwas zugeschickt wird, falls Du gewinnst, da ist es zwangsläufig nötig, dass Du deine Adresse angeben musst es ist eine TMNT Promotion, da finde ich 3-4 Fragen zu Deinem Verhältnis zum beworbenen Produkt verhältnismässig ich sehe nirgends einen Anhaltspunkt, dass andere, als die dort erhobenen Information verarbeitet oder geteilt werden es steht jedem frei dabei mitzumachen oder nicht, genauso wie Du bei jedem anderen Wettbewerb mitmachen kannst oder nicht (wenn ich mir so schaue, was für Informationen auf Papier-basierten "sende dies ein für eine Teilnahme", ist das recht vergleichbar) Und ja, genauso wie ich bei keinen papierenen "wir machen einen Wettbewerb um an deine Adresse zu kommen" mitmache, habe ich auch hier nicht mitgemacht. Abgesehen davon, dass solche Trackable Promotions bei den Spielern extrem beliebt sind und immer wieder kritisiert wurde, dass die meisten nur in den US laufen (schau Dir mal die öffentlichen Foren an), gibt es diese schon fast seit es TBs gibt (gewisse davon (z.B. Jeep) sind sogar regelrecht legendär), weshalb ich nicht ganz verstehe, wieso die aktuelle Promotion nun als "nochmals kommerzieller" gilt? Einfach weil Du die anderen (da auf die US beschränkt) gar nicht wahrgenommen hast?

15cm im Ruhezustand? Vielleicht muss ich doch mal auf eines dieser Spam-Mails reagieren ;-)

1) würde mich nicht stören, ist aber auch kein Bedürfnis meinerseits 2) keine Ahnung

Ihr habt ja sicher eine Kontaktadresse, mit welcher Euch mitgeteilt wurde, dass ihr 5 Labcaches erhalten habt. Ich schlage vor, dass ihr obiges Verhalten via diese Adresse ans HQ meldete, meines Wissens, sind sie in Seattle immer noch daran das ganze Lab Adventure Zeugs zu verbessern.

Hoi Paravan Danke für den Beitrag. Ich habe das gleiche Problem vor ein paar Monaten ebenfalls mit Suguru gelöst (und mit der schwarzen Variante, da ist sogar das Gehäusebild noch schön :-) Ich hatte damals statt fem Radiergummi auch den inneren Teil mit Suguru befüllt. Das funktioniert zwar, macht aber einiges an Kraft nötig, um den Schalter zu betätigen, von dem her ist deine Varianten sicher noch einen Zacken eleganter als meine.

Das ist eine gute Frage. Seit letztem Jahr erteilt Geocaching.com ja für vollständig abgeschlossene Geotours ein "Souvenir". Ich gehe davon aus, dass dort gilt gefunden ist gefunden. Wenn der Geotour betreiber natürlich basierend auf irgendwelchen "Codes", die in den Caches platziert sind noch ein separates virtuelles oder physisches Geschenk verteilt, würde ich diesen mal anschreiben und fragen, ob sie den alten Fund auch ohne Code akzeptieren, kannst ja den Link zu Deinem Fundlog mitschicken.

Das Problem ist, dass Geocaching.com nicht konsequent ist, wie es meldet, wenn ein Cache korrigiert Koordinaten hat. Es gibt verschiedene Kanäle (einzelnes GPX File vom Listing; Pocket Queries; Download/Refresh über das API). Je nach Kanal werden Originalkoordinaten oder korrigierte Koordinaten geliefert und je nach Kanal im letzteren Fall noch die Angabe, dass die Koordinaten korrigiert sind oder leider auch nicht. Deshalb hat GSAK je nach Kanal gar keine Chance zu erkennen, ob die gelieferten Koordinaten korrigiert sind oder nicht. Aus diesem Grund nutze ich dieses Feature auf geocaching.com prinzipiell nicht, sondern korrigiere die Koordinaten nur in GSAK, welches quasi mein "Datenmaster" ist. Falls Du zu diesem Verzicht nicht bereit bist, gibt es ein paar Methoden, die helfen, das Puff etwas zu lindern: lade die Caches nicht via PQ oder GPX File sondern nur via "Refresh/Get Geocache", meines Wissens kommen dort die korrigierten Koordinaten *UND* der Marker, dass sie korrigiert sind. in GSAK gibt es die Möglichkeit die Koords manuell zu korrigieren, dort gibt es zuunterst eine Anzeige zur Quelle der korrigierten Koords, mögliche Werte sind "gui" (manuell) oder "api" (via Refresh/Get Geocaches). Wenn Du das manuell machst, wird Quelle "gui" gesetzt, die wird *NIE* überschrieben, so kannst Du sicherstellen, dass sie immer als korrigiert gelten. Es reicht dazu, das Fenster zu öffnen und mit OK zu schliessen. Wenn die korrigierten Koordinaten also geliefert aber nicht markiert wurden, kannst Du die Markierung so manuell nachführen. Ist aber natürlich Mühsam.

Grundsätzlich ist der Weg, das in den offiziellen Foren zu diskutieren der richtige, allerdings ist es so wie Dave schreibt: häufig führt dies leider zu nichts. Reviewer haben prinzipiell schon einen direkten Draht ins HQ, allerdings nur ins "Community Volunteer Team", welches sich um die Zufriedenheit und die Tools der Reviewer kümmert. Bei den Features für "normale" Cacher/Owner hat das CVS offiziell keinen Einfluss. Ich habe dieses Anliegen mal ans CVS gemeldet, mit der Bitte, dies dem entsprechenden Produktteam weiterzuleiten, kann aber genau nichts versprechen bezüglich Wirkung :-)

Grundsätzlich gilt folgendes:

Ich bin ja nicht Earthcache Reviewer (das machen unsere deutschen Kollegen für die Schweiz mit). Ich kann mich deshalb nicht zu den Details äussern, aber mein Verständnis war folgendes: EC Owner dürfen nicht verlangen, dass man die Antworten zuerst schickt und dann auf eine Logfreigabe warten muss. Es muss einem Cacher erlaubt sein zu Loggen und "quasi gleichzeitig" die Antworten per Mail oder das Message Center an den Owner zu schicken meines Wissens ist nicht genau definiert, was unter "quasi gleichzeitig" zu verstehen ist. Ich handhabe das so, dass ich jeweils zuerst die Antworten schicke und dann gleich Logge, aber ohne auf eine Antwort zu warten; es wäre aber sicher auch erlaubt, zuerst zu loggen und dann die Antworten zu schicken (ob die Zeit dazwischen eher einige Minuten bis Stunden liegen darf oder ob das sogar mehrere Tage sein dürfen, ist mir nicht bekannt) wie gesagt, entspricht das nur meinem Verständnis, bitte behaftet mich nicht darauf, das ist definitiv nicht das Gebiete meiner Expertise Im vorliegenden Fall ging es ja aber nicht darum, ob/wann die Antworten gesendet wurden, sondern dass der Owner die Antworten als nicht ausreichend betrachtet wurden. WIe hier der genaue Prozess aussieht, weiss ich auch nicht und die von Sechsfüssler zitierten Antworten aus dem HQ stiften hier offenbar eher Verwirrung als der Klärung zu dienen Eine kleine lustige Anektote am Rand: ich habe vor 2 Wochen eine Antwort eines Owners erhalten, der mir zu den korrekten Antworten gratuliert hat, und zwar für einen EC, den ich vor mehr als 10 Monaten geloggt hatte ;-)

Das Groundspeak Tool beim erstellen von neuen Caches zeigt grundsätzlich nur Tradis an. Mystery und Multi Caches werden dort nie angezeigt, egal ob Du dazu korrigierte Koordianten eingegeben hast oder nicht. Du kannst allenfalls im offiziellen Forum einen "Feature Request" erstellen, ab und zu werden die aufgenommen, eine Garantie gibt es aber nicht. Alternativ zu Flopp's Karten kannst Du die Lösungen von Mysteries und Multis auch in GSAK erfassen und dort dann mit den entsprechenden Makros die 161m Kreise anzeigen lassen. Damit mache ich seit Jahren gute Erfahrungen.

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.