sbeelis

Damit bin ich nicht einverstanden. Ich brauche seit einem guten Jahr mein iPhone 4 zum Cachen und bin damit im grossen und ganzen sehr gut gefahren. Was ich vor allem Schätze, sind die online Satellitenkarten (halt nur solange eine Datenverbindung da ist). Zur Eignung des iPhones 3GS kann ich mich nicht äussern, das kenne ich nicht. Da bin ich hingegen wieder einverstanden. Ich kann mir nicht vorstellen, dass es eine GPS Maus gibt, die den Empfang des iPhone 4 (so es diese überhaupt unterstützen würde) verbessern. Ich habe als Zweitgerät ein occasions eTrex Vista HCx erstanden, welches ich mit OSM Karten befüllt habe. Ich brauche dieses vor allem für Caches im Wald, das ist die einzige Situation, wo der GPS Empfang des eTrex deutlich besser ist als jener des iPhone 4.

Schade, dass Du Deine Caches alle archiviert hast. Ich habe mir die Logs dieser 17 Caches kurz angeschaut. Bei den meisten waren ja nur positive Logs drin. Ich habe einzig bei folgenden mässig kritische Logs gefunden: GC36WJF: Bahnhof Hunzenschwil Vielen Dank fürs auslegen eines weiteren der heute vielen sehr nahe beieinander liegenden. Nun sind es inzwischen 10 R.....P..... vom gleichen Owner (der es wahrscheinlich nicht weiss und nichts dafür kann). Haben die Guidlines geändert E Gruess und Dank auch an den Reviewer Dieser Eintrag ist editiert worden, ich weiss deshalb nicht, ob da usprünglich etwas "deftigeres" drinstand, aber so wie es hier formuliert ist, finde ich das absolut ok als log. GC31VDJ: TiLiHu's first of Biberstein Hier gab es ein paar durchaus höfliche Logs, die darauf hinweisen, dass die Logger den D-Wert eher höher ansetzen würden (z.B. "Wir würden hier die Difficulty allerdings auf zwei Sterne setzen, denn so offensichtlich ist der nicht zu finden"). Dann gab es ein paar höfliche DNFs, sowie ein Found, der auf den nassen Log und die undichte Box hinweisen ("Haben erst zuhause gesehen, dass der Cache den wir heute gefunden haben, momentan nicht auffindbar sein soll. Kein Wunder, er war ja auch sehr gut versteckt - habe mir bei der Bergung beinahe den Arm gebrochen. Das Logbuch ist völlig durchnässt, da die Dose nicht wasserdicht ist. Haben versucht, den Cache (hoffentlich) wieder ordnungsgemäss zu platzieren.") GC31VDJ: TiLiHu's Binzen-Multi Das ist der einzige Cache, bei dem es ein paar ungehaltene (aber meiner Meinung nach immer noch höfliche) Logs gab, da es offenbar bei der Publikation einen Fehler im Listing hatte und einige Posten sehr schwer zu finden waren. Nach Deiner Wartung am Listing kamen dann nur noch positive Logs. Bei allen anderen Caches habe ich ausschliesslich positive Logs lesen können. Ich weiss nicht, welcher Log/welche Logs Dir so in den falschen Hals gekommen sind, dass Du deswegen alle 17 Caches archiviert hast. Natürlich ist es Dein Recht als Owner, das zu tun. Da Du das hier aber so demonstrativ verkündet hast, muss ich jedoch schon sagen, dass ich das nicht nachvollziehen kann. Gemessen an den Logs, die ich bei deinen Caches sehen konnte, hätte ich mit gewissen Logs, die ich für meine schon Erhalten habe, meine schon längstens schliessen müssen. :-) Allenfalls brauchst Du eine etwas dickere Haut, um berechtigte Kritik nicht persönlich zu nehmen, sondern als Chance Deine Caches zu verbessern und unberechtigte Kritik an Dir abprallen zu lassen... Vielleicht überlegst Du Dir es ja nochmals.

Kein Tracker, aber falls Du ein iPhone hast, gibt es die Rega App. Mit der kannst Du im Notfall automatisch die Rega anrufen inklusive Übertragung Deiner aktuellen Position. Funktioniert halt auch nur mit Handy-Empfang und geht nicht um Deine Familie zu orientieren, aber "für mittem im Wald mit gebrochenem Bein" sicher nützlich...

Negative Logs erfordern Fingerspitzengefühl, sowohl als Finder, wie auch als Owner. Ich habe gerade gestern 4 von 5 Funden aus muffeligen Plastiksäcken herausgrübeln müssen. In 3 von vier Fällen total unnötigerweise, weil die Lock'n'Lock Dosen auch ohne absolut dicht wären. Ich habe das in meinen Logs kommentiert, aber versucht höflich zu bleiben und auch erwähnt, was mir am Cache trotzdem gefallen hat. Ich hoffe, dass die Owner das im konstruktiven Sinn aufnhemen, in dem ich es geschrieben habe. Andererseits habe ich auch schon Logs gehabt, die sich zurückhaltend bis offen aggressiv an einem Cache gestört haben, den ich gelegt habe. In den zurückhaltenden Momenten nehme ich das zur Kenntnis und überlege mir dann, ob es eine Änderung benötigt oder nicht. Beim - bisher einzigen - offen aggressiven Log habe ich mich beim Owner gemeldet und ihn höflich darauf aufmerksam gemacht, dass ich durchaus Kritik ertrage, aber seinen Ton etwas unpassend fand. Er hat dann - ohne, dass ich ihn explizit dazu aufgefordert habe - seinen Log in einem gemässigteren Ton neu formuliert und wir haben danach noch 2-3 Mails ausgetauscht, über Sinn und Unsinn bestimmter Verstecke, alles ganz freundlich. Ich denke, es ist bei Kritik immer wichtig möglichst höflich und sachlich zu bleiben, so dass der/die Kritisierte sich nicht persönlich angegriffen fühlt, weil sie dann aus der Defensive heraus kaum auf den Inhalt der Kritik eingehen können. Es gab bisher einen einzigen Cache, wo Koordinaten, Hint und Versteck so weit auseinanderlagen, dass die Leute in einem riesen Umfeld suchten und es richtig wüste Cacherautobahnen gab. Damals habe ich dem Owner eine PM geschickt sowie eine Note geschrieben (auf beides hat er nie reagiert) und mir einen NA Log überlegt und es dann bleiben lassen. Heute würde ich den NA vermutlich loggen.

Also, ich halte meine Schweizer DB wie folgt up-to-date: 16 Pocket Queries, welche die ganze Schweiz abdecken. Diese erstelle ich nach folgenden Kriterien: - Run this query every week on the days checked - Show me 1000 caches - any type - any container - (manche Leute beschränken das noch auf "[x] I haven't found", aber ich behalte meine Funde gern in der DB, drum habe ich das nicht limitiert) - within countries = Switzerland - from origin = none selected - placed during <von> and <bis>, siehe dazu weiter unten Dadurch, dass man nicht geografisch, sonder nach Platzierungsdatum staffelt, hat man die Garantie, dass es keine Überlappungen und keine Lücken gibt und die PQs nie mehr als 1000 Caches enthalten. Meine Staffelung sieht wie folgt aus: Schweiz_01__2000-01-01__2005-11-15 Schweiz_02__2005-11-16__2006-11-15 Schweiz_03__2006-11-17__2007-09-03 Schweiz_04__2007-09-04__2008-05-08 Schweiz_05__2008-05-09__2008-11-04 Schweiz_06__2008-11-05__2009-05-20 Schweiz_07__2009-05-21__2009-09-12 Schweiz_08__2009-09-13__2010-02-12 Schweiz_09__2010-02-13__2010-05-31 Schweiz_10__2010-06-01__2010-09-08 Schweiz_11__2010-09-09__2010-12-30 Schweiz_12__2010-12-31__2011-03-26 Schweiz_13__2011-03-27__2011-05-27 Schweiz_14__2011-05-27__2011-08-02 Schweiz_15__2011-08-03__2011-10-12 Schweiz_16__2011-10-13__open Ich hatte die so gewählt, dass es genau die Tage waren, damit das PQ gerade nicht 1000 überschreitet. Mit jedem archiviertem Cache werden die Queries nun kleiner, das letzte, offene wächste immer und wenn es 1000 überschreitet terminiere ich es und starte ein weiteres offenes. Ab und zu sollte ich wohl die Datumsbereiche überarbeiten, um nicht unnötig viele Queries zu haben, dazu war ich bisher aber noch zu faul. Ich habe die Ausführungsdaten so gestaffelt, dass ich ab Sonntag jeden Tag 3 davon ausführe. Das lässt mir Platz auch ab und zu andere Queries laufen zu lassen. Das offene Query läuft 2x pro Woche, die anderen 1x. So habe ich bis am Freitag jedes mindestens einmal ausgeführt. Diese Queries lade ich in GSAK V8 mit "PQ Download" direkt in die DB. So habe ich die Garantie, dass alle Caches mindestens einmal pro Woche aktualisiert werden, es sei denn sie wurden archiviert. Somit erkennt man archivierte Caches daran, dass das "Last GPX" Datum mehr als 7 Tage zurückliegt. Das prüfe ich nach dem PQ Download automatisch mit dem Review_For_Archive_API.gsk Makro, welches archivierte Caches dann automatisch in meine "Archiv-DB" verschiebt (oder auch löschen würde, was ich aber nicht will). Ich hoffe, dass Euch das dabei hilft, eine Wochen-aktuelle Schweizer DB zu haben.

Danke Euch beiden für den Hinweis. Das finde ich eine super Änderung. Ich denke mit dem Default-checked hat mancher ein Listing aus versehen schon freigeschaltet bevor der Cache versteckt war. Nun sollte das nicht mehr passieren. Im schlimmsten Fall wundert er sich nun halt, wieso das Listing nicht reviewed wird, aber ich denke, das ist das kleinere Übel. Bezüglich Platzierung hätte ich es besser gefunden, wenn die Checkbox entweder geblieben wäre, wo sie war, oder aber auch eher nach unten zu den beiden AGB-Boxen (aber nicht ganz dorthin, damit sie nicht im Reflex mit angeklickt wird). Aber wie gesagt, danke für den Hinweis!

Nun auch im GSAK forum gelistet: http://gsak.net/board/index.php?showtopic=8241&view=findpost&p=143527. Zukünftige Updates werde ich nur noch dort posten.

Ah, da bei mir das GPS immer via GSAK befüllt wird, habe ich das gar nicht versucht. Werde das aber bei meinem nächsten Cache testen. Herzlichen Dank für die Rückmeldung.

Paravan Danke für den - wie immer spannenden - Podcast. Ich habe eine Frage zu Deinem Beitrag über das erstellen eines neuen Caches. Du hast dort erwähnt, man könne mit dem Knopf "GPX File" auch für noch nicht veröffentlichte Caches eine GPX Datei herunterladen, um diese dann aufs GPS zu laden, um den Cache zu testen. Ich habe das schon bei mehreren meiner Caches versucht ohne Erfolg. Da ich während dem hören deines Podcasts gerade daran war meinen neusten Cache abzuschliessen habe ich das nochmals getestet. Drücke ich auf den "GPX File" Button, passiert bei einem unveröffentlichten Cache nichts. Klicke ich stattdessen auf "LOC waypoint file", so kann ich auch für unveröffentlichte Caches ein location file herunterladen. Der Versuch dieses nach GSAK zu laden scheitert aber, im Gegensatz zum Import des LOC Files eines veröffentlichten Caches. Habe ich Dich falsch verstanden? Mache ich etwas falsch? Ich würde mich über einen Tipp freuen. Danke und Gruss sbeelis

@Waschi, Attila Die Idee hat durchaus gewisses Vorteile. Ich befürchte aber, dass das keine Chance hat im Feedback Forum und zwar aus folgendem Grund: Die Länge dieser Felder sind schon lange so definiert und vermutlich in einigen Drittapplikationen auch mit der 500 Zeichenlimite für die Short Description implementiert. Wenn die neu plötzlich grösser wird, fliegen da sicher einige auf die Schnauze und ich vermute, dass Groundspeak diesen Vorschlag deshalb wohl kaum umsetzen wird. Aber wer weiss, vielleich liege ich falsch. Ein Versuch ist es allemal Wert...

So, unterdessen habe ich die Karten und Daten aller Kantone zusammen. Ehre wem Ehre gebührt Folgende Dinge sind von silavon (siehe erster Post in diesem Thread): Ursprüngliches Makro Daten und Karten für folgende Kantone AG AI/AR SH TG ZH [*]Karten für folgende Kantone BE Innerschweiz (GL/NW/OW/UR/SZ/ZG) Folgende Dinge sind von mir: Korrekturen der Polygon Files um die Gemeindefusionen 2010 und 2011 der von mir gemachten Kantone zu berücksichtigen Erweiterung des Macros um einen "Alle" und "Keine" Button Datenfiles zu den Karten von silavon für BE Innerschweiz (GL/NW/OW/UR/SZ/ZG) [*]Karten und Datenfiles GR LU BS/BL GE JU SO NE TI FR SG VD VS Installation Die Dateien aus Schweiz_Gemeinden_v2.zip müsst ihr nach ...\GSAK\Macros kopieren. Danach könnt ihr das Macro Schweiz_Gemeinden.gsk laufen lassen, welches die Gemeindedaten in ein Feld Eurer Wahl schreibt. Die Dateien aus Karten_Gemeinden_Schweiz_v2.zip müsst ihr nach ...\GSAK\Macros\FindStatGenData kopieren. Die Kartendaten gehen davon aus, dass das UserData2 ist, ansonsten müsst ihr die DAT Files entsprechend anpassen ($MapDataSource = "User2"). Verwendung Um die Karten mit FindStatGen zu erzeugen müsst ihr im Optionen-Menu den Button "Maps" anwählen und dort die entsprechenden Kantone anwählen. Beispiel Ein Beispiel mit gefälschten Daten für alle Kantone finde ihr hier. Weiteres Vorgehen Ich freue mich über Euer Feedback. Ich werde nochmals versuchen silavon zu erreichen (bisher habe ich auf meine Kontaktversuche keine Antwort erhalten), um abzuklären, ob er damit einverstanden ist, wenn ich die beiden ZIP Files bei GSAK hochlade. Wenn er einverstanden ist, werde ich die dort hochladen und danach Feedback zu den Karten gern in den dortigen Foren entgegennehmen. Viel Spass mit den Gemeindekarten.

Ich habe das nicht kontrolliert, aber ich hätte erwartet, dass er bei Caches, für die Du in GSAK "Corrected Coordinates" eingetragen hast auch diese verwendet, für den Lookup. Zumindest für die Zuordnung zu County/State wird das verwendet, gemäss Aussagen im GSAK Forum.

Und noch ein CD Tausch-Cache: GC1F9K Jean Nouvel's Cache

Bei mir stehen in den Caches von 2 meiner 3 Sonntags-PQs in GSAK als letztes Update-Datum der 9.10 statt der 16.10 drin. Habe mir nun die beiden PQs von Hand runtergeladen. Das ZIP File hat als Datum zwar das Datum vom 16.10, das GPX File im ZIP drin hat aber das Datum vom 9.10, also die Daten der Vorwoche. Im XML des GPX Files steht ebenfalls der 9.10 drin. Folglich scheint das in der Tat ein Problem von GC.com und nicht GSAK zu sein. Mal schauen, was sie rausfinden. Habe die fehlenden Caches nun via API der V8 upgedated.

Hihi, das war auch das erste, was ich nachgeschaut habe :-) Grundsätzlich finde ich es eigentlich toll, wenn in einem Listing etwas zum Ort oder Cache steht, bzw. eine Geschichte und etwas Hintergrundinformation enthalten ist. Das macht für mich die Qualität eines guten Caches aus. Ich kann aber auch das Problem von neisgei nachvollziehen, denn auch auf dem iPhone scrollt man da z.T. recht lange bis zum "Cache relevanten Text". Ich habe am Anfang versucht "papierlos" zu Cachen mit meinem iPhone. GCBuddy konnte mich bisher aber überhaupt nicht überzeugen und obwohl ich einige Tools nutze (GCTools, iGCT) bin ich dazu übergegangen für komplexere Mysteries und Multis das Listing auf Papier auszudrucken und die Rätsel dort drauf zu lösen. Das ist für mich einfach die bequemste Lösung. Bei einfacheren Varianten notiere ich mir vorgängig die Aufgaben/Berechnungen in meinem Cacher-Heftli (ein A5 Heft), statt dem Ausdruck. Damit fahre ich eigentlich recht gut, ohne dass die Würze in der Cache-Beschreibung "stört".

Das stimmt natürlich, wenn Du im Ausland bist. Aber solange Du hier in der Schweiz (oder wo immer Du dein Datenabo hast) am cachen bist, hast Du auf dem iPhone tatsächlich die Wahl aus verschiedenem sehr guten Kartenmaterial auszuwählen, auch wenn es nur online zur Verfügung steht. Diese Option hast Du mit einem Garmin Gerät aus der Box nicht. Andererseits kannst Du (wenigstens mit der GC App) auf dem iPhone mit etwas Vorbereitung auch OSM Kartendaten für den offline Gebrauch herunterladen, womit das iPhone im Offline-Modus und ein Garmin mit OSM Material bezüglich Kartenmaterial etwa gleichaufliegen.

Bei Coins und Travelbugs kann man ein Attribut setzten, ob die "sammelbar" (collectible) oder nicht sein sollen. Typischerweise ist das *nicht* gesetzt, das heisst, dass Du, wenn Du einen TB oder Coin mitnimmst, diesen innert nützlicher Frist wieder in einem Cache ablegen solltest, idealerweise noch so, dass der TB seinem Ziel näher kommt. Einen Coin aus einem Cache zu nehmen und dann mit dem Cachen aufhören und diesen behalten ist wohl eher nicht die ideale Umgangsform... Hoffe, dass Dir das weiterhilft.

Öhm, ich kenne mich mit sqlite nicht so aus, aber in Oracle und DB2 findes Du mit '%vor Ort%' die folgenden Einträge: 'vor Ort' 'vor Ort muss noch was gemacht werden' 'das mache ich dann vor Ort' 'das kann man auch vor Ort machen' Meines Wissens entspricht das % im SQL dem *, sprich "irgendwas, kann auch nicht sein". Ist das bei sqlite nicht so?

% (Gcnote like "%vor Ort%")

Ich würde sagen "es muss ja niemand". Obwohl die Aufregung um Challenges ja etwas abgeflacht ist und die Qualität der verbliebenen Challenges eher gestiegen ist, finde ich viele davon immer noch nicht super toll. Wenn ich gerade an einen Ort komme, wo es originelle zu machen gibt, nehme ich sie mit (so z.B. ein paar in Berlin), aber ich werde nicht für Challenges eigens eine Tour planen. Das gleiche für Munzees. Erstens gibt es in und um Bern noch kaum welche (in Bern nur den einen, den ich testweise gelegt habe). Zweitens braucht man um den Munzee zu loggen zwingend Netz, somit fallen alle Munzees im Ausland schon mal weg. Ich verstehe nicht, wieso man nicht offline den QR Code ablichten kann (GPS Empfang hat man ja), und das dann in der App offline gespeichert wird und wenn man WLAN hat später hochgeladen werden kann. Fazit für mich: - Munzee mal schauen wie sich's entwickelt, ist aber für mich eher nicht interessant - Challenges wenn sie grad am Weg liegen und ich nix besseres zu tun habe - Geocaching ist und bleibt mein Hauptinteresse. Dafür plane ich Touren und auf die konzentrier ich mich. Aber das ist natürlich eine persönliche Frage, die jeder anders beantworten wird. Ausserdem kannst Du es Dir ja noch richtig schwierig machen und noch "Waymarking" mit reinnehmen, um etwas weiteres zu haben, das Du machen "musst" :-)

Ich kann das nur bestätigen. Ich habe vor ziemlich genau einem Jahr mit Geocaching angefangen. Zuerst ausschliesslich mit dem iPhone. Vor ca. 5 Monaten habe ich mir dann ein Occasions-Etrex Vista HCx gekauft. Ursprünglich kaufte ich dies, damit ich um Ausland (wo ich kein Datenroaming habe) auch cachen kann. Nun war ich Ende September 10 Tage in Berlin und habe dank etwas Vorbereitung (5-6 Pocket Queries à je 100 Caches) mit dem iPhone super offline cachen können, obwohl ich das Etrex dabei hatte, habe ich es nie gebraucht. Der einzige Ort, wo ich das Etrex noch mitnehme, ist wenn ich im Wald cachen gehe, da ist der Empfang etwas präziser als beim iPhone.

So viel ich weiss, werden die Notes von der Webseite nicht mit ins GPX des PocketQueries gepackt, somit sind diese Daten auch nicht in GSAK verfügbar. Ich weiss nicht, ob die Information über das Groundspeak API von GSAK V8 geliefert werden, das fragst Du am besten im GSAK Forum.

Soweit ich gesehen habe, unterstütz die neuste Version Dropbox und import ab Mails. Habe das selber aber noch nicht getestet. Habe ausserdem per Mail beim Programmierer angefragt, ob es allenfalls offline OSM Unterstützung geben soll und er hat mir geantwortet, dass sie mittelfristig vorhaben OSM Karten im *.img Format (gleich wie für Garmin Geräte) zu unterstützen. So wie es aussieht wird das Ding also noch weiterentwickelt werden. Falls Dir die anderen oben erwähnten Punkte also wichtig genug sind, lohnt sich evtl. ein Mail an info@smudgygames.com (auf Englisch halt).

Auch von mir ein herzliches Dankeschön für die geleistete Arbeit und die offene Kommunikation. Der (T)antefix viel Spass beim weiteren unbeschwerten Cachen und Publish-Edi danke für die Arbeit, die Du noch Leisten wirst!

Bin auch schon mehrmals mit GPS geflogen. War nie ein Problem, Batterien in Plastiksäcken höre ich hier zum ersten mal. Ausserdem frage ich mich immer, wieso man elektronische Geräte im Flieger ausschalten muss (bei Mobiltelefonen kann ich das ja noch verstehen, die haben immerhin einen Sender drin), aber CD Spieler oder GSP (die haben ja nur einen Empfänger) leuchten mir überhaupt nicht ein. Das Zeugs sollte ja eigentlich alles auf elektromagnetische Verträglichkeit (EMV) geprüft sein. Dass sich ein Flugzeug von so was stören lassen kann gibt mir als El.Ing. immer ein wenig ein mulmiges Gefühl....