Yamar

I don't think anyone has published a xslt transform, but gpsbabel outputs a bunch of stuff (html, text, ...) that you may want to look at to see if it already does what you want.

Although "approved" is actually a better name for what happens. Published implies purely administrative overhead, whereas what's really going on is rule-checking. It really is being "approved" not just "published".

Thanks for yet more excellent examples! Jeremy, you're welcome for the feedback. I know it's a hot topic but I'm really trying to help it out not make it worse. It's hard to appear that way when the potato is already scalding though...

1) Click through agreements haven't even stood up properly in court yet. 2) anyone that has read the entire agreement and afterwards says they've memorized it completely is lying (or amazing). 3) anyone that says they read the entire documents every time from start to finish every they click on those checkbuttons is also lying. Or very very bored in general. it's not possible to force people to read things. It is possible, however, to help them out in other positive ways. That's why we have computers in the first place: to help us do difficult things in easier ways (an unfortunate side effect, of course, is that computers themselves are difficult and the net-result is still 0).

Perfectly said. As I mentioned, my suggested changes are not to try and state in any way that the rules are bad. They're not. As I said they're well thought out and I'm not complaining. Originally I didn't like the no-more-virtuals rule but I've actually come to think that it's right only because of the sheer growth this game continues to get and will continue to get for a while now I think. My home town is already getting crowded with physical caches and I do think that's the main point of the game. So the delete-the-virtual suggestion and other suggestions are merely to help the new people that come around so they don't get confused and disappointed trying to learn the not-really written rules. In short, it's much easier and less discouraging to teach people that some rules can be broken than it is to tell people they did something wrong. Yes, some rules are bendable. Reviewers can always allow for something and discussions with them and here in the forums will help those cases actually happen. But I agree that few people come here (< 5% I'd even bet). And it shouldn't be required to play the game (but if it became a rule, I wouldn't fight it either). My only goal is to reduce the problem space, not to change it. The suggestion for splitting the submission screen into parts was suggested so you could present a warning. I never suggested that it should be a "you can't go on" second screen. Merely a warning saying "You are entering a details for a cache which are against the requirements for cache submission. Are you sure you want to continue? If so, make sure you indicate in your reviewer note why you think this cache is a special exception to the rules."

Games require rules. Geocaching is no exception. Players, of course, get annoyed by particular rules but the general consensus here is find a new game if you don't like the rules (which is just fine). Rules are a good thing, even ones you disagree with. It keeps the playing field level and safe. The geocaching.com rules, although not ideal for everyone, are a well thought out set of rules. However (you knew this was coming right), there are some improvements that could be made to the site to make the game easier to play and the fustration lower for new players. Nothing below is going to talk about modifying the rules because they've been long fought about and I certainly don't think we need another discussion on the subject. However, I have a few suggestions (most simple) that I think will greatly decrease the potential depression of a new cache submitter. 1) in the good old days, when the players were few, the guidelines were somewhat flexible and this was probably a good thing. However, the "guidelines" as the site refers to them have become more strict over time. This, I believe, is a good thing since it decreases the potential for user error as long as they read the guidelines. The problem is that they're called "guidelines". They're not. "guidelines" implies that they're suggestions to the cache creator, which they're not. They're actually "rules" or "requirements" because they're not up to the cache creator to debate. My first suggestion, therefore, is that you change the wording on the page to call them what they are: either "rules" or "requirements". IE, they're imposed and not subject to debate. 2) Delete virtuals from the option of cache types to create. I understand they may be replaced at some point, and that's great but until then they shouldn't be listed as an option. They only depress people when they get denied even though the creator though they were following the guidelines. There really is no reason to have them listed any more. If someone experienced believes they have a valid case for them, they could accomplish creating one via a reviewer-note post requesting special attention. having them listed as a possibility only confuses the newbies who don't understand the long history behind them being highly restricted. even if the replacement is coming on line in a short time (I don't know) delete them even if it's next week because it's got to be a 1 line code change. 3) make the cache creation form more than one form long. The simple reason is that then you can codify some of the rules so that people don't spend energy working on a description for a cache that ends up getting denied. Their feelings will be much improved if they get stopped early on with a warning before the expend major effort writing up a description. Consider some examples: a) if you don't do #2 above, you could stop them before they enter the description for the virtual and say "Virtuals are rarely approved and you should consider creating a multi-cache instead to help assure the cache is approvable". if an event cache and they submit it outside the rule time boundaries (2 weeks to 2 months) then you could stop them right there and tell them "Event caches are normally only approved if they fall within 2 weeks from today to 2 months fromtoday". c) If less that 512 feet away based on the coordinates, you could certainly let them know before they finish filling out the more time consuming form entries. d) ... more are certainly possible. These are only examples. All of the suggestions aren't because I think the rules are not appropriate. As I said, games need rules. However, I think with these improvements in place the newer cache creators will be happier with the system and there will be less annoyed posts and complaints in the long run. That's got to be a good thing!

Most of the time this is true. However, the two few to-do items in my nearest caches list are about 8 miles away supposedly. However to drive there I'd need to drive about 20 miles and hence I keep wanting to knock them off my list just because they're actually not the nearest ones to me. I tried to one day, but I took 2 small kids with me and we got 0/8 done.

Some tools let you combine logs from mulitple pocket queries into a single one. IE, I have mine come in over many months and slowly combine them so the number of stored logs increase. My software is hand-written and tailored to my needs, but I know GSAK can do it too and is a common tool for doing so...

Though I agree with your statement, we shouldn't be redundant I bet it was a real pain for him to do 60 manually (the same way it would be a pain for you to download 500 of your nearest caches without pocketqueries). We need mapsource or some other program to provide a programatic interface to routing!

It's a computer. Anything is possible. It may not be a high priority though. (since as someone pointed out you can get to the list, the work involved is likely even trivial since it's already possible just not through a simple top-link)

Actually, I think it would be very useful to have an entry box where people could put in the coordinates of the result to match against the real coordinates. If they got it right, they'd know it was ok to go search there. If not, they'd be told they blew it. That being said, I suspect some puzzle-cache creators wouldn't want that so it might have to be optional. It's probably not a trivial new feature either, but adding it to the wish-list would be a good thing IMHO.

I even used cachemate on a palm IIIx for a while with a whopping 4 megs of memory. It wasn't even slow and I stored 1500 caches there at times. (I'm still glad i have a newer palm now, but it wasn't cachemate that demanded the power and memory).

I was actually going to ask a similar question as well but hadn't gotten around to it. Specifically I agree that if we can do 5 a day, we should be able to store 35 ideally. I doubt the space of a PQ definition is big (the hit is the generation of the results, not the PQ definition itself). That being the case, even 100 makes sense to me assuming the storage space is indeed small. I hate deleting ones that I travel to only occasionally in order to make room for my temporary single-time trips. It'd be much easier just to uncheck and check things as needed with a slightly more reasonable boundary (say 50-100; even 35 would be better). (I'd think the server load of us editing stuff all the time would be worse than the storage requirements).

A project more likely to enable what you want: http://www.mythtv.org/

Excellent, thanks!! Looks great.

Messing with the html showed that it was the Attributes_AttributesTable with a height of 100% that caused the problem. Removing the height=100% attribute to the table tag fixes the problem (and has no adverse affects).

Konqueror is a web browser that comes with KDE which mostly runs on linux... I suspect I'm nearly the only one using it here, but I thought I would report the problem anyway... The new edit attributes page does not display properly for some reason. I may play with the html later and see if I can figure out why, but I haven't yet due to lack of time. The end result is that the page ends before the form and all the attribute images are fully shown (the submit button is missing as well). This very certainly could be a konqueror bug, since it seems fine in every other browser but I thought you'd want to know about it anyway. Odd.

My maps don't show check marks next to the last few caches I've found in the last few weeks either. I know this happens occasionally as well, but I don't know if it's related.

Actually, I implemented a 2004 TB Olympics but it didn't get much attention. I was planning on doing some of the things people wanted for 2005, but haven't completed things yet. Anyway, the system actually does calculate average speed from drop time to drop time. The concept was the fastest traveler would win the speed event. There are other events as well. I'm about to reset the system for the 2005 games. Let me know if you're interested in entering a bug. http://geocaching.sharedlists.com/olympics/

I suspect that logging a find for it will be difficult though: Value cannot be null. Parameter name: Argument 'Array' is Nothing. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.ArgumentNullException: Value cannot be null. Parameter name: Argument 'Array' is Nothing. Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. Stack Trace: [ArgumentNullException: Value cannot be null. Parameter name: Argument 'Array' is Nothing.] Microsoft.VisualBasic.Information.UBound(Array Array, Int32 Rank) +131 Geocaching.UI.LogBookPanel.ShowLogOptions() +89 Geocaching.UI.LogBookPanel.ShowNewLogInfo() +226 Geocaching.UI.LogBookPanel.Page_Load(Object sender, EventArgs e) +5163 System.Web.UI.Control.OnLoad(EventArgs e) +67 System.Web.UI.Control.LoadRecursive() +35 System.Web.UI.Control.LoadRecursive() +98 System.Web.UI.Control.LoadRecursive() +98 System.Web.UI.Page.ProcessRequestMain() +753 Version Information: Microsoft .NET Framework Version:1.1.4322.573; ASP.NET Version:1.1.4322.573

I agree... I'm writing a tool now that needs as many logs as it can get to. 5 is very little and I'd love to be able to get at all of them. Some people I know, in fact, run pocket queries really really frequently so that they can merge all the logs. Thus it takes a lot more bandwidth to regenerate all the same data on a really frequent basis for areas where they only intend to visit once in a while. I bet they'd zero-day those queries if they knew they could get the data on demand rather than have to collect it over time. I've been considering doing the same thing actully.

Thanks again for the warning process!

First off, I must be honest. I didn't read all the posts to see if this was suggested. However, I was actually thinking about this in the last week. I was considering writing a patch for GPSbabel which would take a route or a track (which it can already parse) or a list of waypoints and then from that "line" do a polygon expansion around it to get the filter Iwanted automatically. Saying "2 mi" along the route would mean taking each line segment and making a polygon perpendicular to it (and extending it both directions by 2mi as well) and then overlaying all the polygons (or running each seperately and combining the results, removing duplicates). The line to polygon math is not hard (can you say "cos" and "sin"; I knew you could). Thus, you could do the same thing on gc.com... Simply have users submit either a route extracted from mapsource (or something) or something more generic like a list of waypoints (which is really all a route is anyway). The calculation on your end I don't think would be too CPU intensive (though I'm sure it would be a PQ only feature).

I have 2 monitors currently, both LCD (one desktop; one laptop). I can *almost* see the colors if I strain my eyes enough and get real close to the screen. Interestingly, I just noticed that the gray background on this posting page seperating the different sections is quite visible without being obnoxious. Maybe copy those?

I think a lot of people use tools that change the icon when they're uploaded to their GPS. I know my self-written mess-with-it script does this based on the size and type of the contraption... At least that lets you see it on your GPS. It would certainyl be nice for the geocaching.com maps to do the same thing for type = regular and container = micro...