sandvika

I'm not afraid to post SBA logs however, I only do so if I'm prepared to collect the resulting geolitter on the basis that if an owner doesn't maintain their cache they're unlikely to collect it when archived either. Recently I posted a SBA on a cache that's been reported as waterlogged for 3 years with 5 NM logs over that period. The owner archived the cache within 10 minutes of my SBA! I'll be going back to collect it shortly..... On the other hand I recently had a little bit of a disagreement with a cacher who wanted me to maintain one of my caches because it was the only one within 10 miles of home that he'd not found. The issue was that the cache was out of position and more difficult to access than usual. My view was that it was well down the pecking order for maintenance because it was otherwise fine - guaranteed to be dry and log not full - and why should I be the one to employ ingenuity to retrieve it, not the cacher who wanted to log it so badly? In the end, he did retrieve it, but not before a reviewer had been invoked and had disabled it. Others then also found the cache and it was duly re-enabled without maintenance. I wonder whether the OP of this thread is now receiving similar 'attention', in view of one of his caches in the same area being difficult to find

I think Wherigo was ahead of its time - the CPU power in the portable devices at the time was not sufficient to allow interrupt driven programming to work (essentially every new GPSr location requires recalculation of the zone rules) and that's why there was the perception that it kept on hanging/crashing. Now Oregons, Androids and iPhones all (Oregon, just about) have enough spare CPU cycles to keep up and my recent Wherigo experiences have been extremely positive, to the extent that I'm about to invest time and effort in the project again. I would like to see proper documentation of all features, particularly built-in methods and objects that can provide more efficient means of determining game play than the rigidity of zones and positions relative to them. It should be accessible to allow creative people with programming skills to create fantastic adventures, whilst allowing those with no such experience to create reasonable adventures using the various builders.

Why? The game is about finding hidden containers and a "found it" log means "I have found the stash. Geocaching does not mean to make people to silly things. Do you remove the log entry in the caches logbook if a cacher does not perform the ARL? To me and my sons, caching is about having fun. There are memorable caches and there are instantly forgettable caches. We'll seek out the ALRs and do them because it adds to the experience. Evidently from your definition, fun is not an important criterion to you. So ignore the caches with ALRs. Simple. But don't take the right of the owner away to remove the logs of those who refuse to play along. I've not needed to remove any logs from my ALR cache and I've not given cause to any ALR cache owner to consider removing my log. I've advised cachers who have signed my cache logs but forgotten to log online, I've advised cachers who have signed the first stage of a multi and claimed the cache that they have not completed it, but I have not deleted the logs. Why? Because I've had perfectly logs for legitimate finds of traditional caches removed by owners for their personal reasons and I know how aggravating it is. The reasonable man adapts himself to the world he finds. The unreasonable man insists on adapting the world to himself. Therefore all progress depends on the unreasonable man. What's significant here is the rights of owners over their caches. This is what has been diminished. Progress and innovation have been stifled further. The fundamentalists will be happy. Now I'm out of here. Thee's an ALR cache I want to log before the owner archives it in disgust.

I'd suggest that anything that removes freedom from cachers to be able to specify what is necessary to claim a find diminishes the game. Others can choose to ignore caches with ALRs, but to ban them seems heavy handed and detrimental. Another genus of cache diversity gets frog-marched to extinction. A typical example would be GCVFP3.... It's good plain honest fun and if you can't rise to the occasion and meet the requirement, then shame on you! As it's a long way from my home, it's been on my todo list for ages, however, I plan to satisfy the requirement and enjoy the moment.

The owner and the reviewers would benefit! I wanted to compare the data I'd entered onto the listing with what I'd recorded on site. It would have allowed me to spot the errors I'd introduced and the cache could have been published on first review. If you're only ever setting traditional caches perhaps this makes no difference to you. However, if you're entering 40+ waypoints for a cache it makes a significant difference.

This is a suggestion for a possible new feature for GC.com. I'm just getting a new night cache published and have created reference point waypoints for all the night markers. Unfortunately (and perhaps unsurprisingly) I miskeyed the coordinates for two of them and unfortunately it thus failed the review. It would be useful to be able to load a GPX file from GPSr or GSAK for example during the cache publishing process to create the initial set of waypoints. These would then be edited to give them the correct waypoint types (they could start with a status of "Reference Point") and appropriate annotations. This would both eliminate human error as in this case and by making it so much easier to do, encourage cachers to provide more complete information for a cache listing. Thanks, Roderick

I'm in the process of publishing a night cache where I've added all the night markers as reference points. I wanted to check my input of waypoints into the listing was correct by generating a GPX or LOC file and comparing it side-by-side with the GPSr waypoints in GSAK. Unfortunately, it seems that the GPX and LOC files generated from the buttons on the download panel on the listing are of invalid format prior to a cache being published, as GSAK was unable to parse them. It would be great if this could be investigated and fixed at some point. Thanks. Roderick

Congratulations Alan. Somehow I doubt you'll be taking it easy from now! Actually, a couple of weeks ago, I exchanged emails with a cacher who is slightly further afield, then looked at his GSP profile and instantly thought of you! How long before you pass him?

As well as being for those who don't read pinned topics, this thread also serves well for replies that don't really belong in the pinned topic. This year there will be an election for the committee (but not yet for chairman), there already being more candidates properly nominated than seats on the committee. I'd like to thank PopUpPirate and MarkandLynn for proposing and seconding my nomination for election to the committee. My personal manifesto is here: http://www.gagb.co.uk/forums/showpost.php?...mp;postcount=85 I hope this resonates with you and will meet with your support. Best regards, Roderick

The interesting possibilities of technology convergence: Find pub/restaurant/hotel/geocache W3C Geolocation API draft specification: http://dev.w3.org/geo/api/spec-source.html and an early implementation: http://labs.mozilla.com/2008/10/introducing-geode/

Thanks a lot for your considered reply. I hope the developers read the forum and can elucidate. I suspect you'll agree that knowing properly how it works can influence cartridge design to optimise results. I guessed the same and have set distance to -1 for proximity and distance. I've eliminated zones that guaranteed certain sequences would be followed and have attempted to approximate that the sequence is being followed instead. This risks boundary effects when GPSr inaccuracy bounces you in and out of a zone, but has to be better than the PDA's CPU being maxed out. I had not considered the possibility of using the timer to prevent cheating. That could be the answer - I'll have to experiment. Basically, "cheating" is "teleportation" where you turn off the GPSr for long enough to overcome known "obstacles" between A & B (equivalent to "goto here" in the Emulator). This could be detected if the delta between previous and current positions is too great within a timer interval, or indeed if Wherigo presents GPSr signal absence somehow. Either way, this could be a lot more simple and computationally less expensive than using zones to achieve the same effect. So thanks a lot for that. If I can conjour up some general purpose LUA routine to achieve this, I'll post it. Cheers, Sandvika

Hi Tom, By not reading the forum before creating a cartridge, I have hit performance problems. However, I think these are inevitable if using zones to prevent "cheating". A couple of questions. 1 - Is zone evaluation triggered by every new reading from the GPSr, and potentially have a new reading cause an interruption of the calculations, so they never actually complete, or is zone evaluation not interuptible, so that it is assured of completion, at the risk of losing GPSr readings? If the former, is there a way of specifying in which sequence active zones must be evaluated? This would allow me to sacrifice non-essential functionality (like detecting cheating) by evaluating those zones last (ie. never, for slow devices) If the latter, is there a way of measuring real elapsed time taken for an evaluation cycle? This would allow me to sacrifice non-essential functionality by setting zones inactive to conserve CPU time on slow devices. 2 - For most of my zones, I am not interested in the within distance or within proximity evaluations at all. Is there a way of turning these off completely for zones, so that they are never evaluated and thus don't consume precious CPU cycles? My initial impression was that they should only be evaluated if there is a script associated with the outcome, however, on reading this topic, it does not appear to work this way and they are evaluated whether or not the results are used. Thanks a lot, Roderick

I wonder then why the thread title is "Pointless Micro Caches", not "One Line Descriptions"? Actually, a really good example. The descriptions may as well be 1 line. The same description was cut and pasted into 15 or so caches, very few of which are actually in Bracknell Town. Most are in the historic and ancient parishes of Winkfield and Warfield, which were collections of historic hamlets, until the 1990s. Therefore the descriptions are wide of the mark: a missed opportunity. If a history lesson was intended, Bracknell Forest Council's own heritage leaflets would have been a good starting point. Further, the majority of the caches lie in the 1990s suburban housing estates, none in the hamlets nor even in the forests and green belt for which Bracknell Forest is known and why people visit from a wide area. As regards preparing your printout of the cache description, simply click the PLUS sign on the map to zoom in 4 times before printing. Then the corelation of the cache name to the street name is obvious, so is the location. Perhaps, I'll grant you, the first of the series would require the briefest of searches, given the shortage of magnetic material to which to attach nano caches. I'd defy you, or anyone else, to complete this series and remain enthused until the last one has been bagged. As they were still being published as we set out, there are several more still to be claimed. Want a FTF, anyone?

I guess I've got a bee in my bonnet over this now, since it has become a very local phenomenon, as of yesterday. "Sign of the Times" series by "Lord Of The Cachers" (and why, it seems, a sock-puppet account?) For example: GC1DDWC A load of "caches", all the same (nano caches stuck between the uprights of street signs and the back face of the sign, street name in the cache name). I thought the requisites for geocaching were: - need for a GPSr - need for a search neither of which applies in this series. I logged them until I could not bear to see another one, basically so that they don't appear as a great "unfound" morass on the local map.

There's also "Pretty in Pink" (GCVFP3) in UK. Nice ideas in this thread. Thanks Sandvika.

Regrettably, it's not so simple. Think of the EPE on your GPSr as the Circular Error Probable (CEP) of your missile dropping out of the sky onto your GPSr. There's a 50/50 chance that it's going to be inside the circle or outside the circle. You can mitigate the chance of the GPSr not being destroyed by making the warhead in the missile large enough for the destructive blast radius to incorporate the CEP. Thus, regrettably, the chances of a location residing within the intersection of the two circles you indicated are actually pretty tiny. In reality, you would be unlikely to get such a small intersection. Where GPSr reception is poor, giving rise to widely spaced readings, or apparent position drift, you are dealing with larger circles, not smaller intersections. You can think of your apparent position as a classical bell curve of distribution points. If you have a great unobstructed signal from a great many satellites (on a boat in the sea, for example) you've got a very steep sided distribution curve and your EPE will be small. On the other hand, if you are in the woods or an urban canyon, most probably you'll be within range of a limited number of satellites within a limited area of the sky (typically overhead - you can see their distribution on your GPS satellite location plot) and you'll have a very flat distribution curve and your EPE will be large. If you are in the woods, the steepness of the distribution curve will be influenced by the extent of the foliage and will thus vary seasonally.... It does not take much to figure that the best time of year to place caches will be when the foliage is at its minimum! Clearly, the number and positions of the GPS satellites at any time also has a bearing on the accuracy of a given reading. There's no point in taking many readings over a short period of time as your measurements will all be based on the same subset of satellites in more or less the same place in the sky. If you want to compare multiple readings, go back at different times, hours or days apart. It's often easier to obtain good readings in open space away from a cache. Take your compass with you and get yourself due east (or west) and north (or south) to get readings with a low EPE for use as the latitude and longitude respectively. Don't rely on your GPSr compass feature: regrettably I have found the top named brand batteries I use to be magnetic and therefore have distorting influence on the GPSr. Lastly, check your cache coordinates in Google Earth. This has super accuracy in areas with high definition photography and people will not curse you as much when they go looking for your urban nano. When I adopted and relocated my cache "Bartlow Hills" I could not get a decent set of coordinates, full stop. Thus, I described the "get yourself due west" technique in the cache listing and suggested people pace their way to the trailhead and then pace their way back to the cache. This works a treat compared to struggling with the GPSr reception in the woods. When seeking caches, just appreciate the quirkiness of your GPSr and remember it's a part of the challenge Cheers, Sandvika