Amberel

Yes, your phone will use the same satellites and signals as a normal consumer GPSr. It doesn't need a telephone network connection to determine position, but the Groundspeak app isn't much use without that. There are other iPhone apps that work better offline, e.g. GeoSphere, that allow PQs to be loaded via USB before you set off, so you can access them when out of network coverage. The GPS receiver in earlier iPhones (up to and including 3GS) was extremely poor quality. Later models are much better. Rgds, Andy

Thanks for your very clear reply. It's a real shame about the maps - if I was designing a location based game system I would have put that very high on my list of priorities. We were using the Oregon, and having nothing more on the screen than a (small and very hard to see) pointer was such a low quality user experience. Having a standard map provided by the platform is probably better than nothing, but it doesn't achieve any of the things I would like to do. If on a tour I would want a fairly normal map except I would want to highlight the focal points of the tour. And for a game, I would want to use an imaginatve map to set the scene, the whole framework, for the game. And if it appears on some platforms and not on others that surely leaves you with an awkward decision about allowing for all platforms but limiting the features, or going for a better experience but only running on certain players. Same goes for the sound, I guess. Rgds, Andy

I've done three Wherigos recently, and felt that they were so basic as to be not worth making into a Wherigo at all. It was just a case of wandering round urban streets from one location to the next, with nothing of interest in the cartridge or the ground we covered, and where the "locations" had nothing to differentiate them from any other nondescript part of the street. Which led me to think maybe I should look at doing one myself, in a more attractive location, with a proper story line and making slightly better use of the platform. So this evening I started to look at what was involved. I rather assumed that the first thing to do after choosing the location would be to map the playing area. One of the things we didn't like when playing was that there was no map - just a mostly blank screen with a small, hard to read compass in the corner. I had expected a "real life" map for a tour, or a more imaginative interpretation of the ground for a game. But nowhere have I seen anything in the tutorials about creating such a map. Can I just confirm that it is possible to create a map as part of the cartridge, over which the player's position is superimposed? A supplementary question - can the Oregon make sounds other than beeps? Rgds, Andy

No, not at all. However, if it was me, after 81 DNFs and no finds I would make ABSOLUTELY SURE the co-ordinates were bullet-proof - if they turned out to be a long way off then all those DNFs might justifiably feel a bit peeved. Also, if the spelling mistake in the title is deliberate, that's fine, but if it is accidental it would be better to correct it, else it might lead people to try and find a non-existent hidden meaning. Rgds, Andy

Obviously I didn't make myself clear, but I'm still surprised you didn't make the connection. It wasn't introducing the "quality of logs" debate at all. I think that for a majority of cachers, the effort they put into a log is influenced by the amount of enjoyment they get from doing the cache. So, overall, a high quality cache is likely to average out with more interesting logs than a poor cache. I understood exactly what the OP was saying, and trying to make the point that the number of finds is yet another statistic that takes no account of quality, and as such it holds no interest for me. I would wish for my caches to receive a small number of good quality logs in preference to a large number of terse ones, as that might be an indication that they provided above average enjoyment. For the avoidance of doubt, this is in no way a comment on the quality of the OP's caches as I don't know anything about them. It's just a caution about placing too much emphasis on numbers alone - they mean very little to me without any means of associating quality/enjoyment/whatever with them - a bit like quoting the magnitude of a measurement without the units. Rgds, Andy

Not sure if you mean how many do I own or how many I've broken . I own 16 (including phone/PDAs with GPSrs in them), but I've never broken any . GPSIII+ eTrex HCx Oregon 550t 5 different O2 XDA phone/PDA models Asus phone/PDA Acer phone/PDA iPhone 3GS iPhone 4S HTC Desire Android Bluetooth GPSr module Garmin GPS30 wired GPSr module RoyalTek wired GPSr module Rgds, Andy

I don't know, and I'm not at all interested in that statistic. It's not the number of logs but the quality of the logs that matters to me. I'd prefer to not receive a log at all than have a blank one, or just TFTC, or just :-), or something that was copy/pasted from a previous find. Rgds, Andy

Dartmoor. Rgds, Andy

Number of caches in group, OS grid ref SW, OS grid ref NE (the bounding rectangle is for the caches, not the exclusion zone, but it's enough to tell you where to look). 162 570111,205428 584679,209517 159 366593,303795 370544,312264 94 263230,145177 268091,148288 89 530978,180028 534347,182282 82 578902,109135 582974,111237 82 492855,202254 497863,205395 74 373109,302595 376247,306837 74 361603,312202 365305,315586 73 523633,153391 527712,156869 70 516140,148643 520050,151763 The first one has Chelmsford on its west side, and largely comprises the west end of the Chelmer powertrail plus a load of caches in Chelmsford itself. Had there not been a break in the powertrail at Hoe Mill Barns, it would have been considerably larger. The second is at Telford. These are numbers of caches, not area. I suspect the Telford group will have the larger area because the caches along the Chelmer are mostly are at the minimum separation distance whereas the Telford ones mostly are further apart. The gap between 2 and 3 is such that I suspect the others won't come into play. I'll do the areas some other time, but it won't be today. Rgds, Andy

Your comments are as I intended it to read. Mine isn't coded like that - I intended it to be a simpler description for non-programmers. As the separation in distance calculations is not more than (just under) 322 metres, not using a great circle distance should introduce an almost immeasurably small error. If you mean you use a 2D projection it may introduce a percent or two. I'm nearly ready for tomorrow, so I'll knock up the first part this evening and run it overnight. As I'm up and about much earlier than my caching buddy I'll probably have an answer to "what's the island-of-exclusion ("Group") with the greatest number of caches?" before I go out. Rgds, Andy

Work got in the way yesterday afternoon, and again today, and I'm out caching tomorrow. I have come up with a simple algorithm, if I get 10 minutes I'll code it up and leave it running tomorrow while I'm out - it's likely to take longer than the original question. Does this do what you wanted? 1) Create temporary integer columns Group and GroupStatus, initialise all rows to 0. Group will be used to identify all caches in one interconnected group, i.e. where all the caches in the group are less than 2 minimum separation distances from any other in the group. Group Status will be used only during the computation, 0 means unprocessed, 1 means unprocessed high priority, 2 means processed. 2) Pick any cache where GroupStatus=0. If there are none left, it's finished. 3) Increment the Group number. 4) Set the selected cache Group to the current Group number, and GroupStatus to 2. 5) For all caches within 2 minimum separation distances, and for which GroupStatus is still 0, set Group to the current Group number, and GroupStatus to 1. 6) Select any cache where GroupStatus=1. If there are none go to 2. 7) Set GroupStatus to 2. 8) Go to 5. This doesn't get as far as calculating the area. There may be an elegant mathematical solution to that, but I don't know it. I'll probably kludge it by plotting the circles onto a bitmap and counting the pixels. RGds, Andy

Quantisation should be unnecessary for finding the islands-of-exclusion. Calculating the area could get a little hairy, and you may well prefer to solve the overlapping-circles problem by discrete approximation. It might not be necessary if you are a (lot) better at maths than I am, but it's way beyond my capabilities. The only way I can see to define the boundary would be by a list of arcs, but I don't know how to generate such a list, nor how to do anything useful with it even if I could . Hopefully I might have a look at this later today, maybe while I'm watching the Ireland/France match. Rgds, Andy

A simpler question, allowing for shapes other than rounded "blots", would be: show me the top ten largest "islands of exclusion" in the UK. The i.o.e. containing cache X is defined as: start with the exclusion zone around X; add all exclusion zones that overlap that; add all exclusion zones that overlap those; keep going until you can add no more. The area's calculated by application of the inclusion-exclusion principle. If done in the U.S. then you'd get a lot of powertrails scoring highly, making long thin islands of exclusion: not so much "blots" as "scars" on the landscape. 30 logs done, only another 41 to go. But I've also got some urgent work for a customer this morning. The initial problem was very straightforward because it was a matter of simple addition. Even this "simplified" one is far trickier than the initial problem. The only practical way I can see to do it would be to quantize the surface, but as quantization is implicit in the fixed precision of the published data points I don't really see that as an issue. As a diversion, after mentioning the fixed precision of the published data points, the Caravan Club web site greatly amuses me. They give the lat/long of CLs, but these are not provided by the farmer, they get them from somewhere else and the accuracy suggests they must compute them from the postcode . But despite the questionable accuracy, they publish the position to 15 decimal places . A case of the programmer not understanding the difference between accuracy and resolution, I think . Rgds, Andy

I haven't been ignoring you - took the campervan down to Dorset at dawn on Thursday morning for a spot of caching, and only got back 15 minutes ago so only just seen your question. That is a MUCH harder problem. I don't have an instant algorithm for it, it will need a bit of thought, and I've got about 70 caches to log before I do that . Rgds, Andy

It's just my job. In the late eighties I was UK technical support for a GPSr chipset manufacturer, so I wrote the co-ordinate transforms more than 20 years ago. And my job now involves some database work, so if the data is already there, which it is, pulling this stuff out of it is easy. GC2J00J is in 312000, 372000. GC1HH4J is in 512000, 147000. Rgds, Andy

To recap, that was: 17 if you include trads, multis, letterboxes, wherigos, virtuals, webcams and earthcaches, but not unknowns, events, etc. 312000, 372000 comprising 16 trads and a multi (one of the trads currently is disabled). 22 if you also include "unknowns". 512000, 147000, these are nearly all unknowns with co-ordinates set in a radius of about 60 metres. I should add one more qualifier - Groundspeak's listed OS grid refs use a very poor conversion algorithm, with a typical error of 5 or 6 metres, to calculate the totals above I use a conversion algorithm with an accuracy of about 1.5 metres, but it means on a boundary condition they might lie in a different square. Rgds, Andy

"unknown" is a cache type - some people call them "puzzle" but that is a bit misleading because there is no cache type of "puzzle", they are just a subset of "unknown". You will find that some setters of "unknown" caches may set the listed co-ordinates of a group of "unknowns" for visual effect, e.g. a smiley face, or whatever. Obviously this is a bit of fun, but it illustrates that the listed co-ordinates are not a guide to the actual cache density in an OS square. Multi's aren't either, though they arguably have a slightly stronger link because they are (supposed to be) the actual co-ordinates of the first stage. But you obviously realise that "... the cache or cache subject would have to actually be in the Sq." is not possible for me to do, as I haven't done every multi and solved every puzzle in the country . So any calculation has to be on listed co-ordinates, and using an arbitrary set of cache types and cache states. HH felt that the choice of cache types and states was obvious, but only 3 of us have expressed what we thought should be included and we have at least 4 quite major differences of opinion, so it's not entirely straightforward. Rgds, Andy

I often do - it's one of the bonuses of working for myself . If you are ever down this way take a look at some of my Church Micros (especially Littleton), definite crossover between work and pleasure there . Rgds, Andy

Who knew what? Which square had the greatest number of caches? I gave various answers depending on what criteria are used for selection, and with the minor reservation that my database takes about 25 days to update, I believe those answers are correct for each selection. Rgds, Andy

Yes, is perfectly allowable to have 1000 caches in the one square, if you use the listed co-ordinates and not the final co-ordinates of a physical cache. That was the point I was making about unknowns and multis, and the ambiguities in the question. Rgds, Andy

I wasn't doubting you - when I said "Should have thought before putting "pen to paper"" I meant me! But having looked at your link, might it not be more than 53? I haven't studied it but there are some shown with more than 53 - or are they smaller circles? I'd work it out, but having messed up once I'll leave it to someone else . Rgds, Andy

OK, added in the disabled ones and it made no difference to the "winner", still just the one square with 22. Running some SQL against an offline database. The reason numbers are approximate is because it takes just under 4 weeks to refresh all the Groundspeak caches. Rgds, Andy

The sums are anything but easy because the caches do not have to be arranged in a square array. It's possible to fit 53 caches into a 1km-square patch of land. Well done . Should have thought before putting "pen to paper". Rgds, Andy

For traditionals, the sums are easy. 1000 metres per side, 161 metres minimum separation, so max 7 per side. Square that = 49. If you use final locations it's the same for multis and unknown. You can't make any meaningful calculation if you use the listed locations for multis and unknowns. Rgds, Andy

It's OK, it wasn't complicated, it just wasn't well defined . I'm a programmer, I try to avoid making assumptions, but if I have to I usually explain what they are . So do you want me to run it again but including events and disabled caches? Quite a lot of squares with considerably more than 16 if you include unknowns, but this is because some setters seem to cluster the listing locations for unknowns to achieve a visual effect on the map, even thought the caches themselves are spread about. Rgds, Andy