Jump to content
Sign in to follow this  
Followers 3
embra

Gsak

Recommended Posts

Clyde just released the 3.0 version of GSAK. It includes the capability of accepting output from bmgpx. He calls this release a beta, but I've been playing with an alpha version for the last few days that has worked well.

 

I'm very excited about using GSAK to run herd on my benchmark data. Chief benefits include the ability to filter on multiple criteria, html output for the PDA, and it harnesses much of the utility of GPSBabel in an easy to use front end. So I can update my finds/not founds etc., then kick out new html data and a new set of waypoints for the gps that exclude the bm that I no longer need to search for.

 

I should note here, though, that it is a bit of a square peg in a round hole for benchmarkers at this point. GSAK is tailored for geocaching, Clyde's largest "market" and his interest. He added the ability for GSAK to accept benchmark data, but is not striving in this release to tweak GSAK to deal with the differences between geocache terms/data and benchmark analogs. He has expressed a willingness to do this in the future but first wants to "get it right" for benchmarking (and also wants to see how benchmark pocket queries will fit in when they become available).

 

So...I have found that GSAK is useful and fun to use for tracking my finds and sending data to my PDA and GPS. However, it requires some creativity in getting it to do what I want. To offer an example, GSAK does running counts of finds, not founds, placements, and archived caches. "Finds" translate directly into benchmarkese, but "not found" means we tried and couldn't, while it means "not yet tried" for caching. "Placed by" and "archived" don't have direct analogs for benchmarking. Thus, I use GSAK's "not found" field to track my not yet attempted BMs, the "Placed" field to track my not founds, and "archived" for any destroyed notes. A little convoluted, but illustrative of a compromise that seems necessary to shoehorn BM data into GSAK.

 

This post is long enough so I'll shut up now. I hope that at least some here will take to GSAK so we can share ideas on how to best use GSAK as it is and help shape Clyde's future BM support. I feel a little protective of him--I can imagine a number of us inundating him with requests that he is not well able to respond to at this point in time. But I think GSAK is worth the effort now and looks very promising down the road.

 

Edit for spelling and punctuation (I should just make this my signature)

Edited by embra

Share this post


Link to post

In the GSAK thread over in the GPS hardware/software forum, elmo-fried raised the question of a way to generate a file list of BMs clustered around a specic cache. Clyde gave the overview of setting the cache as a center point to allow a filter on distance, but was a bit less expansive there on how to distinguish BMs from other points in the list.

 

He had communicated a tip using the states field for user-specific purposes. My particular desire was to have a way to distinguish BMs by county (I've got an SD card in my gps so I wanted to carry waypoints with me for the 5 counties near my home), and I didn't care about the state distinction. Here is what he wrote back:

 

If you would prefer they are all in the same database and then use filters to slice and dice (remembering you can save filters for later use) then may I suggest you use the State field to signify the county. You can actually do a global replace on states in the database within GSAK. For example, (forgive me if the terminology/names are incorrect but I hope you get the idea) lets say you You have 3 GPX files each for a different county in California:

 

1. Create a new database called "Benchmarks"

2. Load the first GPX into GSAK

3. Tools=>options, then select the abbreviations tab. Add a new entry at the bottom California=Orange (assuming the state name is EXACTLY "California" in the BM GPX file)

4. Click on the "Full state to abbreviation button"

5. Load the next GPX file

6. Tools=>Options, abbreviations tab. Change the entry in 3. to California=Red

7. Click on the "Full state to abbreviation button"

8. Load the next GPX file

9. Tools=>Options, abbreviations tab. Change the entry in 6. to California=Blue

10. Click on the "Full state to abbreviation button"

11. Remove the California=Blue entry in the abbreviations dialog

 

You now have just one database with the state column identifying the different counties. You can then set up filters to do what you like with them.

 

So if you want to set up a state abbreviation of "BM" for batch conversion, it would be easy to do. As is apparent, it would be good to do the conversion prior to merging with geocache waypoints.

 

If the state designation is important to you, then the user text field might be a promising place to use. At this point, one has to use a text editory to do a global find and replace in the gpx file outside of GSAK, and due to a bug non-Groundspeak gpx fields are getting lost in the import/export. That should be fixed soon, I think.

Share this post


Link to post

That'll work. <_<

 

My GPX files converted by BMGPX actually don't have the state field populated, so GSAK prompts me to enter a state. I believe what I'll do is use something like BMca###coname (ca for california and ### is the NGS county number designation, and for my own sanity coname=the real county name). Like: BMca099Stanislaus (I just turn off the state field in the display mode anyway since Calif. is so huge, so length isn't an issue).

Edited by elmo-fried

Share this post


Link to post

Embra: Sorry to bother you with a question about an old

> post. However, I have been in communication with Clyde

> England regarding use of GSAK in benchmark hunting, and he

> referred me to your post of (I think) March 14. You indicate

> that you use GSAK to track your finds and not founds, etc.,

> with a little tweaking. My question is: do you enter the

> finds manually into GSAK, or have you figured out a way to

> get GSAK to do it automatically? As at this time there is no

> way to obtain the info about finds, etc. from gc.com via

> pocket queries, I must assume you enter the info manually. Is

> that correct? Seems like if Jeremy ever gets the pocket query

> info available for BM's, then it will load automatically. I

> presume you get the same info I do when loading a BMGPX file

> into GSAK - the number, listing as a mystery cache,waypoint

> name, miles, bearing,placed by and placed. The column with

> the four little boxes representing the last four logs, and

> the last log column are blank. Thanks for

> any info, or just verifying that I am not missing

> something. BTW, what do you do with BM's generated by the NGS

> using BenchmarkGPX that are not listed in the gc.com

> benchmark database? Toweres do not seem to be listed in the

> GC.com output. Just curious. Thank you in advance for your

> help. It is greatly appreciated. :P

Share this post


Link to post

Catcher24 backchanneled me, and I suggested he route his question through here so if anyone else has figured out a way to do this that differs from my approach, they could throw in their opinion.

 

I like the running count that GSAK offers, as well as the color status codings of caches in the list. Since the current state of the program is cache-specific, I've had to adapt it as follows (from left to right in the count fields):

 

Green (found caches) - I log my found BMs as found caches in GSAK

 

White (not found caches) - these are the BMs I haven't looked for yet

 

Yellow (placed caches) - When I look for but can't find a BM (i.e., a not found), I log it in GSAK as a placed cache...that is, I open the record for editing with a right-click, enter my name in the placed by field and the date I looked for it in the placed date. This is probably the biggest perversion of GSAK in terms of how Clyde intended it to be used and the way I use it for BMs. The only reason I can offer is that the color code of yellow fits into my logic (see below).

 

Red (archived caches) - another perverted adaptation: I log any BMs I think are destroyed by toggling the archive status with the right-click pop-up menu. Obviously, these are few.

 

This leaves me with green designations for my founds, yellows for my not-founds, red for destroyed, and white/no color for those I have yet to attempt. Then, when I want to upload a set of points to map or gps, I filter out whatever I don't want (which is usually anything I've already looked for).

 

Now, to answer the question that you asked: I did this all manually...and it did take a while to enter everything I had tried so far. I downloaded my list from the "my cache page". I'm not sure of a way to do this in batch...there may be a way to this. I know that GSAK will replace "old" cache records with "new" ones when update pocket queries, but I don't know at the moment what field GSAK looks for to tell which record is newer--I'll ask. If you had a gpx file of all your finds, and another for all your not founds, you might be able to do a search and replace of the relavant fields for each record in a text editor, and then update to your master list. Although I wouldn't have such details as when I found/didn't find each BM, I would have traded that specificity for the ease of getting GSAK updated with my desired status for founds/not founds.

 

I haven't yet seen a way to change within GSAK the "four little boxes" for the last four logs or the last found field; I think those are more cache-specific things.

Share this post


Link to post

Embra - Thanks for the reply. I've pretty much decided that the column for the last four logs (the little boxes column) is only going to show anything if you ae loading in a pocket query; I think GSAK checks the last four logged visits and interfaces that with the boxes. I thought it would have to be done manually, so I actually started updating my finds (thankfully, few at this time, but I expect that to increase soon). I do it a little differently - I use the cache type column to indicate the ones I have looked for but are gone. For those, I use the virtual cache symbol (a ghost; I thought it appropriate, since all that is left of BM's that are gone are their spirits!). I like your idea, though, of color coding the designatiion column, too. Think I will go in and do that, too. It will be easy to look for a different color AND the ghost. I was using the found color, and the ghost, so your idea is better. Hope some other posters have good suggestions, too.

Share this post


Link to post

Clyde did remind me that GSAK can force an update of a merged list, so you could do a batch processing if you didn't mind a degree of uniformity. For example:

 

1. Transform all desired dat files into gpx files, then merge in GSAK to a master.

 

2. Get a list of your founds (or not founds as the case may be), and check off the user flag for each one in the master list.

 

3. Filter by user flag, then save as a gpx file.

 

4. Do a global search and replace for whatever field(s) you wish to change.

 

5. With the master database open in GSAK, open the edited gpx file into it. Select the "always" option for when to modify corresponding records.

 

This would (in my scheme) leave all the dates of my pre-GSAK finds the same, but it would save the time and effort to enter each one manually. If I had a lot to enter, the tradeoff might be worthwhile.

 

Your coding by cache type makes sense (I like the ghost, too). Try a few my way to see if the color coding is useful to you or not.

 

Eventually I hope that Clyde will give us a benchmark-specific interface that doesn't require adapting cache conventions. But I think he wants to see what benchmark pocket queries will look like before investing any time in that sort of project. Especially when he doesn't do benchmarking in Australia, I can't argue with that.

Edited by embra

Share this post


Link to post

Thanks for GSAK - it's really robust and appears that it will take care of most of my BM hunting needs. I've been looking for a database program where I can keep up with my NGS DBs and log the finds/no finds.

 

I was wondering if there are future plans to add the ability to attach photos to a record. There's no need to upload the photos to a PDA but it would be useful for personal logging and viewing on my PC.

 

Thanks again for the program....

Share this post


Link to post

Neat idea! I don't think Clyde, the creator of GSAK, frequents this forum. So if you'd like to submit a feature request you may need to use the GSAK thread in the GPS units & software forum.

 

A bit of a workaround that I think would give you what you want is to edit the waypoint in GSAK to change the URL to a picture file on your local drive. This would let you see the picture in a browser window, but would lose the connection to the geocaching.com datasheet (or whatever you otherwise have it set to).

 

That's a bit cumbersome, though, and would only handle a single photo.

Share this post


Link to post
Neat idea! I don't think Clyde, the creator of GSAK, frequents this forum. So if you'd like to submit a feature request you may need to use the GSAK thread in the GPS units & software forum.

 

A bit of a workaround that I think would give you what you want is to edit the waypoint in GSAK to change the URL to a picture file on your local drive. This would let you see the picture in a browser window, but would lose the connection to the geocaching.com datasheet (or whatever you otherwise have it set to).

 

That's a bit cumbersome, though, and would only handle a single photo.

Sorry, I'm here. I’ve Just been a bit busy of late. Having GSAK on the software section at gc.com has helped to make GSAK more visible, but the downside now is that I am now spending nearly all my time on new user support rather than making any changes to the program ;)

 

Anyway, that's my problem ..... back to the topic at hand.

 

You will be happy to know that is one is definitely on my "to do" list. There is still a couple of big ones before it (printing and User definable output formats) but it does rank quite highly.

 

As this one will be useful to all users it will certainly make it in before full benchmark support :D

Share this post


Link to post

Cool! FWIW, let me make clear that having even one photo linked in is great, but multiple photos links are desireable for benchmarking--we often take a closeup as well as one or two longer shot of the surrounding environs.

 

Thanks, Clyde.

Share this post


Link to post
Cool! FWIW, let me make clear that having even one photo linked in is great, but multiple photos links are desireable for benchmarking--we often take a closeup as well as one or two longer shot of the surrounding environs.

 

Thanks, Clyde.

Also, if you really want multiple images, you can do this now. The user notes section in GSAK supports HTML, so just add as many img tags as you like. Example <img src="file://C:\gsak\images\mypic.jpg">

Share this post


Link to post
Having GSAK on the software section at gc.com has helped to make GSAK more visible, but the downside now is that I am now spending nearly all my time on new user support rather than making any changes to the program :(

As a suggestion, direct support to one of the forums and set back a bit to let helpful individuals get a chance to solve the problem for you. Then all you have to do is post a few "that's right" and tackle the ones that really area an issue.

Share this post


Link to post
Having GSAK on the software section at gc.com has helped to make GSAK more visible, but the downside now is that I am now spending nearly all my time on new user support rather than making any changes to the program  :D

As a suggestion, direct support to one of the forums and set back a bit to let helpful individuals get a chance to solve the problem for you. Then all you have to do is post a few "that's right" and tackle the ones that really area an issue.

Sorry guys for getting a bit off topic but....

 

You are right of course, I do need to step back a bit (and learn how to say no). I just get this horrible guilt feeling when some new user emails me directly and I don't respond with an immediate answer.

 

Nature of the beast I guess :(

Share this post


Link to post

I just downloaded an updated list of benchmarks from the ngs and imported them into GSAK - I lost all my finds, archive, etc. :D

 

Luckily I backed it up. :lol:

 

I guess will have to 'Lock' all benchmarks that I log as found or archived so that the info is not removed.

Share this post


Link to post

ooo...good idea, that (locking *and* backing up).

Share this post


Link to post

Will have to figure out how to update a couple of them - My report is in the new data file - and I would like to see them :D

 

Guess will just have to import those 4 somehow and then manually mark them as found or not again.

Edited by YeOleImposter

Share this post


Link to post

Also may not be a bad idea to ask Clyde for some kind of warning when a cache previously marked 'found' is changed to 'not found'

 

Not worried so much here - I don't expect it to work for benchmarks - but if a regular cache log gets 'removed' I would like to know it.

 

GSAK is nice enough to notify you that an archived cache is now available, it should warn you that your 'find' has been removed. :D

Share this post


Link to post

Seems that GSAK is smart enough to not overwrite cache founds; I'm not sure why it seemed to do that to you with your BM founds. Clyde's on vacation for a few weeks, so we'll have to be patient for any light he can shed on this.

Share this post


Link to post

Am guessing the PQ always sends the user's 'found' log - so if that log was ever deleted by the user or the cache owner then it would also disappear out of GSAK.

 

Since BMs have no 'found' log the 'find' is always removed.

Share this post


Link to post

I have written a little perl script that 'cleans up' the County Data Sheets if you get them directly from NGS that I run before I run it through bmgpx. If anyone is interested I could post it here or just forward the file.

 

It removes the following lines:

 

ELLIP HEIGHT

DYNAMIC HT

MODELED GRAV

LAPLACE CORR

VERT ORDER

HORZ ORDER

SUPERSEDED SURVEY CONTROL

NGVD

ELLIP

U.S. NATIONAL GRID SPATIAL ADDRESS

STABILITY

SATELLITE

MAGNETIC

Lines that begin with these: -|:;

Comment Lines

 

I have not found use for these - so it cleans up my data sheet that I use.

Share this post


Link to post
Am guessing the PQ always sends the user's 'found' log - so if that log was ever deleted by the user or the cache owner then it would also disappear out of GSAK.

 

Since BMs have no 'found' log the 'find' is always removed.

Not quite so. The key to not having your finds wiped out lies in your setting of "Manual update of cache found status" (Tools=>Options)

 

If you have this box checked, GSAK takes the view that you are updating your finds and therefore don't want an incoming GPX file removing them (it will flag a not found as found, but not the reverse)

Share this post


Link to post
SATELLITE

MAGNETIC

Lines that begin with these: -|:;

Comment Lines

 

I have not found use for these - so it cleans up my data sheet that I use.

Satellite - gives you an idea how well GPS will work. Also tells you if you should consider reporting to NGS about how well it will work with GPS.

 

Magnetic - possibly useful if having to search for something buried.

 

Lines that begin with | - Actually quite useful if throw out the ones that are not measured in Meters. It will tell you direction and distance to a RM for example. Without that you might be stuck trying to find them as that information is not always included in the text.

 

I'll have to look at some more sheets to decide about the rest of the "begin with".

 

Could you explain about "Comment Lines"?

Share this post


Link to post

For those of you non-Perl folks there is a Windows app that does pretty much the same thing. I find that it leaves a lot of blank lines though, since I do not want all empty lines removed and I remove lots of lines, the blank lines sort of bunch up and leave empty looking spaces.

 

The program is called Text Harvest

Share this post


Link to post
Am guessing the PQ always sends the user's 'found' log - so if that log was ever deleted by the user or the cache owner then it would also disappear out of GSAK.

 

Since BMs have no 'found' log the 'find' is always removed.

Not quite so. The key to not having your finds wiped out lies in your setting of "Manual update of cache found status" (Tools=>Options)

 

If you have this box checked, GSAK takes the view that you are updating your finds and therefore don't want an incoming GPX file removing them (it will flag a not found as found, but not the reverse)

Is this "Manual update of cache found status" kept on a per database or is it global for all of GSAK?

 

If Global -- and maybe even if not - How hard would it be for someone to have 2 seperate copies of GSAK? I am thinking I want to keep one set of settings for Caches and another for Benchmarks. Most of the settings are so different for export etc that I am always having to experiment every time to get my settings back to the way I want them after going from one to the other.

Share this post


Link to post
SATELLITE

MAGNETIC

Lines that begin with these: -|:;

Comment Lines

 

I have not found use for these - so it cleans up my data sheet that I use.

 

Could you explain about "Comment Lines"?

They start with a '.' - don't have an example handy, but all these were ones I kept adding after finding them in the datasheets.

Share this post


Link to post
They start with a '.' - don't have an example handy, but all these were ones I kept adding after finding them in the datasheets.

I may be cutting them too. I think I cut off most everything between the horz position down to "History" with the exception of some settings and the box score. My program works on the text file before BMGPX.

Share this post


Link to post
Am guessing the PQ always sends the user's 'found' log - so if that log was ever deleted by the user or the cache owner then it would also disappear out of GSAK.

 

Since BMs have no 'found' log the 'find' is always removed.

Not quite so. The key to not having your finds wiped out lies in your setting of "Manual update of cache found status" (Tools=>Options)

 

If you have this box checked, GSAK takes the view that you are updating your finds and therefore don't want an incoming GPX file removing them (it will flag a not found as found, but not the reverse)

Is this "Manual update of cache found status" kept on a per database or is it global for all of GSAK?

 

If Global -- and maybe even if not - How hard would it be for someone to have 2 seperate copies of GSAK? I am thinking I want to keep one set of settings for Caches and another for Benchmarks. Most of the settings are so different for export etc that I am always having to experiment every time to get my settings back to the way I want them after going from one to the other.

That setting is Global.

 

Sounds like another option to add to the "to do list"

 

However, you really don't need two copies of GSAK, just the settings. Fortunately, all GSAK settings are kept in the one place GSAK.ini - which you will find in the install folder of GSAK.

 

I actually have about 50 different copies of this file myself - mainly for debugging user problems. I will quite often ask for a user database and the GSAK.ini file to enable me to replicate a user setup for testing.

 

To use one of these files I just do a copy at the command line, for example "copy GSAK.027 GSAK.ini". You must however, do this before GSAK starts and not while GSAK is running. For the reasonably computer literate, this would not be hard to automate.

 

If you want to look at the installed defaults, first take a copy of the current GSAK.ini then delete this file.

Share this post


Link to post
However, you really don't need two copies of GSAK, just the settings. Fortunately, all GSAK settings are kept in the one place GSAK.ini - which you will find in the install folder of GSAK.

 

I actually have about 50 different copies of this file myself - mainly for debugging user problems. I will quite often ask for a user database and the GSAK.ini file to enable me to replicate a user setup for testing.

 

To use one of these files I just do a copy at the command line, for example "copy GSAK.027 GSAK.ini". You must however, do this before GSAK starts and not while GSAK is running. For the reasonably computer literate, this would not be hard to automate.

Great idea! I will implement that right away, one .ini for caches and another for benchmarks. Similar to what I had to do for our client management system at the office until the software impletmented a command line switch that allowed specifying the .ini file that was to be used, ie "gsak /cfg:gc.ini" or "gsak /cfg:bm.ini"

Share this post


Link to post
For those of you non-Perl folks there is a Windows app that does pretty much the same thing. I find that it leaves a lot of blank lines though, since I do not want all empty lines removed and I remove lots of lines, the blank lines sort of bunch up and leave empty looking spaces.

 

The program is called Text Harvest

Thanks to Y.O.I and mloser for these suggestions. It took me a while to recognize a parameter TextHarvest wanted to use ranges, but I finally got it to do what I wanted.

 

I agree on the blank lines, deciding that too much white space is better than none at all. At least now all the printed information is useful to me, and I don't have to do that preliminary scan to decide if this is a line I pay attention to or ignore.

Share this post


Link to post

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...
Sign in to follow this  
Followers 3

×
×
  • Create New...