Cardinal Red

A Company has to do what it does best, and they have gotten quite good at it.

There might be other situations where this could be helpful, but if you made a find while caching with a friend - their find log will show right there on the cache page very close to yours. Their profile is easily accessible from that very close proximity find log. Why complicate a very simple game?

What is an "unconsolidated" email.

Only two months, how would you know? Well, they are absolutely correct about the epidemic of crappy can't be bothered to do better cut and past at best logs. So it seems they do know something. :not laughing: To save anyone the trouble of looking it up, I found my first cache more than 12 years ago.

Based on the average length of a Nautical Mile by International agreement: 1 Degree = 364,566.9291 feet, so round that to 365,000 feet. .00001 Degrees then = 3.65 feet. 1 Minute = 6,076.115486 feet, so round that to 6,000 feet. .001 Minutes then = 6 feet. 1 Second = 101.2685914 feet, so round that to 100 feet. .1 Second then = 10 feet. You indicate you have a dd.ddd option. If that is correct, that isn't good enough. You need dd.ddddd That is 5 decimal points needed in Decimal Degrees instead of only 3 decimal points in Decimal Degrees. If your app will actually give you 5 decimal points of Decimal Degrees accuracy, that is good no matter what they call it in the app. The mm.mmm option is good. That is the Geocaching standard. When Keystone says that an "out of the box" iPhone in degrees, minutes and seconds is an insufficient level of precision, that must mean it is only capable of ss.s At ss.ss it would have more precision than either dd.ddddd or mm.mmm Explaining to someone that 6 foot precision is the desired Geocaching standard, while 10 feet is insufficient precision could be a bit of a hard sell. So we usually don't explain it. We just say don't do it. I know why mm.mmm is the Geocaching standard. dd.ddddd would have been a much better standard at 3.65 foot precision, and one nice clean number. To late to "fix" that, but you can still collect coordinates as dd.ddddd - but they must still get published accurately on the cache page as mm.mmm Good Luck with your hide.

I would like to take a look at the actual cache page. Could you provide (or email me) the GC#. Doesn't sound all that tough.

I am stunned that you think of Groundspeak as a responsive company. Though this case is probably even worse than usual, since I suspect they have no idea how to fix it. How do you fix what you don't understand? And how is silence going to hurt them? They won't lose customers over it. They have no competition. The decision has been made that it is better to say nothing. Thank You for your patience.

Obviously, Groundspeak Headquarters could make any exception they choose to. I will say with an absolute certainty approaching zero, the odds that your situation would ever get approved is ABSOLUTELY NOT. Your situation is not unique. Your reasoning is not valid. The best advice you will get is that you can use your location as a NON PHYSICAL STAGE that could be used to interpret existing information that will direct cachers to an open area, free of any proximity issues.

I had to wait an entire 5 minutes this afternoon for a hide to publish. Part of the reason it took so long is the Reviewer had to Archive my older disabled place holder cache that was still listed there, before the new one could be published in its place. That is what I clearly indicated I wanted to happen. Thanks "O". Seriously. I probably just happened to catch the Reviewer at the computer. No issues came up about the hide style or location. I knew what information to include to give the Reviewer confidence that there were not any issues. It normally doesn't go that quickly, but any cache that sits in the Review Que around here for a week probably has the Reviewer concerned about something. I would be looking for some type of communication to find out what it is. Or the Reviewer just might be on vacation. They do that sometimes, but I would say 10 days without a review is not typical most places. And just because a cache is Reviewed, that isn't the same as Published. Take note of those possible issues I mentioned. The stated goal by Groundspeak is a Review within 7 days.

What is the GC# and/or Cache Name it was listed under on your GPS? There are many reasons why it could be on your GPS, but not so easy to locate on the site now. Give some additional information that can be tracked down, and someone will figure it out.

And how soon do you predict there would be even the minimum necessary constellation of GPS satellites orbiting those space "destinations"? Are there enough features on the surface of either one of those to even play a worthwhile game of Letterboxing?

Are you using a dedicated GPS unit? The conversion can be done on a GPS unit in the field. And I found two different UK sites that will also do the conversion for you on line. Try them both and see which one you prefer. That second site has an odd name for a coordinate converter, but it seems to work quite well (and even has two different Format output options - they hid it quite well so look for it). nearby.org.uk Movable Type Scripts

Are you saying that logging out and logging back in will connect you to a different server? Or is this something I supposedly have selection control over? I tried your suggestion. It didn't work. I have been around the block a few times in the 13 years I have been hanging out here. I tried more than 1 PQ originally. I tried more than 1 PQ this time. I even tried to throw in a My Finds PQ for good measure. NOTHING. The hamsters are not asleep. They are dead. A follow up note here for anyone following this conversation, I really do understand the PQ priority system, but in this case I was the one that didn't specify in bold letters. I was creating BRAND NEW test PQ's - the highest possible priority PQ submission. I didn't say that "possibly" or "maybe" the PQ system is down again on a weekend. I am saying with absolute dead certainty that it is. I don't see any possibly way to "spin" that statement.

Having read your post, I just tested the PQ generator. I can confirm that it is the Weekend, and Pocket Queries are broken. This is not all that rare a combination. Happy Geocaching.

After reading through the thread a few things are not clear to me. #1 - What is the attraction to Chrome? If it works for you, fine. If not, give Firefox a chance. My Oregon 450's (both t and non t models) like Firefox just fine. As for IE, when heck freezes over is the next time I will use it willingly. #2 - Are you familiar with MASS STORAGE MODE on your Oregon, AND are you familiar with the GARMIN SPANNER Interface? I find that most local users I talk to have never heard of it. I also find it invaluable. Look for it under Menu - Setup - System - Interface That is something ANY good browser should be able to do. I refer you back to my opinion of Firefox and IE. How did you "put them on the GPS"? I refer you back to my question about MASS STORAGE MODE. Why? As in, why complicate any part of the process, at least until you know how it works. There is a very real possibility that those LOC and GPX files don't play well together. It doesn't matter in this case. Keep going back to the GPX FOLDER regularly to clean out old outdated data, and replace it with fresh data. Get rid of that old GPX data. Repeat - keep going back and deleting old data. Basecamp is a option, NOT a requirement. Again, why complicate the process in the early stages when you don't have to? GPSBabel is a option, NOT a requirement. What is wrong with good old COPY / PASTE? In 12 years and 2000+ finds I have NEVER used either one of them. Figure this out first, and then experiment if you want to. For now, keep it simple.

The "friend" thing quick link to their profile has been useful to me on occasion. Not a big deal, but useful. The invaluable "friend" thing feature is being able to read logs written to any specific cache, limited to ONLY those written by your "friends". If I am going to be caching with someone occasionally, I will initiate a "friend" request. If a cache has (just for example) 2000 logs written to it, finding a few specific "friends" logs can be quite a job. But you can quickly narrow that down to ONLY those logs that were written by your "friends". One of the best kept secrets in Geocaching.

Since the site clearly states 3 days between My Finds downloads, why did you think there might be a way to shortcut that? Are you aware of the history here? Site wide there can be extensive resources consumed in the pursuit of this data. I remember when the period in between downloads was 7 days. EXACTLY 7 days. So if you wanted the data on the same day of the week every week, the download time kept getting later and later in the day. The only way to "reset" it was to skip a week (oh the horror), and return to your desired day of the week and time the following week. Not a concern for most of us, but some data enthusiasts were not satisfied with the situation, though all they really asked for was the ability to be able to hold to a strict weekly schedule. Groundspeak went far beyond that request with a new 3 day limit (basically a very flexible twice a week schedule). But no matter what concession Groundspeak makes, someone is sure to come along later asking for even more. No, it doesn't hurt to ask, but quite often the answer is NO. But as was mentioned by Team Taran, you can usually get all the recent data outside of a My Finds Query. Good Luck on your Challenge.

Look at the bottom of any cache page. Preferably a newly placed cache. There won't be so many logs to wade through to get to the bottom. Coordinates are in the WGS84 datum Yes, after you have correctly entered your WGS84 coordinates, you can switch the GPS back to NAD27 (or any other Datum you care to). Set to NAD27, any WGS94 coordinates will be shown as the NAD27 conversion. They won't look the same as what you originally entered, but they will lead you to the same spot. If someone asks you to tell them what the WGS84 Datum coordinates are, you would have to temporarily switch back to WGS84 before reading off the coordinates to them.

OK. You prefer UTM. Fine. As long as you understand what you are doing, you can use any preference you like. You have the GPS set to UTM UPS and NAD27 CONUS. You found the UTM coordinate conversion on the Cache Page. ALL CACHE PAGE COORDINATES ARE PRESENTED IN THE WGS84 DATUM. Datum mismatch. Immediate fail right there. That mismatch can easily put you off target by 200 Meters. Sounds like that is about the error you were experiencing. When you are entering coordinates obtained from a Cache Page, you need to set the Datum on the GPS to WGS84. If the Topo Maps you pull coordinates from are referenced to NAD27, then you need to have the GPS set to that. If you are pulling from both sources for the same trip, you have the GPS set correctly for each data entry (do all like Datum coords first, and then the other ones instead of doing a lot of switching back and forth). Afterward you can change to ANY FORMAT and DATUM setting available to you. At that point, the coordinates can LOOK totally wrong to your eyes, but the GPS will take you to the correct intended location if you did it right. Trust me, anybody who mixes Datum Formats will eventually forget what they set the GPS to the last time it was used. Then you toss new numbers at it and go to the wrong spot. I have already figured out in the field what I had done wrong. I looked up the numbers on the GPS and wrote them down. I changed the GPS setting and then re-entered those same numbers. Then I followed the GPS to what I was looking for. Fun times. Hopefully that is the solution to your problem. Good Luck. If that doesn't fix the problem, come back again with even more information. But I have a good feeling about this.

I would suggest that you don't yet fully understand coordinate systems. How then is "triple checking" going to yield the correct result? Why did you find it necessary to use the UTM coordinate system? Have you successfully entered UTM coordinates to the GPS previously? Where did you get the coordinates that you entered? Which cache were you looking for? EXACTLY what did you enter into the GPS? Which Datum did you use? You are sure you had the GPS set to accept UTM? Did you look at the coordinate display on the GPS during the search? Did the coordinates display still look the same as what you had originally entered? With all those unknowns it would be next to impossible for anyone reading a Forum to simply figure out exactly what the problem was - without quite a bit more specific feedback from you. If you can tell us exactly what you did, we can figure it out.

So I'll do the math - but let's round to 9,700 for easy 1000 x 5 PQs = 5,000 caches - well maybe 4,900 with the needing to make each one less than 1,000 That leaves 4,800 to pull from the API in the same day. Since there's 6,000 per day with the API, I'd still be able to pull an additional 1,200 And you must have missed this part... Suggestions to make the packaging of PQ's more flexible are not new. Lack of interest by Groundspeak to allow that flexibility is not new. We have no leverage. Stalemate. But consider that so few users need anywhere near the available PQ limit that it seems to be a little known fact that the available daily limit was increased from 5 PQ's to 10 PQ's quite some time ago. From the PQ page: You can create up to 1000 queries. However, a maximum of 10 queries can be run each day. And yes it is a royal pain to determine the date ranges that allow you to combine those 10,000 (minus just a bit of shrinkage) caches into one large radius. I think I once saw a third party site that offered an automated solution for that, but I don't use that site. So I have to do it the Grounspeak way.

I've only been at this a few years longer than you have, but lets review. I remember a 500 cache per PQ limit, with a maximum of 5 PQ's per day = 2,500 total caches per day. Then there was the increase after the fire where the servers were housed. Was that the increase to 1000 caches per PQ? If so, that was then 5,000 total caches per day. The current daily PQ limit is not 5 as you suggested, but is 10 PQ's per day. 10 PQ's per day with a 1000 cache per PQ limit = 10,000 total caches per day. So while Groundspeak could make the process of acquiring 10,000 caches in one area every day easier, that is the one thing they have never done. Why would anyone think there is any real chance it ever will happen? That data (created by us) has value, and Groundspeak has always been careful to not let that data flow too freely. And they don't NEED to do anything. What are we going to do? Take our business to their viable competitor? What is the name of that competitor again?

Writing a good log is its own reward. Most of my find logs are time machines that can take me back to re-experience those past moments permanently preserved by those logs. You are only wasting your time trying to make a TFTC logger appreciate that. It is not in their DNA. A good analogy would be trying to get me to appreciate Opera. Good luck with that, and I suspect that Opera Favorite Points won't help.

I think Challenge caches are a total waste of time. For that reason I have not really commented on the issue. Not my problem. Please leave innocent cache owners out of this debate, and do not suggest that we should customize attribute selection for Challenge cache checking. My GPS does not display attribute information, so attributes are also a non issue for me.

I have never placed a Velcro hide, so no help there. But the question that comes to my mind is, who owns the painted aluminum - and do they know you have placed a cache there? If you find some super adhesive Velcro, are you able to remove it (after an extended period of time) without leaving any telltale sign or residue?