GeoToad

I discovered GeoToad this weekend.  I haven’t messed with too much, but I already like it.

It’s written in Ruby, so it will run everywhere natively (i.e without Cygwin or a Unix environment).  I’ve been having problems with the geo-* tools that I have raved about before.  They assume that you are using GNU tools and the  BSD  utils  that come with OSX behave differently  than their GNU counterparts — different command line options, etc.  So  I needed something else.  GeoToad will fit the  bill.

I don’t use the full-screen interface — that’s for wimps. Instead I’ve been using the command-line interface.  Both of them do the same thing.  One of the great things about GeoToad is that it caches it’s results.  This prevents you from hitting Gecaching.com over and over again.  They get picky about that.  GeoToad also exports GPX files with the the groundspeak namespace.  Doing that with the geo tools took a lot of time, but GoeToad does with by default, and with ease.

I’m looking forward to hooking GeoToad up with GPSBabel and having a good ol’  time with hacking with geocaching data.

Finally . . . Number 75

I had hoped to be past 100 now, but things got busy.  But this weekend I finally got my 75th cache!  So it’s not quite the 100 milestone, but it’s one I’m proud of.  Especially since I was at 50 in mid-September (Gina reminded me of that).

Park Tour #1 was one that I had tried last Christmas with my brother-in-law.  But getting into that park turned out to be tough.  We drove around it, but couldn’t quite find how to get into it properly. When we were there this weekend, I finally had a chance to do some caching and got 1 of 3 (two of them are MIA, methinks).  I couldn’t go home with a 33% success rate!  So I asked around and found out that the park really doesn’t have a parking place, which is odd since it’s so big!  But regardless, I made it out there.

The cache description says this is one of Sioux Falls’ most neglected parks and I agree, even though it has a great sledding hill.  The walk was long, and the last 100 ft was really hard.  The ammo can was quite out in the open, if you look at it from the right angle.  But it’s so far off the beaten path from the rest of the park, it’s not going to get muggled.

So that was cache 75 for me.  My caching time is now limited, but I still hope to get to 100 before the end of winter.  Hopefully it will be a mild one.

A techno-geek geocaching holy grail

If you’ve been following my geocaching posts, you have probably realized that I keep everything in a GPX (read: XML ) file and go lookups on that.  The reason is simple: with a GPX file you can keep everything together in one place and use GPSBabel to do “queries”  on that.  An important query for me is finding the distance away from one point to a geocache in my GPX file.

I wrote many shell scripts to manipulate data into GPX files and to query against them.  But, eventually, my XML-as-a-database abstraction ran into problems:

• I wanted to be able to choose a waypoint (geocache or otherwise) by name and find all the geocaches around it.  Doable with some Python DOM-fu, but not something I wanted to do a lot of.
• Mucking with the GPX files, especially those with Groundspeak’s namespaces is bulky.  The size is huge.
• I wanted to easily mark a geocache that I had found as “Found” but keep it in my records.

 All of this means that my abstraction is leaky.  The real solution was to put it in a database but manually figuring out the distance between two latitude and longitude coordinates is not trivial.  I could do it at the database level, but the only decent, free DB with geographical support is PostGIS, which implies a lot of overhead for my little stuff.  Not that I’m complaining — it’s just not something I wanted to do.

I was looking for something else last night when I saw this on the close method in the Geo::Distance  documentation.  Huh? A DBH filehandler?  Sqlite database?  Oh, it seems I can point Perl at a database of waypoints and it will find the closest points to the given latitude and longitude.  This is what I’ve been looking for.

Using Geo::Distance is a piece of cake.  Making the database is a different story.  I grabbed Python and SQLObject and created two tables — waypoint, which contains the latitude, longitude, name, and description from the GPX file.  Then another table called cache that contains the geocache-specific information — container type, diffculity, etc. That way, I can have waypoints that aren’t geocaches, so I can still query on them.

Then the diffcult part — writing a GPX to DB converter.  It was easier than I thought, because I combined SQLObject to represent the databae and cElementTree to work the XML and *poof* things were converted.  I first worked on my found cache list and then a list of caches from an upcoming trip.  Very easy.  Then I worked my “master list” — the 8MB GPX file.  I had to do some massaging, but it turned out nicely.  And the SQLite DB is just over 1MB — much smaller than the GPX file!

I haven’t posted anything yet, because it’s still a little rough.  That said, if you read this via Google and want a copy, drop me a line and I’ll ship it off to you.

It’s a little more than 1.25 caches per week.

I found cache number 66 yesterday.  That number isn’t a milestone in the geocaching world, but it also coincides with my one anniversary of finding my first geocache. 

It almost seems longer than that, but in a good way.  I’ve seen so many neat parks and places around Omaha and, well, just around than I ever imagined.  And it’s given me a lot of little computer projects do to, which I like.  I mean, I don’t mind walking a mile and a half to find a dollar store item hidden in the trees, yet I have to muster the energy to walk to the bathroom at work (for the record: the bathroom is on the floor below).

I hafta say that I wanted to be at 100 finds by now, but life this summer got busy (and hot) and I didn’t get to it.  But it’s not the number of finds that count, or the dollar store items, but the journey to get there and, yes, the joy of the hunt.  Not to mention the creativity in the hides.

Here’s to another year of using multi-billion dollar satellites to find worthless crap!

Look up cache information with gpsbabel

I tend search out my geocaches when I get a chance and keep them in a huge GPX file. When I want to get some caches in an area, etc., I use GPSBabel to query that GPX file. Groundspeak keeps tons of useful data and metadata in it’s GPX extensions that I like to have a copy of — if nothing else, I can few it while out in the field withing CacheMate.

The latest problem I had was that I had a list of caches in a CSV file in the format “lat, lon, wptname”. I wanted copy those cache entries from my main GPX file to a new GPX file (that way I can just copy those caches to a CacheMate doc). This could take some serious XML programming, but as I thought about it, I figured that there must be a way with GPSBabel. Here is what I came up with. Note that it is an assumption that the caches in the CSV file are a strict subset of the caches in the GPX file:

1. Load master GPX file
2. Push a copy of the GPX file on the stack
3. Load the CSV file
4. Filter out all the duplicates. Note that this will leave you with just the caches that aren’t in your CSV file.
5. Pop the stack and append it to current list
6. Again, filter out all duplicates. Note that now you will have just the caches that were in the CSV file.
7. Write the GPX file

Yes, this is a takes a little to get your brain around, but it works well. Here is the GPSBabel call that did it:

gpsbabel -i gpx -f everything.gpx \
-x stack,push,copy \
-i csv -f goodcaches.csv \
-x duplicates,shortname, all \
-x stack,pop,append
-x duplicates,shortname, all \
-o gpx -F goodcaches.gpx

Next Page »