RCH65

Ich wurde allerdings schon ziemlich harsch angemacht, als ich in einem Log eine Redewendung benutzte, die auf einen kleinen Cache schliessen lässt. Zitat der Mail: "Bitte ändere sofort Deinen Log beim [...]. In einem Listing sollte man NICHTS verraten,- aber Du verrätst gleich Alles [...] Sonst werde ich den Log löschen, machen mich ziemlich sauer solche Logs wo Cacher immer meinen sie müssen den Nachfolgenden gleich mitteilen was sie alles raus gefunden haben." Für gewisse Owner scheint die fehlende Angabe zur Cachegrösse Teil der Herausforderung zu sein, was ich nachvollziehen kann, wenn es sich um eine atypische Form (wie zB Magnetstreifen) handelt - in allen anderen Fällen nervt es aber doch eher...

Okay... Groundspeak hat das Routing für "meinen" IP-Block geändert... und seit gestern bin ich doch tatsächlich wieder mit voller Geschwindigkeit unterwegs. Ich nehme mal an, das hat tatsächlich mit der Änderung zu tun und nicht mit der Möglichkeit, dass es jetzt zufälligerweise gerade wieder funktioniert... Sie werden die ganze Sache noch einen Moment lang beobachten und dann auch die anderen Blocks umstellen.

Okay, ich habe die Liste der IP-Blocks (von RIPE, nicht von Cablecom). Ist eine ziemlich lange Liste mit 63 (!) IP-Bereichen. Bin ja gespannt, was Groundspeak damit macht - für die Deutschen Telecom haben sie das Routing nur für die 7 grössten Blöcke geändert (und die waren wirklich gross!)

Ich habe vor ein paar Tagen eine entsprechende Note im grünen Forum hinterlegt... und zu meiner grossen Überraschung doch tatsächlich eine Antwort erhalten. Gemäss Groundspeak liegt das Problem nicht am Routing CH->Seattle, sondern in der umgekehrten Richtung Seattle->CH. Der Datenverkehr in diese Richtung ist natürlich massiv grösser, schliesslich muss ja die (unglaublich "fette") Webpage zu uns übermittelt werden. Die Tatsache, dass die Pakete auf dem Rückweg ihr eigenes Routing "suchen" und nicht (wie beim Telefon) durch denselben Draht zurückkommen, geht gerne mal vergessen... Groundspeak sagt, dass vor allen das Routing via AT&T und GTT nach Europa zu bestimmten Zeiten problematisch ist. Offenbar hatten in Deutschland zahlreiche Kunden dasselbe Problem wie wir und Groundspeak hat in der Folge das Routing zur Deutschen Telecom neu konfiguriert, um AT&T bzw GTT zu vermeiden. Hierzu wurde das Routing zu insgesamt 7 grossen IP-Blöcken der Deutschen Telecom geändert. Groundspeak hat mich nun gefragt, in welchem Adressblock wir (ich) denn so unterwegs sind und ich habe ihnen in der Folge "meinen" Adressblock der Cablecom genannt: inetnum: 178.82.0.0 - 178.83.191.255 netname: CABLECOMMAIN-NET descr: Cablecom GmbH descr: DHCP Scopes descr: Zuerich country: CH Wenn ich richtig gerechnet habe, sind darin 114'432 IP-Adressen enthalten und wenn Groundspeak tatsächlich das Routing für diesen Block ändert (hoffentlich bald!), könnten alle Kunden in diesem Block geocaching.com wieder problemlos erreichen (hoffen wir's mal...) Nun dünkt es mich jedoch, dass 114'432 Adressen etwas wenig sind, um alle Cablecom Kunden abzudecken - ich habe deshalb Cablecom kontaktiert, damit sie mir die weiteren Adressblöcke mitteilen, sodass ich das weiterleiten kann und dann hoffentlich auch Cacher in anderen Teilen der Schweiz wieder schnell unterwegs sind. Mal schauen wie's weitergeht... PS: Wer prüfen will, ob seine IP-Adresse im oben erwähnten Block liegt, kann https://www.whatismyip.com/ aufrufen - dort wird Eure (vom Provider zugewiesene) öffentliche Adresse angezeigt. Falls Eure Adresse nicht in diesem Block liegt, könnt Ihr die Adresse hier reinschreiben (oder via PM, wer's diskreter will) - ich kann dann bei RIPE (das ist die Vergabestelle für IP-Adressen in Europa) den entsprechenden Block raussuchen (Plan "B" - falls sich die Cablecom zieren sollte, die Blocks rauszugeben).

Tönt irgendwie nach Geocaching in Nordkorea. Der war vermutlich auch kein Reviewer sondern von der Parteiführung...

Habe soeben eine Antwort vom Cablecom Kundendienst erhalten: Vielen Dank für Ihre Anfrage. Wir haben bereits mehrere Fälle bezüglich geocaching.com. Ich habe auch Ihren Fall an unser Networking weitergeleitet. Es scheint aber in der Tat so zu sein, dass unser Peering Partner teilweise überlastet ist. Networking wird den Fall kontrollieren und sich anschliessend bei Ihnen melden. Vielen Dank für die beiden Traceroutes, dies vereinfacht uns die Fehlersuche. Besten Dank für Ihre wichtige Zusammenarbeit. Mal schauen, wie's weitergeht...

...oder es hat vielleicht schlicht mit der Tatsache zu tun, dass geocaching.com über gewisse Provider (zB Cablecom) seit ein paar Tagen (wieder einmal) extrem schlecht - bzw gar nicht - erreichbar ist: http://www.swissgeocacheforum.ch/forum/topic/12414-gccom-extrem-langsam/

Na, dann werde ich die Cablecom heute Abend wohl noch etwas belästigen... Da ich in der Regel mit Chrome unterwegs bin, habe ich mir extra für den Besuch auf geocaching.com in Firefox schon vor ein paar Tagen einen Proxy eingetragen (der Proxy gilt eben für alle Webpages - ausser mit einem weiteren separaten Plugin mit der gefühlten Nummer 387). Ist jetzt nicht gerade ein Wunder an Speed; funktioniert aber ganz brauchbar: -> Extras -> Einstellungen -> Erweitert -> Taste Einstellungen -> Manuelle Proxy-Konfiguration -> HTTP-Proxy: 212.82.126.32 / Port: 80 / Für alle Protokolle verwenden

Wie erwähnt, das grundsätzliche Problem scheint das Routing des Providers zu geocaching.com zu sein, denn das Problem existiert hier (natürlich abhängig vom Provider) schon weit länger als drei Tage. Da die Datenmenge der APIs im Vergleich zur extrem aufgeblasenen Wegpage geradezu lächerlich klein ist, kommen diese Daten natürlich schnell(er) mal ans Ziel. Wenn ich in meinem endlos drehenden Browser mal den bereits empfangenen HTML-Code anschaue, sehe ich jeweils, dass die ersten paar KBs längst hier sind - aber das reicht halt noch nicht, um die Wegpage anzuzeigen. Im API kannst Du damit natürlich bereits 10 Caches geloggt haben...

Falls Du Dich vom iPhone nicht via WLAN sondern via mobiles Internet verbindest, ist es natürlich gut möglich (bzw äusserst wahrscheinlich), dass der Mobilfunkprovider ein anderes Routing in die USA verwendet als Dein Internetprovider (siehe Post oben "home" vs "office").

Habe diesen Post gerade erst gesehen und unabhängig davon vor ein paar Minuten in einem einschlägigen Thread des Groundspeak Forums etwas darüber geschrieben. Es liegt definitiv nicht an geocaching.com selbst, sondern (bei mir) an Timeouts beim Peering Partner ntt.net. Wenn ich von zuhause aus auf geocaching.com zugreife (Cablecom), ist die Verbindung im Prinzip nicht benutzbar. Gemäss TRACERT ist der Engpass wohl bei "ntt.net" zu suchen (Frankfurt->NYC->Seattle). ..snip.. ae-10.r03.frnkge03.de.bb.gin.ntt.net ae-1.r21.frnkge03.de.bb.gin.ntt.net ae-3.r23.nycmny01.us.bb.gin.ntt.net Timeout Timeout ae-2.r04.sttlwa01.us.bb.gin.ntt.net ae-0.internap.sttlwa01.us.bb.gin.ntt border8.po1-40g-bbnet1.sef.pnap.net www.geocaching.com Sobald ich aber von meinem Büro auf geocaching.com zugreife (zur exakt gleichen Zeit via VPN) ist alles in bester Ordnung - anstelle von ntt.net wird dann der Atlantik aber via zayo.com überquert und wir enden auf einem anderen Gateway bei pnap.net (scheint wohl das RZ zu sein, in dem die Groundspeak Server stehen). ..snip.. xe-1-2-0.mpr1.fra4.de.above.net ae8.mpr1.fra3.de.zip.zayo.com ae4.cr1.ams5.nl.zip.zayo.com ae0.cr1.ams10.nl.zip.zayo.com v142.ae29.cr2.ord2.us.zip.zayo.com ae11.cr1.ord2.us.zip.zayo.com v11.ae29.mpr1.sea1.us.zip.zayo 208.185.125.106.ipyx-072053-008 border8.po2-40g-bbnet2.sef.pnap.net www.geocaching.com So wie's aussieht, müssten die Jungs von pnap.net wohl mal ein paar Worte mit deren Peering Partner ntt.net wechseln... Ist aber trotzdem extrem mühsam! Von meinem Laptop kann ich das Problem ja bequem via VPN umgehen - aber das gilt natürlich nicht für die anderen Geräte im Haushalt. Muss ich jetzt wirklich noch irgend ein Abo bei einem "freien" VPN-Provider lösen, der nicht via ntt.net mit der USA verbunden ist? Grmpfl...

Neben der bereits erwähnten Tücke mit dem Filter gibt's noch eine Einstellung, ab welcher Zoom-Stufe die Caches auf der Karte angezeigt werden sollen -> Einstellungen -> Karte -> Erweiterte Einstellung -> Zoom-Massstäbe -> Geocaches. Ich hab's bei mir so eingestellt, dass die Caches erst ab einer Zoom-Stufe von 500m angezeigt werden (Massstab Anzeige unten auf der Karte). Wenn ich weniger reinzoome (also zB 800m, 1.2km etc) werden die Caches ausgeblendet, sodass sie die Anzeige der Strassen und Wege nicht überdecken.

Haaaammmmmermässig!

Ich bin es immer noch gewohnt, bei den Podestplätzen einen Tag lang auf eventuelle Vorlogger zu warten, bis ich mein Online Log platziere. Schwierig wird's dann jeweils, wenn der FTF durch eine ganze Gruppe geloggt wurde - da kann es dann schon mal vorkommen, dass ich mich nach den ersten drei FTF-Loggern als Zweiter eintrage und dann kommt irgendwann noch ein vierter FTFler hinzu.

Auf geochaching.com hat's immer noch einen kleinen Bug, der bewirkt, dass FPs etwas verspätet vergeben werden. Wenn ich eine Note schreibe und diese dann in einen Found umwandle, wird der Found für die Vergabe der FPs nicht mitgezählt. Offenbar habe ich das bislang 3x gemacht, denn ich erhalte meinen nächsten FP jeweils bei xxx3 Founds und nicht mehr wie üblich bei xxx0 Founds. Ist aber wohl vernachlässigbar - um 8 FPs zu verpassen, müsste ich das schon 80x machen...

Der Link ist nun auch auf der Profilseite oben rechts verfügbar (Available Sneak Peeks -> Advanced Search)

Doch, mein voller Ernst Selbstverständlich habe ich auch schon (gerne) als TJ gedient und diesen Dienst auch schon in Anspruch genommen. Logischerweise schreibe ich das dann aber im Log. Was ich etwas schräg finde ist ja nur die Tatsache, wenn die Hilfe im Log nicht erwähnt wird.

Würde mich ja schon wundernehmen, ob diejenigen, die sich die Zielkoordinaten so "beschaffen" das Rückgrat haben, dies im Log entsprechend zu schreiben... ("hatte keine Lust/Lust/Interesse, das Rätsel zu lösen..."). Musste in der Vergangenheit schon oft schmunzeln, wenn bei einem "satten" Mystery im Log absolut nichts über die Mühsal der Rätsellösung steht...

Ja, das stimmt selbstverständlich. Und ich bin auch nicht wahnsinnig traurig, wenn ein Cache in einem Astloch so angefroren ist, dass man ihn nicht rauskriegt (wie vorgestern geschehen). Das konnte der Owner unter Umständen nicht ahnen. Wenn ich aber bei einem Cache bin, der sich am Boden ganz klassisch zwischen den Wurzeln eines Baumes befindet, frage ich mich halt schon, ob das Setzen des "available in winter" Attributes eine weise Entscheidung war... Da habe ich dann manchmal schon Hemmungen, überall den Schnee wegzuräumen. Obwohl das der Natur wohl nicht schadet, sieht es anschliessend einfach aus "wie Sau"...

Sollte mit dem JavaScript API von Google Maps möglich sein: https://developers.google.com/maps/documentation/javascript/examples/?hl=de Der Geocoding Service bastelt aus einer Adresse einen Satz Koordinaten: https://developers.google.com/maps/documentation/javascript/examples/geocoding-simple?hl=de Damit kann man dann die üblichen Marker erzeugen: https://developers.google.com/maps/documentation/javascript/examples/icon-simple?hl=de Du kannst auch die Boundaries der aktuell angezeigten Karte abfragen, sodass Du im Idealfall nur die Pins im aktuell angezeigten Fenster zeichnen musst.

Nun ja... ich habe keine Ahnung, was ich mit 15'000 Caches auf dem Navi anfangen sollte... aber bislang ist mir ja auch verborgen geblieben, weshalb man jede Woche alles Caches der Schweiz zu sich auf den Rechner herunterlädt. Wenn ich nach Basel cachen gehe, lade ich mir ein PQ der Region Basel auf's Navi und wenn es Richtung Bündnerland geht dann ist es halt ein PQ aus dieser Region. In Ausnahmefällen können es auch mal zwei PQs sein; wenn sich die Zielregion im Schnittpunkt zweier vorhandener PQs befindet und ich kein neues Query erstellen mag. Einzig das PQ meiner Heimregion lasse ich wöchentlich 1x automatisch aufbereiten. Alles easy peasy...

Wenn ich die folgenden Daten richtig interpretiere, würde ich mal sagen, dass GLONASS am 4. Oktober ein Problem hatte. So sehen die Differenzmessungen zwischen GLONASS und GPS an einem normalen Tag aus: Die Differenzen betragen offenbar zwischen 3 und 7 Metern in beiden Richtungen. Am 4. Oktober sieht's jedoch so aus: Nur noch zwei Messergebnisse und eines davon mit Abweichungen von 23.9 km Richtung N/S und 31.1 km Richtung W/E. Würde mich nicht wundern, wenn das eine oder andere Navi hier ebenfalls forfait gegeben hat... Quelle: http://www.sdcm.ru/smglo/stparam?version=eng&repdate&site=extern

Wäre nicht das erste Mal Anfangs April haben die Glonass Satelliten (ebenfalls) durchgedreht und jeweils Positionen 200km im Off ausgesendet. Receiver mit kombiniertem GPS/Glonass Empfang haben damals oft den Geist aufgegeben, da sie die extrem abweichenden Positionen zwischen GPS und Glonass nicht unter einen Hut bringen konnten: http://gpsworld.com/the-system-glonass-in-april-what-went-wrong/ Ist für das Problem von gestern aber natürlich reine Spekulation...

Ja, dieser Link ist weg: http://forums.groundspeak.com/GC/index.php?showtopic=326545&view=findpost&p=5433947 Offenbar haben sie die Zuteilung nach Country/State aus den Profilen entfernt und damit natürlich auch diesen Link, der direkt davon abhing. Die URL selbst scheint aber (vorerst) noch zu funktionieren: List newest in... Graubünden http://www.geocaching.com/seek/nearest.aspx?country_id=192&state_id=229 Ostschweiz http://www.geocaching.com/seek/nearest.aspx?country_id=192&state_id=230 Zürich http://www.geocaching.com/seek/nearest.aspx?country_id=192&state_id=231 Nordwestschweiz http://www.geocaching.com/seek/nearest.aspx?country_id=192&state_id=232 Zentralschweiz http://www.geocaching.com/seek/nearest.aspx?country_id=192&state_id=233 Espace Mittelland http://www.geocaching.com/seek/nearest.aspx?country_id=192&state_id=234 Suisse Romande http://www.geocaching.com/seek/nearest.aspx?country_id=192&state_id=235 Jura http://www.geocaching.com/seek/nearest.aspx?country_id=192&state_id=236 Wallis http://www.geocaching.com/seek/nearest.aspx?country_id=192&state_id=237 Tessin http://www.geocaching.com/seek/nearest.aspx?country_id=192&state_id=238

Ohhh... ein Wettbewerb! In diesem Sinne: 7SofA erfüllt PS: Krieg ich ab jetzt Werbeanrufe...?