Lemon

Ik gebruik ook c:geo (Android), maar voor projecteren ook de app GeoMT (The Geocaching Multi-Tool). Heeft veel mogelijkheden.

Ook een GEARCHIVEERDE (en daarna weggehaalde) cache wordt soms doodleuk nog als FOUND gelogd: zie http://www.geocaching.com/seek/cache_details.aspx?wp=GC3W95W, log van 2 mei.

Bogus logs zijn "valse" logs, of neplogs. Iemand logt bijvoorbeeld op geocaching.com een cache als gevonden, terwijl hij in werkelijkheid de cache helemaal niet heeft gevonden en zijn naam dus ook niet in het logboekje staat. Zie voor een voorbeeld http://forums.groundspeak.com/GC/index.php?showtopic=278884 .

Al wachtend meld ik nog even dat het probleem vandaag (1 november) nog bestaat (Windows 7 + Firefox). Foutmelding luidt: Fatal error: Call to a member function topicPostSearchResultAsForum() on a non-object in /home/geocaching/domains/geocaching.nl/public_html/forum-7nUT6/admin-21zxc/applications/forums/extensions/search/format.php on line 229

Ik denk, dat de contacten nog vééél leuker worden, indien je de logger toch eerst even een mailtje zou sturen met de vraag om het logje te verwijderen. En als je dat dan ook nog met redenen omkleedt, dan kom de cacher waarschijnlijk ook nog bij jou op de thee.... Zomaar logjes weghalen zonder reden aan te geven vind ik niet passend.Veelal zal de beginnende cacher "iets doen" uit onwetendheid of onnadenkendheid. Het is mijzelf aanvankelijk ook wel eens overkomen. Eén keer heb ik een mailtje ontvangen waarbij ik dacht... "Ja natuurlijk, de legger heeft helemaal gelijk, zo heb ik het niet bekeken". En uiteraard heb ik toen onmiddellijk het logje gewijzigd. Nogmaals.... het is een spelletje. Ik zou het nog wat minder eufemistisch willen zeggen: ik vind het weghalen van een log van een ander, zónder daarover eerst contact te hebben gehad, bepaald onfatsoenlijk. Zo ga je toch niet met elkaar om. Het kan dan wel jouw cache zijn, maar het is zijn/haar log. En het is juist wat in het citaat staat, wellicht is het log zo geplaatst uit onwetendheid of onnadenkendheid. Als ik zou merken dat een vinderslog van mij zónder voorafgaand overleg door de CO is verwijderd, zou ik daar zeker over klagen bij een reviewer. Maar natuurlijk niet dan eerst van mijn kant een poging te hebben gedaan, contact te leggen.

Met de voorgestelde richtlijn 1 (Altijd een hint) ben ik het niet eens. Dat lokt juist uit dat men onnodige hints gaat plaatsen, zoals "Leg de cache voorzichtig terug" of "Kijk goed om je heen" e.d. Maar met de voorstellen 2 t'm 4 gaarne eens!

Mijn reactie (die gedeeltelijk herhaalt wat anderen al hebben geantwoord): 1. Gebruikers van prikstokken woelen juist niet de grond om. Hooguit maken ze kleine gaatjes. Het omwoelen gebeurt door mensen die geen prikstok bij zich hebben, en daarom met takken of met hun schoenen gaan "vegen" of "graven". 2. Eigenlijk zou ook een prikstok niet nodig moeten zijn. Een cache moet zó zijn weggelegd dat een cacher de plek kan vinden door scherp opmerken, terwijl een dreuzel niets zal opvallen. Een kist met een stammetje, stronkje of tak op het deksel waardeer ik hoog. 3. Additional hints zouden beter kunnen. Hoe vaak lees ik nog: "Achter een boom" (over een cache die in een bos ligt). 4. "De cache-legger heeft altijd gelijk" zegt men. Als dat zo is, schept dat een grote verantwoordelijkheid. Een cache-legger moet zich ervan bewust zijn dat zijn cache bezoekers lokt. En dat de natuur daarvan schade kan lijden. Ik heb wel eens het idee dat niet iedere cache-legger zich realiseert wat de gevolgen kunnen zijn van een cache op een bepaalde plaats in de natuur. 5. Er zijn kennelijk ook cachers (ik bedoel hier: vinders) die zich geroepen voelen om een cache moeilijker weg te leggen dan ze 'm zelf hebben gevonden. Zij verwijderen bijv. een stapeltje takken boven de kist (hoewel misschien afkomstig van de cache-legger zelf) en begraven de kist onder een paar centimeter zand. Soms vermelden ze dat zelfs trots in hun log. Mijns inziens een foute mentaliteit. Ook dat lokt weer prikken en/of omwoelen uit. 6. Waar ik wél waardering voor heb (en ik doe het zelf ook) is dat een vinder ook een beetje onderhoud pleegt: bijv. door een met zand e.d. volgelopen kist weer even leeg te graven. En uiteraard feedback aan de legger (in log of indien echt van belang via maintenance log) als er echt iets mis is waarvan herstel door de legger zal moeten plaatsvinden (bijv. kapot deksel, kist onder water etc.)

Wat de tweede vraag, over omzetten van RD-waarden, betreft: het is je toch wel bekend dat in RD de X en de Y staan voor resp. Lengtegraad en Breedtegraad? Dat is dus net andersom dan in WGS84, waarin de Breedtegraad (voor Nederland N=Noorderbreedte) als eerste pleegt te worden opgegeven. In sommige tools moet je daarmee rekening houden. Wat ik als controlemiddel wel eens toepas, is dat ik de gegeven WGS84-coördinaten van de Mystery via bijv. gct.exe (te downloaden hier) omzet naar RD-waarden. Dan heb ik tenminste een beetje idee hoe de RD-waarden X en Y er ongeveer zouden moeten uitzien. Natuurlijk ligt de cache niet op die coördinaten, maar het geeft soms wat houvast bij het oplossen van puzzels. Wat de eerste vraag betreft: helaas kent gct.exe niet de mogelijkheid om de snijpunten van drie cirkels te berekenen. Wel van twee cirkels, dus misschien een paar keer toepassen? Deze tool kan ook de snijpunten van twee cirkels berekenen. Succes

Ik sluit me graag bij alle andere complimenten aan. Er zaten hele mooi foto's bij, en graag volgend jaar weer zo'n wedstrijd!

Glennenmaik vergist zich. In logs van september en oktober 2010 bij deze cache wordt over een recent afgebroken tak geschreven. En er is ook een (andere) foto, van 22 september 2010 waarop de tak te zien is. (N.B. Ik ben niet de inzender van de foto.)

Hm, hier geen probleem met Firefox 3.6.13. Het laden van een Geocaching.com pagina duurt wel even, maar dat komt door de geïnstalleerde scripts (Greasemonkey, Geocache Decrypt 2010, GC Vip List Helper, GC Gallery, GCV Email Maximizer, GC Find Counter, GC Tidy, GC Bag-o-tricks, GC VIP list, GC-Vote; hier moet ik eens in snoeien denk ik). Terug naar je probleem: kan het niet veroorzaakt worden door een antivirusprogram (real time web shield) dat niet zo goed samenwerkt met Firefox?

Dit verschijnsel (ook op andere webpagina's) kan liggen aan de cache (jawel) van Firefox. Het helpt dan om te doen Extra -> Opties -> Netwerk -> Nu wissen, en dan Huidige pagina vernieuwen (blauwe ronde pijl op de werkbalk). De Add on Clear Cache doet met één klik hetzelfde (op het Huidige pagina vernieuwen na, dat moet daarna nog wel). Met de Add on Better cache kun je instellen dat Geocaching.com niet meer gecachet wordt. Verder: Greasemonkey-scripts (GCVote, GCTidy enz.) zo mogelijk updaten. De Greasemonkey-scripts vertragen overigens het volledig laden van de pagina altijd wel, daar is niet veel aan te doen (behalve dan geen of zo weinig mogelijk scripts gebruiken). Je kunt controleren of het aan deze scripts ligt door Greasemonkey even helemaal uit te zetten en dan een pagina te laden.

Dit lijkt me geenszins 'volkomen onnodig', maar juist precies volgens de richtlijnen van Groundspeak, zoals enkele postings eerder geciteerd: If you find a geocache that is in need of some help (e.g. container is cracked, logbook is full or wet), please post a "Needs Maintenance" log on the cache page so the cache owner and the community is notified. (...) Needs Maintenance logs are not forwarded to reviewers. Ik zie ook niet in waarom dat een smetje zou zijn, vooral niet als op die cachepagina ook nog te zien is dat direct actie is ondernomen.

Als je een PDA bij je zou hebben in 't veld, zou je het programmaatje GCT.exe kunnen gebruiken. (Dit kan je ook thuis op je computer draaien, maar daar heb je uiteraard niet onmiddellijk wat aan in het veld.)

Misschien een beetje Off Topic, want het gaat niet over het nut van de hidden waypoints. Maar het lost wel een probleem op: met het Greasemonkeyscript GC Tidy kun je bereiken dat de hidden waypoints altijd worden getoond. En dus ook geprint. Dus onderweg merken dat je print niet compleet is, is er niet meer bij.

Nederland is wel degelijk creatief. Probeer maar eens wat caches van team Dalamot (is al genoemd) in of rond Schoonhoven, en de Brouwertjes in Alphen. En er zijn er vast wel meer, maar die moet ik zelf ook nog ontdekken.

Mijn Garmin 550 wordt soms niet herkend door de computer. Op het display van de Garmin zie ik dan wel 'Garmin' branden, maar de computer ziet geen apparaat (niet in MapSource, niet bij Send to Gps op Geocaching.com, niet in de verkenner). En als ik de usb-kabel losmaak, blijft de Garmin 'hangen'. Op het display blijft "Garmin' branden, maar ik kan'm niet meer uitzetten. Wat ik dan doe is dat ik een van de batterijtjes een 20-tal tellen loshaal. Dan weer er in. Dan weer de usb-kabel aansluiten. Meestal gaat het dan goed. Geen idee waarom.

Ten slotte nog: dank aan allen die hebben gereageerd. De bewuste cache is inmiddels gevonden. Zonder dit forum was dat niet gelukt, zouden we er zelfs niet aan zijn begonnen.

Even off topic, want dit betreft de conversie Lambert -> WGS84 (die weliswaar óók nodig is voor dezelfde cache als waarvoor we deze draad begonnen): dank voor dit document, dat ik heb gedownload, maar dit is van het jaar 2000, en inmiddels is er ook een 'Lambert 2008' - ik heb de indruk dat we van de laatste moeten uitgaan, de cache-legger schrijft in juli 2008 ook nadrukkelijk "selon le système le plus récent des Lambert"). Ik heb me maar niet verder verdiept in de verschillen tussen de, naar ik begrijp thans: drie Lambert-systemen.

Wij hebben opnieuw getekend met lineaal, gradenboog en passer, volgens de methode Kolkendotters, maar nu na omrekening gon naar graden (dank aan scoutvinder). Helaas worden de onnauwkeurigheden alleen maar groter, want de nieuw te berekenen hoeken worden erg klein (2 resp. 4,5 graden) zodat het bepalen van de cirkelmiddelpunten moeilijker wordt. Wel komen wij nu vlak bij een kruispunt van boswegen uit. Misschien is het kruispunt bedoeld. Maar de vraag blijft: is het mogelijk deze berekening ook via een formule te doen, zodat de uitkomst echt nauwkeurig is? (N.B. Gelet op al de moeilijkheden - cacheomschrijving in het Frans, coördinaten in Lambert, hoeken in gon, er moet een achterwaartse insnijding berekend worden - is het geen wonder dat deze cache in de Belgische Ardennen nog nimmer door een Nederlander gevonden is, en ook nog maar vijf keer door Belgen.)

Tja, er zijn bij deze (Belgische) cache namelijk nog meer problemen dan alleen de 'achterwaartse insnijding', nl. ook nog omrekening Lambert->WGS84 en hoeken die zijn opgegeven in 'gon'. Dankzij scoutvinder weten wij nu dat gon niet hetzelfde is als graden, dus: we gaan weer opnieuw met de gradenboog aan de slag!

Liever geen details van een specifieke cache op het forum behandelen. Stuur liever een PB (mag ook naar mij) Dank beiden voor het aanbod. Ik heb PB's verzonden met als onderwerp 'achterwaartse insnijding'. Want zoals Kalkendotters schreef, daar gaat het inderdaad om.

De bladzijden waarnaar Kalkendotters verwijst, geven precies ons probleem weer. Ik heb dus zitten rekenen en tekenen. Maar ik zou niet durven beweren dat ik op twee meter uitkom! Er zijn zoveel onzekerheden (meten van hoeken met gradenboog, tekenen van lijnen met een zekere potlooddikte) dat de onnauwkeurigheid wel tientallen meters kan bedragen. Maar niettemin mijn grote dank, want met deze aanwijzing ben ik wel een heel stuk verder gekomen. Echter, hoe zit dat nou met numerieke benadering maken in Excel? Daarmee zou ik mijn berekening wellicht kunnen checken? Trouwens, is er ergens een tool om de hoek tussen twee gegeven coördinaatpunten te berekenen, gezien vanuit een derde punt? (Dus niet t.o.v. het noorden). Daarmee zou ik ook kunnen checken.

Deze opgave lijkt te moeilijk voor ons (het is lang geleden dat wij op school aan meetkunde deden). Voor een bepaalde cache zijn drie locaties gegeven (A, B en C). Ze liggen zo'n 2-3 km van elkaar af in een bos en vormen een soort driehoek (maar niet een gelijkzijdige). Nu moeten we een punt (D) berekenen dat ergens in het midden van die driehoek ligt. Wat we weten is dat als je kijkt vanuit punt D je de punten A en B ziet in een hoek van 118,306 graden, en idem vanuit punt D de punten B en C ziet in een hoek van 121 graden. Met behulp van een geodriehoek kunnen we wel ongevéér punt D bepalen, maar dat is niet nauwkeurig genoeg (want op punt D moet je weer zoeken naar een metalen plaatje met coördinaten). Is het mogelijk om punt D exact te berekenen? Zo ja, hoe?

Inderdaad, hier lukt het prachtig mee, als ik eerst de graden, minuten en seconden met de conversietool converteer naar dd,ddddd, dan berekent de tool "2 WP + 2 richtingen = Nieuw WP" het snijpunt exact. Dank voor dit programmaatje, waar nog veel meer tooltjes in zitten.