Gsak (geocaching Swiss Army Knife)

[+ClydeE]

GSAK 3.05 is now ready to download at www.gsak.net

 

There are a few fixes and some new features. The big news in this build is the addition of the new GPSBabel custom dialog. This effectively gives GSAK instant access to all GPSBabel supported formats. The new custom dialog may not be as user friendly as the other supported formats, but the sheer power of this feature more than makes up for it. I suspect there may be some issues with users trying to get the syntax correct, but I am sure experienced GPSBabel users will be able to help out in the forums in this regard.

 

Don’t forget, you can now register your copy of GSAK here

 

Cheers

Clyde

 

Changes since 3.04

 

Added GPSBabel Custom export Dialog

Added "Fix Windows ME freeze" option to get around Windows ME system lock ups

Added "Country" to the list of fields that you can display, sort, and filter.

Added new "in list" operand in filter for State and Country (use ; to separate values)

Custom URLs can now be assigned to the "double click" action in grid view

Moved Registration information from main screen to Help=>About screen

Added check to make sure new database name is a valid windows folder name

Sorting by Waypoint Code now sorts GCXXXX codes by cache number rather than the current strict alpha sequence.

E/W (East/West) indicators for arc filter coordinates no longer case sensitive

Added support for www.geocaching.de gpx files

Added Version 6 to drop down box for MapSource export

Added support for "Street Atlas" route file (.anr) to load into arc filter.

Centre Point is now saved with each database rather than saved globally

Post Code search forced to uppercase

Added support for load of st2gpx generated GPX files.

Added %Dif1 and %Ter1 tags

Mapsource Autoload now uses registry settings to find MapSource.exe

Added error message if you try to automate GSAK when it is already running

When Automating GSAK tips are not shown

Cache now available dialog suppressed when running GSAK in automation mode

Added TomTom and Maptech eXchange to automation exports

Added File= parameter to the EXPORT automation command

Prefix a custom URL name with ! (Exclamation mark) and the link will show in offline generated HTML

Added scroll bars to the custom URL panel.

Added option to HTML generation to include/exclude ! Custom URL Links

Added option to HTML generation to include/exclude "current link" at top of page

Special characters also removed when generating HTML name Index header

Added abort button when generating HTML files

Added ability to choose which indices are created when generating HTML

Added to summary total of waypoints not updated because of "waypoint lock"

Added %user (User Data) special tag

Fixed Bug where trying to set all user flags for filter when sort sequence is user flag.

Fixed bug where geocaching.com "add waypoint to log" coordinates not being output in GPX export

Fixed rare obscure bug when converting full state abbreviations

Fixed "unable to load OziExplorer" message when you try to show waypoint on OziExplorer map and OziExplorer is not running.

All %tags are now NOT case sensitive

Edited June 29, 2004 by ClydeE

[+Z_Statman]

Sad to see my name not being displayed as the registered owner, also not receiving an email notice of the new version.

[+ClydeE]

Sad to see my name not being displayed as the registered owner, also not receiving an email notice of the new version.

Mailing has been sent - sometimes there are holdups.

 

What do you mean your registered name is not displayed?

 

What shows when you click on Help=>About?

[+Team DEMP]

Sad to see my name not being displayed as the registered owner

I don't recall if it was the last version or prev betas of this version, but your registered name was moved to the About box and not displayed on the main window.

[+ClydeE]

Sad to see my name not being displayed as the registered owner

I don't recall if it was the last version or prev betas of this version, but your registered name was moved to the About box and not displayed on the main window.

Correct. I had some users say that showing the registered name in the main screen made it hard to read the database name - also pointing out that the norm for this was to put this information in the Help=>About screen.

 

I also made mention of this in the release notes.

 

Are people now saying you prefer to see the registered name in the main screen?

 

Who was it that said you cant please all the people all the time

[+ClydeE]

I was wondering what Clyde and other folks thought about the coloring of the cache waypoint code to identify found and archived caches.

 

By default (I think), found caches have a yellow background in the code cell and archived caches have a pink background in the code cell.

 

My question is which color wins when you have a found cache that is archived. Currently, archived wins and a shows the cache as pink. My personal preference would be to have Found be the dominant color and show the code as yellow. For caches I haven't found, obviously seeing it in pink, as it is today, is preferable.

I have been giving this one some more thought.

 

Although I would like to keep it simple, In this case I just don’t think it is possible.

 

I will try to explain, so stick with me:

 

The problem with the cache status (found, not found, placed, archived) is that only found and not found are mutually exclusive. For example, it is quite possible to have a cache that is not found, placed, and archived (or any permutation of these three). There are also times when you can log a find on a cache you have placed (event cache for example), so in theory you can have a found, placed, and archived cache (or any permutation of these three).

 

So rather than an option to just say that found overrides archived, I think we need the option to set the order of precedence. Really, that is what GSAK is doing now. You don’t get to see this exact order of precedence, but it can be deduced by looking at the current colours of each cache. So in case you haven’t worked it out the current default order of precedence is:

 

Archived = 1

Placed = 2

Found = 3

Not found = 4

 

So if a cache belongs in multiple categories, it will get the colour of the status with the highest priority (1=highest, 4=lowest). That is why any archived cache, currently shows in the archived colour regardless of any other status it may have.

 

Allowing you to customise this order of precedence would then enable you to set up the colours the way that make most sense to you – I guess there really is no right or wrong way here.

 

Ok, does any of this make sense?

 

How would this fly or am I just making the whole thing unnecessarily complicated?

Edited June 29, 2004 by ClydeE

[+Team DEMP]

So in case you haven’t worked it out the current default order of precedence is:

 

Archived = 1

Placed = 2

Found = 3

Not found = 4

 

So if a cache belongs in multiple categories, it will get the colour of the status with the highest priority (1=highest, 4=lowest). That is why any archived cache, currently shows in the archived colour regardless of any other status it may have.

 

Allowing you to customise this order of precedence would then enable you to set up the colours the way that make most sense to you – I guess there really is no right or wrong way here.

 

Ok, does any of this make sense?

 

How would this fly or am I just making the whole thing unnecessarily complicated?

It's exactly how I figured you would do it so it makes perfect sense to me.

 

Not that it matters, but I'd make the order:

Found

Archived

Placed

Not found

 

The above makes the most sense to me.

 

David

[+beejay&esskay]

Allowing you to customise this order of precedence would then enable you to set up the colours the way that make most sense to you – I guess there really is no right or wrong way here.

 

Ok, does any of this make sense?

 

How would this fly or am I just making the whole thing unnecessarily complicated?

Sounds great.

 

Like many others, I'd like to have "found" more important than "disabled/archived".

 

But I also understand not everyone will agree to the ordering, and that it's important not to change the default ordering.

[+rutson]

GSAK 3.05 is now ready to download at www.gsak.net

Added error message if you try to automate GSAK when it is already running

When Automating GSAK tips are not shown

I can't find any documentation about automating, is there some?

[+Team DEMP]

I can't find any documentation about automating, is there some?

In v3.05 which is the latest release, if you click on Help / Contents, the Windows Help file is opened. In the Windows Help file, double click on Miscellaneous Features to expand that section in the Contents. The last item in the list is Automating GSAK which discusses that area of the program.

 

David

[+rutson]

cheers, I did look in the help, but only in the index, guess I should've searched!

 

While I'm here is there a list of <#XXX> includes for the HTML files anywhere? Specifically I'm looking for lat and longin decimal format.

[+geonickel]

Here's a situation noted on the CacheMate thread that affects GSAK. (Sorry if you're getting both, Clyde -- I don't know how much time you get to read the CacheMate thread. If I'm out of line for cross posting, let me know -- I really do appreciate your product and the obvious thought you put into new features and trying to design them the best for the most people from the start!)

 

When a description is too long for the Palm, CacheMate truncates (I think 8k is the limit when long descriptions are enabled -- 3k when they're not). When you load the file into CMConvert, there is a warning that records have had their descriptions truncated. In the list there is a warning icon so you at least know what items are truncated.

 

This occurs quite frequently with Benchmarks (I can send you a gpx with Benchmarks with long descriptions, if necessary), but I understand that there are at least a few caches that have very long descriptions.

 

It would be nice to have an indication of which caches will be truncated. One could then decide what to do -- make a hard copy, make sure it was in a different format on the PDA, ignore it, whatever.

[+YeOleImposter]

This occurs quite frequently with Benchmarks (I can send you a gpx with Benchmarks with long descriptions, if necessary), but I understand that there are at least a few caches that have very long descriptions.

 

It would be nice to have an indication of which caches will be truncated. One could then decide what to do -- make a hard copy, make sure it was in a different format on the PDA, ignore it, whatever.

I have run into this also - was trying to think of a solution too.

 

Was wondering if there is a reason not to move the 'Reported by' into the 'logs' category?

 

This is not really a GSAK 'problem' but if it makes sense we may be able to talk the creator of BMGPX to recode it to move them?

[+ClydeE]

cheers, I did look in the help, but only in the index, guess I should've searched!

 

While I'm here is there a list of <#XXX> includes for the HTML files anywhere? Specifically I'm looking for lat and longin decimal format.

Currently No. Later down the track I plan to allow for full customization using these codes. At the moment some of these codes do more than just substitute a value, so it is not really practical to make consistent user modifications.

[+ClydeE]

Here's a situation noted on the CacheMate thread that affects GSAK. (Sorry if you're getting both, Clyde -- I don't know how much time you get to read the CacheMate thread. If I'm out of line for cross posting, let me know -- I really do appreciate your product and the obvious thought you put into new features and trying to design them the best for the most people from the start!)

 

When a description is too long for the Palm, CacheMate truncates (I think 8k is the limit when long descriptions are enabled -- 3k when they're not). When you load the file into CMConvert, there is a warning that records have had their descriptions truncated. In the list there is a warning icon so you at least know what items are truncated.

 

This occurs quite frequently with Benchmarks (I can send you a gpx with Benchmarks with long descriptions, if necessary), but I understand that there are at least a few caches that have very long descriptions.

 

It would be nice to have an indication of which caches will be truncated. One could then decide what to do -- make a hard copy, make sure it was in a different format on the PDA, ignore it, whatever.

GSAK just hands the conversion to CmConvert - It does not know if the description has been truncated or not.

 

So from this point of view I like the sound of YeOleImposter's idea.

[Cachengrab]

Uninstalled V.3 and installed V3.5

In split screen mode the HTML pages does not contain Cache name or Cache owner.

I'm lost

 

Cache Type shows Icon then skips down to Co-ords.

[+Team DEMP]

Uninstalled V.3 and installed V3.5

In split screen mode the HTML pages does not contain Cache name or Cache owner.

Not that I normally view split screen, but I did it under 3.5 and it shows everything it always has.... cache type icon, cache name, cache owner, coords, waypoint code, size, hidden date, etc.

 

Is it just 1 cache that is a problem or every one?

[Cachengrab]

All caches on list

[Cachengrab]

I went to tools- option- HTML tab- WPT description box for HTML is empty does this need something in there?

[+Team DEMP]

I went to tools- option- HTML tab- WPT description box for HTML is empty does this need something in there?

I have:

 

%Name by %by

 

on that option dialog tab.

[Cachengrab]

I think I found it in the Help default THX cachengrab

[Cachengrab]

Fixed thanks Team DEMP

[+YeOleImposter]

Clyde, any chance we will be able to add different 'types' to GSAK?

It would be great to be able to customize it for Benchmarking

Right now I just have mapped out Different types of benchmarks to the current list of types.

[+YeOleImposter]

And I think it may have been asked before (by Embra?) if you might consider adding a 'Did Not Find' Category? This would be useful for those caches I have looked for but did not find as well as for benchmarks (alterior motive).

 

Thinking out loud: Probably easiest to set it up as a different field altogether from the Found since computers do not like 3 states (Success / Failure / No Attempt) All three are mutually exclusive but awaiting a Tri-nary instead of Bi-nary computer

Don't know if it could share the same date field as found or not?

If the 'found' field is character based instead of binary - well then, very easy to change.

[+geonickel]

GSAK just hands the conversion to CmConvert - It does not know if the description has been truncated or not.

 

So from this point of view I like the sound of YeOleImposter's idea.

I agree with the idea to move "Reported by" to "Logs" in the gpx, which should help for most benchmarks.

 

However, benchmarks are not the only examples of descriptions being truncated -- just the majority, and (more to the point!) the examples I personally had knowledge of.

 

One example of a geocache with an abnormally long description is Up the Close and Down the Stair

 

CMConvert does know that descriptions are truncated and indicates this when loading the caches, prior to generating the pdb. I don't know if/how that information is passed when implementing CMConvert under the hood.

[+ClydeE]

GSAK just hands the conversion to CmConvert - It does not know if the description has been truncated or not.

 

So from this point of view I like the sound of YeOleImposter's idea.

I agree with the idea to move "Reported by" to "Logs" in the gpx, which should help for most benchmarks.

 

However, benchmarks are not the only examples of descriptions being truncated -- just the majority, and (more to the point!) the examples I personally had knowledge of.

 

One example of a geocache with an abnormally long description is Up the Close and Down the Stair

 

CMConvert does know that descriptions are truncated and indicates this when loading the caches, prior to generating the pdb. I don't know if/how that information is passed when implementing CMConvert under the hood.

Don't forget GSAK uses the command line version of CMConvert not the GUI version you are probably talking about. I don't think this information is available in the command line version.

 

Even if it was I'm not sure how or even if GSAK should be responsible for trying to fix something that is essentially a palm limitation.

[+ClydeE]

And I think it may have been asked before (by Embra?) if you might consider adding a 'Did Not Find' Category? This would be useful for those caches I have looked for but did not find as well as for benchmarks (alterior motive).

 

Thinking out loud: Probably easiest to set it up as a different field altogether from the Found since computers do not like 3 states (Success / Failure / No Attempt) All three are mutually exclusive but awaiting a Tri-nary instead of Bi-nary computer

Don't know if it could share the same date field as found or not?

If the 'found' field is character based instead of binary - well then, very easy to change.

This post and the one before refer to benchmarking.

 

Although I do plan to add more support for benchmarking in the future one of the main reasons I have been holding off (also benchmarking is only in America, where as new geocaching features add are for everyone) is that I am waiting to see what geocaching.com are going to come up with here. (they have indicated you will soon be able to get pocket queries of Benchmarks)

[+ClydeE]

GSAK just hands the conversion to CmConvert - It does not know if the description has been truncated or not.

 

So from this point of view I like the sound of YeOleImposter's idea.

I agree with the idea to move "Reported by" to "Logs" in the gpx, which should help for most benchmarks.

 

However, benchmarks are not the only examples of descriptions being truncated -- just the majority, and (more to the point!) the examples I personally had knowledge of.

 

One example of a geocache with an abnormally long description is Up the Close and Down the Stair

 

CMConvert does know that descriptions are truncated and indicates this when loading the caches, prior to generating the pdb. I don't know if/how that information is passed when implementing CMConvert under the hood.

Don't forget GSAK uses the command line version of CMConvert not the GUI version you are probably talking about. I don't think this information is available in the command line version.

 

Even if it was I'm not sure how or even if GSAK should be responsible for trying to fix something that is essentially a palm limitation.

OK, I just did some testing with the command line version of CmConvert.

 

By taking out the -q option that GSAK generates I can get it to show the truncation message.

 

I think the best solution here is for GSAK to just pass on this informatin in the form of a message box - at least then you will know which waypoints were truncated.

[+GLM]

Another column that the user can choose to display or not (and hence you can position anywhere). I am thinking of a very small width column like the travel bug, but with a "padlock" icon. Obviously those records that are locked would have the "padlock" icon, and those not locked would be blank

 

Clyde,

 

Sorry for referring to the old thread, but I was off the forums for a couple of days. Your solution to "Locked Records" is just what I need. That would work great. You could even do the same type of thing for records with corrected coords entered. Small width columns with just about anything in them would let me know I have done something to the record.

 

Gary

[Deego]

And I think it may have been asked before (by Embra?) if you might consider adding a 'Did Not Find' Category?  This would be useful for those caches I have looked for but did not find as well as for benchmarks (alterior motive).

 

Thinking out loud:  Probably easiest to set it up as a different field altogether from the Found since computers do not like 3 states (Success / Failure / No Attempt)  All three are mutually exclusive but awaiting a Tri-nary instead of Bi-nary computer

Don't know if it could share the same date field as found or not?

If the 'found' field is character based instead of binary - well then, very easy to change.

This post and the one before refer to benchmarking.

 

Although I do plan to add more support for benchmarking in the future one of the main reasons I have been holding off (also benchmarking is only in America, where as new geocaching features add are for everyone) is that I am waiting to see what geocaching.com are going to come up with here. (they have indicated you will soon be able to get pocket queries of Benchmarks)

We do have Trigpointing here in the UK which is nearly the same so even a new icon/type would help

[+geonickel]

I think the best solution here is for GSAK to just pass on this informatin in the form of a message box - at least then you will know which waypoints were truncated.

I can't speak for anyone else, but that would work for me. As you've already pointed out, this is really a Palm problem, not a GSAK problem. As long as I know which caches are truncated, I can decide how I want to handle them.

 

This is a feature that will benefit geocache seekers as well as benchmark seekers, since some cache hiders are giving very long descriptions.

[+roolku]

I think the best solution here is for GSAK to just pass on this informatin in the form of a message box - at least then you will know which waypoints were truncated.

Yes, that would be very helpful. Thanks a lot.

 

Roolku

[+Z_Statman]

Bug?

 

V3.05 - When I delete a cache from the list my column heading are reset to "default."

 

I made several changes to my display [added & dropped columns] then deleted a cache and the display reset/lost my changes.

[+YeOleImposter]

However, benchmarks are not the only examples of descriptions being truncated -- just the majority, and (more to the point!) the examples I personally had knowledge of.

 

One example of a geocache with an abnormally long description is Up the Close and Down the Stair

Holy Cow! That guy can write and write and write and write.....

Edited June 30, 2004 by YeOleImposter

[+Z_Statman]

How does one select a DB beside Default?

[+Team DEMP]

On the menu in GSAK, click on Select and then Database and select the database.

 

Other options under the Database menu allow you to Create a new one, delete one you no longer want, Or you can use Save As to create a backup copy of the existing open database.

[+ClydeE]

Bug?

 

V3.05 - When I delete a cache from the list my column heading are reset to "default."

 

I made several changes to my display [added & dropped columns] then deleted a cache and the display reset/lost my changes.

 

Yes, I get the same behaviour here. This also holds true if you change the column order or widths and then do a delete.

 

I'll squash this little bugger, but in the mean time the work around is to exit GSAK if you make any changes in this area, then start GSAK and do the delete(s)

 

On the menu in GSAK, click on Select and then Database and select the database.

And don't forgt this option is also on the toolbar

 

.

[+YeOleImposter]

Now that I have GSAK I noticed that I had a cache in Indiana and Wyoming - two places I have not been in 20 years.

 

They were Locationless Caches - and so of course the cooridinates were meaningless to me.

 

I realized this is a perfect place to use 'corrected coordinates' and so looked in the logs for my coordinates and corrected the two to show where I found the 'cache'

 

Thought would pass this along - now my map of found caches looks a little more 'true' and if I ever do more locationless caches I won't end up with caches in Norway

[+harleycache]

I realized this is a perfect place to use 'corrected coordinates' and so looked in the logs for my coordinates and corrected the two to show where I found the 'cache'

 

Thought would pass this along - now my map of found caches looks a little more 'true' and if I ever do more locationless caches I won't end up with caches in Norway

That's what I've been doing. Makes things look a bit better.

[+RocketMan]

Will this work and/or is there a better way?

 

What I want to do:

Use Mapsource to select specific cache waypoints on the map and then have GSAK filter just those same waypoints so that I can export the cache information for them into my PDA.

 

Summary of how I did it:

Opened several PQ's into GSAK and also exported the cache waypoints from the PQ's into Mapsource.

Selected the cache waypoints that I want in Mapsource, and exported them to a .loc file.

Loaded the .loc file into the Arc/Line filter and set the distance to a very small number like .01.

Applied the filter.

 

This seemed to work, but I didn't check to make sure I got the specific caches that I had in the .loc file. The total number of caches left after filtering was actually slightly higher than what was in the .loc file, but that is what I would expect because some other caches may fall in line with the ones in the .loc file.

 

Does this work and is there an easier way to do it?

 

Thanks,

Rocket Man

Edited July 2, 2004 by Rocket Man

[+ClydeE]

Will this work and/or is there a better way?

 

What I want to do:

Use Mapsource to select specific cache waypoints on the map and then have GSAK filter just those same waypoints so that I can export the cache information for them into my PDA.

 

Summary of how I did it:

Opened several PQ's into GSAK and also exported the cache waypoints from the PQ's into Mapsource.

Selected the cache waypoints that I want in Mapsource, and exported them to a .loc file.

Loaded the .loc file into the Arc/Line filter and set the distance to a very small number like .01.

Applied the filter.

 

This seemed to work, but I didn't check to make sure I got the specific caches that I had in the .loc file. The total number of caches left after filtering was actually slightly higher than what was in the .loc file, but that is what I would expect because some other caches may fall in line with the ones in the .loc file.

 

Does this work and is there an easier way to do it?

 

Thanks,

Rocket Man

From your description it would seem that you only want the exact waypoints you have selected in MapSource and exported to a loc file.

 

There is a way to do this, but for it to work you must use the %code tag when exporting the waypoints into MapSource. As I don't have MapSource, I am also assuming that when you generate this .loc file it also outputs this code. (you could verify this by loading this loc file into a new GSAK database and see if the GCXXXX code does in fact show up in the code column).

 

So assuming the above conditions have been met:

 

1. Clear all user flags (User Flags=>Clear all)

2. Load the LOC file you generated from MapSource into the database that has these caches. In the load GPX dialog make sure you check the box "set user flag if waypoint added/updated" and also select the "always" update for Database update options.

3. Now set a filter on "User Flag" = set

 

You should now have a filter of only the caches that you selected via MapSource.

 

If you don't like the idea of updating your production database with the LOC files generated from MapSource, then you can just precede step 1 with a Database=>Save As.. and use the newly created copy of the database to muck about with.

[+hbrx]

I won't end up with caches in Norway

 

What's wrong with caches in Norway?

 

hbrx.

32 V 598598E 6646042N

[+GLM]

GSAK 3.06 Build 13

OH WOW!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Gary

[+rutson]

GSAK 3.06 Build 13

OH WOW!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Gary

where?

[+GLM]

GSAK 3.06 Build 13

     

OH WOW!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

     

Gary

where?

If you are a registered user, you should be getting and email from Clyde as to where to find it. Since it's a Beta, I don't think unregistered user will get it.

.

I think there is also a link on his site that you can choose to be notified of new versions. I'm assuming registered users get notified first.

 

I found a small bug (that I may have created myself ), so Clyde is looking into it now.

 

Gary

[+Team DEMP]

It's typically (from what I can tell) offered to those that have registered and reported an issue/enhancement that is incorporated into the release.

[+rutson]

Small issue with GSAK and Multimap for UK users,

 

Multimap have gone and changed their systema little, the current URLs give deformed pages, if the URLs are changed to the following all is well:

 

Multimap (Zoom in)=http://www.multimap.com/map/browse.cgi?lat=%lat&lon=%lon&gride=%lon&gridn=%lat&scale=10000
Multimap (Zoom out)=http://www.multimap.com/map/browse.cgi?lat=%lat&lon=%lon&gride=%lon&gridn=%lat&scale=25000

 

Also I find the following URL useful, take you straight to the print page:

 

Multimap (Print 1:5000)=http://www.multimap.com/map/browse.cgi?client=print&scale=25000&gride=%lon&gridn=%lat&lat=%lat&lon=%lon&width=600&height=600

 

Hope this helps someone,

Edited July 2, 2004 by rutson

[+ClydeE]

It's typically (from what I can tell) offered to those that have registered and reported an issue/enhancement that is incorporated into the release.

Yes, currently 3.06 Beta versions are only for selected beta testers that I have invited to test these versions.

 

Typically they are users that use GSAK very often and try things I wouldn't dream of.

 

The beta versions change rapidly and are not for the faint hearted.

[+ClydeE]

Small issue with GSAK and Multimap for UK users,

 

Multimap have gone and changed their systema little, the current URLs give deformed pages, if the URLs are changed to the following all is well:

 

Multimap (Zoom in)=http://www.multimap.com/map/browse.cgi?lat=%lat&lon=%lon&gride=%lon&gridn=%lat&scale=10000
Multimap (Zoom out)=http://www.multimap.com/map/browse.cgi?lat=%lat&lon=%lon&gride=%lon&gridn=%lat&scale=25000

 

Also I find the following URL useful, take you straight to the print page:

 

Multimap (Print 1:5000)=http://www.multimap.com/map/browse.cgi?client=print&scale=25000&gride=%lon&gridn=%lat&lat=%lat&lon=%lon&width=600&height=600

 

Hope this helps someone,

Thanks for the post. I am sure there are users out there that will find this information helpful.

 

That is really what these forums are all about

[+RocketMan]

Will this work and/or is there a better way?

 

What I want to do:

Use Mapsource to select specific cache waypoints on the map and then have GSAK filter just those same waypoints so that I can export the cache information for them into my PDA.

 

Summary of how I did it:

Opened several PQ's into GSAK and also exported the cache waypoints from the PQ's into Mapsource.

Selected the cache waypoints that I want in Mapsource, and exported them to a .loc file.

Loaded the .loc file into the Arc/Line filter and set the distance to a very small number like .01.

Applied the filter.

 

This seemed to work, but I didn't check to make sure I got the specific caches that I had in the .loc file.  The total number of caches left after filtering was actually slightly higher than what was in the .loc file, but that is what I would expect because some other caches may fall in line with the ones in the .loc file.

 

Does this work and is there an easier way to do it?

 

Thanks,

Rocket Man

From your description it would seem that you only want the exact waypoints you have selected in MapSource and exported to a loc file.

 

There is a way to do this, but for it to work you must use the %code tag when exporting the waypoints into MapSource. As I don't have MapSource, I am also assuming that when you generate this .loc file it also outputs this code. (you could verify this by loading this loc file into a new GSAK database and see if the GCXXXX code does in fact show up in the code column).

 

So assuming the above conditions have been met:

 

1. Clear all user flags (User Flags=>Clear all)

2. Load the LOC file you generated from MapSource into the database that has these caches. In the load GPX dialog make sure you check the box "set user flag if waypoint added/updated" and also select the "always" update for Database update options.

3. Now set a filter on "User Flag" = set

 

You should now have a filter of only the caches that you selected via MapSource.

 

If you don't like the idea of updating your production database with the LOC files generated from MapSource, then you can just precede step 1 with a Database=>Save As.. and use the newly created copy of the database to muck about with.

Works great - Thanks ClydeE

 

BTW: I am using Mapsource 6.3. I use EasyMps to do all the conversions from GPX into Mapsource and from Mapsource to .loc. EasyMps has supported the new GDB format since Mapsource 6 first came out. How did the EasyMps programmer get the specs for the GDB format when others can't seem to get them? Robertlipe – Have you contacted him?

 

Thanks again,

Rocket Man