Eagles

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?!?

Als je reply't (of hoe schrijf je zo'n Anglicisme in hemelsnaam) op een PM in het forum dan staat er bovenaan: Die "OR" is nog wel een vertalinkje waard. Het zal er denk ik ook wel staan als je een nieuwe PM opstelt, maar dat mag je zelf controleren.

SuperdeSuperdeSuper dat hij het weer doet. Thanx!

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.

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.

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.

Gelukkig was het in de source code inderdaad mogelijk om rücksichtloss alle alt's te vervangen door title's. Er ontstond nergens anders een probleem, dus de macrootje ietsies uitgebreid... en klaar was het weer. Zit ik me daar de afgelopen week startklaar om die nieuwere macro toe te passen: blijkt geocaching.com de gedownloade .loc files anders in elkaar gezet te hebben . Grrrr, toen kon ALLES op de schop. Gelukkig was ook dat relatief rap te doen. Gevolg is dat ik niet zeker weet of de .loc files die ik samenstel met alle caches van één land erin, degene die dus onder de hoofdkaart staan, nog volledig compatible zijn met de diverse pakketten (bijvoorbeeld met CacheMaps van Bigbird, dit kan ik zelf niet checken omdat ik onder de software eis voor CacheMaps zit). Als iemand iets bijzonders merkt in de combinaties van die .loc files met welk pakket dan ook: laat het me ff weten.

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.

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.

O.k. Kees-Jan ik zal er eens een poging aan wagen. (Verwacht het niet de eerste twee weken hoor... het zal even tijd kosten.) Ik had overigens wel bij het attribute gekeken hoor, ook bij de paragraaf die je quote. Maar daar wordt geschreven: "Please consult an element's definition to verify that it supports this attribute."... tja, zodoende verzandde ik in de area-element omschrijving. Op de pagina's die P-Terminator aangeeft wordt ook aangegeven wat ik dacht te halen uit dat hele gedoe bij w3c: title is een core-attribute binnen de standard-attributes, die weer binnen de area-element definitie vallen. Tussen alle lastige html berichtjes door ook nog een berichtje aan overige lezers: De kaartjes update van 4 juni is weer te vinden op: http://home.zonnet.nl/mirwalt omdat de upload naar geocaching.nl nog steeds niet mogelijk is.

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.

Phew.... dat is ff spitten in taaie definitie kost zeg, vooral in de tweede link en na wat doorklikken! Maar dan heb je ook wel echt de goede definitie te pakken en daar hou ik wel van!! Dáár kom ik nou helaas niet helemaal uit, of nu ineens misschien toch (na tig keer lezen). Er staat op die pagina een stukje met als kopje: "Attributes defined elsewhere", rechtstreeks na "AREA attribute definitions". Of ze nou bedoelen dat die tweede lijst attributes er wel of niet bijhoren dat zie ik niet.Òf zou ik de conclusie mogen trekken dat 'title' is toegestaan door de tekst in het kleurige stukje net boven die kopjes te bekijken: in: <!ATTLIST AREA staat: %attrs; met daarachter: %coreattrs die link volgen..... daar staat 'title'!!! Zo zou het inderdaad te implementeren kunnen zijn, daar had ik wel aan gedacht hoor (no offence)... maar ik moet even kijken of het met de overige title en alt definities dan nog goed blijft gaan in de macro. En het belangrijkste: als het maar aan de officiële html definitie voldoet en daarin krijg ik steeds meer vertrouwen. Anders zou bijvoorbeeld een probleemverschuiving kunnen optreden naar weet-ik-het-wat-voor-browser-nou-weer. Als je nou nòg één link kunt produceren, waarin ze hun notatie-definitie uitleggen (om te checken of ze met die %attrs inderdaad bedoelen wat ik erachter zoek)........... dan ben ik een heeeel eind over de streep om de implementatie een keer te bekijken.