pppingme

Its not a simple upload and store. GC does do processing to reduce size and some things like that, to strip the exif data at that same point would not be hardly any burden. Assuming they are using some 3rd party tool to do this (and I highly doubt they wrote this themselves), then its probably already an option of that tool.

Um, seeing as cleaing your session cookie fixes the problem instantly (without even restarting browser), this is clearly wrong. Clearing the session cookies will reset any the temporary state (on the server) the site stores about you, since you are starting a new session. Waitiing until that session expires would have the same effect. As a web developer I doubt it's related to 'business', though possibly the initial condition is triggered by that. Wrong, the time he took to clear his cookies probably gave enough time for him to land on another server at gc. Remember, there is more than one front end server, and if this is happening on one server only, then whatever method they are using to load balance (it appears to be round robin dns) could very well be enough of a pause to force him to a new server. A 500 error is ALWAYS something on the web server, if clearing cookies fixes it, then in most cases something underlying is what really fixed it (like moving to a new server) OR some really bad code that allows a bad cookie to make it error out (which should never happen, its an open door to a dos attack). Official definition (as defined by w3.org): 500 Internal Server Error The server encountered an unexpected condition which prevented it from fulfilling the request.

GSAK didn't have a single problem with the attributes. I'm not aware of a single complaint from a gsak user. Of course GSAK didn't do anything with the attributes except to gracefully ignore them. Had he known what was coming and the format of the new GPX extensions, I am certain Clyde could have had something working and ready to use the attributes when they came out. Actually, gsak didn't ignore them, they were stored and could be queried (via macro, not added to the user interface yet). The point being that certain people like to slam gsak, when there were in fact no problems.

GSAK didn't have a single problem with the attributes. I'm not aware of a single complaint from a gsak user.

No thanks. Then you show up in audit logs on MOCs. No, because you still don't visit the page. Field notes take you straight to the log screen, not to the cache screen.

The better solution is (gc, are you paying attention) is for anything that is logged via the wap site to show up as field notes, just like every other mobile platform (trimble for example). Then dups can be cleaned up and notes expanded before actually being logged on the site.

A workaround is to pull individual .gpx files as soon as you log a cache. Unless you have a really busy day, this should only take a few minutes (that is unless the sites running really slow again or kicking errors).

Deletion logs are not horribly reliable. Do you keep track of your finds in gsak or any other way? If you do, import your current finds into gsak, setting it to check the user flag, then see what finds you have that don't have the user flag set.

If I can figure out exactly what they use I would be glad to do so. I haven't had much luck with getting it to date... I'm pretty sure Nate said what they were using here about 6 months ago or so, but I can't find the post. There were a couple threads at that time because they changed it and it was resulting in caches being reported as being further out than they used to. Maybe someone else will have better luck searching or Nate may chime in if he remembers.

Fizzymagic, Even though I get the feeling that you think its inaccurate, is there any chance adding the same formula as the gc site as a 4th option?

Oops, my mistake, its no longer called geocalc, its called fizzycalc. Here's the url: http://www.fizzymagic.net/Geocaching/FizzyCalc/index.html

The first waypoint you gave is in florida, so I couldn't try the distance calc my self. Several months ago, gc did change how they computed distances, and there was a ripple in the forums at that time. I don't remember if they stated what method they started using, maybe Nate or someone that remembers can chime in here. I tried searching but thats pretty useless anymore. A program I use is geocalc, it uses a couple different formulas. You just key in both coordinates, and you can change which method it uses and see the difference immediately.

Was it a warning about a spyware or tracking cookie? There are 1/2 dozen or so 3rd party cookies that gc is more than happy to plant on your system.

An issue with this is that GC does not keep track of county. GSAK does, which is why its easy to filter. Right now I see a ton of problems with users getting the STATE correct when setting up new caches (and yes, the reviewers seem to consistently miss this), most people have no idea where county lines are and listing in the wrong county would become a very large problem.

Not a particularly helpful solution. I would have to re-log all my finds in a second account. Actually, there is a way to do this, here is how to do it. When logged into the 2nd "query only" account, go to this url: http://www.geocaching.com/seek/nearest.asp...untName&f=1 (replacing "FirstAccountName" with your main account). If anything is there, ignore it. This takes the longest when you first start, but as you keep it up, doesn't really take any time. Then for the PQ's for the "query only" account check the "Are not on my ignore list", with all your finds on the ignore list of the query only account, this acts the same as "I have found". Every couple days or how ever often you rework your PQ's, go to the url, if anything is there (your finds since last time you checked) ignore it.

And yet it will show up in a PQ the next morning, all without ever visiting the site. What "cache info" is on the page thats not in the .gpx? Wouldn't that mean that gc isn't sending out valid .gpx files to start with? If thats the case, they need to fix the .gpx files, not make you come grab them manually off a page your not going to read anyway, because you know your going to read it later in the .gpx file. Pictures. All the logs. Links to the pics ARE included, and I'm not going to read 1500 logs just because a cache has that many finds, if logs are important, then include more in the .gpx (I would prefer 10 be included, and when I'm out caching, I carry the last 10 logs if I have them).

And yet it will show up in a PQ the next morning, all without ever visiting the site. What "cache info" is on the page thats not in the .gpx? Wouldn't that mean that gc isn't sending out valid .gpx files to start with? If thats the case, they need to fix the .gpx files, not make you come grab them manually off a page your not going to read anyway, because you know your going to read it later in the .gpx file.

The current one is findstatgen3 You can get it here: http://gsak.net/board/MacroIndex.php

Just create a query with the defaults you like, then when you need to create a new one, instead of clicking on the new query link, copy your default query and edit away.

Yeah, but considering the number of people watching caches, the number of bookmarks, etc. every log on a cache probably generates an average of 3 or so emails anyway, so its not like we are talking about a significant increase in email from a gc perspective. Obviously something that can be turned on or off per user, but I personally (and many other cachers do as well) want a .gpx after logging a cache, my preference would be to receive it in the same stream as I get pq's, so it updates my info. As it is now, after logging, I still have to drudge through and grab .gpx files after logging finds, this is easy if I just did one or two on the way home, but if I do several in a day, it quickly becomes a pain, especially when I'm on a slower connection.

Partially true. I support .gpx in notifications, but not all of my finds fall within the ranges of all of my notifications. This would be a separate notify, tied to me that sends me a .gpx when I log a cache, regardless of that caches status in any notifies, watchlists, pq's, etc.

Maybe a more optimized feature request, is sort of a auto email with .gpx, where every time you log a cache (I would want every log type, finds, dnf's, note, etc, but even if it were just finds) that gc would send a .gpx. I think a LOT of people try to grab a .gpx after they log, and if gc would just auto send those, sort of pq format, but just that one cache, it would answer a lot of problems, like the whole gpx macro issues, wanting current find data, minimizing the pq's run now (elminate the need for the full my finds pq for a lot of people), and probably more.

We won't mention a few previous because it angers one of our friends, but we just saw them disable one yesterday. If it hadn't been found today, we have no idea where that was going... You sure it wasn't a fake find log to avoid this very situation? That's what this issue is going to drive CO's to do, post fake finds so the reviewers leave them alone. Knowing the cachers who found the cache, Im sure it isnt a fake log. Oh, I didn't mean to say anything bad about the finders (in this case), Its meant to point out that with this, and the fact a couple more caches have been disabled since this cache was archived, its inevitable that this will happen.

We won't mention a few previous because it angers one of our friends, but we just saw them disable one yesterday. If it hadn't been found today, we have no idea where that was going... You sure it wasn't a fake find log to avoid this very situation? That's what this issue is going to drive CO's to do, post fake finds so the reviewers leave them alone.

I would say most of this is people trying to figure out why it quit updating in their own (dare I say it, offline database) listings, and possibly grabbing a .gpx to "close it out" of their listings. Hmm... Maybe a good reason to include .gpx in notify emails. Another reason would be cachers that get either a notify or have it bookmarked and get an email saying it was archived, then they just want to see the final details.