as77

And why do you think that information is useless? Oh give it a rest as77. We heard the customer-friendly company CEO again.

And why do you think that information is useless?

OK, then I was misinformed, sorry about that. Don't blame me though, I read this here in the forums...

As far as I know, non-MO caches have audit logs, too, and you can always view the audit logs by switching the caches temporarily to MO status. That is to say, you just switch them to MO, look at the audit log and then switch them back to non-MO.

The second one looks like a website glitch. The logs seem to be associated with an event cache with multiple temporary caches. I guess somehow these logs got entered for the wrong cache. The first example is an event cache, those are now "Attended" logs, not "Found" logs.

Let's see some concrete examples.

Well, in that case the problem is unsolvable because there is no storage device that can store a continuum of waypoints As for the rest of your post, I don't see any issues. Both mathematically and computationally, the problem is trivial. You have a set of points connected with straight segments, find the subset of caches closer than a distance R from the set of these segments (and not the points of course).

If the user is willing to define his route himself by providing a set of waypoint along the route then there is absolutely no map of any kind needed to come up with a list of caches along that route. Therefore the high cost of some maps having certain features is by no means an excuse for not implementing the "caches along a route" feature.

I don't understand how an alternative mapping provider would solve the "caches along a route" problem. Essentially this problem has nothing to do with the maps. Sure it does. How else is the site going to find caches along my route, if I don't have a way to tell the site my route? I know my mapping software on my PC has a "find along route" feature, so if the site could afford a web based version for us to use, instead of searching for POI's like mine does, it'd search for caches. You upload or enter waypoints along the route. No map is needed. And if you want to click on the map to mark waypoints, that must also be possible with the current maps. I don't see why a different map provider would be needed.

I don't understand how an alternative mapping provider would solve the "caches along a route" problem. Essentially this problem has nothing to do with the maps.

Search for "gpxtomaplet".

Sure, but that's just one type of accident. When you combine the data for all types of accidents, it turns out that SUVs are not safer than cars, and actually they are slightly less safe. They have an advantage in crashes with smaller vehicles (usually the people in the smaller vehicle get killed), but on the other hand they roll over much more easily than cars, and rollovers are often deadly.

But you don't have to use two compilers. Code compiled with eVC++ 3.0 should run both on PPC2002 and PPC2003 devices. That's why I asked what special PPC2003 feature or library are you using that is not available in PPC2002.

You hit on the exact reason that we have two SUVs. In fact, I've been seriously considering trading my WJ in for something larger. Just so you know: The occupant death rate in crashes per million SUVs on the road is 6 percent higher than the death rate per million cars.

This is just a cache listing site. When a member is banned, he's only banned from using this cache listing site, he's not excluded from the community. The rules of this site are the rules of this cache listing site, not the rules of the geocaching community. Let's not get ridiculous by trying to create a complex judiciary system. It's just a website. The admins should decide on a case by case basis what they do.

Please tell me you're not serious. Yes, I am. The thread starter heard this rumor from his neighbor. The rest of us heard it here.

This thread does more than anything to help spread the rumor.

"Learns"? WTF does that mean? Has it ever occured to you that SUV drivers probably don't care much about gas prices or they too would probably be driving a cheap beater? Most of them can only afford to drive SUVs because gas has been cheap. Just look back on history: during the oil crisis in the 1970s, lots of people abandoned their pickup trucks in favor of more fuel-efficient, small cars. Then when the oil crisis ended and gas prices came down they switched back to the pickups and started to buy SUVs. Had it not been for the low gas prices, the SUV would never have become popular in the first place, and I bet that as gas prices continue to increase, more and more people will eventually get rid of their humongous gas guzzlers and buy more fuel efficient cars again.

Now we'll see if the SUV nation ever learns...

Here's a Traditional Virtual (type: traditional, container: virtual); indeed a virtual. A Multi Virtual (type: multi-cache, container: virtual) An example of a multi with no container type selected, turns out to be a virtual A Traditional Virtual (turns out to be a physical cache)

GEO, what feature does PPC2003 have that you utilize in GPXsonar and is not available in PPC2002? Is it not possible to compile a version that just runs on both? The executable itself should run under both OSs and work fine unless you are using some OS feature or library that is new in PPC2003.

Currently, Virtual is both a cache type and a container size. If the approver rejects your Virtual (as type) cache, you can just submit it as a Traditional cache in a Virtual container . You can also have a Multi cache in a Virtual container.

btw do we need html in the hints at all?

While you're at it, try it on the main page of the site, too. Or just any other page on the site for that matter.

Indeed, it doesn't work for me either. It did work just a few days ago... probably Google changed something.