Yamar

Just like there is no spoon, there is no list. (I think the original intent was to make one, but they never did or make the sandbox they discussed) Do start following this discussion, though, as sometimes important things are posted here by TPTB.

I actuall have a "compiled" version of it which is a single binary install, but I haven't finished testing it. I was hoping to finish it last weekend but some other tasks on the weekend took all my time in the end (sigh). If you're having weird dependency issues then something in the package chain probably broke and fedora itself is messed up in some odd way... You could try: yum -x perl-Pod-Escapes install geoqo I think the perl-Pod-Escapes module in fedora needs someone to wack it.

Take a .gpx file from your pocket query and just run this: gpsbabel -i gpx -f THEFILE.gpx -o garmin -F /dev/ttyUSB0 If your device is connected to your USB port. If it's an older serial device, then use /dev/ttyS0 instead.

I think I have GeoQO almost packaged into a single binary (and that will include a single windows binary too I think). Give me another week and I think I'll have it done. (I really need to find someone to maintain a debian (Ubuntu) package for it...)

I've been a linux user since, um, well a really really long time since I can't remember. I almost never use windows and when i do it's frequently to load garmin maps to my GPS. Now with the ability to put maps from openstreetmap into my garmin without touching windows my motivation to use windows is much lower. There wasn't, however, any decent geocaching database tools for linux. I ended up cobbling together a bunch of scripts to do what I needed with gpx files which worked well till I decided I really needed something properly designed. After that I started the GeoQO open source project for doing geocaching and generic waypoint management. It's quite powerful, but hardly perfectly-friendly yet. On Fedora (which is what I use) you can try "yum install geoqo" to try it. On anything else, the instructions are a bit more painful because of pre-requisites. However, I think that's about to be solved distributing a pre-compiled version in the near future.

Speaking as someone who wrote an online cache-adventure long before Wherigo existed and who has dealt with many people that played the game the way "they should have" and those that "cheated" to get the answers I'd like to say "you can't stop the cheating". I generally know, as the cache owner, those that cheated and those that didn't. I will say that the ones that didn't cheat were much more appreciative and happy when they finished the online (and the physical counter part) of my adventure cache. I even put in a few "tricks" to make the cheating harder, but I know that it'll be impossible to make it impossible. So don't even try. (the best you could do would be to use a decent form of encryption and let the encryption key exist as a code in the field. Making the document itself encrypted won't help; the device will have the ability to decrypt the file and it'd be trivial to extract the decryption key from the device and decrypt all the games. Decryption and vendor-only DRM-software decoders have never worked and never will.) But is this new? No... it's always been possible to cheat at geocaches in the first place. You can always simply log a cache online without actually visiting the cache (since code-word proof-in-the-cache aren't legal (on GC.com at least)). Does that stop you from placing traditional caches? No...

As I said, "...I also don't see a Palm-based player any time soon." With that said, I'd love to be wrong. I don't see a PPC in my future anytime soon so I'll have to miss out until a Palm player is developed. The better question to me is: why is the file format closed-source? What is it buying Groundspeak to not publish the file format details so other people could help write readers for it? To keep this post on topic about what I think about the new caches? I don't think about them since I don't have the hardware so I can't. I'd like to think about them, but...

I have it and have used it... However, I generally use GeoNiche instead for finding caches as it does a bunch of stuff CacheNav won't. But... I rarely use my palm for finding caches. Most of the time I use a real handheld GPS (and have my palm out with cachemate description info open instead). BTW... if that bluetooth gps is tomtom's, you might as well give up now. It has a limitation that prevents you from doing much serious caching: if you drop below 2mph or so it stops updating the coordinates quickly (once every 30 seconds or so).

Which is where most painful feelings come from by new cache placers: the guidelines read as if you can make a case, but in actuality the case is decided upon by the reviewers. Different reviewers have different levels of conformance strictness. If you're placing a new cache: I'd advise sticking tightly to the guidelines as if they are rules and you'll be less likely to be surprised by a rejection. Then again, if you're just throwing a film can under a lamppost then you probably won't be too set back emotionally anyway.

I have a fairlry long winded rant on how to making your geocaching experience better called: How to find good geocaches. In it, it discusses why you should gave a rating based on a topic instead of just one (eg: "Location", "creativity", etc). Different people have different desires and the geoqo software tries to take this into account, for example, by using topics for ratings rather than a singular number.

Google Earth can read in GPX files and generated KML files... I'd suggest using a geocaching database program to generate KML files that suit your needs. GSAK is a popular one as well. Filter data as you need based on what you want to find.

I'm not sure which modules you have installed and which you don't. The quick way to check is to run the "check-prerequisites.pl" script in the source code directory. It'll list all the modules that you need and more than are optional. If run as root it'll help you install the missing modules using CPAN as well. You could also try reading the tutorials on getting started: http://www.geoqo.org/wiki/index.php/Tutorial

It's almost certainly because you're including pictures, which makes sense but makes it slow because downloading the pictures themselves is not quick (and may get you banned temporarily by the Groundspeak servers) and because plucker seems to be quite slow at scaling them from a larger size to a smaller one.

GeoQO ( http://www.geoqo.org/ ) has been written in the last year, so it certainly didn't exist if you've been out of touch in the last year. I have no idea how it compares to GSAK, since I've never used GSAK. It likely does a bunch of stuff GSAK doesn't do (like google earth denisty plots), and it likely doesn't do a bunch of stuff GSAK does (but I don't know what).

It's a pain... Unknowns are really the hardest ones to get filtered right. Sometimes you need to solve them "in the field" and sometimes you need to solve them before hand. I actually use geoqo to sort through the unknowns and tag them as "infield" or solve with coordinates. Then I filter what actually goes into the gps based on whether the solved puzzle coordinates exist or if there is an infield tag assigned to it...

FYI, geoqo can do all those things except export to maps.google (which doesn't allow that sort of support without a running webserver somewhere with your data on it). It can export to google earth, though, which will run on linux if you have a supported 3D card. The current SVN tree for geoqo has new support for exporting to anything gpsbabel can handle (and is functionally has a GUI interface to gpsbabel prompting for the output type and the associated parameters). (I've never used GSAK so I cant' offer a full feature comparison)

Then they should stop sending out pocket queries!

Wow. I haven't heard or thought of that song since probably the 70s. Thanks for the reminder. And I was too young at the time to even know who might have played it, so thanks for teaching me something. (Now, if only I could get this thing out of second gear)

I think we need an official geocaching honk; you know... when you're driving by a cacher looking for a cache and you don't have time to stop... ya honk! But if we had a common honk pattern, you'd know it was a cacher that just drove by and is laughing at you. Thus, I propose the letter "G" in morse code: dah dah dit. IE, two longer honks followed by one shorter. (thanks to RightWingWacko for knowing quickly what the letter G was in morse code)

For transferring stuff to your device, gpsbabel runs on linux and supports talking over serial and usb both. It's the most versatile solution out there for transferring data. For a geocaching database, I'll invite you to check out geoqo (http://www.geoqo.org/) which is written on linux (but works on windows and osx too). I just released 0.9 the other day which I consider to be the first release with a usable GUI... I've never used GSAK, and I'm sure that geoqo doesn't do everything GSAK does. But I'm sure geoqo can do a number of things gsak can't too (cache density plots being the most popular)

I would definitely implement permanent storage for data and update it as new data comes in. This lets you do a number of important things, like slowly building up a log collection that numbers greater than 5 (which is what is in a standard .gpx file... most people like more logs than that when they export to cachemate and similar). It also lets you show history and do comparisons. I'd also suggest using as much of a real database as possible for storing information. It simply makes things faster than trying to search through it using code-based searching and is more flexible. EG, in my geoqo application (www.geoqo.org (which I wrote on linux but works everywhere)) for example, I can do very complex searches across a large amount of data very quickly: # time geoqo -s 'cache:state=California' -d count: Search/Set Count: 10642 2.131u 0.372s 0:03.34 74.8% 0+0k 8+4736io 0pf+0w # time geoqo -s 'cache:state==California&&(cache:subtype=Unknown||cache:subtype=Multi)' -d count: Search/Set Count: 1741 0.755u 0.348s 0:01.33 81.9% 0+0k 0+864io 0pf+0w # time geoqo -d stats: Waypoints: 18512 Geocaches: 17469 Waymarks: 484 Geodinings: 125 Wigles: 0 Logs: 167283 Sets: 200 Tags: 1526 0.988u 0.548s 0:01.79 84.9% 0+0k 16+944io 0pf+0w If I had stored data in something that wasn't a real databsae, those first two searches would take a lotttttt longer. Searching 167k logs for the word awesome takes only a second: # time time geoqo -s 'log:text=awesome' -d count: Search/Set Count: 951 1.065u 0.878s 0:02.43 79.4% 0+0k 8+776io 0pf+0w As far as re-implementing a bunch of protocols, I strongly recommend you make use of what's available like gpsbabel rather than reinventing everything again. You'll be able to concentrate on what you want most, rather than spending time re-inventing things. (of course, you could help me develop geoqo instead ; ha ha)

I would definitely implement permanent storage for data and update it as new data comes in. This lets you do a number of important things, like slowly building up a log collection that numbers greater than 5 (which is what is in a standard .gpx file... most people like more logs than that when they export to cachemate and similar). It also lets you show history and do comparisons. I'd also suggest using as much of a real database as possible for storing information. It simply makes things faster than trying to search through it using code-based searching and is more flexible. EG, in my geoqo application (www.geoqo.org (which I wrote on linux but works everywhere)) for example, I can do very complex searches across a large amount of data very quickly: # time geoqo -s 'cache:state=California' -d count: Search/Set Count: 10642 2.131u 0.372s 0:03.34 74.8% 0+0k 8+4736io 0pf+0w # time geoqo -s 'cache:state==California&&(cache:subtype=Unknown||cache:subtype=Multi)' -d count: Search/Set Count: 1741 0.755u 0.348s 0:01.33 81.9% 0+0k 0+864io 0pf+0w # time geoqo -d stats: Waypoints: 18512 Geocaches: 17469 Waymarks: 484 Geodinings: 125 Wigles: 0 Logs: 167283 Sets: 200 Tags: 1526 0.988u 0.548s 0:01.79 84.9% 0+0k 16+944io 0pf+0w If I had stored data in something that wasn't a real databsae, those first two searches would take a lotttttt longer. Searching 167k logs for the word awesome takes only a second: # time time geoqo -s 'log:text=awesome' -d count: Search/Set Count: 951 1.065u 0.878s 0:02.43 79.4% 0+0k 8+776io 0pf+0w As far as re-implementing a bunch of protocols, I strongly recommend you make use of what's available like gpsbabel rather than reinventing everything again. You'll be able to concentrate on what you want most, rather than spending time re-inventing things. (of course, you could help me develop geoqo instead ; ha ha)

The biggest issue with tagging and rating is that everyone has different opinions and that tags and ratings from opposites of you are useless, which is the main argument people use against them. However, the solution is to only trust tags and rates from people who are similar to you (as discussed here). I'd argue that the owner should be able to tag their own cache too, though. But obviously they should be treated differently when looking at the collective tagging results.

If you're brave, GeoQO can tag and rate caches for you now and has a publication and sharing mechanism with others that use GeoQO too. However, the software is currently at the beta level and needs usability improvements (the base technology is there to do what you want now though).

Finally did get a new copy of geoqo posted, by the way, that has a much improved install script for windows folks. See: http://www.geoqo.org/ for details. (It's free)