Eagles

Ik vind ook dat dit niet moet kunnen. Zowiezo al vanwege het feit dat het op een kerkhof lag. Hoe oud en verlaten ook: het is en blijft nog een plek waar mensen ooit een eerbiedwaardige rustplaats is gegeven. Er is ook eens een discussie geweest over een lokatie waar ooit eens een kerkhof is geweest maar dat geruimd was. Dan vind ik het wat anders, maar in het Ierse geval is het duidelijk: moet niet mogen, verzin maar wat anders zou ik de maker aanraden. De alternatieve 'naderingsroute' over een ruïne is ook niet o.k. Je moet hunters wel een veilige hunt geven. Vandaar dat sommige plekken hier ook niet goedgekeurd worden. Logisch.

Yeah, tijdelijk... nog even en hij staat al een jaar op tijdelijk. Tja het is een relatief begrip.

En voor het geval dat je dat nog niet ergens gelezen had: download teveel in een te kort tijdsbestek en je krijgt een IP ban. Dus deel de download op in brokken.

Deze site is mij ooit ter ore gekomen: http://www.elstead.co.uk/d/ar2003.htm. Iemand die ook 2001 had is daarmee bezig geweest (ondanks dat het artikel over 2002/2003 spreekt), maar daar weet ik nog geen resultaten van. Gewoon proberen zou ik zeggen. Een backup van de .exe is zo terug gezet. *Het is wel je eigen risico natuurlijk, voor zover daar sprake van is.*

Zo! Nu ik eindelijk zelf m'n licentie binnen heb van OziCE kon ik zelf eens gaan knoeien en uitvogelen wat er nou allemaal gebeurt met de ijking en aflezing. Er moet EERST even duidelijk verschil gemaakt worden tussen een goed geijkte kaart en een goede aflezing/invoering. Er kan volgens mij toevallig best een situatie zijn waarbij de ijking fout is èn de aflezing, zodat je netto goed bezig denkt te zijn als je koppeling hebt met je GPS en fout als je waypoints gaat invoeren met de hand. Wat in elk geval handig is, is dat de nieuwe OziCE (1.11.1) standaard al het datum Rijksdriehoeksmeting kent! Als je dus de ijkfiles gebruikt met "Rijksdriehoeksmeting" erin (en dus NIET "RD") heb je zelfs geen datums.dat file meer nodig om het datum bekend te maken in OziCE, zie voor die ijkfiles mijn rommel-homepage. Ook kun je (wellicht: nu wel, eerder niet?!?) onder File->Configuration->General Settings het Position Format, en zodoende ook de aflezing in de statusbalk, op User-TM zetten. (De keuze die ooit is gemaakt om het datum in de .map files RD te noemen, zoals ze dus op de CD's staan, is natuurlijk niet geheel onlogisch geweest. Als je dan toch een nieuw datum moet verzinnen en introduceren via datums.dat dan is RD voor de hand liggend i.p.v. het lange Rijksdriehoeksmeting. Alleen aangezien Ozi en OziCE dit niet overgenomen hebben, maar daar intern in het programma gekozen is voor de lange naam, is de combinatie van de oude .map files met nieuwe Ozi wat onhandiger geworden dan nodig.) Goed, na deze lange intro: wat heb ik gedaan? -> OziCE 1.11.1 geïnstalleerd -> ozf2 file plus .map file met Rijksdriehoeksmeting erin op de PDA gezet -> géén datums.dat aanwezig (overigens dezelfde excercitie is ook gedaan met .map file met RD erin in combinatie mèt een datums.dat, dit leverde _exact_ dezelfde resultaten op, dus dit noem ik verder niet meer) -> Position Format (zie hierboven) op "User-TM" gezet Als ik dan een gridlijnenkruising onder de cursor positioneer, dan lees ik in de statusbalk EXACT de goede getallen af (bijvoorbeeld op de kruising 185-432 lees ik ook echt 185000 432000 af) Conclusie: de kaart is GOED geijkt. Zet ik dan het Position Format op Deg.Min om lat/lon af te lezen en in te kunnen voeren bij het aanmaken van waypoints (je zou heel naïef kunnen denken dat je dan in WGS84 verder gaat), dan lees ik af: 51 52.601'N 5 49.401'E. En dat terwijl deze kruising in WGS84 als coördinaten N51° 52.5437' E 5° 49.3711' heeft (opgezocht in Ozi-PCversie). Zijn de coördinaten 51 52.601'N 5 49.401'E dan fout?!? -> NEE, het zijn echter graden en minuten behorend bij Rijksdriehoeksmeting. Je kunt echter niet bij een met Rijksdriehoeksmeting geijkte kaart kiezen voor een display en invoer in WGS84. Je hebt dus alleen de keuze om dan in het kilometergrid van RD in te voeren, of in lat/lon Rijksdriehoeksmeting (en dat is zeer ongebruikelijk en niet te doen voor Geocachers). Dus de enige oplossing is: de kaart moet al in WGS84 geijkt worden en het Position Format ingesteld worden op Deg.Min. Dat is de enige manier om in geocachingformaat een waypoint in te kunnen voeren en ook een goed geijkte kaart te hebben. => .map files van de Bruine Beren gedownload vanaf de homepage van Zenz. Daar ga ik nu mee verder. (Al dat werk om die files te maken lijkt dus zeker niet voor niets! ) Deze werkwijze heb ik overigens nog niet uitgeprobeerd. De resultaten meld ik nog wel, maar ik heb wat verwachtingen... dat het goed gaat. Ik heb ook nog even gekeken naar het voorbeeld van Zeke (de 3 screendumpjes). Hij zegt dat hij stond op de positie die overeenkomt met het eerste en het derde plaatje, dus wysiwyg. Wat zegt de cursor in de statusbalk: 52 43'12.7"N 6 55'14.7"E. Omgerekend in deg.min is dit: 52 43.2117'N 6 55.2450'E. Voer dit maar eens in in Ozi-PCversie, met het invoerdatum op WGS84: dan kom je *bijna* op het kruispunt uit dat je krijgt als je 1) het kleine lijntje onder de 55 van het East deel in de statusbalk en 2) de lange lijn net boven de cursor in plaatje 1 en 3 verlengt.... niet het juiste punt dus. Voer je het nog eens in, maar dan met het invoerdatum op Rijksdriehoeksmeting (of voor sommigen onder ons: RD).... dan kom je wèl uit op de plek waar de cursor in plaatjes 1 en 3 staat. Dus je hebt niets aan de aflezing in de statusbalk in relatie met het "geocaching"-WGS84.... want het is in Rijksdriehoeksmeting lat/lon en niet in een ander datum te kiezen... alleen in een ander grid.

Nee, dat kan niet. Vandaar dat ik het over GarTrax had want daar kun je van diverse bronnen inlezen en dan uitschrijven naar een ander formaat (keuze uit vele), waaronder .wpt van Ozi.

Even er van uitgaande dat je geen Premium Member van .com bent: Ik zou als ik jou was uitgaan van GarTrax. Je zult wel van Portugal zelf de nodige .loc files moeten downloaden (bijvoorbeeld in brokken van max 20 per file, waarbij je caches toont vanaf een zeker coördinaat) waarin alles staat wat van je gading is en inlezen in GarTrax. Daarmee kun je dan alles off-line in een gestripte versie ter beschikking hebben: inclusief wat logjes en (spoiler)foto's. Let wel op dat je niet in één keer alle caches die je wilt hebben gaat downloaden. Dan leg je een veel te grote belasting op .com aan en krijg je vanzelf een IP-ban. Het is wel verstandig op tijd te gaan downloaden, want door de overgang van .com naar de nieuwe website zijn er soms caches waar het indexfile genereren op fout gaat. Dan valt dit wel op te lossen met andere config files, maar daar gaat natuurlijk even wat tijd en zoek- plus vraagwerk in zitten. Soms wordt er ook een cache bij het downloaden overgeslagen die je dan later nog even over moet doen. (Dat zie je aan het simpele feit dat de download dir van die cache leeg is, of aan de errorlog )

Die kosten zijn sinds 1 juli jongstleden niet meer van toepassing, door een Europese regel die verplicht is gesteld voor internationaal bankverkeer. Die regel bepaalt dat de kosten gelijk moeten zijn aan de kosten voor het nationale bankverkeer. Er moet alleen aan een paar voorwaarden voldaan worden, en daar valt ook in dit geval eenvoudig aan te voldoen: 1) betaling in €'s 2) maximaal bedrag €12.5000,= 3) de betaling binnen de EU 4) je moet de IBAN gebruiken (International Bank Account Number), dit is eenvoudigweg een samenstelling van bankrekening begunstigde + rekening ontvangende bank, deze is meestal zelfs via de website van de bank te bepalen 5) je moet de BIC code gebruiken (Bank Identifier Code, staat op de website van de bank), soms vernoemt een bank een SWIFT code omdat dat een instantie is die al langer werkt met codes voor dit soort bankverkeer. Op de Swift website kun je je BIC code checken 6) betaling uitvoeren op basis van Shared Cost (en dat is nou net hetgene wat verplicht is door de Europese Comissie): dit wil zeggen dat aan beide kanten van de betaling de kosten betaald worden, en die zijn nu gelijk aan het nationale verkeer. Dus als die nul zijn, dan zijn ze dat ook voor het internationale verkeer. Er is dus niet meer een bankrekening in Nederland nodig om het goedkoop te houden!

Daar moet je inderdaad niet zijn als je een normale prijs wilt betalen. Ik ben daar ook eens geweest (half jaartje terug) om te kijken, en blijkbaar zijn ze *nog* weer een stuk duurder geworden. Hij is ook gewoon in alles duur vergeleken met andere dumps. Wanneer je daar wel moet zijn? -> als je iets bijzonders zoekt. Hij heeft echt zo'n beetje ALLES staan daar, nog net geen Leopard II. Als je daar in de buurt woont dan kun je ook eens gaan kijken bij Hamstra aan de Kleine Haarsekade in Gorinchem (ongeveer op N51° 50.900' E4° 58.420'). Die heeft een variërende hoeveelheid op voorraad en is ook niet echt bijzonder goedkoop, maar een stuk acceptabeler dan in Heukelum. Ik moest er even bij vermelden dat het een echt waterdichte moest zijn anders loop je kans om er één met een deuk erin te krijgen, dus slecht passend op het rubber. Dit geldt overigens bij elke winkel dat je daar voor op moet passen.

Net voordat ik dit las heb ik een topic gestart over de status Temporarily Unavailable, die voor een deel van de genoemde caches geldt. Dit topic hier gaat weliswaar over het leren van praktijk voorbeelden over wat er allemaal kan komen kijken bij een lokatie, dus is natuurlijk een andere discussie maar er is een raakvlak: als namelijk er van tevoren door de andere cache-ogen naar een nieuwe lokatie gekeken wordt, raakt de lijst met temp. unav. misschien niet zo veel langer!

Bij het kaartjes maken valt me elke week weer op dat er zo'n enorm groot aandeel caches met als status: temporarily unavailable tussen zit. Op dit moment zijn het er 57, van de in totaal 634 aanwezige caches in Nederland. Dat is nota bene 9%!!! Op zich is het logisch dat als er onderhoud is, of als iemand even niet naar z'n cache kan die gejoept is, of wat dan voor tijdelijke bijzondere omstandigheid er dan ook moge zijn waarom een cache niet beschikbaar kan, dat hij dan op temp. unav. wordt gezet. Maar sommige caches zijn m-a-a-n-d-e-n lang tot meer dan een jaar temp. unav. Eigenlijk zijn ze gewoon een soort van archived geworden. Tuurlijk: temporarily is een rekbaar begrip. Er zal dus altijd een wit, lichtgrijs, donkergrijs, maar zeker ook zwart gebied zijn. Laat iedereen daar alsjeblieft wel een beetje logisch in blijven nadenken en als het een beetje lang gaat duren: zet hem op archived zodat hij tenminste niet meer in de downloads terecht komt. Tegenwoordig is het prima mogelijk om een cache te unarchiven. (Dat is wel eens anders geweest en misschien stamt daar de vrees vandaan om te archiven.) Dit heb ik een keer aangemeld bij .com met het verzoek om een soort klok in te bakken die een cache automatisch archiveert als hij meer dan een zekere tijd temp. unav. is. Hun antwoord was dat dat de verantwoordelijkheid is van de plaatser en dat als het te lang duurt dat er dan maar een "this cache should be archived" logje geplaatst moet worden. Maar als een plaatser hier niet op reageert, dan gebeurt er gewoon niets. Voorbeeld: Night Crawlers and Travel Bugs. Geen idee of het voor hun moeilijk te implementeren is, daar werd geen uitspraak over gedaan. In elk geval neem ik aan dat we bij andere de andere 56 toch wel met z'n allen een normaal evenwicht moeten kunnen vinden?

Ga nou gewoon maar vast een nickname verzinnen...! Je kunt echt geloven wat JAKo schrijft.

Wauw Yvanka, dat klinkt als een ECHTE geocachers-spirit. Als ik jou was zou ik snel een gps kopen! Ennuh, als je dan wat ervaring hebt dan verwacht ik eigenlijk wel een cache van jou die een beetje op zo'n sneaky wijze verstopt is zoals je altijd al deed. De meeste caches liggen op redelijk normale plaatsen en gaan voor een groot deel om het wandelen en het natuurgebied, maar de andere soort: op bijzondere wijze verstopte caches: daar hou ik in elk geval zeker ook van! Maar om even terug te komen op het topic: wordt het nou Piep of Yvanka?

Tenzij..... hij z'n data net zo goed als wij ook niet uit de database kan krijgen van .com, toch?!?

Tja de ene is er wat rapper in dan de ander, niet?

Een offset cache is een cache waarbij een punt opgegeven wordt en je vervolgens daar ter plekke info krijgt waar de cache eigenlijk te vinden is (vaak wordt dit al snel een multi cache genoemd). Hoe, dus in welke vorm, de offset genoemd wordt en hoe hij verwerkt moet worden kan dus altijd anders zijn. In dit geval is het zaak om gewoon zo goed mogelijk op het gegeven punt te komen, slim te zijn, en dan ff een aha beleving krijgen! Dus inderdaad zoals Barnold zegt: "doe maar gewoon wat er staat en kijk om je heen". Verder ga ook ik niks verklappen, want dan is de lol eraf.

Nee joh! Da's helemaaal niet sneu... nou blijkt dat hij NOG harder kan gaan rijden (op 120-wegen althans). Ik denk dat Dennixx nou snapt waarom hij altijd zoveel werd ingehaald, of niet?!?

De laatste tijd merkte ik ook E-N-O-R-M-E performance problemen. Bij het downloaden van de kaartjesdata kwam er na een verzoek om een nieuwe pagina gewoon tientallen secondes tot soms minuten geen respons van de site. Men was weliswaar bezig met het opzetten van een nieuwe site, maar dat zou toch niet tot een opstopping in die orde hoeven leiden? Ook was het niet zomaar een periode van een week of twee, maar maanden. De vraag is of met de mate van groei van het geocachen een capaciteitsuitbreiding niet al snel richting lapwerk gaat, omdat de vraag als snel de uitbreiding weer kan overtreffen. Voorlopig is het, zoals het lijkt, na de overgang naar de nieuwe site opzet wel merkbaar beter. Waarom de opstopping niet wat verdeeld wordt over de wereld, dus d.m.v. de mirroring waar je het over had, dat begrijp ik ook niet. Kwestie van geld zou ik kunnen indenken. Want dan moet er dus ook ergens een vette mirrorserver opgezet worden. Toch lijkt me dit uiteindelijk de enige echte oplossing.

Hahaha, lijkt op het spreekwoord "Als de moderator van huis is...." (in vrije interpretatievorm).

Die had ik inderdaad ook al eens gemerkt. Een setje .loc files staat in de inbox van P-Terminator voor de poging om het te reproduceren. Maar daar heb ik hier verder geen melding van gemaakt, omdat ik in principe alles via de GarTrax supportlijn wil laten lopen. Echter voor het crashen had ik (dacht ik) een oplossing die voor iedereen als work-around kon dienen. Daarom had ik die bug hier maar wèl even vermeld. Laten we hier dus niet direct alles noteren waarvan we denken dat het een foutje is in het programma, tenzij P-Terminator dat wel graag hier wil hebben i.p.v. via de supportlijn. En... af en toe voutje valt wat mij betreft in het niet vergeleken met wat je kunt met het programma! Dit nog eens even ter welverdiende ophemeling!!! Greetz, Eagles (die collega's en Shikra vaak hoort zeggen: "Geef een softwarepakket met een bug aan hem en hij komt 'm tegen!")

M'n woordenboek meldt: lutin, gnome.

Eeh.... ik denk dat er hier wel een reply van de Prof zal komen: een pro-RD stemmer in hart en nieren!

Hmm, volgens mij heb ik een bugje gevonden en vermoedelijk een verklaring: als je eerst Gartrax opstart, vervolgens wat locfiles laadt en DAN pas internetverbinding maakt, dan crasht Gartrax als je start met downloaden. (Ik draai XP als OS). Ergo: maak eerst verbinding en start dan Gartrax op. Dat kan toch geen kwaad. Ha! Krijg ik nu, zoals vaak met gevonden bugs gebeurt, een fles wijn?!?

SuperdeSuperdeSuper dat hij het weer doet. Thanx!