kalkendotters

Ja, het dataverkeer van het modem kun je bv uitlezen via de SNMP interface. Er zijn diverse programmatjes die dit netjes voor je zichtbaar maken. Een van de vele progjes die dat kan is bv MRTG.

Nog even voor de duidelijkheid: Met de gegeven constructie via de wap is het alleen mogelijk om eerder de cachegegevens te zien; er staan geen oplossingen bij en geen eindcoordinaten. Dus het puzzelen en multi's oplossen blijft gewoon exact hetzelfde als dat het al was. Ook het zoeken naar de cache veranderd niet, en blijft dus net zo moeilijk/makkelijk als de cachelegger bedoeld heeft. Het enige voordeel dat ik dus heb van maken van de geocaching-wap puzzel is dat ik die informatie soms wat eerder zie. En uiteraard had ik het veel langer vol kunnen houden als ik gewoon nergens de datums/tijd had ingevuld, en gewoon stug volhoud dat ik midden in de nacht 60km heb gereden :-) En ik beloof jullie dat ik vanaf nu geen gebruik van de WAP meer zal maken om de FTF te scoren. Ik vraag me zelfs af of ik daar uberhaupt nog aan ga doen...

Zoals al aangegeven zit er een 'fout' in de wap interface van geocaching.com, hierdoor is het soms mogelijk om informatie te verkrijgen over een nog niet gepubliseerde cache. Deze fout is al bekend bij het amerikaanse team sinds minimaal feb 2006. Normaal gesproken heb je niets aan deze informatie omdat onze NL reviewers zo snel zijn: voordat je ze via wap gevonden hebt staan ze al online. Toevallig waren beide reviewers tijdelijk niet beschikbaar en hoopte het aantal ungepubliseerde caches zich op, en daardoor wordt de kans op het vinden van een ongepubliseerde cache natuurlijk ook groter. Vervolgens kun je met die heel beperkte gegevens kun je dan soms een cache vinden. (let wel, dat zijn dan zeker nog niet de eindcoordinaten van de puzzels of multis, daarvoor moet ik net als ieder ander hard puzzelen) Overigens nog niet zo eenvoudig als het lijkt: want: ligt de cache er uberhaupt wel, wordt de cache wel goedgekeurd door de reviewer, is de locatie eigenlijk wel correct (banpaal lag bv aan de andere kant van het kanaal), etc. Kortom nog veel lastiger dan met een 'gewone' cache. En volgens mij staat FTF toch echt gewoon voor First To Find.. en dat heb ik. Is de cachelegger het daar niet mee eens is, dan moet ie maar een mailtje sturen naar Willxii en dan trekt ie die puntjes wel van mijn resultaat af. (ps ik beantwoord geen emailtjes over hoe en wat betreffende deze thread)

De caches krijgen standaard tijdens het invullen van de cacheomschrijving een 'geplaatst' datum. Deze datum kan de cachelegger aanpassen zolang de cache nog niet gepubliseerd is. De website geocaching.com gebruikt alleen die datum om op te sorteren, en er wordt dus ook niet bijgehouden wanneer een cache precies online komt. Normaal gesproken is een cache binnen een aantal dagen online, en zal dus de plaatsdatum voldoende nieuw zijn om het labeltje 'new' (namlijk < 7 dagen) te rechtvaardigen. Aangezien er de afgelopen weken er wat weinig is gereviewed komen er nu dus caches online die al 2 á 3 weken geleden geplaatst zijn en dus ook pas 'laat' in de lijst met caches voorkomen. Je kunt de 'echt nieuwe' caches zien door naar de kaartpagina te gaan van geocaching.nl en daar te kijken naar de nieuwe caches.

Het is mij niet helemaal duidelijk hoe je dit voor elkaar gekregen hebt. Peiling op kompas ? Of een projectie uitgevoerd in de GPS... Ik neem aan het laatste: er vanuit gaande dat je een projectie doet vanuit het waypoint waar je je bevindt kan het eigenlijk alleen fout gaan doordat de je cijfers niet goed invoert. Als je een projectie doet vanuit je 'huidge positie' dan is er een kansje dat dat misgaat omdat de gps je positie op dat moment niet helemaal goed heeft bepaalt. Zelf controleer ik de projecties altijd vlak voordat we weer gaan lopen want dan moet het pijltje netjes in de richting van de projectie staan en de afstand moet redelijk overeenkomen. Overigens hadden wij geen enkele gps-problemen bij pompen en/of verzuipen

Ik heb uit best wel betrouwbare bron vernomen dat het al lekker opschiet. Als er verder niks tegenzit / over het hoofd is gezien, dan zal deze waarschijnlijk in de loop van het weekend weer actief worden. Dus nog een klein beetje geduld.

Dat is vreemd. Dus in demo-mode werkt oziCE wel geheel op de MIO, maar hij accepteert niet het registratie van het serienummer ? Je zou Des even kunnen vragen waar dat serienummer wordt opgeslagen, en dan dat bestandje/registerentry handmatig op de pda kunnen zetten. Of dat bestandje/registerentry bestaat reeds, en kan t niet overschrijven tijdens de registratie. Daar heb ik wel interesse in :-) reserve accu is altijd handig.

Je kunt (bij niet te grote afstanden) die ook gewoon met de WGS coordinaten doen. Gewoon optellen en door 2 delen.

Het is nu zomer Al wat verder bekend over het project ? Of liggen alle Paddo's in de ijskast ?

je kunt in elk geval de eerste drie waypoints overslaan :-)

Hier werkt het ook... meestal.... In sommige gevallen levert google echter een fout bestandje terug (zonder foutmelding) waardoor er geen kaart getekent kan worden. Als je de link dan gewoon nog een keer opent, dan werkt het opeens wel weer goed. Ik heb hier nog geen 'echte' foutmelding gezien, maar dat kan eenvoudig voorkomen als een van de vele bestandjes niet helemaal goed wordt gedownload. En het zou ook nog afhankelijk kunnen zijn van de cache waarbij je de map opent, dus eve een paar verschillende proberen.

Nou ja, alles OK... Er zijn nog een paar kleine foutjes, op de archived kaart zijn de volgende caches die echter niet gearchived zijn: GCF8DA (net geunarchived) GC87F9 GCG1JP GCMJYP GCN6Z2 GCNNWT GCPNHH GCPNHK GCQ0YV GCX60D

Hallo darek. Dit geeft het door bij mij: @Reintje: wat is er dan mis met googlemaps? Bij mij werkt het als een tierelier. Supersnel eigenlijk. Als ik een van mijn eigen caches invoer en dan even de afstand ga vergroten dan zie je meteen alle caches die er bij in de buurt liggen. Als je in detail gaat, zie je me voor het raam zitten te kompoeteren De melding die je krijgt is het gevolg van het maken van heel veel punten op de Googlemap, zodra je boven de 100/500 komt ga je dit erg merken. Het opbouwen van de kaart om alle punten te definieren wordt dan merkbaar te lang (zelfs als je een rappe PC hebt) Het werkt 'wel' via de GC site omdat je daar gewoon niet meer dan 150 waypoints tegelijkertijd krijgt te zien. Zodra je probeert heel NL of de Benelux te tonen met z'n 2500 caches dan werkt dit niet meer... En dat is het probleem waar Rein nu tegenaan loopt: de Google API is gewoon te traag als er veeeel punten getoond moeten worden.

Tsja, zonder stafkaarten zul je de grenspalen toch moeten bezoeken om de juiste coordinaat van elke grenspaal te achterhalen. Op de stafkaarten staat namelijk de exacte positie van de grenspaal aangegeven, en dan kun je dus de coordinaat aan de hand van de kaart bepalen. Pas als je de exacte positie van deze drie palen hebt, kun je je storten op het volgende probleem: bepaal een punt dat op 2 km van elke paal ligt. Hiervoor zou je bv geotools4.xls kunnen gebruiken; snijpunt van twee cirkels.

Het enige dat ik kan vinden zijn zijn (transparante) hoogtelijnkaarten te vinden op http://www.italymaps.tk/ of misschien heb je mazzel en staat je gebied hier tussen: http://mapcenter.cgpsmapper.com

Dit is inderdaad in de testfase (zie het groundspeak forum thread). Het idee (dat al werkt!) is: je maakt in Google Earth een route, deze upload je naar gc.com (in .kml formaat), vervolgens kan je alle caches die maximaal 1 tot 5 mijl/km naast de route liggen laten selecteren in een PocketQuery. Daarnaast kun je ook gebruik maken van de routes die andere aangemaakt hebben.

Het is een bugje bij .com, daar kun je zelf helemaal niets aan doen. De enige oplossing is om ervoor te zorgen dat je ingelogd blijft bij gc.com, dus het vinkje aanzetten bij 'remember me' tijdens het inloggen.

Ik houd het op de eerste optie. <{POST_SNAPBACK}> Zou nu goed moeten zijn. <{POST_SNAPBACK}> Nog nét niet... Nu is opeens WK pool cache Hattem voortijdig in het archief gedaan. Niet dat het veel uitmaakt omdat ie toch al unavailable is. Maar ja, computers he; die zouden niet zelf moeten beslissen om de cache alvast maar te archiveren.

Ofwel is de oplossing nog niet geimplementeerd, ofwel treedt er een ander probleem op. Deze keer is "Anc(h)or's Nordic Walking Cache" het slachtoffer. Op de gearchiveerde kaart, maar gewoon werkend...

Ik snap echt niet wat je nu precies bedoelt. De PQ nemen wel degelijk de unavailable caches mee, tenzij in de query hebt aangegeven dat je dat niet wilt. Bij Tools, opties, general kun je (rechts bovenin) deze unavailables middels een rode kleur zichtbaar maken. Net als je founds en je zelf geplaatste caches. Zo valt alles heel goed te beheren. <{POST_SNAPBACK}> Als je niet snapt wat er bedoelt wordt, waarom antwoord je dan Er is een fundamenteel verschil tussen 'unavailable' caches en 'gearchiveerde' caches: de eerste worden nml wel mee gestuurd met een PQ, en de tweede niet De enige keer dat gearchiveerde caches meegestuurd worden in een PQ is in de eigen founds lijst. En aangezien je de gearchiveerde caches niet in de PQ's meekrijgt, kun je dus alleen constateren dat een cache gearchiveerd is doordat deze cache opeens niet meer meekomt in de PQ. (Of door van alle caches de webpagina te openen en te kijken of ie daar op gearchiveerd staat.) Als de cache eerst een tijdje op 'unavailable' heeft gestaan voordat deze gearchiveerd wordt, dan is het probleem niet zo groot omdat je dan eerst een PQ krijgt met de status op 'unavailable', en later verdwijnt uit de PQ. Als Mumzle dus zijn manier van inlezen/controleren niet aanpast, dan gaat ook hij een keer op zoek naar een gearchiveerde cache; omdat ze in GSAK gewoon op de laatst bekende status blijven staan... (vaak 'unavailable', maar soms 'available')

Ja, heel duidelijk. Wat je ziet is de UTF8 encoding, die zul je dus eerst 'ongedaan' moeten maken. Zelf converteer je nu de 'escape'codes van UTF8 naar HTML, waarschijnlijk bevat je programmeeromgevind ook een routine die dit netjes voor je doet. (ook in de header van de pagina staat dat wat je ontvangt gecodeerd is in UTF8 [])

Tsja, wat noem je fout... Het zou kunnen komen door de UTF8 encoding, of door het gebruik van een andere codepage... Geef even een paar voorbeelden, dat maak het een stuk makkelijker.

Dan heb je een of meerdere antwoorden niet goed, want bij mijn oplossing krijg ik netjes de juiste pagina te zien. Maar een mailtje naar de maker kan natuurlijk altijd.

les 1 consumentenrecht: als het product niet werkt dan moet de leverancier (de winkel dus!, en niet de fabrikant) zorgen dat het wel werkt (repareren of omruilen dus) of je het geld teruggeven. Ze mogen je niet afschepen met het feit dat de verpakking is geopend.... (hoe zou je anders kunnen constateren dat het niet werkt?) (als je het terug wilt geven omdat het je bij nader inzien niet bevalt, is het een ander verhaal)

Ik krijg ook de indruk dat het probleem zich niet massief openbaart. De voor de hand liggende controles, zoals de correcte status in XML feed achter de parser heb ik natuurlijk al geprobeerd. Daarom vrees ik dat je hulp niet direct resultaat zal hebben. Deze code loopt al jaren/maanden en nu gaat er met één cache iets mis. Ra, Ra. <{POST_SNAPBACK}> Bertien is weer een gelukkig mens, want haar cache handcijfers staat nu weer goed. Het nieuwe slachtoffer is de cache "925 jaar Langedijk deel 2", van roestje; nu is deze onterecht gearchiveerd []