russellvt
-
Posts
154 -
Joined
-
Last visited
Posts posted by russellvt
-
-
I've asked this question before, but no one who knows the answer has ever responded:
How large could a PQ get before the "average" email server would not allow it to be received? I mean, I know the PQs are zipped, so they are smaller than the could be, but they do have a "size" right?
So theoretically at some point they would be "too big" to be received as an attachment---Yes? No?
Well... "large" used to be around 64k or more. About the largest PQ I can remember receiving was probably about 256k or so... maybe more. These days, that's not really that large... but it all comes down to what your administrator defines as "too big" -- usually a meg or two (1024k is one meg) is pretty safe
Can someone explain to someone like me, who can send and receive attachments but doesn't really get how zipped files are smaller than the size they ultimately open into?
Well... there are many different ways to compress data. A very simple one could be to note that printable characters only occupy a small/predictable segment of the eight-bit byte for the english character set (Aka ASCII)... and the "high order bit" is never used with those characters, so can be ignored. So, if you simply "remove" that bit and effectively "compress" the rest together, you already have a 1/8th sized savings in this "compressed" format (and re-expanding that same data is as simple as just adding the 0-bit back in after every seven bits of the compressed stream).
Of course, there are much better ways (aka algorithms) to compress data and save space, such as the zip form you mentioned... but that's one of simplest example I think I could easily relate, here, in any real understandable form (it's also one of the very first ones I remember writing back when I was still in school). *laugh*
-
i guess i just don't understand, there's no way i'm going to do 500 caches in a day or a week so why do i need a PQ for 1000 a day ????????
My only "devil's advocate" argument is that I tend to load caches in and around areas I frequent or am traveling, in case I ever suddenly decide to break out the GPS and go for a hunt nearby. Of course, cache density is quite thick around here, too. Then again, lately my main objective these days is to simply start clearing out "cache free zones" nearby... of course, I only have like 1-1.5k or so "local" caches in my DB at the moment.
Also, on a separate note, we've recently discussed making a cross country drive and, of course, we'll need/want to be caching most of it (though gas prices might make that a tad... crazy). I'm currently pondering "how" to get a reasonable cache list along our anticipated, but still subject-to-change, route.
-
Maybe I'm just thick, but I don't see the privacy angle. People are posting their finds as notes because their definition of private is "visible to everyone who views the cache pages, but not to those who view my profile?" The logs are still online, just inconvenient to find. That's not really private. What am I missing?
Maybe "private" isn't quite the right angle. I see it as just a subtle difference between letting people view your logs cache-by-cache by happen-stance versus a "complete list of every place and approximate date/time you were there."
Perhaps, similarly, there's also call for an "ignore" list that prevents folks from seeing your cache logs. Or simply allow the direct exposure of your "found" logs (in your profile) to be user settable/selectable.
-
I was concerned about the privacy/stalking part of this idea until I saw the "Friends" connection. That should be a critical criteria of anything like this. You can accomplish the same thing now by opening each cache they've found and finding their entry. Very tedious, but doable. Stalkers already have their ways of doing their thing.
Good point... but I also like the idea of maybe closing down the "found logs" to those in a contact and/or "friends" list. Though I tend to be more of a "paranoid" type (read: network security dweeb), of all things I'm not too overly concerned about folks reading my GC log entries... then again, I've not yet done something like "a sick call for the sake of another caching day" or anything like that, either! *laugh*
-
I agree. DNFs can be very entertaining logs. I write some of my best adventures on a DNF.
Similarly, I agree. It also helps spouses and S/Os who maintain their own account and have the tendency to log by "surfing the other's profile."
And yeah, while it potentially enables some level of "cyberstalking" (though that's expressly forbidden in the ToS, IIRC), certain more-prolific folks can be quite fun/entertaining to read their logs for comedic value alone (similarly I've seen a few "best DNF log" discussions here a few times).
-
I'm also a system (UN*X) engineer and "tools" type. I do a lot of systems automation / tools development.
Kind of "random" how I found this topic, too... *laugh*
-
If you get Notifications for "Archived" caches, and "Disabled" caches, you can keep the data you are putting into your GPSr as current as possible. I use several "Date Placed" PQs to get a wide search area coupled with those notifications and the "Last .gpx Update" filter in GSAK to keep my data current.
It really is easy-peasy once you get used to understanding how to filter out caches that didn't update with the last set of PQs.
/slaps forehead
This entire thread and you're the first to suggest something as bonehead-simple as that... doh! Guess I got entirely too tunnel-visioned with the entire "bulk" idea... something about "forest of sake of the trees," eh? Similarly, I sometimes think others might get too locked in to arguing a point rather than simply stepping back, thinking, and trying to actually help with a given issue.
Thanks Miragee! You rock!
(also thanks to trainlove who also replied privately to me with another good line of reasoning)
-
Allowing the user to get an update of just caches that have been archived would make it easier to keep a larger offline database. Instead of getting the same 2500 caches everyday, one could build up an database of 25000 caches or more and get the caches that have been updated everyday including those that were archived that day. I'd bet you'd only need one 500 cache query per day to maintain a 25000 cache database. With a little effort one could probably keep a up to date copy of a significant portion of the Geocaching.com database.
I'd still contend that the only thing that really changes here is the ease at which you maintain these databases... really, there's not much difference between it and in pulling the same PQ every N days. As early as the second time you request the "same" dataset (or even a significantly overlapping one for that matter), you should already know basically what you expect to see, the only exception being the furthest outliers from a center point or a particular query (which can be calculated on each request, essentially based on the delta of changes). And, you'd not even need to screen-scrape.
So, to put it as simply as possible, any cache that was listed in a previous query that's "closer" than any other point is likely listed as archived... anything further out than (or a relatively small average of a few of them) simply is ignored as not being included in the dataset you were sent. It's really not that hard if your goal is to copy the database -- I'm just looking to make my life easier, that's all (and unfortunately I've seen caches archived much faster than I might otherwise like to admit).
So really, I think all that's happening (in my opnion) is sacrificing that ease at which legitimate or paid users are able to update whatever caches they're caching (in the sense of a "maintained database" go). Again, in my opinion... for all that's worth (I know, probably nothing, at this point).
Then again, neither one of us can speak for Jeremy, let alone Groundspeak, can we? *smirk*
(though perhaps this thread's received enough attention that someone in some official position might be able to further enlighten us... *shrug*)
-
I find it amazing that everyone who asks for a way to get archived caches in their pocket queries is sure that Groundspeak would prefer that they didn't put such a load on the servers by using one of the other methods to determine which caches in their offline database had been archived.
Let's see... download a large page (something around 1MB, all told, last I looked), or send me the text portions of the same data... seems like the later would be a lot less intensive just in terms of bandwidth, alone (nearly 50MB versus like, what, 256k maybe?). Either way, I still need to get the same data (for my own personal use, of course).
Perhaps if you can propose a way to prevent abuse of a PQ of archived caches it would be a reasonable request.
Well, personally I see far less abuse potential for a list of "what used to be" than what's currently already allowed... meaning, I think it's far-more-abuseable to be able to PQ the same 2500 caches every day and, by process of elimination, deduce the "missing" (archived?) caches than to let me get 2000 of those same caches and 500 caches that "no longer exist."
Then again, I guess I fail to see why someone would specifically/otherwise want this data for illicit purposes; guess I must be missing something. I mean, truth by told, there are enough tools out there these days that detecting a crafty person with malicious/illegitimate ideas is already the proverbial "needle in the haystack," so to speak (especially when that "needle" looks like just another piece of hay). Personally, I'd rather just ask and hope the-powers-that-be might agree.
I guess perhaps I should have just left this topic to "adding them back on to the map" instead of the "dreaded PQ." eh? *laugh* And here I thought maybe the PQ would get a bit less resistance... at least that way the option would be for paid subscribers, only. Guess I figured wrong, there.
-
I noticed, too, it was mostly my mobile browser and often more-so the case with multi-line or paragraph hints... sometimes the first paragraph/line would decode, but the rest would stay encoded. Glad to know they're working on it, at least.
-
The trials we must suffer for a superior browser I suppose...
Or at least, refusing to use the sign-me-up-for-the-virus-of-the-day browser...
-
I was just wondering how do I delete a bookmark list?. I know how to delete individual bookmarks but just not the list once I've completed finding all the caches on my bookmark list. I just don't see an option to do that.
Once you clear all the caches/bookmarks out of it, you should be able to "Archive" it from the edit page.
Edit: Oops... StarBrand is a little faster on the keyboard than I am, today.
-
If one is like me, ie. 8 million tabs open on launching Firefox, a few being gc pages, the easiest way to accomplish this is to just delete the geocaching.com cookie (just in case anyone is actually finding a browser restart alone doesn't do the trick)
Yep... that's me, too! Luckily I also use the Web Developer plug-in, so it's just as easy as clicking "Cookies | Clear Session Cookies" and then all is well, again. Of course, it took until the time I read this thread and noticed people complaining about IE versus Firefox issues. Gah... gotta love it, eh?
Of course, doing that clears all your sessions. So anything else you "log in to" is likely also going to boot you out to a login prompt. Still a much better alternative to restarting the entire browser, IMO.
-
I'd have to disagree with at least part of that. All too often when people ask for features on this site, they are told that they dont need it on the site because they can already do it in GSAK. In your post you claim that they have no interest in helping us maintain our GSAK, but then it comes down to a catch 22 of sorts. May of the requested features should be integrated into the website, else make consessions for people doing that work on thier own...
See this quote from jeremy (owner of the website)
The sheer irony of this, of course, is that when you create a PQ and download caches directly to your GPS, what you are doing in essence is creating an offline database. You can still take that data off the GPS or manipulate it in any way you so desire. Simply because it doesn't reside on someone's PC (in GSAK or anything else for that matter) is pretty much irrelevant. You can even still pull those same waypoints back from your GPS in to any number of applications...
Of course, further irony here (part of the catch-22 root1657 pointed out) is that by not providing the functionality, they're essentially encouraging others that want/need to use these offline databases to come up with their own (possibly automated) mechanisms to verify the status of caches. I'm sure, however, that Groundspeak would likely prefer that people didn't do such things, as it only helps to drive up load on their webservers as more and more people with large databases end up pounding their way through their DBs in-attempts to make sure a cache they're planning on hunting hasn't been disabled or archived. Of course, I also can't speak for anyone at Groundspeak, though they've listed spidering as against the ToS, it's probably not often worse than someone just opening up a ton of windows (in a non-automated fashion) so they can click through the "GPX" update.
Just seems like a reasonable request, as people really don't want to waste time on looking for caches that no longer exist... and truly, there's not really much differentiating something like GSAK and whatever waypoints I already have stored in my GPS without the benefit of some form of middleware. And, like I said, it'd probably help reduce the load on the Groundspeak webservers/database.
-
Looks like whatever they did screwed up session cookies, which forced you to an error page (and probably refreshed your "bad" session). Clearing your sessions (in essence, restarting your browser) tends to fix it.
Why they just don't tell the browser to dump invalid session cookies is a question in and of itself, though.
-
So yeah, I'm making enough progress here in San Diego that I now have areas that are nothing but 'disabled clouds'. Sure I can put pressure on the owners and all of that, but that doesnt really take care of the 'right now' issue with now being able to see past them because they are cluttering up the map.
The map already knows what they are, what is the harm in adding one more filter check box so I can see what I want to see, just like I can for other categories of caches?
As "The Leprechauns" pointed out, premium members already have the ability to filter out these icons from the map, even though they are useful. However, like so many other things on the site, navigation there isn't necessarily the simplest.
Premium members can click on "Build Pocket Queries" from the "My Account" page, and then in any one of the pocket queries you have defined or you build (like "Near Home" or whatever), just select the "Is Active" option under the "That (and)" heading, below "Container Size" and click save. Return to the list and click on the second icon on the line in-question -- it should say "Preview in Google Maps" when you mouse-over the thing. Your map will now only include active caches.
Yeah, it's a little cumbersome, but like others have said I think it's more to better-enable the community to self-police. As we also know, many folks also don't log DNFs and some cache owners may not be the most responsive when their cache seems to turn-up missing. I think having those icons on-map helps light a fire under some folks butts... and, conversly, think that maybe we need to add archived caches back to the map/query page.
-
It would be useful to add the attribute "Archived Cache" (similar to "Is Not Active") to the pocket queries page. I'd say it should be on the Google Maps page (though unselected by default) but that might be overkill. This feature would be useful for those that maintain things like GSAK databases and they need/want to know when caches on their list (read: possibly already in their GPS) have either been marked inactive or simply archived -- sometimes there is no time in-between, or the two happen very quickly from one another.
I know that I (like others) have had a few occasions where I've spent way-too-much-time looking for a recently archived cache (which I missed because it wasn't on the map for the area I was targeting, but I already had it in GSAK and didn't cross-verify the caches from that angle before I left on my caching day). Adding this would help premium members better optimize their time.
-
It would be nice to have the calendar in "bookmarkable" form rather than the overly complex javascript postbacks it currently uses. Basically, I'm asking that calendar months/days/etc become bookmark'able or easily tradeable/linkable. It would make it A LOT easier to trade links with your geocaching buddies and "plan a trip" or even for search engines to pick up and index/publish these events (though that's secondary, I'd not doubt you might be trying to avoid it -- but isn't that what robots.txt is for, though?).
In my opinion, the general ROT (Rule of Thumb) is that anything which doesn't modify data should use a simple "get" from the webserver rather than hiding things in posts (and invariably, making it difficult to bookmark). Currently to plan with other folks/friends, you are forced to say "hey, check out those events on Somestate on Someday" rather than "hey, look at this list of events in this link."
(And yes, I know you can just link to individual events (Aka "caches"), but the point is to be able to get to the list for a given day/week/month, not the individual event)
-
A friend of mine's been "curious" about geocaching for a couple of months now... he's been reluctant to sign up for the free account, was having a bit of trouble finding his handheld GPS, etc... of course, giving him a "proper" introduction is further complicated by the fact that he now lives a good 500+ miles away. Anyway, I checked out some caches in his area and, low and behold, there are some that I think I can "pick out" from the safety of my machine and google maps -- so I offered to try to give him "an intro" the next time he was at his son's ballpark while I try to verbally guide him to a cache.
Anyway... a couple weeks pass and he calls me, says he "found" his first cache. The funny thing... it was on his doorstep. Apparently the young daughter of a neighbor had "found this cool pine cone" and, embedded in the bottom of the thing was a bison tube complete with log and was doing the "look what *I* found" thing (in typical 5yo fashion). Anyway, he called me yesterday and relayed this story to me... I thought it was pretty funny.
In any case, I finally talked him in to signing up on the website and I helped him locate the cache (and owner) who are now short one container and log sheet. Surprisingly enough, there was NOT a "this is a geocache not a bomb" sheet with the cache, or even a reference ID on the cache... luckily the little girl managed to take this to someone that had heard about geocaching and even had an idea on someone to call -- after that, it was just a bit of brute force.
-
I was entering my weekend finds this morning and that function worked normally for me.
By the way, you mentioned that you enter the first cache then the next, etc. When I enter several caches that were all from the same day I always create the log for the last cache first, then entering the others in reverse order. That way the order the found caches are displayed are in the same order as I found them. The display shows the most recent dates first, but for some reason reverses the order that they are entered (with the first cache entered on a date being shown at the top of the day's entries). If the most recent date is shown at the top, then the most recent cache log for a date should also be shown at the top.
Technically, GC.com is showing them to you in-order... just the reverse of what most people would expect when looking at it, I think.
But, if you're interested in tracking the order in which you find things, among other stats, use something like GSAK (Geocaching Swiss Army Knife).
As for the button for entering "next cache" -- it's never worked for me, personally. Then again, I tend to disable javascript on pretty much every web page...
-
Feel free to add your own
I'll just leave the car running for this one....
This one has to have been muggled....
There's NO way this is only a 1.5 difficulty cache!
There's no place HERE that would hold/hide a "regular" container.
(while eying the map) This should be a quick park-and-grab...
...which is followed by "WTH do/can I park for this one?!?"
(while night-caching) I can get in there and grab it before the sprinklers come on...
-
5/4/2008
Hi everyone. In the past, I used my Garmin 60CSx on long flights until a United Airlines flight attendant told me that they were not allowed. I just intercepted a posting that restricted GPSr units from cruise ships (see attached).
Actually, UAL permits the use of handheld GPS units... however, generally the cabin crew doesn't have much knowledge of many of the electronics that the average business traveler may even possess and may tell you that you can't use them (look at how long it took them to start "worrying" about pagers, blackberry devices, etc).
Strangely however, I've taken a few UAL flights (possibly operated by another one of their sister carriers, like Mesa) where they've enumerated GPS receivers as "forbidden." In any case, you can politely ask that the cabin crew ask the pilot for permission.
One page that may also be useful: Airlines which approve/disapprove of GPS use in-flight
-
I remember reading a funny thread at some point, where someone joked of having a snake cache and suddenly see a cacher log a DNF with a message like, "Couldn't find the cache, but were startled by a snake which we were able to grab and throw over the side of the cliff!"
-
I noticed while browsing some of mw own website referral stats that caches link-out with a http://geocaching.com/seek/cache_details.aspx?guid=XXXXXXX URL, yet that URL breaks when it is used/followed and comes up as an "Unpublished" cache (even with a valid GUID). Simply adding the "www" to the hostname fixes it (ie. http://www.geocaching.com/seek/cache_detai...x?guid=XXXXXXX). Note: neither one of the above links will work, but are there as example.
But this begs the question, should the host by fixed or should the referring URLs (reverse DNS?) be fixed?
Is it always this hard to get a geocache approved?
in General geocaching topics
Posted · Edited by russellvt
One thing I'm surprised no one has mentioned yet with regard to railroads... similar to overhead power lines, natural or constructed barriers or not, they also tend to have an "easement" on both sides of their tracks that may extend well in to what someone else may consider "property" (either public or private). Likewise, people tend to have a general perception on what "too close" to those same active structures may be before they consider you to be "around" it (purely from an observer's "personal space" point of view).
Like with most important structures, infrastructure and facilities (included but not limited to power plants, government buildings, bridges, schools and railways), observant muggles may tend to be a bit more paranoid when they notice someone milling about or otherwise loitering or looking suspicious in those types of areas... and consequently, are much more likely to get the authorities involved in this post 9/11 world... and we've probably all seen enough news stories of the bomb squads that have been called in to clear out harmless geocaches and similar, lately.
So, what I am trying to say: these guidelines exist for a reason -- to protect people (and this hobby) from themselves and not simply to annoy/inconvenience you. The more bad press that brought about for this hobby that we all enjoy (don't we?), the tougher I figure it may be to participate with it as time goes on (similarly, the more frustrated many people (like yourself) that may become with it and "give up"). Yeah, it sucks... and it may cause you more "work" up front to get something approved. But sit back, take a breath / drink a beer / whatever... as others have said, there has to be some rather simple reason that you are seemingly (temporarily?) having problems with approvals -- I don't think you're anyone's kick-dog, though.
As I've also been known to point out in situations like this... if you really think it's "all about denying you," the next time you are in the store, remember to pick up a tube of Preparation H and read the side of it. Notice it says: "Do Not Ingest!" You know why? Because at some point some idiot did... that should be food for thought (kinda like the warnings on blow dryers, toasters, etc that say "do not use in the shower").
BTW... as others have also pointed out... I think all that you need to do to keep that cache from getting archived is that the owner (yourself?) just needs to be "kick" the thing out of "needs maintenance" and then all should be good.