Eagles

Trouwens Kruimeldief, even voor de duidelijkheid: het feit dat dit jou nu ff overkwam en dat er dus nu een mooi voorbeeld is om steeds aan te halen, wil niet zeggen dat ik dat bedoel als steken onder wat er naar jou hoor. Alhoewel... als ik je laatste verklaring lees over 'de download kwestie' was je toch wel heeeeel erg naïef bezig hoor.

Zeg Cachemier, ben je nou helemaal belatafeld? Van dit soort uitlatingen ("die vinden het blijkbaar niet nodig om te reageren") ben ik niet gediend hoor. Wat had je gedacht van de zinsopbouw "helaas hebben die nog steeds niet gereageerd, om welke reden dan ook", in plaats van zo hoog van de toren te blazen? Zelf hou ik helemaal niet van polemiek en meng me dan ook niet in soortgelijke schriftelijke meningsverschillen, maar DIT gaat me te ver, en daarom kom ik nu wel met deze reactie. Je hebt je mailtje verzonden naar geo@geocaching.nl op de datum die te lezen is in de header van de forward die ik gekregen heb: Dus maandagOCHTEND. Het kan natuurlijk dat dat inderdaad het 3e mailtje was in 5 dagen... zoals Geoman al zei heeft dat dan weinig nut, vooral in vakantietijd... een situatie waarin dus ook een handmatige ontvangstbevestiging niet mogelijk is (overigens: ik was niet op vakantie, bij mij speelt er een ander tijdsplaatje zoals je verder kunt lezen). Op woensdag heb ik de forward van geocaching.nl binnengekregen, die las ik dus 's avonds net voor het kaartjes maken. Na dat kaartjes maken + sporten (ja hoor, ook ik heb andere dingen te doen dan alleen geocaching gerelateerde zaken) heb ik 's avonds laat nog een start gemaakt om in gewone nette bewoording je mailtje te beantwoorden + uitleg te geven over het hoe en waarom wat betreft Frankrijk.De inhoud van dat mailtje krijg je dan bij deze maar zo, omdat het nu toch openbaar staat in het forum. Dan weet gelijk iedereen die het zich eventueel nog meer afvroeg hoe het staat met .loc files van Frankrijk. Dit stond er tot vandaag in m'n drafts folder. Ik wilde er nog een paar zinnen bijzetten over de kaartjes procedure in het kort. Niet om zielig te doen ofzo, maar gewoon omdat ik een soort 'verantwoording' wilde schrijven waarom dat er echt niet bij kan; een gevoel daarvoor aangeven. Ook iets over de recentelijke verandering van geocaching.com die impact heeft op de kaartjes-maak-tijd wilde ik erin zetten. Dat was ik net nu (de eerste kans die ik weer had) verder gaan doen, toen ik ineens dit topic zag.Maar dan ook nog: als je je ogen eens de kost had gegeven, dan had je al gezien en geweten dat het tijdelijk was, zoals ik ook in de laatste zin van m'n mail schreef. De blauwe titelbalk van het kaartjeswindow vermeldde dit, en in de gele balk boven het hoofdkaartje stond dezelfde tekst ook nog eens in koeienletters. Wil je dit nog even zien?!? Op de uitwijk website i.v.m. de toenmalige upload problemen naar de nieuwe geocaching.nl server staat toevallig nog een voorbeeld van het kaartje van 04-06: zie deze website. Tot slot: over een handmatige 'het-is-in-behandeling' reply heb ik het al hierboven gehad in combinatie met de vakantietijd, maar voor wat betreft een automatische reply op een ingekomen mail: schrijf jij dan maar zoiets voor de website zou ik zeggen, in plaats van te zeggen hoe je het gehad had willen hebben. Dien maar een voorstel in bij Geoman. Maar er zullen altijd wel zaken overblijven die beter/anders hadden gekund. Als er dan een frustratie ontstaat over zo'n punt, dan blijf je toch maar gewoon netjes.

Hier kan ik het niet helemaal mee eens zijn. Er wordt door diverse instanties op gewezen dat een teek oplopen overal fors in kans aan het toenemen is. Zelfs in de bosjes langs een trapveldje in de stad. Dus het is gewoon een kwestie van niet jezelf afhankelijk maken van een waarschuwing van een ander, maar altijd opmerkzaam blijven. Altijd een tekentje is dan niet nuttig meer. Van die Postbus51 meldingen wel bijvoorbeeld want die geven gewoon een algemene waarschuwing.

Als ik het zo lees dan vind ik dat Gartrax zich wat dat betreft behoorlijk netjes gedraagt. Dat je van een paar caches de inhoud geautomatiseerd opvraagt moet toch op zich geen probleem zijn. Als ik op pad ga voor een hele ris caches dan zou ik handmatig grotendeels dezelfde info toch ook al opvragen en is de hoeveelheid data die ik van .com vraag ongeveer hetzelfde: in de ene situatie handmatig, in de andere geautomatiseerd. Alleen ontstaat er natuurlijk wel een probleem als je onbewust een supergrote (en wellicht niet geheel nodige) datastroom gaat genereren. Als we daar met z'n allen rekening mee houden dan lijkt me dat .com er niet al te moeilijk over zal hoeven te doen. Het programma is opgesteld om dataverkeer in eerste orde te beperken, de gebruiker bepaalt vervolgens hoe heftig hij/zij het inzet.

AHA, dus jij bent één van die personen die .com soms qua performance onderuit trekt. Niemeer doen hè? Nee, zonder gekheid: als ik elke woensdagavond de .loc files van alle caches download, gewoon op de handmatige manier (dus pagina voor pagina met tegenwoordig 20 stuks per keer i.p.v. 25 ) dan merk ik heel vaak dat de respons na verloop van tijd dramatisch keldert. Een half jaartje terug kon ik supersnel nieuwe pagina's opvragen, tegenwoordig duurt het vaak lang voordat er überhaupt data terugkomt na aanklikken van een nieuwe paginalink! Het gaat zelfs tot een timeout aan toe! Er is dan gewoonweg nagenoeg geen, tot geen, dataverkeer. Het varieert hoeveel pagina's ik al gedownload heb voordat het wel eens instort, dus het zal niet aan de load liggen die ik leg op de server. Dit frustreert ENORM de download en wordt volgens .com voornamelijk veroorzaakt door mensen die over de hele wereld vette automatische downloads plaatsen. Dat trekt de server niet. Dus ook aan anderen: hou het beperkt wat je voor dataverkeer genereert vanaf geocaching.com .

Ik kan je de Coordinate Calculator van RDNAP van harte aanbevelen. Klik daar onder download (rechts in het menu) en je krijgt dan vervolgens de links naar dat programma en een eventuele handleiding (is niet echt noodzakelijk). Er zijn meerdere formules, door benaderingen, die zodoende ook verschillende nauwkeurigheden opleveren. Zelf zou ik het liefst zo'n programma gebruiken wat door DE bron van het Rijksdriehoekstelsel wordt verspreid. Tevens kun je dan off line werken. Waar ik zelf nou ook heel benieuwd naar ben, is of je met gebruik van dat programma i.p.v. de door jou genoemde website anders uitkomt of niet. (Onder verder volledig gelijke omstandigheden qua kaart en kalibratie.)

Ik denk dat het icoontje voor 'pas op teken' een overbodige is. Op ELKE lokatie waar begroeiing is, ook al is het alleen maar wat hoog gras, moet je rekening houden met teken. En dat ongeacht de ervaring van anderen. Want namelijk juist de keer dat je denkt dat het ergens qua teken wel meevalt en je minder alert zou raken, is de keer waar je het meest kans maakt om er eentje te lang niet op te merken. (De eerste 24 uur zijn van groot belang om hem nog gemakkelijk en zonder al teveel risico op besmetting te kunnen verwijderen.) Wat mij betreft geldt dus dat elk gebied altijd even verdacht is, los van het feit of er ooit wel of niet teken gesignaleerd zijn, tenzij het een stadscache betreft zonder begroeiing.

Kan het zijn dat je op één of andere manier grote hoeveelheden data van hun database zuigt? Daar hebben ze namelijk nogal een hekel aan en heeft al geleid tot IP-ban voor sommige personen. Er is zelfs al eens een hele provider eventjes de klos geweest omdat ze een hele range banden (i.v.m. dynamische IP adressen bij een inbel-situatie).

O.k. ik maak hieruit op dat jij 100m van Timboektoe woont?!? Eeh, oh, sorry, ik zal ff serieus worden. Omdat ik niet helemaal weet wat je precies bedoelt, schets ik gewoon even wat situaties: 1) Als je DE digitale mappen hebt van Nederland, stel bijvoorbeeld: geheel Nederland verdeeld over 3 CD's, dan hoef je natuurlijk NIKS te calibreren hè... even voordat je de hele problematiek voor niets op je hals haalt. Dat is al gedaan. 2) Als je map gebaseerd is (en dan bedoel ik gewoon: het plaatje, hoe het platgeslagen is vanaf de 'bol'vormige aarde) op Rijksdriehoeksmeting, dan moet je de 4 hoekpunten helemaal niet omrekenen bij het calibreren. Maar dan moet je ook calibreren in Rijksdriehoeksmeting en Dutch Grid. 3) Als je een in RD geijkt RD-kaartje hebt, hoe laat je dan iets omrekenen in WGS84? Weet je zeker dat je getallen afleest onder NB/EL als je het display datum in de statusregel ook daadwerkelijk op WGS84 hebt staan? Anders zit je RD-datum in lat/lon-grid af te lezen! 4) Als je buiten gemeten waardes opzoekt op de kaart, probeer je die waardes dan niet per ongeluk in de cijfers in te vullen van Dutch-RD grid notering? (No offence hoor, ik check het alleen maar.) 5) Als de afwijking ECHT bizar groot is, een halve aardbol bijvoorbeeld: heb je niet Ooster- en Westerlengte verwisseld bij het invullen? Het kan natuurlijk zijn dat ik je vraag volledig verkeerd lees, stuur me dan nog ff meer in de richting van wat je dan wel bedoeld! Maar in elk geval: wanhoop niet, dit moet gewoon opgelost kunnen worden.

O.k: doe ik er nog één. Ik had gedacht dat er al wel een ander mee zou komen, maar dan doe ik deze nog zelf. De Grote/Kleine Beer / Steelpannetje zijn wel bij iedereen bekende termen denk ik. En er was iets met een Poolster in die beren... de Kleine Beer draait om de Poolster heen, die het noorden aangeeft. Probleem is meestal om de Kleine Beer te vinden (hij is relatief zwak en valt daarom minder snel op). Dat gaat gemakkelijker via het beter zichtbare Steelpannetje uit de Grote Beer. Dat Steelpannetje is een beetje scheef opgerekt vierkant, met een steel eraan van 3 sterren in een knik. Op deze pagina is het Steelpannetje in de plaatjes te zien: de steel is de staart en de 4 sterren die het vierkant vormen maken onderdeel uit van de rug van de Grote Beer. Als je nou de korte lijn van het vierkant die tegenover de steel zit (dus niet de korte lijn die aan de steel zelf vast zit) neemt en legt 5x die lijnlengte in het verlengde van zichzelf erbij, dan kom je uit bij de Kleine Beer (klein steelpannetje). De Poolster, die dus zoals gezegd in het Noorden staat, is de punt van de steel van het kleine steelpannetje. (Let even op dat je het verlengen van de lijn doet in de goede richting: van de bodem van de steelpan naar boven toe. Anders kun je lang zoeken naar de Kl*te... eeeh Kleine Beer. ) Nou kom op mensen, er zullen toch vast nog wel meer mogelijkheden zijn om N/Z te vinden?!? Wie? Deze twee waren de twee die ik zo ken, maar er moet toch meer zijn (gemakkelijk dan wel moeilijk toepasbaar)? Anders is het topic wel gauw ten einde.

Wat ik heb gedaan als work-around, is in de header van de .loc file de nieuwe term src="Groundspeak" vervangen door wat daar eerst stond: src="EasyGPS". Toen wilde Gartrax hem weer inlezen. Kwestie van header-herkenning dus? Lijkt me hoop ik gemakkelijk op te lossen Pieter?

Kijk! Dat zijn nou leuke aanvullingen om te weten. Het valt mij dan overigens mee dat de fout zich beperkt tot graden als gevolg van de correcties. Dat valt inderdaad binnen de fout die je zowiezo al maakt door het voldoende goed richten van de kleine wijzer op de zon en het bepalen van de bisectrice. Wat ik zelf wel grappig vond is de literatuur waar ik deze truc in heb gelezen: het Zwitsers telefoonboek ! Daar stond een hele ris pagina's in besteed aan problemen die zich in de bergen voor kunnen doen (verdwalen, overstromingen in een dal, kou, etc.) plus wat 'eerste-hulp-bij-problemen'.

In dit draadje staat: Dit lijkt me wel een leuke aftrap voor een topic over kompasrichting zonder GPS/kompas. De truc, Prof, voor zover ik die ken is: - Eerst even je (wijzer- )horloge op wintertijd zetten of denken. - Richt de kleine wijzer op de zon. - Neem de kleine hoek tussen de 12 uur en de kleine wijzer. - Deel die door twee (oftwel, neem de bisectrice). - Die lijn wijst het zuiden aan. Hoe precies dit is weet ik niet. Als iemand daar een aanvulling op heeft: graag. Ik kan me namelijk zo voorstellen dat dit trucje afhangt van je lokatie qua Noorderbreedte en/of de hoek van de aardas en dat er dus een correctie nodig is op de genomen hoek.

Eerst een cache waar je dus niet in moet stinken als je wilt gaan klimmen: Climbing in the Ardennes. Dit is echt een (te) simpele cache. Alleen een stukje over asfalt tegen een heuvelhelling, in de kale vlakte. Het is dat er een paaltje in de weg stond, anders had ik hem van achter het stuur zittend in de auto kunnen pakken en loggen. Zelf vond ik FDC een mooie. Redelijk kort, maar de wandeling er naartoe heeft een mooi stukje uitzicht. GEEN gebruik maken van de klimfaciliteiten daar. Dat is NIET nodig. Een paar waar je ondanks dat het een 'normal' is toch redelijk wat loopt (vanwege het karakter van de bossen in de Ardennen, i.t.t. het vlakke Nederland waar overal wel een paadje is te vinden): * Geocache (degene van Mr. Baggins), vanaf de lokatie waar wij startten redelijk lastig tochtje. * Snoopy, kun je op 2 manieren doen: the normal way of... the hard way. Wij namen achteraf gezien de hard way. Een beetje link misschien, zonder juiste zekeringsgear. * als me nog meer te binnen schiet dan edit ik dit berichtje nog wel.

Die pagina ziet er schitterend uit! Handig om in te vullen en er rolt een mooie lapje tekst/html uit. Het lijkt me ook voor wandelwagenduwers (is toch inderdaad bij het cachen ook een soort van "handicap") prima bruikbaar om af te schatten. Ik heb het eens in zitten vullen voor onze 12 Steden 13 Ongemakken (Nijmegen) en binnenkort gaan we deze ook eens echt doen met een rolstoel. Aan de hand van deze twee gegevens zal ik eens kijken om de info erbij te zetten. Voor nu alvast even: deze cache komt in totaal ongeveer neer op 6.5km (auto tot auto). Er zit in het centrum van Nijmegen wel wat hoogteverschil, wat alleen wat problemen oplevert als je een paar trappen moet nemen. Die vallen echter allemaal te omzeilen. De langste helaas alleen met een redelijk grote boog, maar ja... dat is niet voor niets de langste trap.

Overigens moest het genereren van de locfile inderdaad wel worden aangepast om tot klikbare caches in CacheMaps te leiden (jij gaf dat probleem toen ooit eens aan). De gedownloade brokken van 25 caches per locfile werden eerst met Geobuddy gemerged tot één, maar die knikkerde de URL info er uit . Nu worden ze onder DOS ( ) met "copy file_1.loc + file_2.loc + ... + file_x.loc totaal.loc" samengevoegd, waarnaar het teveel aan headers met een macro eruit gesloopt wordt en nog wat andere formattering gedaan wordt ter eventueel nodige leesbaarheid. Even enigszins off topic: Wat voor info heb je dan offline als je de Pocket Query gebruikt? Gewoon de hele cache pagina? In dat geval: als je geheel Nederland laat toesturen... is dat niet een enorm bestand... voor een arme 56k-inbeller als ik? (Interesse omdat ik sinds een tijdje een PPC heb.)

Nou, ik zal toch even reageren ondanks dat je niet fout redeneert hoor. Zelf gebruik ik ook Ozi via het Garmin protocol en dat gaat prima. Het enige nadeel is dat er een welbekend stukkie navigatiesoftware, dat naar zijn zeggen en keuzelijstje ook dat protocol ondersteunt, dan volledig van de leg raakt. De hele PocketPC moet dan worden gereset. Het werkt pas als ik daar nmea kies op 4800baud. Nu zit ik dus steeds te swappen in de GPS tussen de 2 protocols. Het Garmin protocol ondersteunt namelijk meer uitgebreide info en gebruik ik daarom dus liever in Ozi.

Maar als ik in Ozi in de kalibratie van kaartjes onder "Map Projection" kijk, dan staat daar: Lambert Conformal Conic Merkwaardig dat het dan toch niet kan voor het grid!?!

Toch zal een geprogrammeerde luxe variant van een kaartje op geocaching.nl moeten komen van mensen zoals jij bijvoorbeeld.... Ennuh even over dat wiel en accoordje: helaas zit e.e.a. wat ingewikkelder in elkaar. Zelf ben ik ook altijd voorstander geweest van bundeling van krachten en van niet twee keer een wiel uitvinden. Want als er uiteindelijk met veel moeite en tijd twee keer nagenoeg hetzelfde ontstaat... wat voor toegevoegde waarde heeft het dan?

Even ter check: heb je ècht niks anders zitten op compoorten 1 en 3? Bijvoorbeeld muis, modem om maar eens wat te noemen?

Worden dan ook al je oude logs op caches met terugwerkende kracht omgezet? Oftwel: hoe dynamisch zou die data zijn? Iemand ervaring? Trouwens Kipje, als je nou nog eens een kleine krijgt... noem hem/haar dan Peter/Petra! Dan kun je nog uitbreiden naar Kippetje...

Hoe denk je dat dat bijhouden gebeurt?... Juist... alle data WORDT van geocaching.com gedownload. Elke week, met de hand, voor alle landen die er op voorkomen zoveel keer als de formule "omhoog.afronden(aantal_caches_in_dat_land/25)" als uitkomst heeft. Omdat tegenwoordig geocaching.com een zeer trage respons heeft na een x aantal van dat soort downloads ben ik hier elke week ongeveer een uur mee bezig wat een jaar terug nog een 10 minuten was. Geocaching.com biedt deze data wel aan hoor: tegen betaling. Je kunt ook proberen hun database te zuigen, maar dat vereist programmeerkennis/toestemming om iets op een server te draaien en met dat dataverkeer zijn ze bij .com zeker niet blij! Na het downloaden wordt een redelijk aantal bewerkingen uitvoeren op de data om die te formatteren en op soort te groeperen. Dan na de bewerkte data ingelezen te hebben worden alle kaartjes uitgeschreven zoveel als er ingezoomde versies moeten komen, en vervolgens wordt weer per kaartje de uitgeschreven html bewerkt om er een tooltip in te knutselen. (Daartoe is geen mogelijkheid binnen het programma.) Als dit is gebeurd dan nog even alles in de huisstijl gieten per kaartje.Zoveel mogelijk wordt geautomatiseerd zover ik er kennis van heb: met macro's, want programmeren kan ik niet. Die macro's besparen al ENORM veel tijd: anders was het niet te doen. Nu valt het met de huidige situatie te behapstukken. Je begrijpt het: in deze werkwijze komen er zeker niet meer en verder ingezoomde kaartjes. Aan de andere kant vraag ik me af of als er caches over elkaar vallen op de ingezoomde kaartjes, het niet verstandiger zou zijn om in een ander gebied waar nog meer ruimte is eens een cache te plaatsen, in plaats van vlak naast een andere in hetzelfde gebied. Dat komt de spreiding ten goede want er zijn nogal wat supervolle en flink lege gebieden te vinden. En die flink lege gebieden zijn al erg lang flink leeg terwijl er in de Randstad en in de provincie Utrecht m.i. veel te veel caches op kluitjes komen. Het is niet erg origineel meer als je bijna struikelt over de caches. Als je je aanbiedt of iemand weet die dat wil doen: graag. Want ik neem aan dat als je zo voor de vuist weg wat van dat soort programmeerkreten uit, dat je er wel genoeg verstand van hebt om een inschatting te maken of die uitingen ook wel realistisch zijn! Waarom? Onder het indexkaartje van de BeNeLux staan toch de voor die kaartjes gebruikte databases samengevoegd in één bestand per land in .loc formaat?

Nee daar kan ik het niet echt mee eens zijn. Het is een internationale sport en daarom vind ik dat het primair op een internationaal systeem gebaseeerd moet zijn. Dat er secundair eventueel daaraan parallel een nationaal systeem voor de liefhebber staat, dat kan ik me dan nog voorstellen. Echter wordt het dan voor de plaatser dubbel werk. Ik moet er niet aan denken dat (als ik geen verstand zou hebben van kaartdata en grids) ik ergens in Verweggistan al geocachend geconfronteerd zou worden met één of ander lokaal datum en grid. Daar zou ik dan als leek goed de pest over in hebben als daardoor de cache te lastig c.q. ondoenlijk zou worden. Het buitenland heeft toch al een forse barrière: taal. Dat is vaak al lastig genoeg.

ALLE?!?..... ALLE?!? Nou, NIET de Garmin Venture hoor!!! (boos is tegen Garmin, niet tegen jou). Maar... het enige wat die upgrade doet is rekening houden met het spanningslevel van een oplaadbare batterij. Een 100% volle staaf in je gps batterijstatus tekentje was normaal overeenkomstig een 100% volle niet-oplaadbare batterij. De firmware upgrade zorgt ervoor dat 100% staaf overeenkomt met het (normale lagere) 100% vol niveau van een oplaadbare batterij zodat het wat meer de werkelijkheid aangeeft. Dit is allemaal een beetje simpel neergezet, want wàt 100% vol is bij een batterij en hoe het verloop is gedurende de ontlaadtijd is allemaal veel complexer maar hier niet zo van belang. Verder hoef je dus niet te upgraden òm een oplaadbare batterij te mogen gebruiken.

Maar als ik dit zo eens lees: dan lijkt alsof het Zeke wèl is gelukt. Vanwaar nu die verschillende resultaten?