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.