Jump to content

New GSAK user needs a little help please.


Recommended Posts

The beauty of GSAK is you can tailor it to your individual needs. :)

 

I keep both found and unfound in the same database.

 

I have separate databases for My Owned, Archived before I found, Campervan parking/overnighting. :blink:

 

When the archived ones get too bulky I save the GPX file which can always be reimported. <_<

 

Quickest way to learn is to play with it :)

Link to comment

I maintain a found database, then an unfound one plus a placed database, plus a few others.

 

I use the macro below to load the caches into my Colorado. There are a couple of boxes further down where you can import found and your placed caches in as waypoints along with the unfound caches as a GPX file.

 

http://gsak.net/board/index.php?showtopic=7745&st=20entry112006

There are lots of options to play with as you see fit, enjoy :blink:

Link to comment

Hiya all, I am trying GSAK out and want to see what it is like.

A couple of things I want to know.

a) Do you use one or two databases ie: to find and found

2) How do you import your finds form an Oregon (just the simple method not the macro one)

 

I really do want to give a good try.

Cheers

Hi Richard, I only ever use one database, then use named filters to show the different combinations of caches I'm interested in. TBH it's never crossed my mind to use more than one, and for my use I can see only disadvantages in doing so.

 

Rgds, Andy

Link to comment

I'm currently maintaining 6 different GSAK databases.

 

All active and temporarily disabled UK caches (updated daily)

All archived UK caches (updated daily)

All the caches I've found (updated periodically)

All the caches I've set (updated if I set another one)

All YOSM trigpoints (updated when Brian sets a new location)

All UK trigpoints (updated after a trigpointing session)

 

I'll also create others as and when necessary for short-term specific requirements like holidays abroad.

 

The limit is only your imagination :lol:

Link to comment

I only use two.

 

One of my finds, and one made up of my 5 regular PQs - which I refresh every time I load them. Some people import their PQs without refreshing - but tbh I only run it to populate my GPS, I'm not interested in having more than 5 logs :)

 

I run the "Colorado Export Beta" macro, which combines the two and spits out a .gpx file to my Oregon containing about 4000 unfound caches, with child waypoints and found caches as POIs.

Link to comment

I'm currently maintaining 6 different GSAK databases...

Maybe I'm being thick, but I can't see the advantage of keeping separate databases. You can keep everything in one database and simply select the bits you are interested in, such as archived caches, or owned caches, or found caches, just by selecting the filter. You don't duplicate data that fits more than one criterion and you get much more flexibility in querying the data.

 

But I'm a computer programmer, and some of my work is database programming. It's completely alien to me to artificially and unnecessarily split the data up - you do the selection when you query the data, not when you store it.

 

The disadvantages of keeping it all in one database? I can't think of any.

 

I can see it is useful as a transfer mechanism, i.e. to allow people to send subsets of the data to other people.

 

And it might be necessary to separate data that cannot be identified by a combination of data columns, but that's not a common situation and even then a better route might be to ask Clyde to add an appropriate column.

 

But several people seem to use multiple databases. This is a genuine question, in case I'm missing something - what are the advantages in maintaining multiple databases?

 

Rgds, Andy

Link to comment

In my case, multiple databases. But, one of those is strictly for caches across North America that were accessible with and had legal and safe parking nearby for tractor-trailers and RVs. The other was for my use when at home (I drive OTR for a living). On occasion, I would open still another database to work on my bookmark lists.

 

You may find one database works well for you, but then decide to take a vacation. A second in that case would allow you to research and hold a specific set of caches for your vacation. In short, whatever works best for each user and the circumstances is the way to go.

Link to comment
You may find one database works well for you, but then decide to take a vacation. A second in that case would allow you to research and hold a specific set of caches for your vacation. In short, whatever works best for each user and the circumstances is the way to go.
With a single database you view your vacation caches using a filter. From this thread I fully understand that some people do prefer to maintain separate databases, but what I don't yet understand is what is the advantage of doing so?

 

Rgds, Andy

Link to comment
You may find one database works well for you, but then decide to take a vacation. A second in that case would allow you to research and hold a specific set of caches for your vacation. In short, whatever works best for each user and the circumstances is the way to go.
With a single database you view your vacation caches using a filter. From this thread I fully understand that some people do prefer to maintain separate databases, but what I don't yet understand is what is the advantage of doing so?

 

Rgds, Andy

In my case the macro I use to export to my GPS calls from seperate databases for found and unfound caches. No doubt there are other ways to do the same job from a single db, but as the saying goes, if it aint broke, don't fix it, and it works for me :)

Link to comment

I'm currently maintaining 6 different GSAK databases...

Maybe I'm being thick, but I can't see the advantage of keeping separate databases. You can keep everything in one database and simply select the bits you are interested in, such as archived caches, or owned caches, or found caches, just by selecting the filter. You don't duplicate data that fits more than one criterion and you get much more flexibility in querying the data.

 

But I'm a computer programmer, and some of my work is database programming. It's completely alien to me to artificially and unnecessarily split the data up - you do the selection when you query the data, not when you store it.

 

The disadvantages of keeping it all in one database? I can't think of any.

 

I can see it is useful as a transfer mechanism, i.e. to allow people to send subsets of the data to other people.

 

And it might be necessary to separate data that cannot be identified by a combination of data columns, but that's not a common situation and even then a better route might be to ask Clyde to add an appropriate column.

 

But several people seem to use multiple databases. This is a genuine question, in case I'm missing something - what are the advantages in maintaining multiple databases?

 

Rgds, Andy

 

Not thick Andy, but as someone else said, the power of GSAK is its flexibility! I have about the same as Pharisee - UK Unfound, All found, All placed, Archived, Not UK, temp holiday db, and numerous other temporary ones.

 

I see a number of advantages with no real disadvantages! In particular, because of how I run my PQs, my default database is updated regularly, and any cache that isn't updated is deemed to be archived and moved. I can't do that if I have overseas caches, my own archived caches, or archived caches I've found, populating the same db (without lots more filtering).

 

I also purge my logs regularly. However, I need to keep my own, and all logs on my caches, so another reason for keeping them separate.

 

Most importantly for me though - various stats macros work MUCH MUCH faster if they only interrogate a db with 3100 caches (my founds) rather than a db of 71000 caches (the UK).

 

I'm sure there are other reasons - but generally separate dbs seems the preferred option! however, if one db works for you...

 

Dave

Link to comment

I have about half a dozen separate databases too. Generally, one for my home area (the nearest 3000 or so), one for the Isle of Man (all caches), one for where I'm going next, one for the next trip abroad, one based on a route (for a walking trip), a My Finds database and perhaps one or two more. So they're mostly based on geographical areas.

 

If they were all in the same database I could still use it but it would be a nuisance. There's no logical reason for having the IOM and Local caches in the same database, and it's easier to select a database than to perform a filter. If my next walking trip has 12 caches en route (identified using the Caches Along A Route PQ), it's easier and quicker to manipulate a database of 12 caches than one of 6000. Once I've finished the trip I simply delete the database - no chance of accidentally deleting a few other caches accidentally, and no need to keep on maintaining caches that are no longer of interest.

Link to comment

I'm currently maintaining 6 different GSAK databases...

Maybe I'm being thick.......

 

But I'm a computer programmer

 

No .... You're not thick but you've answered your own question. You're a computer programmer :lol: As a engineer who worked alongside IT people for may years I never did understand their need to be un-necessarily convoluted and overly complicated in the way they approached a problem or created a solution..... Generally speaking, of course :)

 

As I said... I was an engineer and liked 'things' to be tidy and in their proper place. The simple answer was usefully the best one. With my current PC, I'm not constrained by lack of memory so duplicating stuff isn't a concern. Why would I want to create, save, search through and run a lot of different filters when I can simply swap databases?

 

Multiple databases may not be your ideal but it works for me :)

Link to comment

I have a number of different databases - partly because I work somewhere far away from home and partly for caches which I find of special interest or challenge. This is my set:

 

  • Home - all caches within 35 miles
  • London - a few PQs populate this
  • UK Virtual
  • LQ Series - one day this will go!
  • YOSM Caches
  • Like to Do (All UK caches before 2001 and any others of interest not in the main areas)
  • Holiday
  • UK Trig Points
  • Found
  • Placed
  • Temp Stats - used for generating stats for challenge caches e.g. Somerset Rounded

 

I have a GSAK macro that I wrote which calls macros that others have written to output into different formats (Cachemate, Oregon GPX, Memory Map, Tom Tom) for various devices I own. So on my Oregon I have some relatively static gpx files which rarely change and a larger file for where I am currently. Sounds complicated but it works for me. This structure has evolved over the last few years and you can probably tell I work in IT :D.

Edited by lodgebarn
Link to comment

Also being new to gsak is there any way of moving a cache up or down on the list? i no its probably easy but i cant work it out :huh: i want to change the order they are in anyone know how? :blink:

 

Just click on the heading of the column you want to sort by and it will sort in that order. If you want a special order - the sequence you want to do a the caches in for example, use the user sort column - number the caches in the order you want to do them and sort on that. BINGO

Link to comment

I normally add a column for USERSORT, and number my planned route. Then I filter the list, using FLAGs, and EXPORT the file in GPX format. I then E-mail the GPX file to my friends, so they can upload the list into their gps unit. In this way, we both have the list, and the numbered route.

 

I was just looking at the database. I do only use ONE file at a time. However.....I have a couple dozen cities loaded up.... in separate files.

But I don't use old files, unless I want to increase the number of logs (5 per download). The risk in old files is - Archived caches will not be deleted.

Link to comment

I normally add a column for USERSORT, and number my planned route. Then I filter the list, using FLAGs, and EXPORT the file in GPX format. I then E-mail the GPX file to my friends, so they can upload the list into their gps unit. In this way, we both have the list, and the numbered route.

I also number caches if they're on a planned route but then print a check list. The Print feature in GSAK is useful, as you can get a whole route of caches on one or two sides of A4 (obviously, the descriptions are lacking but basic details are there) and having them in the right order helps a lot. Although I'm not normally a great user of paper it has its strengths, and tick lists is one of them - you can also jot a word or two at the side of the cache line to act as a hint for the online logging (e.g "dog bite"!).

 

Although if you're after beating 1157 caches in 24 hrs you'll need quite a few sheets of paper (I don't think it's possible in the UK)! How long would it take to write up the finds on GC.com? Probably more than 24 hours...

Link to comment

I also run separate databases. I am a computer engineer, but not a programmer.

 

I have one db for my local unfound caches and a second for the MyFinds PQ. With the finds DB it means that I have to set no filters, no searches or anything and I can just click the findstatsgen macro to generate the statistics.

 

My local unfound DB only holds around 500 caches which I then filter to only show available caches. This is because my GPS only has 500 POI memory (eTrex Venture HC). THis normally brings me down to around 490 which fits. I also turn off the child points when sending to the GPS.

 

If I am going somewhere then I will run a separate PQ for that area, import it into a separate DB specifically for the location and filter as above for the GPS.

 

Simple, but it works for me. :)

Link to comment

I normally add a column for USERSORT, and number my planned route. Then I filter the list, using FLAGs, and EXPORT the file in GPX format. I then E-mail the GPX file to my friends, so they can upload the list into their gps unit. In this way, we both have the list, and the numbered route.

 

I was just looking at the database. I do only use ONE file at a time. However.....I have a couple dozen cities loaded up.... in separate files.

But I don't use old files, unless I want to increase the number of logs (5 per download). The risk in old files is - Archived caches will not be deleted.

 

It is very easy to sort out archived caches. Sort on the 'Last GPX' column and any caches not updated in your latest set of PQ's will be the archived ones so yo can filter on the Last GPX date and delete them.

Link to comment

Not thick Andy, but as someone else said, the power of GSAK is its flexibility! I have about the same as Pharisee - UK Unfound, All found, All placed, Archived, Not UK, temp holiday db, and numerous other temporary ones.

Forget the temporary ones, I occasionally use multiple databases for data that I know I won't want to keep - I'm trying to understand why anyone would MAINTAIN multiple databases. Surely all the other hings you've mentioned are much more simply achieved by the most basic filtering than they are by messing around with multiple databases?

 

Most importantly for me though - various stats macros work MUCH MUCH faster if they only interrogate a db with 3100 caches (my founds) rather than a db of 71000 caches (the UK).
Well, it goes without saying that doing stats on 71000 caches takes longer than doing stats on 3100 caches. But it SHOULDN'T take noticeably longer to do stats on a 3100 subset of 71000 caches than it does to do a whole database of 3100 caches, assuming the filtering is done on a commonly used column such as owner that it would be reasonable to expect to be indexed. If it does, there is something quite badly wrong with the database engine, Clyde's use of it, or the macro.

 

I don't run stats, so have no first hand experience of this, so can I just confirm that I understand exactly what you mean. If you run the stats program on a database of 71000 caches but with an owner filter that selects 3100 caches, it takes much, much longer than running it on a database of 3100 caches, all of which are selected?

 

I'm sure there are other reasons - but generally separate dbs seems the preferred option! however, if one db works for you...
Oh, I'm not disputing that separate databases seems to be a common preference, I'm just trying to understand why!

 

Rgds, Andy

Link to comment

With a single database you view your vacation caches using a filter. From this thread I fully understand that some people do prefer to maintain separate databases, but what I don't yet understand is what is the advantage of doing so?

 

I am keeping 6 permanent databases:

 

Caches - everything not found or archived within 200km of home

Trigs - all T:UK trigs plus Passive & Active stations etc

Benchmarks - all Flush Brackets & 1GL Bolts , plus Rivets/ OSBM Bolts/ CBMs etc within 200km of home

Found - All finds of the above, kept together for BadgeGen/FindStatgen purposes

YoSM - populated with .gpx from the website

Hills - everything from the Database of British hills, plus my own supplementary data

 

Plus a temporary database containing Ordnance Survey info for Northern Ireland, which will disappear in the next few days once I've integrated it properly into the main trigs database.

 

Aside from caches, much of this data is generated from .csv fies, with a variety of different sorts of information in different fields - e.g. in the PlacedBy field, I keep flush bracket numbers in two of the databases, and the User Data fields are all used differently too. Keeping this all together in one database would be highly impractical.

Edited by agentmancuso
Link to comment
As I said... I was an engineer and liked 'things' to be tidy and in their proper place. The simple answer was usefully the best one.
But one is simpler than many.

 

Incidentally, I'm an engineer too - I do quite a bit of database programming but my primary job is as an embedded system designer, which is half programming, half engineering.

 

With my current PC, I'm not constrained by lack of memory so duplicating stuff isn't a concern.
Lack of memory isn't usually the primary reason to avoid duplication. In general terms duplication can become a problem if the 2 copies get out of sync. Though in caching terms it's probably not the end of the world if they do.

 

Why would I want to create, save, search through and run a lot of different filters when I can simply swap databases?
You can turn that round - why would you want to create, save, search through and run a lot of different databases when you can simply swap filters?

 

Swapping filters is more flexible and less error prone than swapping databases, and it is just as simple, quick and easy.

 

Please note that I'm not trying to make you change, though it may appear that way. I'm just trying to understand why people use multiple databases in case I've missed some advantage. But at present I'm more mystified than ever :-).

 

Rgds, Andy

Link to comment

But at present I'm more mystified than ever :-).

because we can, and we like it that way :)

Kinda the same way I dont get why you'd have only one database, instead of 6/7/8/9?

 

Well for me apart from liking the logical separation the three main benefits are:

  1. When I run the PQs needed to populate each database I can quickly identify which are archived.
  2. I have different views for some of the databases e.g. Trig Points, YOSM, Found, Placed.
  3. It is easier to load smaller generated sets into memory map e.g. if I am making a journey I can easily see which YOSM caches are near the route.

 

If they were in one big database I think this would still be possible using filters but extra work. Maybe I will give it a go one day :).

Link to comment
Well for me apart from liking the logical separation ...
You still get the logical separation, it's just done at view time rather than import time. The later you leave the separation, the more flexible it is, PROVIDED the database contains the information you need to do the separation.

 

[*]When I run the PQs needed to populate each database I can quickly identify which are archived.
That one is a valid point. Provided you only ever import the same Groundspeak PQ into the same database, and never change them, it will be easier to identify archived caches.

 

[*]I have different views for some of the databases e.g. Trig Points, YOSM, Found, Placed.
Also valid, though minor. Changing filters is generally quicker overall than changing databases, but this would require an extra click.

 

[*]It is easier to load smaller generated sets into memory map e.g. if I am making a journey I can easily see which YOSM caches are near the route.
This would be just the same, but with extra flexibility if you ever decided you wanted to add other classes.

 

For the way I work, having separate databases would greatly increase the effort of importing data. I get 5 PQs a day. I typically download and import them every 3 or 4 days by clicking "Get data via email". This involves about 1 second of work - the import takes longer, but there is no user interaction so I'm doing something else. If I had separate databases I would have to manually download and sort the PQs, select a database, select the PQ, wait for it to finish, do the next one and so on. That sounds like a lot of unnecessary work!

 

Rgds, Andy

Link to comment
Aside from caches, much of this data is generated from .csv fies, with a variety of different sorts of information in different fields - e.g. in the PlacedBy field, I keep flush bracket numbers in two of the databases, and the User Data fields are all used differently too. Keeping this all together in one database would be highly impractical.
Most of what you've described is storing different types of data in different databases. This is very reasonable, and is quite different to storing, for example, found and not found in separate databases despite the data having the same type.

 

Rgds, Andy

Link to comment
Aside from caches, much of this data is generated from .csv fies, with a variety of different sorts of information in different fields - e.g. in the PlacedBy field, I keep flush bracket numbers in two of the databases, and the User Data fields are all used differently too. Keeping this all together in one database would be highly impractical.
Most of what you've described is storing different types of data in different databases. This is very reasonable, and is quite different to storing, for example, found and not found in separate databases despite the data having the same type.

 

Rgds, Andy

 

Yes, that's true enough. The only other example I can think of is keeping a separate database of caches round a specific holiday destination or suchlike, which I tend to do, then delete the database entirely when we get back.

Link to comment

An interesting discussion, and I sort of understand where you're coming from Andy - although you won't get me to change!

 

I'll try and explain a bit further why one db would not be easy to work with...

 

I have my main db which is regularly updated with the same set of PQs, which allows me to filter for archived (ie, not updated) caches. I do this every day, and simply filter based on last GPX update, and any that haven't been updated are instantly moved into the archived db, out of the way. This may include my placed caches, and/or found caches. I don't want to keep archived caches in the default db!

 

As I say, the default db is updated regularly from a fefined set of PQs, so I can't keep overseas caches in there either. Therefore, I can either move my overseas finds and archived finds INTO this database when I run stats,and then move them back again when I'm finished, or maintain all my finds in a second db, which only requires one copy process.

 

For the same reasons, I do the same with Placed caches.

 

Make sense?!

 

Dave

Link to comment

An interesting discussion, and I sort of understand where you're coming from Andy - although you won't get me to change!

 

I'll try and explain a bit further why one db would not be easy to work with...

 

I have my main db which is regularly updated with the same set of PQs, which allows me to filter for archived (ie, not updated) caches. I do this every day, and simply filter based on last GPX update, and any that haven't been updated are instantly moved into the archived db, out of the way. This may include my placed caches, and/or found caches. I don't want to keep archived caches in the default db!

 

As I say, the default db is updated regularly from a fefined set of PQs, so I can't keep overseas caches in there either. Therefore, I can either move my overseas finds and archived finds INTO this database when I run stats,and then move them back again when I'm finished, or maintain all my finds in a second db, which only requires one copy process.

 

For the same reasons, I do the same with Placed caches.

 

Make sense?!

 

Dave

 

SNAP !!

Link to comment

I'm currently maintaining 6 different GSAK databases.

 

All active and temporarily disabled UK caches (updated daily)

All archived UK caches (updated daily)

 

Slightly off topic, but as we're around the general area...What's the best way to compile a collection of all active/temp disabled UK caches? I've started on mine, got about 25,000 in there so far, but is obviously going to take another couple of weeks for all of the PQ's to come through. So I've done it by date placed and am pulling out as many as I can between each date range so that I cover all caches.

 

What I'm wondering about is archived caches. They don't get included in pocket queries, but will exist if my data was collected say a week ago, and they have only just been archived today (for example). What's the best way to get rid of them? I'm not too bothered about them. Am I right in guessing to use the "updated in the last 7 days" option? There must be more to it than that though... :unsure:

 

Thanky!

 

Cass

Link to comment

I maintain 3 databases - Unfound, Found and Placed (caches that I own). The last two are purely for production of the GSAK stats. So I'm with Amberel in terms of just having one database for unfounds.

 

Before a caching expedition, I run the appropriate PQ and download it to my Unfound database. Then I export the whole Unfound database to my local drive as a GPX file, then use the Garmin POI Loader to upload all the details to my Etrex. The caches are uploaded as POI's, which means I can get thousands on there, along with the decoded hints (15000+ and counting). In the field I search for nearest POI or by name/GC code on the Etrex, then Save it, which converts it into a geocache.

Link to comment

I'm currently maintaining 6 different GSAK databases.

 

All active and temporarily disabled UK caches (updated daily)

All archived UK caches (updated daily)

 

Am I right in guessing to use the "updated in the last 7 days" option? There must be more to it than that though... :unsure:

 

Thanky!

 

Cass

 

I think you're right in as much as that's what a lot of people do. However IIRC from other posts you're a bit of a techie, so you could set up a notification for archived caches in the "Member features" area, which sends you a mail every time a cache gets archived, you could then write something to parse the mails and generate a script to update GSAK, or even write it as a GSAK macro that you could share with the community. I used to do this but I don't use GSAK now but I do something similar with geoqo.

Link to comment

I'll try and explain a bit further why one db would not be easy to work with

...

I don't want to keep archived caches in the default db!

...

Make sense?!

 

Dave

That was indeed very interesting, because it showed that the necessity for maintaining a large number of databases is predicated on that one single requirement - ensuring there are no known archived caches in the default database.

 

My approach to archived caches is different. The offline database effectively is always out of date. The longer it is since the oldest update from every PQ that contributes to the database, the more out of date it is. Caches that don't appear in a PQ because they have been archived are merely one example of that. So the last update date column is important - for each purpose for which I use the database I have a qualifying period. For generating GPX files for the Oregon it is 7 days - I will always have updated an area I'm visiting within that time.

 

So archived caches usefully remain in the default database. They don't get in the way at all, and removing that requirement also removes the need to keep swapping between databases and copying rows from one to another.

 

Rgds, Andy

Link to comment

What I'm wondering about is archived caches. They don't get included in pocket queries, but will exist if my data was collected say a week ago, and they have only just been archived today (for example). What's the best way to get rid of them? I'm not too bothered about them. Am I right in guessing to use the "updated in the last 7 days" option? There must be more to it than that though... :unsure:

 

 

This macro might be of use - I've only just discovered it, and it does the trick for me.

Edited by agentmancuso
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...