New BM2GPX Program

[+YeOleImposter]

I'll stop bugging ya'll after this for a while. Really..

 

New version supports importing finds/nofinds from geocaching (or another file) while importing, so that they will automagically be marked as such upon loading into GSAK (or another GPX-enabled program).

 

Wow! version .90 to .128 in 1 day

 

Had my hopes up for a minute with the newest feature that you had figured out some way to pull the logs of others at GC.com into GSAK.

 

Thanks for all your work on this!

 

YOI

[foxtrot_xray]

You give me a brand new wrench for my toolbox, and think the discussion on how best to use it is 'bugging' me?

Well, you know.. I know people on here want to talk benmark HUNTING, not PREPARING for a hunt. ..For me, I have as much fun getting ready for the hunt as I do the actual hunt. Research is fun!

 

Wow! version .90 to .128 in 1 day

 

Had my hopes up for a minute with the newest feature that you had figured out some way to pull the logs of others at GC.com into GSAK.

I never thought of this.. but then I am thinking.. would you really want this? True, could be helpful to see what others have written about it, but when you get something like that 4-corners mark mentioned in that other thread. I dunno how GSAK would handle 200+ logs.

 

As an aside: Clyde released 7.1.2.21 last night, and I strongly recommend upgrading to it. It 'fixes' (something that wasn't really broke, but he was a good guy and took care of it for us benchmark hunters) the Container type in the "Edit" dialog. My program puts the coordinates type in the "Container" (as per YOI's request) which technically is okay for the GPX standard. However GSAK's edit dialog forced it to once of the selectable types ("Small", "Micro", etc.) even if all you did was open it up to tag the mark as 'Found'. So, you'd lose the custom value in that field. In .21 however, that's taken care of, so you can edit the container type to anything you want as well, and if you don't, it won't lose the values that were originally imported.

[+YeOleImposter]

Well, you know.. I know people on here want to talk benmark HUNTING, not PREPARING for a hunt. smile.gif ..For me, I have as much fun getting ready for the hunt as I do the actual hunt. Research is fun!

 

I call that 'aggressively getting ready' - which, for me, is just another way to look productive without actually doing anything

 

-YOI-

[AZcachemeister]

Well, you know.. I know people on here want to talk benchmark HUNTING, not PREPARING for a hunt. ..For me, I have as much fun getting ready for the hunt as I do the actual hunt. Research is fun!

 

In general, I have found that if your preparation sucks, so will your results.

[ArtMan]

The problem was that my ancient pkunzip converted "short.html" to "short.htm". I simply renamed it to "short.html" and it worked.

BDT, I think you'll be happier with free, open-source 7-ZIP. It creates faster and/or smaller archives than other programs. I avoid their proprietary 7z format, which may be better, but at the cost of compatibility. .zip is the standard in the Windows world.

 

-ArtMan-

[ArtMan]

[dupe posting]

Edited October 13, 2007 by ArtMan

[2oldfarts (the rockhounders)]

[dupe posting]

Is this what you really meant?

 

 

 

John

[ArtMan]

[dupe posting]

Is this what you really meant?

 

John

Actually dope would probably be the better term ... for whoever designed the forums so that you could edit but not delete a post. In this case, I got an error message when I tried to publish my message, so I returned to the previous screen and tried again. Despite the error message, the post had been accepted, so the result was a duplicate post.

 

-ArtMan-

[+Black Dog Trackers]

ArtMan -

 

Well I did find that I have winzip somewhere on my machine and didn't even know about it. But thank you for the recommendation about 7-zip I will have to try that one.

[foxtrot_xray]

Will be releasing a new version tomorrow. Ran into an odd problem with this datasheet. (How I also found the photographs!)

 

Anyways, if you can find the problem with that datasheet, you get a free registered copy of NGS-GPX.

[+YeOleImposter]

Will be releasing a new version tomorrow. Ran into an odd problem with this datasheet. (How I also found the photographs!)

 

Anyways, if you can find the problem with that datasheet, you get a free registered copy of NGS-GPX.

 

I looked, and it sure looks like everything is in order. Was really hoping to get a 'free' copy of NGS-GPX!

 

PS. Last time I ran the program, all my heights were '0' but I did not have time to check it out and forgot to send you a note. May be fixed already.

[foxtrot_xray]

I looked, and it sure looks like everything is in order. Was really hoping to get a 'free' copy of NGS-GPX!

Yeah, it took me a little bit too...

 

Turns out that the last station recovery for that mark was on April 31st.

 

I never added code to check for *valid* dates.

 

PS. Last time I ran the program, all my heights were '0' but I did not have time to check it out and forgot to send you a note. May be fixed already.

Let me know if you still get it. I didn't have an issue the last time I actually imported data (the previous version) I got altitudes. I haven't looked at any imported data in this version yet.

[+YeOleImposter]

Yeah, it took me a little bit too...

 

Turns out that the last station recovery for that mark was on April 31st.

 

I never added code to check for *valid* dates.

 

Hmmm, the only date I see in the logs on the sheet you reference is "20051218" ??

[foxtrot_xray]

Hmmm, the only date I see in the logs on the sheet you reference is "20051218" ??

Hrm.. now I feel like an idiot. I somehow linked the wrong sheet. Twice. Brilliant, I am. This is the sheet I had meant to reference.

 

Mike.

[+YeOleImposter]

Hmmm, the only date I see in the logs on the sheet you reference is "20051218" ??

Hrm.. now I feel like an idiot. I somehow linked the wrong sheet. Twice. Brilliant, I am. This is the sheet I had meant to reference.

 

Mike.

 

Just another Senior Moment. I did see the correct page later when I read your post about photographs in the data sheet.

[foxtrot_xray]

New version released, ya'll. Major items:

1. Fixed issue where GSAK would error on a load with designations with "&"s in them.

2. Creates UserIDs for log reporting.

3. Uses the 'type' field for the location specifics of the benchmark.

4. Puts the GPX date as the date of the input file.

 

Download and see full details here.

[foxtrot_xray]

Bringing up a dead topic, because some may be interested..

 

Version 2.0 of the BMGPX replacement is almost ready. It's grafical<tm>! Anyways, the not-yet-finished help for the program is here, if you want to head over there and scan through the files, I'm open to any comments, suggestions.

[+YeOleImposter]

Bringing up a dead topic, because some may be interested..

 

Version 2.0 of the BMGPX replacement is almost ready. It's grafical<tm>! Anyways, the not-yet-finished help for the program is here, if you want to head over there and scan through the files, I'm open to any comments, suggestions.

 

Looks good! Will be interesting to see how it plays with the stuff created by version 1.0

[+Klemmer]

Hi FX:

I had to set aside a 1.XX something version of yours, and go back to the old original BMGPX, because of the way your BMGPX stuffed the whole datasheet into GSAK "long description". That came out a total mess in cachemate on my PDA. And I haven't had time to get back to it.

 

Has this been addressed? Old news, all fixed? Or news to you?

[+YeOleImposter]

Hi FX:

I had to set aside a 1.XX something version of yours, and go back to the old original BMGPX, because of the way your BMGPX stuffed the whole datasheet into GSAK "long description". That came out a total mess in cachemate on my PDA. And I haven't had time to get back to it.

 

Has this been addressed? Old news, all fixed? Or news to you?

 

I have the datasheet in cachemate just fine -- just like it looks in GSAK. Must have been a fluke.

[foxtrot_xray]

Hi FX:

I had to set aside a 1.XX something version of yours, and go back to the old original BMGPX, because of the way your BMGPX stuffed the whole datasheet into GSAK "long description". That came out a total mess in cachemate on my PDA. And I haven't had time to get back to it.

 

Has this been addressed? Old news, all fixed? Or news to you?

 

Hmmmm... Since I'm not sure what a 'total mess' is, I can only venture in broad guesses:

1. If you don't want the full datasheet in the long descriptiion, just edit the "long.html" file, and put in there whatever you want. No need to have it at all. I think I defaulted to that just for my testing, and never took it out.

 

2. There's two ways to indicate newlines in a file, of course - <br> for HTML and CR&LF (or LF) in a normal text file. The 'Long Description' file uses <pre> tags with CR&LF in the datasheet. I'm guessing that is cachemate doesn't honor <pre> tags correctly, then all the lines would run together (since HTML broswers ignore newlines).

 

My Palm has about 5 inches of dust on it, I've used it that recently. I can tug it out and try it with Cachemate, if you want.

 

In the new version MOST of the tags will use standard CR&LF newlines. Perhaps I'll add an option to change them into <BR> for HTML output. I'll look into that.

 

[Edit: I went ahead an added a setting to convert any NEWLINES to <br>'s for using tokens in HTML pages (instead of forcing the user to use <pre> tags..]

Me.

Edited January 17, 2008 by foxtrot_xray

[Papa-Bear-NYC]

Hi Foxtrot

 

I am (hopefully) about to upgrade to your routine (waiting for version 2.0), especially to get the feature of adding the child waypoints for reference marks and azimuth marks.

 

I use GSAK as my primary database for my finds, but I also export the data from GSAK and put it in a format which I then use for my customized Google Map showing the find. maybe you can help me here. I currently have to compute (using the NGS FORWARD program) the positions of the reference marks and azimuth mark one at a time if I want to show them on my map. I separate the refs. and the AZ by color and also draw in an azimuth line (since the position of the azimuth mark along that line is approximate).

 

The following screen shot shows what I get. It's for KV3473 "BOGART" a historic mark used in the 1903 NYC triangulation on Staten Island NY. The green mark with the info Window is the station. The two blue marks are the reference marks and the yellow line goes to the azimuth mark. The Az happens to have its own PID so you see that in the little label next to it. The other marks are simply nearby marks.

 

KV3473 BOGART

 

 

So my question/request is: how much of this can I automate using your routine including the child waypoints. I'd like to somehow use a tag to distinguish the reference marks from the azimuth mark, and also omit all the intersection stations that tend to appear in a typical box score. Of course putting the tags in myself would be possible (although time consuming) and certainly better than what I do now. Now I only put these things in only for stations I've found (due to the manual nature of the process), but it would be nice to see them for stations I may want to visit.

 

 

Thanks

Edited January 17, 2008 by Papa-Bear-NYC

[foxtrot_xray]

PapaBear - Let's see...

 

As it stands, right now, my program may help you with the following already.. However, some midification may be necessary to your macro, not sure -

With the option enabled, it will take the reference marks (RM's, AZ, anything else listed in the reference box in the datasheet) and compute the coordinates. It will then insert them as Child Waypoints in GSAK. (Right click on a benchmark, select "Child Waypoints". They'd be listed in there.) If you have another option enabled and you are loading more than one datasheet at a time (for example, a county or state archive), if a child waypoint (reference mark) has its own PID, it will update some information from that, including the coordinates (so instead of projecting them, they'd be the datasheet's location), date, and other basic info. (And while this won't help the exporting, a last option will let you use a GSAK URI for any existing child waypoints, so that if you're viewing station A, and a reference mark is station B, clicking on child point B will take you to GSAK's cache entry for station B.)

 

I separate the refs. and the AZ by color and also draw in an azimuth line (since the position of the azimuth mark along that line is approximate).

This may be a little difficult on the color markers, only because not all AZ marks have "AZ" in their name, so it'd be hard-pressed to 'guess' which ones are AZ marks and which ones are normal RMs. Also, at least down here where I am, a lot of times AZ marks don't have distances listed in the Reference box, just a direction, so that would make projecting it rather difficult.

 

So my question/request is: how much of this can I automate using your routine including the child waypoints. I'd like to somehow use a tag to distinguish the reference marks from the azimuth mark, and also omit all the intersection stations that tend to appear in a typical box score. Of course putting the tags in myself would be possible (although time consuming) and certainly better than what I do now. Now I only put these things in only for stations I've found (due to the manual nature of the process), but it would be nice to see them for stations I may want to visit.

Guess I jumped to answering the question above. I will add that unless selected to do so, the program will only include reference marks with an exact distance. That is, any distance that is NOT preceded by "APPROX". (You can, if you want, include the approxes. but by default, it won't.) For different symbols, I'll have to look into it. At the moment, the "SYM" tag is ignored in GSAK for Child Waypoints. (The "SYM" can be used for main waypoints, tho). The "type" of child waypoint would need to be used. At the moment, every child point inserted is a "Reference Mark". GSAK limits the user to a few select types. Haven't tried using custom types in there.

 

Feel free to PM me or reply here, if you wanted to get into this more. I'll play with some child types today and see if custom ones are allowed. (If they are, for example, I can make all "RM" ones a type of "reference Mark" and any AZ's that are useable an "Azimuth Mark"

 

Mike.

[Papa-Bear-NYC]

PapaBear - Let's see...

 

As it stands, right now, my program may help you with the following already.. However, some midification may be necessary to your macro, not sure -

With the option enabled, it will take the reference marks (RM's, AZ, anything else listed in the reference box in the datasheet) and compute the coordinates. It will then insert them as Child Waypoints in GSAK. (Right click on a benchmark, select "Child Waypoints". They'd be listed in there.) If you have another option enabled and you are loading more than one datasheet at a time (for example, a county or state archive), if a child waypoint (reference mark) has its own PID, it will update some information from that, including the coordinates (so instead of projecting them, they'd be the datasheet's location), date, and other basic info. (And while this won't help the exporting, a last option will let you use a GSAK URI for any existing child waypoints, so that if you're viewing station A, and a reference mark is station B, clicking on child point B will take you to GSAK's cache entry for station B.)

 

Hi again

 

Just wanted to comment on what you said here. (The rest I understand and I'll fiddle with what I get and see if I can get a reasonable way to distinguish the child waypoints)

 

I think it's a mistake to update the coordinates when a reference mark has it's own PIDs. Why? At least around here, most reference marks with their own PIDs are bench marks with scaled coordinates which are MUCH less reliable than the computed coordinates using the box score. In another thread I mentioned a reference mark to a station on the palisades set in the 1930s, was used in a leveling in the 1950s and the scaled coordinates from its separate datasheet put it on the wrong side of the George Washington Bridge! Not good. Keep the computed coordinates.

 

If you are going to change anything, change the scaled coordinates on the reference mark's datasheet to the computed coordinates from the box square. In other words the other way around. I do this in my own GSAK data and set the GSAK "Coordinates Corrected" flag. That way I can see I "fixed" the scaled coordinates from the datasheet. In fact that's just what I did for the Az mark for the station on my map. I moved the mark from the datasheet's (scaled) location so it would fall on my yellow line at x feet from the curb (as per the description) from where they put it (about a block away). Remember the rule we all memorize: NEVER TRUST SCALED COORDINATES!

Edited January 17, 2008 by Papa-Bear-NYC

[foxtrot_xray]

Hi again

 

I think it's a mistake to update the coordinates when a reference mark has it's own PIDs. Why? At least around here, most reference marks with their own PIDs are bench marks with scaled coordinates which are MUCH less reliable than the computed coordinates using the box score. In another thread I mentioned a reference mark to a station on the palisades set in the 1930s, was used in a leveling in the 1950s and the scaled coordinates from its separate datasheet put it on the wrong side of the George Washington Bridge! Not good. Keep the computed coordinates.

 

If you are going to change anything, change the scaled coordinates on the reference mark's datasheet to the computed coordinates from the box square. In other words the other way around. I do this in my own GSAK data and set the GSAK "Coordinates Corrected" flag. That way I can see I "fixed" the scaled coordinates from the datasheet. In fact that's just what I did for the Az mark for the station on my map. I moved the mark from the datasheet's (scaled) location so it would fall on my yellow line at x feet from the curb (as per the description) from where they put it (about a block away). Remember the rule we all memorize: NEVER TRUST SCALED COORDINATES!

 

Well, I'll be. D@mn good point. The original reason I wanted to update coordinates from the main datasheet was because I didn't trust my calculations on projecting. (At the time, had plenty of sample functions that gave me the distance and direction, but not the other way around. Math isn't my strong point, so it admittedly took me a while.) However, now that my functions done, that's a good point to make. It's an option right now to update or to not update, I'll have to re-work it and transfer some information both ways. (Coordinates from projection to main sheet, description and other data to child.)

 

Cheers,

Mike.

[+Klemmer]

FX:

 

OK, thanks. Yes, it was mising returns. Probably I could have done something about it, but at the time I was too buried.

 

Awaiting Ver 2.0 eagerly.

 

Klemmer

[Papa-Bear-NYC]

Well, I'll be. D@mn good point. The original reason I wanted to update coordinates from the main datasheet was because I didn't trust my calculations on projecting. (At the time, had plenty of sample functions that gave me the distance and direction, but not the other way around. Math isn't my strong point, so it admittedly took me a while.) However, now that my functions done, that's a good point to make. It's an option right now to update or to not update, I'll have to re-work it and transfer some information both ways. (Coordinates from projection to main sheet, description and other data to child.)

 

Cheers,

Mike.

Wow!

 

I complain and:

1) you listen

2) you understand and

3) you make a change!

 

You are great! You're not like my phone company or the software company or the landlord. You should double your price with the level of service you give.

[foxtrot_xray]

FX:

 

OK, thanks. Yes, it was mising returns. Probably I could have done something about it, but at the time I was too buried.

 

Awaiting Ver 2.0 eagerly.

 

Klemmer

Glad to have helped, at least. I added a setting now to 'automagically convert' CRLF's to <br>'s if you want. (Not a hard change, really..) Just gotta be sure that you (the users using the program) know when to enable it and not. Otherwise, weird results could occur.

 

Wow!

I complain and:

1) you listen

2) you understand and

3) you make a change!

 

You are great! You're not like my phone company or the software company or the landlord. You should double your price with the level of service you give.

Okay, I'll listen. The price is now doubled. In fact, to make EVERYONE happy, I tripled it.

 

It's getting closer to release, all the features are in place, now just working on ironing out display and bugs. Then, I'm going to have to figure out making an install executable for it.. (Which I have *no* experience in, so that should be amusing.)

 

And I am rather pleased with myself to make the following announcement: It's faster than V1 now. By a long shot. Woot.

 

Me.

Edited January 17, 2008 by foxtrot_xray

[+YeOleImposter]

Hi again

 

I think it's a mistake to update the coordinates when a reference mark has it's own PIDs. Why? At least around here, most reference marks with their own PIDs are bench marks with scaled coordinates which are MUCH less reliable than the computed coordinates using the box score. In another thread I mentioned a reference mark to a station on the palisades set in the 1930s, was used in a leveling in the 1950s and the scaled coordinates from its separate datasheet put it on the wrong side of the George Washington Bridge! Not good. Keep the computed coordinates.

 

If you are going to change anything, change the scaled coordinates on the reference mark's datasheet to the computed coordinates from the box square. In other words the other way around. I do this in my own GSAK data and set the GSAK "Coordinates Corrected" flag. That way I can see I "fixed" the scaled coordinates from the datasheet. In fact that's just what I did for the Az mark for the station on my map. I moved the mark from the datasheet's (scaled) location so it would fall on my yellow line at x feet from the curb (as per the description) from where they put it (about a block away). Remember the rule we all memorize: NEVER TRUST SCALED COORDINATES!

 

Well, I'll be. D@mn good point. The original reason I wanted to update coordinates from the main datasheet was because I didn't trust my calculations on projecting. (At the time, had plenty of sample functions that gave me the distance and direction, but not the other way around. Math isn't my strong point, so it admittedly took me a while.) However, now that my functions done, that's a good point to make. It's an option right now to update or to not update, I'll have to re-work it and transfer some information both ways. (Coordinates from projection to main sheet, description and other data to child.)

 

Cheers,

Mike.

 

I agree. I have found the computed coordinates to be much closer to the mark than the scaled coordinates on the data sheet. I manually change the scaled coordinates to the child coordinates calculated by NGSGPX.

[foxtrot_xray]

Okay guys...

 

It's official.. v2.0 is released! Go here and grab a copy.

 

As far as testing goes, I tried to test every known conceivable configuration and possibility with the settings and options and preferences. However, being the programmer, I know what to expect and therefore can't rightfully say that I've got ALL bugs.

 

SO, having said that, since all the processing code is new, try a few imports in a temporary database first, and verify that things were imported the way you like them. Some settings MAY need to be changed from defaults to match v1.0's running behaviour and to make it work the way you want to. If you have *ANY* issues of concerns, PM me here or over on the GSAK forums. (Same user name there, too.)

 

PLEASE, have at it and let me know what you like AND don't like. I'm nervous as all heck, since: 1. I'm not a programmer, and 2. I've never programmed anything (well, other than v1) before.

 

Oh, it DOES require M$'s .NET 2.0, sorry. It will try to automagically install (I think..), but in case it gives you issues, you may have to install it manually.

 

Thanks!!

Mike.

Edited January 21, 2008 by foxtrot_xray

[+GEO*Trailblazer 1]

My name want fit in the provided space.

It is one shy.

Does it have a character limit?

I know some programs will not allow *.

 

On reference marks they default 1/1/1800 in childs waypoints.

The stations may say 1961.

 

Everything else looks good.

[foxtrot_xray]

My name want fit in the provided space.

It is one shy.

Does it have a character limit?

I know some programs will not allow *.

Fixed in the next release. I did limit it, although that was way back when I started the program. Now, I can't remember why, so I took off the limit.

 

On reference marks they default 1/1/1800 in childs waypoints.

The stations may say 1961.

 

Everything else looks good.

Ah, thanks! Will also be fixed in the next version (coming really, really soon). The child points *should* have the same date as the main waypoint, UNLESS you select the 'transfer info to/from main sheet' option selected, then the date will come from the main sheet.

[+GEO*Trailblazer 1]

I got the name to work less the one Character.

The code and initials must have taken.

 

On the reference marks.

No matter what I do I get the same error of 1800 and I only get 1 of the reference marks for all of them so they are all in the same place.

 

I am a beginner to so don't know all the quirks.

 

What is GSAK URI?

[foxtrot_xray]

I got the name to work less the one Character.

The code and initials must have taken.

 

On the reference marks.

No matter what I do I get the same error of 1800 and I only get 1 of the reference marks for all of them so they are all in the same place.

 

I am a beginner to so don't know all the quirks.

 

What is GSAK URI?

I just posted a fixed version for the reference marks and a few other small issues. Try it. If you still get odd results, send me your GPX file and the input file that you used, let me take a gander.

 

For the GSAK URI, it works like this:

Every waypoint *can* have a URI associated with it. For the main points, you can have it point to the NGS datasheet, or the GC.com page, or any custom page you want. Since child waypoints of one benchmark may be a benchmark of their own, normally these child waypoints will have their own URL, pointing to their own datasheet. However, sometimes you may want to pull up the record in GSAK instead of pulling up the online datasheet. (So you can see if you've found it, etc.). So, when you enable the GSAK URI option, Child Waypoints that exist in your database will have a custom GSAK link. Clicking on the child PID will take you to the entry in GSAK's database for that PID, instead of showing you the online page.

Edited January 22, 2008 by foxtrot_xray

[+GEO*Trailblazer 1]

Tried the update.

Reference marks are now 1989 instead of 1961.

They are also still only 1 reference for them all with the same coordinates for all.

 

The State is Missouri county Barry.

I would need an email to send them to you.

 

Thanks for being prompt,I am not trying to find problems just trying to use it to it's best and trying to get you feedback.

[foxtrot_xray]

Tried the update.

Reference marks are now 1989 instead of 1961.

They are also still only 1 reference for them all with the same coordinates for all.

PM me a PID, and I'll look at it. (Or, in the 'About' dialog, my name there is a n e-mail link. I dont' wanna post it here for spambots and such..)

 

Thanks for being prompt,I am not trying to find problems just trying to use it to it's best and trying to get you feedback.

Nooo problem. I'm not a programmer, but liked working on this little thing, and wanna make it as perfect as I can.

[foxtrot_xray]

Time to bug everyone again.

 

Fixed version is up, Reference marks are now properly set and imported, if you have that option enabled.

 

You can let this version do an upgrade, tho if you're upgrading form the first release, you'll have a dead start-menu item.

 

Any comments, suggestions, and other stuff welcome. Hope everyone enjoys.

[+GEO*Trailblazer 1]

Everything great so far.

Thanks for those quick fixes.

 

I did find when you export a GPX file from GSAK you get double waypoints.

It is probaly another setting though in GSAK and not BMGPX.

 

I still do not know what all them buttons do.

But have fun working on em.

 

Thanks again.

[foxtrot_xray]

I did find when you export a GPX file from GSAK you get double waypoints.

It is probaly another setting though in GSAK and not BMGPX.

Possibly they're child waypoints, or the database needs reindexing. Try repairing the database, and check the export settings for Children. As a rule, GSAK won't allow IMPORTING of duplicate caches, unless they have a different code/PID.

 

GPX file weren't really made to handle "child waypoints" that well, and in this case, a "child" waypoint has the "Parent" element set. If that "Parent" flag isn't set, then the values for that 'invalid' child waypoint will overwrite any existing waypoint in GSAK's database when loaded.

[+Team Trail Walker]

I have been working with your new program trying to get the short and long description just like I want it. I found a problem using the alt token. It always gives the result of ####0.0##. I will also add that the program will put the proper alt into the user 2 data space. I am not sure what to try to fix this.

 

Thanks

[foxtrot_xray]

I have been working with your new program trying to get the short and long description just like I want it. I found a problem using the alt token. It always gives the result of ####0.0##. I will also add that the program will put the proper alt into the user 2 data space. I am not sure what to try to fix this.

 

Thanks

Hey, Thanks for letting me know. I'm looking into it now.

Mike.

[foxtrot_xray]

Hey. Just letting you know that a new version is posted that fixes your ALT issue, as well as a few other tokens that were not always being set properly. Also fixed a few other items, like the "Country" and the "Container" not always being set as well. You can go grab it here.

[+Team Trail Walker]

Thanks for the update, I'll give it a try.

 

Craig

[+TheBeanTeam]

foxtrot_xray,

 

You are very welcome.

 

 

 

 

 

 

 

 

 

 

I read the terms. And a big thanks to you as well.

[foxtrot_xray]

You are very welcome.

I read the terms. And a big thanks to you as well.

 

Hey, thanks! The install made me put something in there. That was all i could think up of at the time.

[foxtrot_xray]

Hey all. A new version up. Many fixes implemented, including the SendTo shortcut. (Easier for processing on the fly!)

 

Go grab it at: http://ngs.tsqmadness.com/help

Latest version is 2.1.0b317.

 

Note that if you'll be installing it on a fresh machine, it will automatically install the latest Install Engine and .NET 2.0 redistributable (both from Microsoft). It may require a reboot after that, however.

 

Enjoy!

Mike.

Edited May 21, 2008 by foxtrot_xray

[foxtrot_xray]

Quick update - for the latest version's "Found File" feature to work you WILL need GSAK v7.2.1 or LATER. Forgot to mention that anywhere..

[+GEO*Trailblazer 1]

So far so good.

 

Thanks for the updates.

[Papa-Bear-NYC]

Hi Mike

 

I've started using this and I'm very impressed. I have used GSAK for a while to track all my finds but it was a bit of a pain since

1) the county downloads were out of date so I occasionally had to add newer stations by hand

2) I had to put in my finds and not founds by hand

3) to display things like scaled/adjusted or marker type, I had to run a hand crafted (translation =kludgey) macro to find the elements from the datasheet

4) I occasionally wanted the lat/lng of the reference marks but I was on my own to run FORWARD to get this data.

 

Now you've solved just about all these issues.

 

A few suggestions (since I'm new to the program, these may already be there but I haven't yet figured how to turn them on)

 

Reference Marks > Child Waypointe (GREAT feature!): Put the name of the reference mark from the box score as the name of the child waypoint. Since I have a procedure to extract these and plot them on a Google Map, the name would be very helpful. You might also put in a different "Type" (all are now called "Reference Point") for those with valid PIDs. Maybe "NGS Station".

 

Odds and ends from the dadaheet: Most of these (lat, lng, monumentation agency, others) map well to Geocache terms but a few require you to "usurp" a Geocaching element. For example "scaled/adjusted" > "container". I would also like the Marker type (disk, bolt, etc.) and others may want other things. I would put the Marker type probably into "Symbol Name" since they are all set to "Benchmark" or "Benchmark Found" now, which is redundant. There are others so this is an open ended issue (translation: "you can never please everyone!"). I only care about the Marker type, and maybe no one cares about any of the others. If they do, maybe they could chime in here.

 

Again thanks for the good job and I would emphasize these suggestions are rather meager copared to the work you have already done.

 

One other thing: I would speculate that the use of GSAK for BMs is sufficiently different from Geocaching that they probably belong in a different database. I actually keep my BMs in a different database for each county (although I may change that for some states like Maine where I have only a few finds scattered all over the state) . What do others think about this?

[Papa-Bear-NYC]

Hi Mike

 

I've started using this and I'm very impressed. I have used GSAK for a while to track all my finds but it was a bit of a pain since

1) the county downloads were out of date so I occasionally had to add newer stations by hand

2) I had to put in my finds and not founds by hand

3) to display things like scaled/adjusted or marker type, I had to run a hand crafted (translation =kludgey) macro to find the elements from the datasheet

4) I occasionally wanted the lat/lng of the reference marks but I was on my own to run FORWARD to get this data.

 

Now you've solved just about all these issues.

 

A few suggestions (since I'm new to the program, these may already be there but I haven't yet figured how to turn them on)

 

Reference Marks > Child Waypoints (GREAT feature!): Put the name of the reference mark from the box score as the name of the child waypoint. Since I have a procedure to extract these and plot them on a Google Map, the name would be very helpful. You might also put in a different "Type" (all are now called "Reference Point") for those with valid PIDs. Maybe "NGS Station".

 

Odds and ends from the dataheet: Most of these (lat, lng, monumentation agency, others) map well to Geocache terms but a few require you to "usurp" a Geocaching element. For example "scaled/adjusted" > "container". I would also like the Marker type (disk, bolt, etc.) and others may want other things. I would put the Marker type probably into "Symbol Name" since they are all set to "Benchmark" or "Benchmark Found" now, which is redundant. There are others so this is an open ended issue (translation: "you can never please everyone!"). I only care about the Marker type, and maybe no one cares about any of the others. If they do, maybe they could chime in here.

 

Again thanks for the good job and I would emphasize these suggestions are rather meager compared to the work you have already done.

 

One other thing: I would speculate that the use of GSAK for BMs is sufficiently different from Geocaching that they probably belong in a different database. I actually keep my BMs in a different database for each county (although I may change that for some states like Maine where I have only a few finds scattered all over the state) . What do others think about this?