SnoWake
-
Posts
187 -
Joined
-
Last visited
Posts posted by SnoWake
-
-
Add me to the queue of anxious Android owners who would like to see an official app. I'm using most of the same apps mentioned: CacheMate, Geobeagle, etc - but will have to check out [removed].
To be truly of value, the app would need to support 'offline' capabilities, for times when you might be outside of coverage (especially for us poor G1 users - not quite as much an issue for Droid users on Verizon). I'm holding out for the Nexus One on Verizon...
Back to the matter at hand: If Groundspeak mentioned a proposed release date of Q1 for a native Android app - asking for a status at this date is reasonable. That being said, they don't really owe us any update until the end of March - but in the spirit of collaboration and transparancy, it would be nice to hear something.
-
Edited to delete duplicate post.
-
Free Heeler and I already have our tickets to Evolution in hand... see you in BRC! With the remodel and the wedding, we had to miss last year's burn - sold our tix a week before the event. Sounds like there was an event, and perhaps even a traditional (though short-lived?) cache? Anyone know who the local approver is for the area? Might be nice to pre-socialize any cache/event ideas we might have? I know Moose Mob and Road Runner cover the Vegas area - does your territory include the entire state? Trying to think of the reviewers/publishers of the various Reno caches I've found...
See y'all on the playa!
Billy
-
Here's a slight spin on the thread: After searching the forums extensively, I couldn't find an answer to the following question - but this thread seemed "close enough" in spirit to field this question:
What are the prevailing thoughts on logging an "Attended" smiley for an event cache that I organized - and, of course, attended and participated in?
Some additional context: The event (GC1MFT1) was in Playa del Carmen, Mexico, on my wedding day. We had a great turn out of international cachers - and a great time was had by all.
Clearly, when I hide a traditional cache - I wouldn't consider logging a find on that cache: it's just not appropriate, or in the spirit of the game. I HID the cache - that's a different stat - and as the cache owner, it's not reasonable (at least in my mind) to log a find on your own cache.
Event caches seem a bit different, though. True, I did submit and organize this event, and as such, got credit for a "hide" or placement. However - I also was a very active in participant in the actual event.
The only other event I organized, I did not log as 'attended'. However, in this case, given the spirit of the event, in seems appropriate that I should. I suppose, as both event organizer ('hider') and attendee ('finder') - there's certainly no one left to complain.
Thoughts?
-
It's been four months since I last bumped this thread - so just re-iterating my frustration with this apparent defect. Any chance that we could at least get acknowledgment from TPTB, so that we know it's at least at the bottom of some "to be fixed" list - or, if not, the discrepancy explained?
Thanks again for adding this great feature - it's so close to being REALLY useful - but I'm grateful for the incremental increase in functionality, even if it causes me some cut/paste grief.
-
There is a geobrowse application that my other half downloaded on the G1 a couple of days ago. We've not used it caching as of yet but will give it a try in the near future.
I discovered Geobrowse a couple of days ago, myself. I haven't used it in any real-world caching situations yet, just some simulated interactions from my front porch. It works, as advertised, taking you to the geocaching.com map page showing all the nearby caches. Since I was near home - all the nearby caches were either found, or my own - and, unfortunately, working the web page UI is a bit cumbersome (checking boxes, controlling the zoom slider).
Still - it's a great first step. I'm off to check out plans for Ben's app, and make any feature requests I can think of. At this point, between the Colorado and Oregon - I rarely need to use a phone to consult any online resources - though I DO still use the Blackberry to log FTFs from the field. But lots of the features I would have wanted (e.g. CacheMate-type functionality) has been negated by the new Garmin platforms with their paperless caching features - combined with some GSAK macros to 'close the loop' for end-to-end paperless processing.
A few days into it, and still loving the G1: No "Buyers Remorse" like I had about 30 minutes after buying the (first gen) iPhone. Of course, I got past that, a bit, once I discovered the joys of jailbreak + Installer.
By biggest current complaint with the G1 has got to be battery life: Enable WiFi, Bluetooth, GPSr, and 3G -- and the device doesn't survive more than a few hours of use. Gonna have to learn some new power management skills... -
I have begun work on a geocaching app for Android.
It will be similar to cachemate, cacheberry, geopher, etc, with the extra touches the G1 allows. Obviously, it won't scrape geocaching.com but will be dependent on grabbing PQs from your email inbox, downloading GPXes from other sources or from your PC.
I hope to have a beta out soon after my G1 arrives around the 22nd.
-Ben
edit: I also know of at least one other person working on an Android caching app. So there will be plenty of options.
Ben / Team:
Just let us know when we can help out with testing the new app. I, for one, am pretty good at documenting use cases, results, and providing feedback.
This just reminded me: Is there a screen capture feature / app for the G1?
Looking forward to see what you code warriors come up with - and let me know if I can help!
-
As a gadget freak - not only do I have an eTrex legend, a couple of 60-series, a Colorado, Oregon, and Nuvi 880 - but I also have an iPhone (first gen), and as of yesterday - a new G1.
Do I think the G1 will replace a "real" GPSr? Absolutely not. But, as noted above - for those 'caches of opportunity' - it's definitely nice to have the capability.
As much as I like the UI on the iPhone, I've got some big pet peeves about it, that never seem to get addressed in firmware upgrades. I had jailbroken mine, so that I could install apps before the App Store existed - but there wasn't anything really compelling there (even the Geocaching app lacks appeal without an integrated GPS receiver).
In the first day, I've installed a dozen or more apps - including two that I found immediately interesting:
Orienteer: While the G1 has an integrated GPSr, as demonstrated by showing "My Location" on Google Maps - there's no 'out of the box' way to view GPS data. This app solves that problem - by exposing both the GPS data, and electronic compass - which was a feature I didn't even realize it had. Now, at least I can view Lat/Lon, and then go plug these values into geocaching.com, and find out what caches are nearby.
GPSTracker: This is a bit big-brotherish for my tastes - but still quite novel. The device uploads your position to a web site, overlayed on a map - so you can, for example, track your travels (or your device, if it's not with you). The disclaimers are hilarious: You can't slip you phone into your teenager's backpack to see what they're up to while you're away at work. [
]I'm anxiously awaiting the first actual geocaching application for the device. Any java coders here willing to take a crack at it? Who knows - perhaps Jeremy and crew might actually consider porting the geocaching app developed for the iPhone?
-
It's been quite some time, so I'm bumping this thread, hoping to get it noticed by someone. C'mon, Jeremy - after I was enough of a Wherigo / GPS Maze Adventure groupie that I ran into you on both coasts within a month of each other - can't you hook a brother up with a little field expansion? It would be one thing if the problem was understood and communicated - but given the discrepancy between the 500 character Field Notes limit, and the 4K character log limit... I'm just having trouble understanding the reason this isn't working. I'm guessing very few people must use this interface (though, as we've commented repeatedly, it's certainly not just for Colorado users) - since it doesn't seem to even get acknowledged, much less worked on. What a shame, too - as it totally cripples the feature, for my particular (wordy) use case.
Thanks for any acknowledgment - or better yet, scheduled resolution. [
] -
Team:
In the last few days, I've noticed a few different problems, that all seem related. I first experienced it while generating a Pocket Query, and realized that (using Firefox) - selecting the dropdown to change from one coordinate format to another - e.g. from (MinDec) to (DegDec) has no effect. Previously, the whole page would refresh (AJAX, anyone? ;-), and when I scrolled back down to the coordinates box - they would have changed, to accommodate the new format.
Today, I experienced a similar problem on the PQ page: I was trying to click the My Finds "Add to queue" button - and clicking it would refresh the page - but NOT 'add it to the queue' (rather, would just re-display the last ran date).
In each of these cases - I have fired up Internet Explorer, and everything works fine.
I haven't upgraded / made and config changes to Firefox recently - so just wondering if this is a personal problem, or if others are experiencing this, as well? My Firefox version is currently 2.0.0.14.
Any thoughts/feedback are much appreciated. Sure hate to have to switch browsers just to click a button or two...
Thanks,
Billy
-
Bumping this thread, and adding:
Is there any reason why the character limit would be any different than the max logfile size? According to the "Log your visit page" - the max log legth seems to be 4000 characters?
<snip>
Your log length can't be more than 4000 characters.
</snip>
Believe it or not - I've written logs that bump up against THAT limit - so imagine how often I'm hitting the < 500 character limit??
I would at least appreciate some acknowledgment of these issues, even if a specific timeline for resolution isn't available. As Robert points out, the timezone thing is a total drag, with finds being logged on the wrong day.
My closing comment is that, while launched in support of the Colorado and it's new features - this interface isn't limited in scope to just Colorado users (as I believe Alan pointed out, in his initial post).
Thanks for the new functionality - it IS much appreciated. Unfortunately for me, it's still 'more trouble than it's worth' since I have to A) detect, and
go back and cut/paste each individual log separately.Peace,
Billy
-
They know about the issue. I've always seen it at exactly 500 characters (so character 501 and up were all truncated).
Knowing about it is one thing: Claiming to do something about it is another story entirely. Is there an official 'defect' list somewhere, with this issue listed, and a sense of the prioritization of when it might be resolved?
I know I'm a bit unique with my verbose logs, but - I also know (from this thread, if nothing else) that I'm not the only one who's noticed the limitation. For me, it's a deal breaker: As cool as this new interface has the potential to be, I'm stuck still using the old tried and true logging from a GSAK macro, until this gets resolved.
Can Jeremy and team at least provide some background on why the limitation is there - and whether or not they even PLAN to fix it? On the one hand, since the Colorado (which is what is supposed to be generating the input file, by design) doesn't currently allow text entry into this file - and, even if it did, no one would be masochistic enough to try and enter more than 500 characters with the Rock-n-Roller UI - I can completely understand if that was a conscious decision. But as Alan points out above, it didn't take long for the community to catch on, that this is a really powerful tool for logging, regardless of what GPSr you're using. In that regard, having the character limit be different than what is actually allowed in a single log entry doesn't make sense.
I'm hoping this one can bubble towards the surface and get some attention - as it's so close to being a really valuable tool, especially for 'paperless' cachers.
Thanks for listening!
-
Back to the originally reported problem:
I am also seeing this truncation - which I find very disturbing, since it takes this potentially very useful interface... and renders it simply annoying.
I'm using a macro to pull geocache_visits.txt file off the Colorado, massage to the timestamp a bit for the offset (and geocaching.com's handling thereof) - and finally, inserting my full (typically verbose) logs into the file.
When I upload this file to geocaching.com - I find that every log is truncated to 496-500 characters (including spaces - according to MS Word's "character count"). I just logged four caches tonight, and each and every log was truncated. The original logs ranged from 700-1000 characters, as represented in the geocaching_visits.txt file.
No sign of any 'special character' or delimiter that might be prematurely terminating the field - the truncation usually takes place right in the middle of a word.
So, now I have to pay careful attention - and, more times than not, go back to my full log, and copy/paste it into the log page on geocaching.com.
Any reason why this interface would not much the existing log size limit?
Please advise - and, thanks for this new feature! Looking forward to seeing it get a bit more polish - but it's definitely a big step in the right direction, and (at least has potential to) simplify some of my paperless caching processes significantly.
Thanks!
-
Here's an interesting HUGE improvement, that I somehow overlooked with all the excitement of the 2.4 release.
Previously, the penalty for loading 'additional' maps was extreme. When I pushed even a moderately large region (say, the Western US) of CN2008 onto an SD card - startup time was measured in minutes, and search operations were unbearably slow.
I finally had the motivation to dust off my unused SD card, and exported the ENTIRE US from CN2008, plus the 24K Western US topos, plus some blue chart, and even some ski area maps - came to about 1950MB.
The next day, when the export was done...
I was absolutely amazed to find that startup time hadn't suffered, at all - still well under 30 seconds.
I haven't noticed the searches being miserably slow - but haven't done a lot, and need to test it more.
So - have others adjusted their "map loadout" following the release of 2.4?
-
Question for any / all Colorado owners, but particularly 300 series:
Where are you installing your GPX files containing the geocaches you want to install on the unit? Are you putting it on the internal memory, or SD card? Does it depend on which / how many maps you have loaded at any particular moment?
In my 400t, I've yet to come close to filling the internal memory - so as a result, I've yet to install anything on the SD card. Just wondering if 300 owners (especially) find that they fill the internal memory with maps, and end up with GPX files saved to the SD card?
Just trying to understand how people with different models are exporting their caches -- thanks for any feedback!
Have a great week,
Billy
-
One other thing to keep in mind when marking caches as found / not found etc... is that every time you do it the CO makes an entry in the field notes file.
My wife accidentally marked a cache as found because the CO truncates the cache name in the list and both caches started with the same phrase. She marked the first one as found, went back to see the next one on the list, and saw the cache still on the list. She assumed she hadn't marked it as found, so she did it again. I noticed her error and remarked it as not found, then we found it, and marked it as found. When I uploaded the field notes it was in there three times. Of course if we had been displaying the GCxxxx instead of the name, she probably wouldn't have mismarked it.
This very "problem" (multiple records for a single cache) poses an interesting challenge. Clearly, with the application of some logic, you can "condense" all the actions down to a bare minimum of one "action" (either Found, or Did Not Find), with one optional 'status' (Needs Maintenance), which could apply to either type of log.
This is exactly what I wanted to achieve, to supersede (and even enhance) what I used to do with CacheMate, HotSync, CM2GPX and GSAK's CacheMate import function. No coincidence, then, that this is part of the core functionality of the Garmin Colorado Field Notes Import Macro accomplishes. Well, that and a little bit more, with correcting the Zulu timestamp for the local timezone, and putting various values in Notes or Log sections, etc.
Why do I feel "dirty" every time I mention this? I'm not here 'plugging', really: I developed these macros for my own personal benefit, but then tried to make them "generic" and friendly enough to be of general use to the community. Your Mileage May Vary.
Peace,
Billy
-
Ok, I have loaded one just to try it out using the GPX loader with send to Garmin. I still can't the caches to load from GSAK. I am totally computer stupid. But thanks for the info.
Vegas Gamblers-
No need to feel stupid: The Colorado introduced a new level of complexity, where it's no longer just "plug and play" (e.g. plug in a USB GPS receiver, and click "Send to GPS" from GSAK ;-). You are not alone, and I've received several emails from folks having trouble getting caches loaded into the Colorado.
Again, at the risk of flame, I'll dare cross-post: I've developed a GSAK macro which eliminates this complexity from the user, "auto-detecting" the Colorado, and generating the GPX export file in the correct location on the unit. A front-end form allows the user to control which caches get exported (by database, location, and filter) - or can just rely on the current GSAK filtering.
You'll find the macro explained and available for download in this thread, with a corresponding discussion thread located here. I'm confident it will help with your troubles - and would be interested in the feedback of both novice and 'power' users.
Hope this helps,
Billy
-
Neat! I can't reproduce this since I don't have any routable maps on mine.
Marky-
How do you get around??
It's funny (sad?) how dependent I've grown on auto-routing. When I went to play the (great) Wherigo cartridge following the Meet & Greet event last month - I was stymied when all I was presented with was an arrow, and a distance.
How will I EVER find my way there? It's over 7 miles from here, across the urban south bay. I actually went BACK to the event, and asked frivlas and workerofwood if they could guide me to the park where the cache was. Better yet, I asked for a geocache in the same park/area - and since I had those loaded as POIs, I could select and auto-route to it. Whew! I knew I shouldn't have moved that Thomas Guide all the way to the box in the back of the Tahoe...
Back on topic: I'm still seeing some strange behavior (though I haven't experienced the double compass problem yet) when dealing with routing, switching between profiles / routing modes. As noted by others, it seems that certain activities "kill" the active route.
One final note: I've also seen the occasional lockups at boot time that Marky described, and others have confirmed. I'm confident it's NOT a problem with the particular GPX files loaded - as a subsequent boot (with the same file) works just fine.
Have a great weekend, everyone!
-
Yes, it happens quite often on my system
Internal is Drive E, SD Card is drive G.
F is my Exteral Drive.
I don't know why it gets ordered this way. Both devices were plugged in when the computer was booted.
I think I did a lousy job of explaining myself.
I'm successfully able to automate the detection of the Colorado, by testing for the existence of a particular file / path (e.g. G:\Garmin\GarminDevice.xml). So - as the device 'bounces around' from drive letter to drive letter - no worries, I can detect it every time, and automate pushing my GPX file(s) to the correct location.
My 400t has enough internal memory, that I'm not sure when or why I'll start using the 2GB SD card I bought for it. However, other 400t owners (with less available memory), or a fully-loaded 300, may need to write the geocache GPX file(s) out to the SD card... which LACKS any obvious, identifiable characteristics (e.g. specific files that must exist). I would hate to test for the existence of a \Garmin folder - because that could be the case on any number of either local or network drives. Rather...
Since at any given point in time, I know, for certain, which drive letter the Colorado is (let's say G:, for my example) - then I'm wondering if the Colorado SD card is every anything except the drive immediately following the internal memory (in this example, H:). I've had the Colorado come up as F: (but then, the SD card was G:) and I think H: once (and the SD card was I:). My question was - has anyone seen that not be the case - for example:
Colorado internal memory: Drive E
Colorado SD card: Drive G
See where I'm headed? If I can assume that the "next drive up" from the Colorado is the SD card - then I can provide an option checkbox on the front end of the macro, asking:
__ : Upload GPX file(s) to SD card? (instead of internal memory)
Make sense?
Thanks!!
Billy
Note: Seems I also did a lousy job of reading and interpreting Right Wing Wacko's post, above. On second read, it sounds like this is exactly the scenario being observed. Hmmm - worst case, I can always make it a "file selector" control, and force the user to navigate to the \Garmin\GPX folder on the SD card - but I'm trying to save them the trouble (and/or confusion, based on emails I've received asking for help).
-
otherwise, I'm never going to upgrade my geocaching Mom from the 60CSx to a Colorado.
Maybe you should upgrade her to a Mac and a Colorado. Problem solved.
She didn't need GSAK anyway, right?--Marky
HEHEHEHE-
Ironically - I DID get her a Macbook for Christmas last year. Lucky her: she's even got an Intel-based one (my slightly older Powerbook is PowerPC-based). But - since I was never quite successful doing the 'data' side of caching from my Mac - neither does she. She's still using her Windoze desktop and GSAK for managing PQs, pushing caches to CacheMate and 60CSx, etc.
I've been reading about the recent developments on the Mac and some new capabilities - I need to power mine up and check it out.
Thanks for reminding me! ;-)
-
Sorry I wasn't clear. After you plug in the Colorado, close the window that appears a apersson states. Okay, this is how it works in XP, hopefully Vista is similar. Double click on the zip file you got from Groundspeak, a window should open. Right click on the main .gpx file, select 'Extract'. A window should pop up where you can select the path. Navigate to the F:\Garmin\GPX and click 'Extract'. You may verify a big .gpx file is in the Colorado using the file explorer.
Just as a point of clarification: It may not ALWAYS be "Drive F": Obviously, this value will vary from user to user based on machine configuration, installed devices, etc - however, it can even change for a given user, from day to day.
For example, I created some "saved settings" in GSAK to export a GPX file to the proper location (G:\garmin\GPX). However, the next day - the Garmin was mapped as a different drive letter, and my saved settings were 'broken'.
That's precisely why I developed the GSAK macro - so, if you're a Windows, GSAK user - this can really eliminate the complexities of this, and make it a 'single click' operation, properly detecting the Colorado, and depositing the GPX file in the appropriate location.
I'm working on combining the two macros (The Colorado Field Notes Import and newly-created Colorado Export) into a single "Colorado Command Centre" type of tool - where you could manage ALL aspects of the Colorado. In addition to the existing functionality, I would like to include a 'modify geocache_visits.txt (load logs) and upload to gc.com' function, as well as options to delete the geocache_visits.txt file, and... ultimately, perhaps even manage POIs, etc.
It's unfortunate that the 'dynamic' nature of the USB drive mapping is causing folks so much headache. Hopefully, it can be minimized... otherwise, I'm never going to upgrade my geocaching Mom from the 60CSx to a Colorado.
-
Greetings, Colorado owners-
I received several different emails from forum users, trying to get caches onto their Colorado. After helping resolve this for a third time, I realized the consistent difficulty is finding the right drive / folder to place the GPX file - whether just a single PQ from gc.com, or a converged one containing 2000 caches generated from GSAK.
I've been working on a couple of different GSAK macros supporting the Colorado. First was the Colorado Field Notes import macro, leveraging the new field logs.
I struggled a bit on how to get by the ambiguity of which drive letter the Colorado would be assigned on any given connection - based on other USB devices, etc. I finally came up with method that seems to work - but would appreciate any feedback.
You'll find this early version discussed, and available for download, in this thread. Would appreciate any thoughts/feedback - and understand that this macro is less than a day old. ;-)
The macro scans for a particular file on the Colorado, and then 'calculates' the appropriate path for the GPX file. A front-end form allows the user to select the source database, location, and filter to select the 2000 caches they want to export - and then exports a GPX file to the relevant directory.
Ooh - OOH! I just thought of the next option: Need to attempt to detect the SD card, as well (a little less 'certain', given that there aren't any files that HAVE to be there). Hmm - maybe I wouldn't have to 'detect' the SD card: Rather, just "add a letter" to the detected Colorado drive.
Has anyone seen a situation where the SD card wasn't assigned the drive letter immediately following the internal memory?
-
I simply made a Garmin folder and placed a GPX folder inside of it on the sd card and it worked flawlessly.
Thanks to all!!
Interesting: My results were different from this. Well - to be fair, I didn't quite test this EXACT scenario - but will.
I put the GPX file in [sD Card Drive]:\Garmin\GPX - and the caches were parsed, loaded, and displayed
I put the GPX file in the root of the SD card - at the same level with the Garmin folder - and it definitely did NOT work.
Sounds like it works if the files are in the Garmin folder - but given A) how the unit wants these in the \Garmin\GPX folder when stored internally, coupled with
Anders observation above, which explicitly states the location -- I think we'd be better off putting them there, even if they DO (currently) work when placed elsewhere.Just a thought...
-
Marky's suggestion is exactly what I would recommend: If you want to keep all your Found caches loaded and with you, I'd push them as POIs. You can absolutely govern how they appear (which icon, etc) - but what you CAN'T do, today, is set a unique zoom level for 'custom POIs' vs. geocaches (both are controlled by the "User Waypoints" zoom level). So - while I considered loading all found/hidden caches as POIs - like Marky, I didn't want the screen clutter, and while it may be a nice concept - I (personally) have had fairly limited use for such information.
Just some thoughts...
]
]
Release Notes 2/24/10
in Website
Posted
Agreed (that it needs work). Ironically, by my estimation, it was fine before - presumably because it wasn't doing any 'localization' of timezone - and, consequently, I dealt with it externally, by 'correcting' the FieldNotes timestamps to accommodate this "functionality".
After the recent update: The 'summary' Field Notes page still shows the correct date - but when clicking through to 'compose log', the log.aspx file is populated with the GMT date (most commonly a day ahead, for my offset and normal caching hours).
It seems that if the site is going to 'translate' (or correct, or offset) the GMT value in the uploaded field notes file - it should do so consistently?