 |
 |
 |
 |
 |
 |
 |
 |
 |
| Currently loaded stats: | Login |
|
|
||||||||||
|
This is a how-to guide for getting and uploading your "My Finds" pocket query into the INATN site which will hopefully address many of the common pitfalls that people have encountered.
One common problem is not having the correct pocket query. Even though you can manually create a query that has "Caches I Have Found" as a condition, that query will not include any caches which have been archived since you found them. Consequently, your find totals will end up being lower than they should. What you need is the "My Finds" pocket query which will include every cache you have found, including any archived caches. On the Pocket Query generation screen, find the button that says "Add to Queue" and click it. That will automatically send the query to the address you have set with GC.com. You can run this query once per week.
There's an annoying quirk that people have noticed and that I have no control over. If you log a bunch of caches, then when finished, immediately generate your PQ, the caches you just logged may not be included with the query. In some cases people have reported that they've requested their query a couple hours after they were finished logging caches and they still were not included. That may be a function of how busy geocaching.com currently is, i.e. busier on weekends than on weekdays. Your best bet is that if you log all your weekend finds on Sunday night, wait until Monday morning to generate your PQ.
Hopefully, within a few minutes of requesting your PQ, it will show up in your email. Unlike the PQs that you create yourself, with the My Finds query, you don't get the option of setting an email destination, so it will show up in the default email address in your GC.com profile.
The query will be sent to you as a zip file and will have a number for a name, such as "354877.zip". You need to save this file to your computer to a place where you can find it later. A good place to save it is either your Desktop or your Documents folder.
File saving pitfalls: When you save the file, don't rename it! You may be tempted to save it and give it a name like "my finds query.zip" DON'T! There are two files inside the zip archive. For my example, they would be called "354877.gpx" and "354877-wpts.gpx" The script that parses through your caches expects that the two files inside the archive are names the same as the zip archive. If you change the name, the script will be looking for "my finds query.gpx" and "my finds query-wpts.gpx", not find them, and give you an error.
Speaking of the files inside the zip archive, don't unzip the file! Again, the script is expecting you to upload a zip file. If you unzip the file and try to upload "354877.gpx", the script will try to unzip that, fail because it's not a zip file, and give you an error. The reason the I want you to upload a zip file is for bandwith savings. Note that the file in the examples above is only 668K. Uncompressed, the file is about 3500K. That's almost a 6x savings in bandwidth and the time it takes to upload the file!
Reportedly, some ISPs may have virus checkers that preprocess the file before delivering it to you. If your ISP does this and sends you the two gpx files instead of a zip file, you'll need to use WinZip or another application to put them back into a zip file (make sure to name it with the number!) and upload that file.
What's described above are the reasons that 99% of the "I'm having trouble getting my stats" emails I get are sent. Every now and then there is a "glitch in the Matrix" and a file won't upload, but it seems to work just fine a few minutes later.
 |
||
|
|
  |
|
