fietspomp

Mooi macro. Bedankt voor de link. De macro is slim genoeg om geen API calls te verbruiken als de informatie er al is. Lijkt ook geen probleem te zijn als je een gemengde database hebt met founds en andere caches. Waarschijnlijk een beter oplossing voor wat Francorius wil.

Dat kan in principe. Op gc.com ga je naar jouw profile, hier staat een link naar membership features (zal je wel premium member voor moeten zijn). Bij Membership features heb je de mogelijkheid van pocket queries (PQ). Als je hier op klikt krijg je een overzicht van je huidige pocket queries. Helemaal onderaan staat de optie 'My Finds' en wanneer je deze voor het laatst hebt aangevraagd. Als je op de knop 'add to queue' drukt wordt er een pocket query gemaakt waarin al jouw founds staan. Het kan een paar uur duren voordat hij aangemaakt is maar dit gaat meestal vrij snel. Let op deze speciale PQ kan je maar eens in de drie dagen aanvragen. Je krijgt een mailtje dat hij klaar is. Download de PQ naar jouw PC. Ga naar GSAK. Maak een nieuwe database aan en laad de PQ in die database met load gpx/loc/zip. Je kan de PQ dus rustig gezipt laten. Succes.

'Gewoon' zoeken op naam lijkt niet meer te kunnen. Bij het hoofdmenu moet je een locatie aangeven. Daarna kan je bij advanced search rond die locatie (max straal 50 km) op naam zoeken. Dit werkt nog wel. Als je geen locatie opgeeft en direct naar 'add filters' gaat staat er 'Searching without a location'. Als ik hier op naam zoek dan wordt er nooit iets gevonden. Wereldwijd zoeken lijkt dus via gc,com niet meer te kunnen. Beetje jammer dus.

attributer.gsk kan een overzicht van attributen in een database maken. Voor GSAK 8.4.0.0 geeft het een waarschuwing maar werkt verder zo te zien nog goed. Je krijgt een html overzicht van welke attributen er zijn en welke caches een bepaald attribuut hebben (maximum stel je zelf in). Eigenlijke doel van de macro zijn challenges maar je kan de macro natuurlijk ook gebruiken om een overzicht te maken. Ik vroeg mij wel af of het niet net zo makkelijk is te filteren in GSAK op bijvoorbeeld 'special tool required' e.d.

Misschien is je database met logs zo groot geworden dat je geheugenproblemen hebt. Je kan een aantal logs purgen en een repair/defrag op je database doen. Beide opties zijn te vinden onder het database menu. Voor gebruik even een backup maken geeft altijd de mogelijkheid om terug te gaan naar het origineel.

Voor het toevoegen van foto's kan je gebruik maken van de GSAK macro SendImagesToGarmin.gsk zie GSAK forum discussie (in het Engels). Hoewel ik zelf voor multies toch altijd op een printje vertrouw.

Werkt perfect, je moet alleen niet die zooi die uit de pocket queries van Groundspeak inc. gebruiken, maar zelf je eigen gpx bestanden genereren. Geen idee of dat in GSAK of zo kan, ik heb daarvoor mijn eigen scriptjes geschreven. Tc Dan moet ik misschien iets duidelijk aangeven wat mijn probleem is. Je kan inderdaad zonder problemen je eigen gpx files maken met (custom) symbolen. Echter deze symbolen worden voor de 'geocaches' genegeerd. Voor de geocaches wordt gekeken naar 'Traditional Cache', 'Multi-cache' etc. Voor deze categorieën kan je ook een ander symbool definiëren. Wat echter niet kan (ik in elk geval niet) is aan bijvoorbeeld twee caches van het type 'Unknown Cache', twee symbolen toekennen en ze ook nog als geocache door de GPS laten herkennen. Bijvoorbeeld een symbool voor opgeloste puzzels en een voor niet opgeloste puzzels of bijvoorbeeld een apart symbool voor caches met veel geo d'ors of favorieten (zie ook J-threads opmerking). Natuurlijk zou dit wel kunnen door zelden gebruikte types zoals 'Project APE Cache' te 'hergebruiken' maar dat is een beetje omslachtig en een beetje beperkt in mogelijkheden. Voorlopig gebruikt ik de GSAK export macro truc met POIs maar als het slimmer kan dan ben ik benieuwd. En ja ook in GSAK kan je een gpx file inlezen, bewerken en wegschrijven dus daar zijn zeker mogelijkheden.

Zoals Technetium aangeeft kan je deze gewoon naar Garmin\CustomSymbols kopieren. Echter de combinatie paperless geocachen (gpx files) en custom symbols werkt niet echt. Verder moet je even op het precieze formaat letten omdat dit net anders is als wat op een 60csx werkt. Zie ook Custom Symbols (in het Engels).

Ik ben wel geinteresseerd als het een oude 60cx is met SIRF chip. Bram.

Ik denk dat je er in dit geval van uit mag gaan dat de cachelegger je wilde helpen door aan te geven dat je naar het Westen (270 graden) moet maar dat er geen pad rechtstreeks naartoe gaat. Mogelijk kan je er wel komen door eerst wat richting het zuid-westen te gaan en dan richting het noorden.

Het idee achter het experiment was om duidelijk aan te geven waar de Garmin fout gaat. Tussen de punten is er met een andere snelheid gelopen. Afhankelijk van de snelheid geeft de software een zeker gewicht aan de positie-informatie (vast met een Kalman-achtig filter). Echter met de oude software werd aangenomen dat je op je oude plek was blijven staan bij snelheden onder de 0.8 km/h. Dus zelfs als je langzaam wegliep werd dit genegeerd. Tijdens het eerste deel was de snelheid 0.4 km/h, het tweede deel in twee stukken een met 0.8 km/h en een met 1.6 km/h, het laatste deel met 3.5 km/h. Tijdens het eerste deel raakt de Garmin de kluts kwijt, tijdens het tweede deel wordt dit alleen maar erger aangezien de positie wel een beetje wordt aangepast maar onvoldoende en daardoor loopt het verschil tussen de virtuele positie en de werkelijke positie alleen maar op, tijdens het laatste deel is de snelheid hoog genoeg dat de positie-informatie voldoende gewicht krijgt om de virtuele positie weer dichtbij de echte positie te krijgen. Op het eind lopen de roze en witte track weer gelijk en is het eindpunt, binnen de meetnauwkeurigheid, identiek. Dit corrigerende vermogen bij normale wandelsnelheden is een van de reden dat het probleem vaak niet opvalt.

Kennelijk merken weinig gebruikers het maar het is/was een structureel probleem voor de Oregon/Dakota/62 bij snelheden onder de 0.8 km/h. Tot nu toe maar een 78 met een (zeer) oude software versie gezien die het probleem niet had. Zie plaatje voor een experiment met de 62 maar de Oregon heeft precies hetzelfde probleem. Het gaat daarbij niet alleen om de route maar ook om de gemarkeerde punten die voor beide op dezelfde plaats zijn genomen, een GPS in de linkerhand en de andere in de rechter hand . Bij de 60cx met een beter dan 4 meter nauwkeurigheid en met de 62s met 100% vertrouwen. Als je kijkt naar bijvoorbeeld het punt 'crossing' dan zit daar een verschil van 100 meter tussen. Verder ben ik netjes over het fietspad gewandeld zoals de roze track aangeeft en niet over het water gezwommen en door greppels gegaan zoals de witte track aangeeft. Met de software update vallen de tracks over elkaar.

Ik merk wel dat sinds versie 5.50, de nauwkeurigheid sterk afhankelijk is van de snelheid waarmee je beweegt: wij gebruiken de Oregon ook vaak om met de auto naar t begincoordinaat/parkeerplaats van een multi te navigeren. Als we dan vervolgens uitstappen en gaan lopen, is de Oregon blijkbaar nog ingestelt op de gemiddelde snelheid van de auto en klopt de GPS van geen kanten (blijft vaak 'hangen' op punt waar we zijn uitgestapt). Even uit/aan verhelpt dit. Ik vermoed dus dat voor de GPS berekening in versie 5.50 de gemiddelde bewogen snelheid wordt meegenomen in de berekening om zo een nauwkeurigere berekening te kunnen doen. Ik kan in elk geval bevestigen dat het probleem dat de positie van de GPS niet meer werd bijgehouden bij lage snelheden is opgelost. Met de vorige software versies kon je 100 meter weglopen zonder dat de GPS dat in de gaten had. Ik heb geen testen gedaan bij hoge snelheden en dan stoppen maar als dat niet goed gaat dan heeft Garmin nog wat huiswerk te doen. In elk geval ben ik blij dat het 'lage snelheid' probleem is opgelost .

Pandora bedankt voor de extra informatie. Goed idee van topzoekertje voor de andere projectie. Ik ben het eens met Bloodwoosj dat het een soort vervorming lijkt. Waarschijnlijk tussen 90-180-270 graden een afwijking richting het zuiden en tussen 270-360-90 een afwijking naar het noorden. Het rare is een beetje dat de afstanden wel lijken te kloppen. Dus nog wat nieuwe ideeen: - projectie 268 graden 500 meter (verwachting afwijking naar het zuiden) - projectie 270 graden 500 meter - projectie 272 graden 500 meter (verwachting afwijking naar het noorden) Er was ooit een Mapsource versie (Garmins software voor kaartbeheer op de PC) die cirkels als ellipsen op de kaart weergaf omdat er op een rare manier 'gecorrigeerd' werd dat de lengte van een 'graad' in de longitude richting (oost-west) afhangt van de latitude (noord-zuid). Dit is iets anders maar mogelijk wel een probleem met een verkeerde correctie. Dus nog een idee: - projectie 150 graden 500 meter vanaf 00 00.000N – 000 00.000E (snijpunt van de evenaar en de Greenwich meridiaan). Mogelijk gaat deze projectie wel goed. Het coordinaat dat jij krijgt voor 1000 meter, 51 28.804 N - 003 32.962, is bijna identiek aan dat voor 500 meter, 51 28.804N - 003 32.964E. Dat is erg raar. Misschien twee keer 500 meter gebruikt? Eigenlijk was mijn suggestie om over 1000 kilometer te projecteren in plaats van 1000 meter. Mogelijk wordt er een algoritme gebruikt dat niet goed werkt voor korte afstanden maar wel redelijke resultaten geef voor lange afstanden. Kijk maar welke suggesties je wilt uitproberen. In zie ik dat er voldoende mensen zijn die mee willen denken.

Het lijkt dus een systematisch probleem. Geen duidelijk idee waaraan het ligt maar ik kan mij twee experimenten voorstellen die misschien meer inzicht geven. 1) Projectie met magnetisch Noorden (Magnetic) in plaats van het echte Noorden (True North). In Nederland is dat bijna hetzelfde dus dezelfde projectie van 150 graden 500 meter zou bijna hetzelfde resultaat moeten geven. 2) Projectie over 1000 km over 150 graden. Dit zou of N 43° 30.439 E 9° 43.712 geotools.xls of N 43° 30.439 E 9° 44.252 GSAK great circle/GCTool 1.6.1/geotools(web) of N 43° 30.735 E 9° 43.030 GSAK high accuracy/GCT 1.12/Global of N 43° 31.029 E 9° 43.865 Garmin 62s (onbekende methode) moeten geven of iets dat daar in de buurt zit . Het verschil tussen de methodes op korte afstand is veel minder groot en kan niet jullie verschil verklaren. Het geeft trouwens wel aan waarom cacheleggers bij projecties over kilometers wat marge moeten nemen omdat er wel wat afwijking kan zijn.

Met nekraV en Vinnie heb je twee goede cachers te pakken om samen op pad te gaan. Dus dat gaat zeker lukken. Het belangrijkste bij het caches is natuurlijk dat je er plezier in hebt. Als de uitdaging belangrijk is dat vinden jullie moeilijke caches misschien het leukst. Als je meer voor de wandeling gaat dat misschien een route zonder rare vragen. Als je gewoon veel caches wilt vinden dan neem je een power-trail. Het mooie aan cachen is dat er voor iedereen wat bij zit. Een drie sterren cache is best te vinden als beginner, zo zie ik dat onze eerste cache een 2.5 sterren mysterie/multi was. Met meer ervaring wordt het natuurlijk makkelijker. Zo zal je merken dat als een nieuw berekend waypoint op een onwaarschijnlijke plek ligt, er waarschijnlijk iets fout is. Ook als het volgende waypoint heel veel verder weg ligt dan de vorige waypoints heb je vaak iets fout gedaan. Meestal een goed moment om de berekening nog eens na te kijken, heb ik de juiste antwoorden opgeschreven en heb ik het juist ingetikt. Natuurlijk zal je dit niet altijd helpen. Soms is een waypoint gewoon weg, doe je gewoon iets fout zonder het te merken of is de cacheplek bezet. Cachers gaan hier verschillend mee om. Meestal zie ik het als een kwestie van jammer en ga ik ervan uit dat ik nog weleens in de buurt kom. Thuis ga ik nog eens nadenken, lees ik wat oude logjes, stuur mogelijk een mailtje naar de eigenaar en hoop ik op wat nieuwe inzichten die de volgende keer helpen. Ook het seizoen kan helpen de zomer met veel begroeiing kan het veel lastiger maken dan de winter als het kaal is (maar soms wel weer bedekt met sneeuw). Laatst de eindcache opgezocht waar ik twee jaar geleden al bijna was en vorige week een stukje van een multi gelopen waar ik vier maanden geleden mee begonnen was. Zeker als de cache wat verder weg ligt zal het meestal niet meteen de volgende week zijn dat ik weer die kant op ga. Gelukkig blijven de meeste multies wel lang liggen in Nederland. Soms ben je natuurlijk ook te laat zoals bij een cache die net voor mijn neus gearchiveerd werd, jammer maar voor mij niet zo erg. Natuurlijk vindt niet iedereen het leuk om weer terug te komen dus er zijn ook genoeg cachers die een belletje in het veld zullen plegen naar iemand voor extra informatie. Een standalone GPS zal waarschijnlijk niet heel veel nauwkeuriger zijn dan jullie huidige 'app'. Dus dat is meestal niet de belangrijkste reden om een aparte GPS te kopen. Weten wat standaard verstopplekjes zijn helpt meestal veel meer om caches te vinden. Het voordeel van een standalone GPS zit er meestal in dat ze beter tegen regen kunnen en dat ze langer werken op een setje batterijen (dat je ook nog kan vervangen). Verder is er ook een zeer brede keuze in GPSsen (touch-screen of toetsen, met of zonder kaarten, groot scherm of lekker compact, etc.). Door eerst de app te gebruiken is het makkelijker om jullie wensen te bepalen voordat jullie een eigen GPS aanschaffen. Een keertje meewandelen of een GPS van iemand lenen helpt natuurlijk ook om de voor- en nadelen te vinden aangezien dit vaak ook erg persoonlijk is. Succes en veel plezier met het cachen, Bram.

Zo te zien werkt het postcode zoeken wereldwijd en ik denk dat in sommige gevallen de 'Nederlandse' postcode in een verkeerd land wordt gezocht. Leusden doet het goed met 4 cijfers en 2 letters, Eindhoven gaat fout. Echter als ik er achter spatie NL toevoeg wordt wel de juiste informatie getoond. Dus 5653 en 5653XX gaan fout maar 5653XX NL of 5653 NL gaan goed.

Het klopt dat er een soort Kalman filter wordt gebruikt. Verplaatsingen met hoge snelheid krijgen veel meer gewicht dan verplaatsingen met lage snelheden. Dit is ook wat je graag wil omdat je anders een hele trage respons van je GPS hebt en deze constant achter loopt. Het probleem ontstaat doordat in de huidige instellingen verplaatsingen met een snelheid onder de 0.8 km/h (0.5 mph) een gewicht van nul krijgen. Door langzaam weg te lopen blijft de GPS hangen op het oude coordinaat, deze data wordt gezien als ruis. Dit is uitstekend voor als je een GPS in een auto hebt want die zal nooit zo traag bewegen. Echter voor handhelds gaat dit dus duidelijk mis. Bij geocaching zal dit meestal beperkt blijven tot een extra afwijking van minder dan 10 meter maar als je op een meer dobbert of een berg beklimt kan het rustig meer dan 100 meter worden.

Het gaat niet om het snel wandelen. Je mag rustig een uurtje wachten op de punten. Het gaat er om dat als je langzaam wegwandelt je GPS blijft hangen op het coordinaat en dat je daardoor grote afwijkingen kan krijgen (ook als je daarna stilstaat en met average waypoint een coordinaat bepaalt). Ik ben blij dat jij tevreden bent maar ik vind het in elk geval erg jammer dat de GPS niet betrouwbaar is.

Eigenlijk verwacht ik dat het een vrij algemeen probleem is bij veel nieuwe Garmin series. Het valt gebruikers vaak niet op omdat voor grotere afwijkingen je gedurende langere tijd langzaam moet lopen in een richting. Bij geocaching loop je vaak heen en weer dus blijft de extra afwijking beperkt of krijgt de cachelegger de schuld dat het coordinaat niet klopt. Ook bij mijn sporadische gebruik van onze Oregon 450 viel het mij niet op. Pas toen ik een 62s als vervanger voor mijn 60cx had viel mij direct op dat het niet het gebruikersinterface is maar de software. Aangezien het een software probleem is kan het zijn dat oudere SW versies het probleem niet hebben. Bij de 62 wordt er in elk geval vanaf versie SW 2.60 geklaagd (ik heb zelf getest bij 2.80/2.90/3.40). Voor de Oregon neem ik aan dat het probleem in elk geval vanaf SW 3.90 bestaat maar heb ik dat maar bij een SW versie getest. Een manier om het probleem te testen is: Neem een open terrein met goed GPS-ontvangst. Loop snel naar een punt en markeer dit punt. Loop snel naar een tweede punt dat 60-100 meter verder ligt en markeer dit punt ook Loop nu heel langzaam terug naar het eerste punt, let er hierbij op dat de snelheid op de GPS 0.0 km/h is. Dit houdt in dat je onder de 0.8 km/h loopt. Als de GPS ook lage snelheden weergeeft, bijvoorbeeld 0.3 km/h zoals bij de 60cx dan is er waarschijnlijk geen probleem en dus ook geen extra afwijking. Langzamer dan 0.8 km/h op vlak terrein is erg langzaam, een halve stap per seconde, en af en toe zal je een snelheid boven de 0.8 km/h komen maar dat is niet erg zolang dat niet te vaak gebeurt. Op de GPS zal je dus wel een beetje in de goede richting verplaatsen maar minder dan in werkelijkheid. Als je sneller dan 1.6 km/h loopt dan zal de GPS snel de positie bijwerken. Als je in werkelijkheid weer bij je eerste punt bent markeer je dit punt weer. Als de GPS denkt dat je nog steeds tientallen meters verwijderd bent van het eerste punt dan komt dat door dat langzame verplaatsingen door de GPS genegeerd zijn en je niet boven de 1.6 km/h bent gekomen. Als je de GPS uit en aanzet zal de GPS weer het correcte, eerste waypoint weergeven als coordinaat. Voor een voorbeeld op de 62s. Afhankelijk van hoelang je bereid bent om langzaam te lopen kan je grote afwijkingen krijgen. Bij geocaching zal de afwijking meestal beperkt zijn maar op de eerste dag ging ik langzaam een steile helling op en ging ik langzaam langs een lange vangrails. In beide gevallen was het duidelijk dat het coordinaat van de GPS niet klopte met de werkelijkheid.

Ik had precies hetzelfde probleem met de topoNl kaart en de OSM kaarten via garmin.openstreetmap.nl op mijn GPSMAP 62s toen ik van software versie 2.90 (fabriekversie) naar 3.40 ging. In SW 3.40 verdwijnen de straten in een wijk al bij een schaal van 80 meter met detail-level 'most'. Bij mijn 60cx en 62s SW2.90 gebeurt dit pas bij een schaal van >500 meter. Met 500 meter kan je een redelijk overzicht krijgen van de omgeving. Bij 50 meter absoluut niet. Het probleem is niet aanwezig bij bijvoorbeeld de OSM Benelux fietskaart. Ik verwacht dat het komt door de zoomlevels anders worden behandeld en het is inderdaad behoorlijk vervelend. Ik heb ook geen ander oplossing gevonden dan maar te downgraden naar SW 2.80 om het probleem op te lossen. Wat ik trouwens een veel groter probleem bij de Oregon en 62 series vind is dat ze niet werken bij lage snelheden onder de 0.8 km/h. Bij deze snelheden kan je meer dan 100 meter afwijking krijgen . Op mijn mailtjes naar Garmin support is na weken nog steeds niet gereageerd.

Hallo Snoekie je doet helemaal niets fout. Projecteren is iets voor een 2-dimensionale kaart, echter de aarde is 3-dimensionaal. Er bestaan verschillende methodes om dit te doen maar die leveren kleine afwijkingen op. Zelfs op hetzelfde model GPS kan een projectie iets andere resultaten opleveren. De afwijking neemt toe als je over een grotere afstand gaat projecteren. Echter meestal projecteren wij maar een paar kilometers en dan valt het wel mee. Zoals al opgemerkt door Leandraakje liggen al jouw coordinaten dan ook heel dicht bijelkaar. Bij veel coordinaatcheckers kan je een marge (afwijking) instellen die geaccepteerd wordt zodat je toch groen licht krijgt als je in de buurt bent. Dat je dat niet krijgt kan inhouden dat er niet voldoende marge is ingesteld bij de cheker of dat je antwoord niet klopt. Bij bijna alle mysteries ligt de cache binnen 2 mijl, ~3 kilometer, van het gegeven coordinaat. De projectie van 7 km lijkt dus wat ver.

Hopelijk deze keer niet te langzaam met typen. Waarom het mogelijk lijkt dat MapSource niets kan vinden is dat MapSource met verschillende formaten kan werken. Standaard is dat bij mij .gdb (Gamin GPS Database File). Echter de tracks staan in .gpx formaat (GPS eXchange). Het .gpx formaat wordt door veel programma's herkend ondermeer door GSAK en MapSource. Als je naar de verwisselbare schijf gaat en bij het openen voor Files of type: GPS eXchange Format (*.gpx) kiest dan denk ik dat je de files wel ziet. Let op: eventueel weer terugzetten op .gdb om je 'normale' MapSource files te zien.

Ik heb zelf geen HCx, maar volgens de handleiding werkt dat net zo als op mijn 60Cx . Deze tracks kan je niet direct via MapSource uitlezen en je moet ze inderdaad altijd via je PC kopieren. Methode A: 1. Sluit je GPS aan op je PC. 2. Op je GPS ga naar het hoofdmenu <menu><menu> 3. Selecteer setup/instellingen en druk <enter> 4. Selecteer interface en druk <enter> 5. Selecteer onderaan USB Mass storage/USB Massa opslag en druk <enter> 6. De GPS gaat in 'Massa opslag' en komt als een 'Removable Disk' beschikbaar voor jouw computer 7. Open deze bijvoorbeeld met explorer en doe met de .gpx files wat je leuk vindt zoals openen in MapSource. Methode B: 1-6 Lees direct je microSD-kaart via een card-reader 7. Open deze bijvoorbeeld met explorer en doe met de .gpx files wat je leuk vindt zoals openen in MapSource. Ik hoop dat dit het antwoord is wat je zocht, Bram. Edit: En Bloodwoosj was net wat sneller maar twee keer hetzelfde antwoord is waarschijnlijk wel goed .

Zoals Herman en Eugeni al aangaven hebben wij een nieuw symbooltje. Alleen vond ik het zelf niet zo duidelijk als de oude rode vinkjes dus heb ik een verzoek ingediend om of de oude vinkjes terug te krijgen of de smiley wat duidelijker te maken. Als je je hier in herkent kan je op het voorstel stemmen op http://feedback.geocaching.com/forums/75775-geocaching-com/suggestions/1328985-more-prominent-found-it-symbol-in-search-results. Hoe meer stemmen hoe groter de kans dat Groundspeak er iets mee gaat doen.