Jump to content

Colorado Upload of Field Notes to geocaching.com


Recommended Posts

Once you upload it, you need to go to the field notes page to enter your log notes. Once you do that, you can see it in 'My Account Details'.

 

Firstly visit this page to upload your caches:

 

http://www.geocaching.com/my/uploadfieldnotes.aspx

 

Secondly go here to enter your field notes:

 

http://www.geocaching.com/my/fieldnotes.aspx

 

The geocache_visits.txt file does contain the time -- here is the entry from my file:

 

GC18NAV,2008-02-21T00:42Z,Found it,""

 

Which would be 1842 hours local time, about the time I marked it found.

Edited by qlenfg
Link to comment

Confirm that is does not show the time of the find

 

I'm not sure if that was a question or a statement, but yes it does.

 

The "geocache_visits.txt" file is a csv file with:

 

code, date:time, logtype, log note

like

GC17M9Y,2008-02-20T04:17Z,Found it,"An easy find today ... 1"

Link to comment

Confirm that is does not show the time of the find

 

I'm not sure if that was a question or a statement, but yes it does.

 

The "geocache_visits.txt" file is a csv file with:

 

code, date:time, logtype, log note

like

GC17M9Y,2008-02-20T04:17Z,Found it,"An easy find today ... 1"

 

Thanks for your response but still can not get it to work

Link to comment

Confirm that is does not show the time of the find

 

I'm not sure if that was a question or a statement, but yes it does.

 

The "geocache_visits.txt" file is a csv file with:

 

code, date:time, logtype, log note

like

GC17M9Y,2008-02-20T04:17Z,Found it,"An easy find today ... 1"

 

Could you send me one of your geocache_visits.txt files to test it out to make sure it is not my colorado that is the problem

Link to comment

I tired this feature yesterday. It worked perfectly.

 

I would have liked it to enter the time found as well, though. Into the web site log, I mean. But the time zone fuzz may make that more difficult than one could expect.

 

I wouldn't know why it'd be TOO hard. It's recorded as standard zulu time...just allow us to offset our time from that in a preference selection.

 

The automatic logging worked for me too...I uploaded 3 that way yesterday.

Link to comment

 

I'm not sure if that was a question or a statement, but yes it does.

 

The "geocache_visits.txt" file is a csv file with:

 

code, date:time, logtype, log note

like

GC17M9Y,2008-02-20T04:17Z,Found it,"An easy find today ... 1"

Greetings, Red90-

 

This function is working for me, but I do have one question:

 

How did you populate the text field at the end of the entry - e.g.:

 

"An easy find today ... 1"

 

???

 

If I could figure out how to accomplish even the most rudimentary data entry in the Colorado (just enough for TB/coin numbers, or terse notes on hide/condition/etc) - I really WOULD be able to retire my Palm/CacheMate.

 

For now - while this is so close to being exactly what I need -- I'm still lugging the palm (even if I don't take it out of the pack very often), so that I can log those 'field notes' (not to be confused with my actual online log, which I write offline in GSAK and then post via logging macro).

 

Perhaps this text is being added by geocaching.com when you write your log using this page:

 

http://www.geocaching.com/my/fieldnotes.aspx

 

but I can't even find a way to add it, here.

 

Any insight is much appreciated!

Billy

Link to comment

 

I'm not sure if that was a question or a statement, but yes it does.

 

The "geocache_visits.txt" file is a csv file with:

 

code, date:time, logtype, log note

like

GC17M9Y,2008-02-20T04:17Z,Found it,"An easy find today ... 1"

Greetings, Red90-

 

This function is working for me, but I do have one question:

 

How did you populate the text field at the end of the entry - e.g.:

 

"An easy find today ... 1"

 

???

 

...

I was actually the supplier of that file, using my 400t.

 

The geocache_visits.txt file from my 400t only had blanks in the last field ( "" ).

 

I dummmied data into that field as I wanted to ensure that the text was entered in the log entry field when adding logs for "field data" via geocaching.com.

Edited by nicolo
Link to comment

I tired this feature yesterday. It worked perfectly.

 

I would have liked it to enter the time found as well, though. Into the web site log, I mean. But the time zone fuzz may make that more difficult than one could expect.

I would be satisfied if Garmin would just 'do the math' for us, and include the corrected, LOCAL timestamp, rather than a zulu one. I mean - we can work around that, programmatically, with a GSAK macro or something, but...

 

Isn't a timestamp of when you found something best represented by the local time - even if it IS 'arbitrary', but time zone? Since they never (?) need to be correlated, across timezones - I personally would prefer to see this adjusted value (e.g. GMT - 8:00 for me here in PST). Since the unit is constantly calculating/displaying local time - it doesn't seem like there would be much overhead in recording this value, instead of zulu time.

 

Just a thought / feature request. Adding it to my list... :lol:

Link to comment

I was actually the supplier of that file, using my 400t.

 

The geocache_visits.txt file from my 400t only had blanks in the last field ( "" ).

 

I dummmied data into that field as I wanted to ensure that the text was entered in the log entry field when adding logs for "field data" via geocaching.com.

DOH! Aww, shucks: I got all excited there for a minute, thinking someone had figured out something that I just hadn't stumbled upon, yet.

 

Well, the fact that this field simply exists is proof enough that Garmin has plans for it (or, so I would infer). Now, we just give them a chance to add the input dialog. My suggestion would be another option, from:

 

Geocaches-> <select> -> Options -> Log Attempt -> Found

 

From here, go to a text entry page (I'm hoping eventually they'll arrive at something a little more friendly that the current interface for adding text - e.g. naming a waypoint, etc... but that would suite me just fine for now!). THEN proceed on to the "Find Next Closest" or "Done" page.

 

C'mon, Garmin! You can DO it!! :lol:

Link to comment

I'll probably write a script that runs across the field notes text file, and fills out the log text with a time stamp. Then I will be happy

 

If text placed between the double quotes appears in the log, just write a script to read each line of the geocache_visits.text file, suck in the GMT time, add / subtract your offset, then place it between the double quotes.

Link to comment

I'll probably write a script that runs across the field notes text file, and fills out the log text with a time stamp. Then I will be happy

Will you do the math, within your script, to correct the zulu timestamp to 'local' time? I've already considered the same thing - but my coding skills suck.

Link to comment

I'll probably write a script that runs across the field notes text file, and fills out the log text with a time stamp. Then I will be happy

Will you do the math, within your script, to correct the zulu timestamp to 'local' time? I've already considered the same thing - but my coding skills suck.

Yep, that's my plan. :)

Link to comment

FWIW, and at the risk of getting flamed for cross-forum pollination:

 

Working with the great community of folks over on the GSAK forums, we have assembled a GSAK macro which does precisely that. Virtually all the heavy lifting (especially the SQL code, which I barely understand - but basically, all of it) was provided by lignumaqua - and the current product, while perhaps not 'finished' - is a sight to behold. It's basic functionality (which replaces what I have historically done through a combination of Hotsync, CM2GPX, and the CacheMate import routines in GSAK):

  • Provides a form for user to select timezone offset, and geocache_visits.txt location (sticky)
  • Creates a SQL file of all entries in FieldNotes
  • "Rationalizes" list according to predetermined logic (e.g. found, followed by DNF = DNF)
  • Matches each cache, and flags (Found, DNF) and respective dates
  • Populates the User Notes section of the Notes field with Time/Date stamp
  • Populates Log Section of Notes field with "Needs Maintenance" text if marked
  • Parses still-unused final text field, and populates Log Section with this text (once we can enter stuff there - tested via mockup)
  • Outputs a summary of records and actions

Anyway - I realize there's an entire forum, and specific thread dedicated to the topic. But, since it was particularly relevant to this thread - I thought I'd share.

 

How long time we get the firmware that allows us to enter text into that final field? At that point, once I can enter basic notes (TB/coin #s, brief notes)... then, I truly am finished with CacheMate and the Palm. Then it's on to Marky's wishlist above of being able to 'pre-load' TBs/Coins/Sig Items, and just 'select' them along with the field log - not unlike what we do today when logging on geocaching.com. Add a little wireless capability to the GPSr, and... you've got yourself a SOLUTION! :D

 

Peace,

Billy

Link to comment

One feature I notice with this otherwise interesting new functionality. The date from the geocaching_visits.txt file isn't carried into the log page - that still defaults to today's date. Could this be added?

Hi Allen-

 

I think that would be a feature request for geocaching.com. Of course, as noted, it's not as simple as taking the date from the geocache_visits.txt file - since this is based on Zulu time, and hence, may not even be the correct date, much less, time.

 

Which gets back to a Garmin feature request: Since the GPSr most certainly knows the CORRECTED time/date (given the current time zone offset) - why not use THIS value for logging in the geocache_visits.txt file, since it's almost certainly 'more relevant' to the action (finding a cache).

 

Not to get 'off topic', but in the interim, I'm dealing with both these issues via GSAK and macros. Working on making it a bit more 'configurable', so you can stuff the date/timestamp, and any 'notes' (once we can capture them in the Colorado, in the field) into various User Notes / Logs fields, for subsequent logging at geocaching.com (though NOT by using the FieldNotes interface - but the traditional logging pages).

 

Ahh - I think the lightbulb just went on with regard to the question you asked, about GENERATING a geocache_visits.txt file, over in the GSAK forums. :unsure:

Link to comment

There's a default time zone setting in your geocaching member profile as well. But as you may be caching elsewhere than in your home time zone, using the time zone setting that was current in the GPS, when the cache was logged, seems to be the smartest thing. Which means this can't be done at the web site, unless the Colorado stores the time zone setting as well.

 

I've been so trigger happy, that I've logged the same day as I found the caches. Hence, I've not seen if it's using another date than the one logged in the file.

Link to comment

Saving local time is never a good idea. It's always best to save it in zulu time and convert it later. The website knows your time offset and can convert the date/time stamp easily.

I totally understand this, from a conceptual perspective: save the timestamp in an unambiguous format which does not allow for variation in interpretation: Zulu time is Zulu time, and then, you can always convert it after the fact...

 

Provided, you know the time zone offset - at THAT point-in-time / location. So, when I was caching in Florida a couple of weeks ago - these same timestamps represent a different 'corrected' time given the -5:00 offset, as opposed to my default -8:00. While we can always calculate it after the fact - it requires that we track another data element, per record (e.g. TZ Offset) - OR, get really fancy, and calculate it, based on location, date, etc.

 

So, I totally agree with you - timestamps really SHOULD always recorded in 'absolute' time (syslog in GMT, etc) - but, for such a mobile activity as caching, with the possibility of time zone offset changing from find to find (or at least, outing to outing) - I would like to store the corrected time zone (and corrected date, when the time math pushes it into a different day).

 

Again - to each is own. It totally depends on where and how you want to process, and consume, the data. I'm digging converting the zulu time to a "local" date/time, and inserting it into the notes field in GSAK to serve as fodder for my log.

 

Feeling pretty good about the functionality with the import macro - I'm starting to think about what Alan has described, in using geocache_visits.txt, and the online interface which consumes it, as a way to further automate and idiot-proof my current logging processes.

 

Has anyone determined a maximum length for this field in "geocache_visits.txt"? One would like to assume it would match the maximum length of a log submitted via the standard online logging form, but I haven't even begun testing that. Also, I've been working hard to keep my head in the sand about the UTF8 / UTF16 issues around this file, and what needs to be uploaded to geocaching.com. Ignorant of the issue or not - it's time to start learning.

Link to comment

I thought along the same line. If I have a weekend on my own, while working in the US, I may want to try some local caches. Then I go home, do some more, and then upload the log file to Groundspeak. At that time, I have caches found (hopefully) in different time zones, so to log them with times that are meaningful to other people, who look at the logs, or looked for the cache on the same day, the local times has to be applied.

Link to comment

Everytime I attempt to upload it tells me there are no records. Dont know what to do now.

Greetings, Othum-

 

Can you look at the geocache_visits.txt file with an editor? Are there "Found It" records inside - specifically, ones that are not later trumped by a "Didn't Find It" record?

 

Another relevant point: Are you checking, or clearing, the box on the upload page which asks if it should "ignore caches older than <date>" If you've got entries in the 'log' file, and aren't ignoring them at upload time - I'm not sure WHY they wouldn't show. Are you uploading a 'vanilla' file, as generated directly by the Colorado - or are you manually or programmatically generating one, and trying to put Log Data in that final field? My limited experimentation with the latter has shown that I was able to cause the import to fail based on the volume and specific content of my log text.

 

Not sure what problems you're having or the problems you're experiencing. Let us know...

Link to comment

was a solution found to this problem (not finding anything when trying to uploa the filed noted file). I just worked out this festure - will save me lots of time, but geocaching.com returns 0 files. i cleared it out and went caching again with new notes, but still keep getting same error.

Not sure what else to do?

Link to comment

Are you changing the cache name using GSAK?

 

If so the site will not return any files. You need to use the GC***** number as the cache name.

 

If that isn't the case open the visits.txt file in notepad and copy the first 5 lines here so we can look at the file to see what is in it. That will help us determine what is going wrong.

Link to comment

You need to better explain what you are doing. The field notes work perfectly. So you are doing something wrong. You do not need GSAK to upload them-you should upload them without GSAK. All you have to do is go to field notes on gc.com and upload the file. Then you have the list. It works perfectly. If you still cannot get it to work, tell us the steps you are taling, the file you are uploading, and cut and paste a few lines of the file you upload.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...