robertlipe

Shame the choices are mutually exclusive since they really aren't. Most of the choices are end-points where one (XML) is a conduit or a format. I want to jam the data into my Palm (which I could do more easily if I could get the database info via XML instead of having to grope the HTML output) but I have other reasons for wanting raw programmatic access to the data which would be easier via XML access. So if I have to pick one (and I did), I'd say that XML solves more problems for me than "pure" Palm format since that allows programmers (like me) to write our own code to stuff it into the PDA.

'Handicapped' is not a boolean. It's not even an enum. It's a float. It has a different meaning for most everyone in the group. My wife, an amputee, is on crutches a big part of the time lately but not always. We've found the best thing to do is to get involved with the locals. By doing this, we've made others more aware of the needs of the challenged and we're starting to see others mention accessibility in the cache description. The same things that make a wheelchair possible ("but i don't know anybody in a wheelchair" I hear people whining right now) make access with a baby stroller possible. And fess up, most of you do know someone that's had a baby. Crutches are different than chairs and both are different than life on prostheses. It gets complicated. The best I can recommend is to find a friend (or friends!) and work with them. We know we can ask our local "five star" cachers about a cache and get a good recommendation. But that's becuase they know us as a team, our level of determination, our limitations, and our challenges. It'll be different for everyone. Vines that a chair can roll over will stop a crutch user in their tracks. Stubble that won't bother a crutch user can stop a chair. If you don't know that it's important to *someone*, you probably don't think to look. Find/Make a friend. Ask. Contact the cache owner before you trek out if "terrain:1" *really* meets the guidelines for terrain:1. If it doesn't, most sensible cache owners will change it.

> OK, How do I "Slurp" the points into my GPS? Just like you do with any other cache. Use easygps or any othe rprogram that understands both geocaching.com's *.loc format and your GPSr

> OK, How do I "Slurp" the points into my GPS? Just like you do with any other cache. Use easygps or any othe rprogram that understands both geocaching.com's *.loc format and your GPSr

quote:Originally posted by bikerdj: I need them in a "Lat, Long, name" format to incorporate them into Delorme Street Atlas" so I can print them on a map. Or, any other way to get a map of the caches in my area in a printable map. While you can do it with things like easy gps and geobuddy and intervening files in yet another inconvenient format, another option is to bounce the waypoints through your GPSR. Slurp the points into your GPS. Then in S&A (I have S&A9) import them from your receiver. It works fine and now you get little flags on the map for the waypoints. [ Well, it works fine unless your magellan has comments in waypoints that are longer than 20 characters. Then it crashes S&A. I'm still arguing with their tech support over that but am getting nowhere. ]

quote:Originally posted by bikerdj: I need them in a "Lat, Long, name" format to incorporate them into Delorme Street Atlas" so I can print them on a map. Or, any other way to get a map of the caches in my area in a printable map. While you can do it with things like easy gps and geobuddy and intervening files in yet another inconvenient format, another option is to bounce the waypoints through your GPSR. Slurp the points into your GPS. Then in S&A (I have S&A9) import them from your receiver. It works fine and now you get little flags on the map for the waypoints. [ Well, it works fine unless your magellan has comments in waypoints that are longer than 20 characters. Then it crashes S&A. I'm still arguing with their tech support over that but am getting nowhere. ]

I could bore you with the electronics, but the magellan cable is "either/or". The unit gets its power from the internal batteries OR the external source. The external source is never connected to the batteries. Reasons for doing this include not having to have the electronics of a "real" charger in the cable and liability in case the batteries leak or combust while inside the GPSr. So you're safe. Throw batteries in and just whip it in and out of the dock while you're driving (or at home with a 12v cigarette lighter or whatever.)

You needn't remove the batteries, but it's not a charger. Note that the battery guage goes to "external power" when you dock it on the power cord.

quote:Originally posted by northmill: Well you asked for it. I would like to see just a command that can read a .loc and convert it into a file readable by a linux based waypoint/track/route manager loader (for Garmin- you asked ). There are already a number of manager/loader thingies that speak the garmin protocol. So the problem to be solved is merely front-end that reads .loc's and writes whatever format is accepted by the loader, right? I'm not particularly inspired to re-invent any wheels but I would like to help unify some of the wheels we now have. (That was where I started thinking about this problem. But then I realized that in reality, once everything is normalized internally, the serial protocols for the GPSrs are "just another backend" so the converter program COULD actually speak straight to the GPSRs instead of bouncing through the manager/loaders. There are some icky things about serving common denominators (i.e. 6 character NMEA waypoints vs. 8 character waypoints in extended Magellan protocol, 20 vs 30 character descriptions, etc.) but I think these are solvable since they're constant for any given target. quote:"The YYY tool shall convert geocaching.com-based .loc files into format supported by (insert linux waypoint app here). I have some Perl code around that converts a geocaching.com *.loc and writes it into the format used by a slightly modified version of 'gpsutil'. I'm pretty ashamed of both ends of that puzzle, but it can be done. That shame was what got me thinking about it. quote: The problem is that everyone has their own file format for reading/writing the GPS files. Annoying, isn't it? This is one of the reasons I'm seeing GPX as a Good Thing. quote:If you are still interested, I will try some of these out and cut you some of the formatted files to you to look at. Yes, please privately send me the same set of a couple of waypoints (and maybe a route or two, but I'm happy to let routes wait) in the formats that are considered interesting. quote:BTW, I grew up in Murfreesboro, just up down the road. Some great caches are there!

quote:Originally posted by northmill: Well you asked for it. I would like to see just a command that can read a .loc and convert it into a file readable by a linux based waypoint/track/route manager loader (for Garmin- you asked ). There are already a number of manager/loader thingies that speak the garmin protocol. So the problem to be solved is merely front-end that reads .loc's and writes whatever format is accepted by the loader, right? I'm not particularly inspired to re-invent any wheels but I would like to help unify some of the wheels we now have. (That was where I started thinking about this problem. But then I realized that in reality, once everything is normalized internally, the serial protocols for the GPSrs are "just another backend" so the converter program COULD actually speak straight to the GPSRs instead of bouncing through the manager/loaders. There are some icky things about serving common denominators (i.e. 6 character NMEA waypoints vs. 8 character waypoints in extended Magellan protocol, 20 vs 30 character descriptions, etc.) but I think these are solvable since they're constant for any given target. quote:"The YYY tool shall convert geocaching.com-based .loc files into format supported by (insert linux waypoint app here). I have some Perl code around that converts a geocaching.com *.loc and writes it into the format used by a slightly modified version of 'gpsutil'. I'm pretty ashamed of both ends of that puzzle, but it can be done. That shame was what got me thinking about it. quote: The problem is that everyone has their own file format for reading/writing the GPS files. Annoying, isn't it? This is one of the reasons I'm seeing GPX as a Good Thing. quote:If you are still interested, I will try some of these out and cut you some of the formatted files to you to look at. Yes, please privately send me the same set of a couple of waypoints (and maybe a route or two, but I'm happy to let routes wait) in the formats that are considered interesting. quote:BTW, I grew up in Murfreesboro, just up down the road. Some great caches are there!

> Looks like the applications are already there > (mostly Garmin, but GPSUTIL mentions Magellans), > but the translation ability is the thing that > seems to be missing. Since I own a magellan 330, I'm glad (in a bizarre way) that it wasn't "merely" my perception that most of the UNIX/Linux software was for Garmins. The reality is that tracks, routes, and waypoint lists for the common GPSRs aren't THAT different between receivers. There's no reason they should be different at the command level. Tonight, inspired at least partially by this conversation, I have expat mostly slurping up the key components of the .GPX format. Even if you're not a programmer, tell me very specifically what you'd expect a program to do (we call those "marketing requirements document" in the software biz) and let's talk.

I've been looking at that in recent weeks. The new "gpx" format is XML and it doesn't look that hard to hook up to the expat XML parser. I've written some (crude) Perl code that parses the XML coming off geocaching.com and writes it into a file that's readable by a program to squirt the waypoints into my mag330. I haven't really specced out what the program will do yet, but I've been sketching it in my head. I'm thinking that a program that reads and writes arbitrary file formats (magellan serial protocol, xml mutants used by geocaching.com and GPX, CSV, maybe a few others) won't be that hard to do. I'm resistant to try to reimplement a UI such as EasyGPS preferring instead to just haul data from on inconvenient format to another. (This is probably becuase I"m not a user interface guy.) If you're a programmer with ideas and willing to help out, contact me. I do plan to release it when I'm done.

There have been a couple of posts dissing McD's toys as geo finds. I'm not sure they're entirely a bad thing. I cache exclusively with (and at least somewhat becuase of) my six year old and he's delighted with such trinkets. I regulate what goes in and out to be sure he trades things of comparable value and coolness. There are a lot of little cachers in this area for whom that sort of thing is ideal. We've passed up $20 bills, computer hardware, and things of much greature interest to adults to score a Pokemon top or McBeanie Baby. Obviously, chewed or broken toys are a different matter and more closely match the "trash" banner. But a McToy that's been played with 30 minutes might get anoter 30 minutes in the spotlight of a child's attention when recycled in a cache. And some McToys (from whatever restraunt) are seriously lame, so don't take it as a blanket endorsement. If someone replaced all the trinkety toys in our local caches with, say, 128Mb SIMMs, the game would become somewhat less fun for us. So please remember that not everyone is in it for the loot. I am, of course, not suggesting that empty gum packages would be so treasured.

It didn't happen to me personally, but it did happen to a local well-known cacher. http://www.geocaching.com/seek/cache_details.asp?ID=9641 Since the cache is now closed - for this very reason - I'll say this was a VERY unique location that placed it in the middle of a semi-cloverleaf to an interstate.

It didn't happen to me personally, but it did happen to a local well-known cacher. http://www.geocaching.com/seek/cache_details.asp?ID=9641 Since the cache is now closed - for this very reason - I'll say this was a VERY unique location that placed it in the middle of a semi-cloverleaf to an interstate.