Jump to content

New BM2GPX Program


YeOleImposter

Recommended Posts

Hey! Okay, I addressed a few of these things here, would also appreciate anyone's comments. A BIG point you brought up is the 're-purposing' of GSAK fields.

 

Things my program does that repurposes fields already are:

1. Uses the "Country" field for the "County" of the mark.

2. Uses the "Cache Type" for the Coordinates accuracy / Intersection station.

3. Uses the "User2" field for Altitude.

4. Uses 'Children' for Reference marks.

5. Uses the 'Archived' flag for 'Destroyed' marks.

6. Uses the "FTF" flag for when you find a mark previously Not Found.

7. Uses the "Container" for the Coordinates accuracy.

 

If I use anything else, I need to get some kind of consensus.

 

And yes, the best way to keep track of your Benchmarks is to keep them in their own Database(s).

 

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".
This is already supposed to be happening. I noticed this yesterday - it's a bug. Will be fixed in a small release next week. :huh: As far as the type, I may not be able to. GSAK may limit those entries to what GSAK allows, I will have to check, and talk with Clyde.

 

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.
The Symbol I'll need to get others thoughts, only because others may use it for their GPS. Those fields, BTW, *ARE* available as Tokens, and can be put into the LONG or SHORT description. :grin: The Container is already used for the accuracy, so that one was easy.

 

Cheers!

Mike.

Link to comment
...
Odds and ends from the dadaheet: ... 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.
The Symbol I'll need to get others thoughts, only because others may use it for their GPS. Those fields, BTW, *ARE* available as Tokens, and can be put into the LONG or SHORT description. :grin: The Container is already used for the accuracy, so that one was easy.

 

Cheers!

Mike.

Hi Mike

 

I just checked with my copy of GSAK and it seems to allow arbitrary values for "Symbol Name", check highlighted waypoint AI8323 "WO 12"

 

cde4ad96-9ca2-440e-8e39-a38fc29af03c.jpg

 

I also downloaded that waypoint to my Garmin 60CSX and it looks fairly normal. Not an in-depth test but it shows promise.

Link to comment

Hi Mike

 

A few things:

 

1) I wrote a GSAK macro to dig out the Marker type and stick it in the Symbol name. I can always move it somewhere else. If you do decide to put it somewhere, then I won't need this.

 

2) On principle, I would suggest you not put anything in User or User 2 since that's the only place users can put their arbitrary stuff. I use it for station condition information. I see you use it for altitude, which I turned off since that is not something I care strongly about. So you might think about this.

 

3) Perhaps you could set Not Found marks as "Temporarily Unavailable". I do that so they get a different color and so I get a count at the bottom (and besides "Temporarily Unavailable" is sort of what a Not Found mark is.) You do something very similar for Destroyed (>Archived) already.

 

4) Perhaps you could also set the "Corrected coordinates indicator" for those marks which you change the coordinates of when you find a reference mark which is also a Benchmark. I already do that (Or I "did" do it when I did the RMs by hand) so I can pick it up for my maps. Like this one: LX1099. It's one I recovered Saturday and it's exactly the case in point. Note the line in the infoWindow saying location is corrected..

 

Oh ...

 

I wanted to follow up on the use of the Found File in cases where a mark may have changed from Not Found to Found or Found to Note. I guess I would suggest a heierarchy on what the final status is:

 

-> Found AND Not Found - Later log should determine the status. Now you leave both checked.

-> Note AND either Found or Not Found - Found or Not Found should always overrule Note. Now (I think) a later Note overrules an earlier Found or Not Found.

 

I posted a question on the GSAK forum (Here) about exporting Child WPs to CSV files. I use this to generate the JS arrays for my Gmaps. If you know a way to do it or a workaround, please let me know.

 

Besides this minutia, every thing looks real good. Thanks for all the work.

 

Richard aka Papa Bear

Edited by Papa-Bear-NYC
Link to comment
...
Reference Marks > Child Waypointe (GREAT feature!): ... You might also put in a different "Type" (all are now called "Reference Point") for those with valid PIDs. Maybe "NGS Station".
... As far as the type, I may not be able to. GSAK may limit those entries to what GSAK allows, I will have to check, and talk with Clyde.

Hi again Mike

 

I figured a way to add a new type for the Child Waypoints.

1) add a file to the GSAK folder with the name OtherChild.txt

2) in the file put the name of the type you want to add.

 

I did this and put in "NGS Station" in the above named file. Now if I go to edit the child waypoint, the new type is available in the drop down. Works great!

 

So you might conside something like this which is fairly simple and would save a bit of hand work for the user to set.

 

I noticed a small "Gotcha" with Child waypoints:

In some cases, the reference marks in the box score, which you dig out have internal numbers (such as CB4011) instead of PIDs. Usually these DO NOT have separate PIDs, BUT SOMETIMES they do!

 

For example for station LX1107 "DOCK", in Putnam County NY, there are two RMs, namely "DOCK RM 3" and "DOCK RM 4". Your program found these and correctly calculated the coordinates (Thanks!), but they had ids of CB4011 and CB4012, which are not PIDs, so you stopped there. BUT they actually do have PIDs, namely LX1108 "DOCK RM 3" and LX1109 "DOCK RM 4".

 

So those two other stations never got the corrected coordinates. So .. what to do? You could search for the Designation, instead of or in addition to the PID, or you could do nothing and say "Too Bad!", or you could think about it. I think it's an interesting glitch but not one to lose sleep over.

And another RM >> Child question:

The feature where you correct the coordinates for RMs with PIDs based on your calculation from the box score data is a great one. These are almost always set as RMs and later used a benchmarks (with scaled location) so what you do is a big win. BUT once in a while, they are not actual RMs but just nearby stations, and sometimes those stations are tri-stations with adjusted coordinates. I have found an example, (although they are probably rare). Station MZ1957 "GREYLOCK RM 1 RESET" is a GPS station which point to MZ1158 "GREY MAG" which is a second order station. I'm not sure which location would be "better" but it's worth a thought.

 

So Mike, you add a nice feature and some guy just has all these annoying questions :anibad: ! Sorry.

Edited by Papa-Bear-NYC
Link to comment

Alrighty, here's what I got:

 

1) I wrote a GSAK macro to dig out the Marker type and stick it in the Symbol name. I can always move it somewhere else. If you do decide to put it somewhere, then I won't need this.

 

2) On principle, I would suggest you not put anything in User or User 2 since that's the only place users can put their arbitrary stuff. I use it for station condition information. I see you use it for altitude, which I turned off since that is not something I care strongly about. So you might think about this.

The Altitude was added from a request, and I liked the feature, so it's stayed in. One thing I may plan in the future (I've already started thinking about it) is making the settings allow users to 'map' their own values, with drop down boxes of datasheet info pointing to drop-down boxes of GPX fields. That may be v1.5 or v2.0.. If I live that long. :D

 

3) Perhaps you could set Not Found marks as "Temporarily Unavailable". I do that so they get a different color and so I get a count at the bottom (and besides "Temporarily Unavailable" is sort of what a Not Found mark is.) You do something very similar for Destroyed (>Archived) already.
I can add this as an option, certainly. The only thing I'd be worried about is that it would then be neigh impossible to tell the actual destroyed marks form the "Temp Unavailable" ones in GSAK. An option - and one that I alluded to in the GSAK forums is using Clyde's Highlighting Syntax. It may be able to highlight 'Attempted - Not Found' marks.

 

4) Perhaps you could also set the "Corrected coordinates indicator" for those marks which you change the coordinates of when you find a reference mark which is also a Benchmark. I already do that (Or I "did" do it when I did the RMs by hand) so I can pick it up for my maps. Like this one: LX1099. It's one I recovered Saturday and it's exactly the case in point. Note the line in the infoWindow saying location is corrected..
This is an idea, and I HAVE thought about it already. The reason I passed it up was this - when I go out to find a mark, I have my GPS and create a waypont for it. Then I'll update GSAK with the coordinates from my GPS as the corrected coords. That way I know which ones are 'gps accurate' that I found. :anibad:

 

-> Found AND Not Found - Later log should determine the status. Now you leave both checked.

-> Note AND either Found or Not Found - Found or Not Found should always overrule Note. Now (I think) a later Note overrules an earlier Found or Not Found.

The way the program handles it is this: Each PID can be Found, Not Found, and/or Destroyed. (Again, I do ignore the 'notes' at the moment.) GSAK, the way it was made, is that (internally) if the "$d_Found" is true, then "$d_DNF" is forced off. (That's Found flag and DNF flag.) However, the DNF Date is still stored. Therefore, if a mark is Found and Not Found, the LATEST date of each (in the case you find or NOT find a mark twice) the DNF date is set, as is the Found date and found flag. (GSAK ignores the DNF flag in that case).

 

 

I figured a way to add a new type for the Child Waypoints.

1) add a file to the GSAK folder with the name OtherChild.txt

2) in the file put the name of the type you want to add.

So you might conside something like this which is fairly simple and would save a bit of hand work for the user to set.

I'm talking with Clyde at the moment on making that user=-editable, and not defendant on the file. Depending on what happens, we'll see. :D (Tho, honestly, I don't see why 'Reference Point' won't work, since.. technically, they ARE reference points? :D )

 

I noticed a small "Gotcha" with Child waypoints:

In some cases, the reference marks in the box score, which you dig out have internal numbers (such as CB4011) instead of PIDs. Usually these DO NOT have separate PIDs, BUT SOMETIMES they do!

Hm. Interesting. Haven't seen that before. I can certainly do a search by name, however, it WILL slow the process down.. I'll have to run a test and see how much it impacts. Another side-effect is that it may return false-positives. i.e. Would there be any other "DOCK RM3"s? It's certainly possible. (Maybe not in the 'DOCK' example, but other names/etc could be duplicated..)

 

And another RM >> Child question:

The feature where you correct the coordinates for RMs with PIDs based on your calculation from the box score data is a great one. These are almost always set as RMs and later used a benchmarks (with scaled location) so what you do is a big win. BUT once in a while, they are not actual RMs but just nearby stations, and sometimes those stations are tri-stations with adjusted coordinates. I have found an example, (although they are probably rare). Station MZ1957 "GREYLOCK RM 1 RESET" is a GPS station which point to MZ1158 "GREY MAG" which is a second order station. I'm not sure which location would be "better" but it's worth a thought.

Yeah, I know. I WAS going the other way and updating reference marks from the parent datasheet, but others mentioned that the forwarded coordinates were actually more accurate than the older datasheets, so the program's been that way now. I'm not sure which coordinates would be more accurate, or how to tell. (Obviously, if the parent marks were, say, horiz order low, then the child marks, no matter how well the forwarded's coords were, they wouldn't be BETTER than the parent's horiz order.

 

Anyways, you've given me some things to consider, certainly. :D And darn, that was a long reply. B)

Link to comment
3) Perhaps you could set Not Found marks as "Temporarily Unavailable". I do that so they get a different color and so I get a count at the bottom (and besides "Temporarily Unavailable" is sort of what a Not Found mark is.) You do something very similar for Destroyed (>Archived) already.
I can add this as an option, certainly. The only thing I'd be worried about is that it would then be neigh impossible to tell the actual destroyed marks form the "Temp Unavailable" ones in GSAK. An option - and one that I alluded to in the GSAK forums is using Clyde's Highlighting Syntax. It may be able to highlight 'Attempted - Not Found' marks.

Of all the suggestions this is the hardest to deal with, given the business with counts, as was mentioned over on the GSAK board. Since I haven't looked into the highlight business yet it needs to be stirred around a bit before a good solution presents itself.

 

Thanks again.

Rg aka Pb

Link to comment
I figured a way to add a new type for the Child Waypoints.

1) add a file to the GSAK folder with the name OtherChild.txt

2) in the file put the name of the type you want to add.

 

I am a dummy what kind of file?

I can add a folder in GSAK with that name but in what place is that file under just the main GSAK folder?

The issue here is: Is there a way to add different types for Child waypoints.

 

The reason you might want to do that is that in this context, child waypoints are used for reference marks. This is good since now all the reference marks for a given station (usually 2,but sometimes more) have their own entry, and their own location - accurately computed form the box score. So now you can search for these with your GPS.

 

Since Child waypoints were originmally designed for geocaching, there were pre defined types, such as "Parking Area", "Question to answer", "Stages of a multicache", "Trailhead", etc. In other words, nearby locations that can help in the process of finding a cache. For Benchmarks, the only one pertinant is "Reference Point", which is fine since all the entries in the box score are reference points. But I wanted to distinguish regular reference marks, form marks that were also stations in their own right, that is the ones with their own PIDs. So I suggested using the made up type "NGS Station".

 

Well, it turns out GSAK lets you define your own custome type, and that's what I found out how to do. What you do is:

 

1) Create a text file (use wordpad or notepad) which contains a single line. The content of the line is your custom type. In my case the line contains the text: "NGS Station"

 

2) Place the file in the GSAK folder and give the file the name ChildOther.txt. In my case the GSAK folder is C:\Program Files\gsak (this was determined when you installed GSAK), so the path is C:\Program Files\gsak\ChildOther.txt

 

Now you are all set. Bring up you child waypoints as follows:

1) Highlight the station with the child waypoints (a station with reference marks)

2) right-click on the station and select "Child waypoints ..."

3) in the box that appears, select a particular child (say "RM 1") and click on the Edit button.

4) You can now edit any of the fields. To edit the type, use the drop down selector. You will now see your newly defined type at the bottom of the drop down list.

Edited by Papa-Bear-NYC
Link to comment
1) Create a text file (use wordpad or notepad) which contains a single line. The content of the line is your custom type. In my case the line contains the text: "NGS Station"

Actually, you can have as many types here as you want, each one on its own line. For example:

 

NGS Station
Reference Mark
Azimuth Mark
Intersection Station

 

So then, all those type would be added to the drop-down.

Link to comment
1) Create a text file (use wordpad or notepad) which contains a single line. The content of the line is your custom type. In my case the line contains the text: "NGS Station"

Actually, you can have as many types here as you want, each one on its own line. For example:

 

NGS Station
Reference Mark
Azimuth Mark
Intersection Station

 

So then, all those type would be added to the drop-down.

That's very nice, I thought it was just one. Sounds like anyone can get whatever they want. Not sure how to automate it though. I guess you could scan the description for "RM" or for "AZ", and also if it has a real PID. But to decide it's an intersection station is another indirect search of the target mark. Where to draw the line? The guy who does the work, decides that! :laughing:

Link to comment

Quick update - the issue with the Child Waypoints (reference marks) not getting their names imported is due to a 'sleeping bug' in GSAK. Ini the latest build, I added "<![CDATA[" tags for the names of teh marks. This was done due to certain marks having the "&" character in the name, which would then cause invalid XML markup. However, while GSAK would read CDATA tags in PARENT station names, it wouldn't in child names. This is going to be fixed (supposedly) in the next build. :anibad:

 

Now, about the RMs, AZ, etc etc.. That's REALLY difficult if I wanted to do ANYTHING other than just looking at the reference point and looked for "RM" or "AZ". (Which then I'd have to look for "Azimuth" and "Reference Mark" as well.) If I started scanning the descriptions, the success hit rate would be VERY low, and would slow the whole process down horribly. (And yeah, I tried it. And then waited 4 hours for it to parse the state of GA for me...)

Link to comment

Quick update - the issue with the Child Waypoints (reference marks) not getting their names imported is due to a 'sleeping bug' in GSAK. Ini the latest build, I added "<![CDATA[" tags for the names of teh marks. This was done due to certain marks having the "&" character in the name, which would then cause invalid XML markup. However, while GSAK would read CDATA tags in PARENT station names, it wouldn't in child names. This is going to be fixed (supposedly) in the next build. :anibad:

This is good news. I saw Clyde's post on the other forum so I'll be waiting for this new version. It's about the only big item I'm hoping to see soon.

 

Now, about the RMs, AZ, etc etc.. That's REALLY difficult if I wanted to do ANYTHING other than just looking at the reference point and looked for "RM" or "AZ". (Which then I'd have to look for "Azimuth" and "Reference Mark" as well.) If I started scanning the descriptions, the success hit rate would be VERY low, and would slow the whole process down horribly. (And yeah, I tried it. And then waited 4 hours for it to parse the state of GA for me...)

Since I may be the only one in the world who might want this, I would say don't bother. I can always set the appropriate type on stations I have actually visited or found, which are the one's I care about and which I would put on a map, especially since now we know how to include these in the drop down. I have to add a thumbnail tag to these any way, so a certain amount of manual work will always be needed.

 

As for any other issues, I think certain ones might be options, like these:

==> Setting the location corrected flag on locations you changed for RMs with their own PIDs

==> Setting DNFs Temporarily Unavailable

==> Setting Destroyed marks DNF instead of Found (already an option). This makes more sense to me, but perhaps not to others

 

Less important and may require some thought:

==> Whether to correct the locations of RMs with separate PIDs when the separate PID has an adjusted location. I would tend towards no, but I'm not sure which would be more accurate. In the one case I had in-the-field experience, MOUNT TOM (MZ1808) and MOUNT TOM BORDEN (MZ1806), it turns out that the location given in the description (written in 1896) was correct (as close as we could measure it) but the adjusted location from the datasheet was 5" off. (Note: MZ1807 wasn't listed in the box score anyway, but it does illustrate the accuracy issue.) Maybe at that level it's a toss up. MZ1807 was a third order station so that may explain the 5" discrepancy. However in these case, it would be more important than ever to set the "Corrected location" flag.

 

As always, thanks for your work, and your responsiveness!

 

Rg aka Pb

Link to comment
QUOTE(Papa-Bear-NYC @ May 27 2008, 04:20 PM)

1) Create a text file (use wordpad or notepad) which contains a single line. The content of the line is your custom type. In my case the line contains the text: "NGS Station"

 

Actually, you can have as many types here as you want, each one on its own line. For example:

 

NGS Station

Reference Mark

Azimuth Mark

Intersection Station

 

So then, all those type would be added to the drop-down.

 

I did this all but when I go to edit it is not in the drop down window.

 

I will keep working on it.

Link to comment
QUOTE(Papa-Bear-NYC @ May 27 2008, 04:20 PM)

1) Create a text file (use wordpad or notepad) which contains a single line. The content of the line is your custom type. In my case the line contains the text: "NGS Station"

 

Actually, you can have as many types here as you want, each one on its own line. For example:

 

NGS Station

Reference Mark

Azimuth Mark

Intersection Station

 

So then, all those type would be added to the drop-down.

 

I did this all but when I go to edit it is not in the drop down window.

 

I will keep working on it.

Just tried this and my custom type DOES appear in the drop down. My version is 7.2.1.40

 

HOWEVER, when you get the dialog box for the Child waypoints don't click on "Set Type", click on "Edit", and then in the Edit dialog box, you set the type and it works. The "Set Type" in the main dialog box does not work (although the Custom type does appear in the drop down).

 

So there may be 2 issues:

 

1) Maybe custom types don't appear in the drop down for certain versions (they do appear in my version)

2) the "Edit" method works, but "Set Type" does not work.

 

IMPORTANT

 

Make sure you restart GSAK after you add the file with the custom types. Evidently GSAK reads the file in when it starts. Just now I added a few more lines to the file while I had GSAK running, but they did not appear in the drop down. Then I restarted GSAK and all the entries now appear. This is reasonable behavior. The 2 cases above look like bugs.

 

Mike: if you ask Clyde about this on the GSAK forum, please include both these failure modes.

Edited by Papa-Bear-NYC
Link to comment
Mike: if you ask Clyde about this on the GSAK forum, please include both these failure modes.
I will, thanks. Interestingly, I *WAS* using the 'edit' mode - didn't know there was another way! :anibad:

Hold on ...

I played around a bit and I ralize I missunderstood the purpose the "Set Type" button. It looks like this just enables you to set or clear the flag on all Child waypoints of a given type. It seems to do that. So cancel that from my suggestion.

 

The only problem seems to be #1, stuff not showing up in the drop down in certain versions.

 

BTW: what version are you running?

Link to comment
As for any other issues, I think certain ones might be options, like these:

==> Setting the location corrected flag on locations you changed for RMs with their own PIDs

==> Setting DNFs Temporarily Unavailable

I can throw these in. At least, I know I can do the second, I believe that I can do the first too. (Depends on GSAK and its GPX-reading abilities.)

 

==> Setting Destroyed marks DNF instead of Found (already an option). This makes more sense to me, but perhaps not to others
Now, this one I did for a VERY specific reason. Possibly a reason that noone else would ever use it for. (But, hey, it's my program. :unsure:) If you click here, and scroll down to the seciont that reads "Foxtrot_Xray has 4 FNFs (3.92 %)". This feature uses the (unused?) "FTF" flag in GSAK to mark caches that you FOUND when the previous recovery was "Not Found". (i.e. The US Power Squadron couldn't find it back in 1994, but you found it without an issue!). Now, to GET a "FTF", it has to be "Found", of course. :blink:

 

I also wanted to stay away from marking it DNF< since GSAK considers "not searched for" the same as a "DNF". :D

Link to comment

7 2 1.40

The latest version I can get.

 

I tried several things and maybe I am not placing it in the right place.

 

It is in the GSAK but am not sure where the install or what exactly is the install folder.

The main folder has several folders but no install folder.

 

Thanks guys I am slow I told ya.

The file goes in the main GSAK folder. There are sub-folders in there, ignore them and don't create a new folder. Typically the GSAK folder is

 

C:\Program Files\gsak

 

(But on Vista I've heard it may be C:\gsak Note: I run XP, so Vista is a guess)

 

Therefore the file itself is at

 

C:\Program Files\gsak\ChildOther.txt

Link to comment
The file goes in the main GSAK folder. There are sub-folders in there, ignore them and don't create a new folder. Typically the GSAK folder is

 

C:\Program Files\gsak

 

(But on Vista I've heard it may be C:\gsak Note: I run XP, so Vista is a guess)

 

Therefore the file itself is at

 

C:\Program Files\gsak\ChildOther.txt

 

That's where she be but it still don't work for me.

Maybe got something else clicked somewhere.

Link to comment
==> Setting the location corrected flag on locations you changed for RMs with their own PIDs

Alright, I've been working on this, and have made a few conclusions.

 

First off, note that in all previous builds, the coordinates weren't actually getting updated. This is my bad, I simply can't type.

 

Second, there's a problem when we have a 'recursive loop'. For example, if BR1592 has AI6261 as a child, and AI6261 has BR1592 as a child. Obviously, on changing AI6261's coordinates from the one's followed in BR1592's reference, then the AI6261's child BR1592 will be changed. Revert to the beginning of this paragraph. Loop until infinity. :wub: Right now - and in the past, even though it hasn't been updated in the GPS file - the program was NOT going back. So in AI came before BR, then BR would be changed but its children would not be. BR's child would then update AI. Then move on.

 

Thirdly, GSAK only has decimal places out to 0.000001 degrees. Running the entire state of GA through, and less than 10% of the marks that had children that could be updated had a difference greater than that. I'm keeping the feature in, but.. it may not be as noticeable as folks think. :rolleyes:

 

Mike.

Link to comment
==> Setting the location corrected flag on locations you changed for RMs with their own PIDs

Alright, I've been working on this, and have made a few conclusions.

...

 

Thirdly, GSAK only has decimal places out to 0.000001 degrees. Running the entire state of GA through, and less than 10% of the marks that had children that could be updated had a difference greater than that. I'm keeping the feature in, but.. it may not be as noticeable as folks think. :rolleyes:

 

Mike.

I'm betting this is because most of those children with separate PIDs are horizontal control stations (i.e. have adjusted coordinates) so the locations are same either way you get there to 6 decimals places of a degree..

 

So here's a procedure that might save a lot of trouble and time:

 

> compute coordinates for child

> check if child has separate PID

> if separate PID, check type of location

> if separate PID location = adjusted then Do nothing.

> if sepatate PID location = scaled then 1) update the separate PID location using the Child location and 2) set location corrected flag

 

The essence of this is, you are only fixing scaled coordinates, and in the cases I've looked at that's a HUGE help, such as PALISADES (KU3890) which has 2 RMs with separate PIDs - PALISADES RM1 (KU1644) and PALISADES RM2 (KU1645). These have scaled locations on the wrong side of the George Washington Bridge! (Ask Harry Dolphin!). Here (and similar cases) your correction would be a BIG help.

Edited by Papa-Bear-NYC
Link to comment

Reference Marks in the box score with separate PIDs

 

Mike

 

We've discussed a few things about reference marks (from the box score) and what to do if the mark has it's own separate PID. On this subject, I have a few questions:

 

1) How do you know if a mark has it's own PID?

2) Is there some way to reliably tell from the ID itself (like the range of values for the two alphabetic characters) if the ID given in the box score is a PID or just some kind of database place holder ID?

3) What do you do if there is no ID given in the box score for a particular mark, or does that never happen? If it happens what does the child waypoint get as an id?

4) What if it has a real PID but in a different county, or otherwise not in the file of datasheets you are processing?

 

The reason I'd like to know, is that I treat reference marks with real PIDs differently (basically I provide a link to the other station represented by the PID).

Link to comment
1) How do you know if a mark has it's own PID?

If you watch the status window, after it "Processes the file", it'll say that it's updating reference marks. At this point, the program checks each child of each station for a matching PID station. This is done after everything else, so that all records in your file can be searched. :grin:

 

2) Is there some way to reliably tell from the ID itself (like the range of values for the two alphabetic characters) if the ID given in the box score is a PID or just some kind of database place holder ID?
No. At least, not that I can tell. Here in GA, all real mark have a PID that's similar to others in the area. (i.e. EE0100 may have a valid child EE0001. Of course, the airport marks in my area start with AB...., so that a valid mark may also be AB1234.) Bad reference points (by 'bad' I mean reference points that aren't listed in the NGS database around here start with "CQ". But in Colorado, they start with another code.

 

3) What do you do if there is no ID given in the box score for a particular mark, or does that never happen? If it happens what does the child waypoint get as an id?
This one's easy - I ignore it. GSAK has to have a unique 'code' for each mark, and each child mark. Without this, GSAK will ignore it. So, if there's nothing listed, I ignore it. :grin:

 

4) What if it has a real PID but in a different county, or otherwise not in the file of datasheets you are processing?
Nothing. The child won't get updated, since the program has no record of that mark. (Unfortunately, I don't have access directly to the GSAK database..)

 

The reason I'd like to know, is that I treat reference marks with real PIDs differently (basically I provide a link to the other station represented by the PID).
Unless I misunderstood (quite a possibility!) what you're saying, the program pretty much does this. If there's no stsation with the PID that matches the child, nothing is done. If there is, it'll change the link for the child to either the online datasheet, or the GSAK database entry.

 

If you're worried about missing cross-county children, it shouldn't be too hard to make a macro that will update the URL for any existing mark..

Link to comment

Thanks for all your replies. It seems like a good implementation. But there is one issue for me:

 

3) What do you do if there is no ID given in the box score for a particular mark, or does that never happen? If it happens what does the child waypoint get as an id?
This one's easy - I ignore it. GSAK has to have a unique 'code' for each mark, and each child mark. Without this, GSAK will ignore it. So, if there's nothing listed, I ignore it. :grin:

The reason ignoring these is an issue, is because I want to search for all the reference marks for a given station (at least in principal - sometimes time or difficulty make this goal unrealistic.) Sometimes these marks without codes are important RMs for the main mark. Since I use the data you provide and the infrastructure GSAK provides as a means to display these RMs on a map, it becomes an invaluable aid in recovery. Before your procedure came along, I would spend long hours using the FORWARD program to calculate the positions of these reference marks.

 

Perhaps you could provide a made-up code for these. Since I think GSAK codes are 8-10 characters (?? anyone know?) and NGS are 6, you could add a couple of characters after the NGS code. For example if NGS station AB1234 had 2 RMs without codes, you might give them made up codes such as AB123401 and AB123402. Maybe make this optional if you think it's unaesthetic.

 

In areas I've done my hunting (the northeast) the "dummy" codes trend to NOT have the same prefix as the real codes. Here's an example, here's the box score for LX4113 BUTTERMILK

 LX4113|---------------------------------------------------------------------|
LX4113| PID	Reference Object					 Distance	  Geod. Az  |
LX4113|														   dddmmss.s |
LX4113| LX4061 VALHALLA WATER DIST OLD TANK		APPROX. 3.6 KM 1061708.1 |
LX4113| CB3705 BUTTERMILK RM 1					   8.500 METERS 12938	 |
LX4113| LX4062 NORTH WHITE PLAINS STANDPIPE		APPROX. 6.3 KM 1460329.7 |
LX4113| LX4078 SQUAT TANK						  APPROX. 4.4 KM 1644746.0 |
LX4113| LX4058 BLACK TANK IN TREES				 APPROX.12.4 KM 2035111.7 |
LX4113| CB3704 BUTTERMILK AZ MK								   2240644.5 |
LX4113| CB3706 BUTTERMILK RM 2					  14.708 METERS 22411	 |
LX4113| CB3707 BUTTERMILK RM 3					  14.935 METERS 29346	 |
LX4113| LX4006 BLITHDALE HOME CHILDREN TWR		 APPROX. 2.9 KM 3061347.1 |
LX4113| LX4009 BRIARCLIFF LODGE TANK			   APPROX. 4.8 KM 3290750.1 |
LX4113| LX4005 MARYKNOLL SEM CONV CUP CROSS		APPROX. 7.9 KM 3473446.8 |
LX4113|---------------------------------------------------------------------|

 

The RMs and AZ mark have codes beginning with "CB". The "real" stations in this area start with "LX". My mapping application (at the moment) simple checks the first 2 characters of the Child Code. If it's the same as the station, it decides it's a real PID and puts in links (to NGS and GC web sites). So far that seems to work for all those I've checked. Maybe it would not work in some areas. All the ones that look like PIDs are in the NGS database, although some of them have "Non published" datasheets.

 

Thanks for the tip about Clyde's latest patch. I'll check it out.

Edit: I just installed the new patch. It seems to do the job. Thanks again for everything (and thanks Clyde, in absentia)

Edited by Papa-Bear-NYC
Link to comment

If you don't keep up, Clyde has officially announced a few plans for GSAK. One major one of which will affect users of this program, the new County field.

 

If you use the feature to put the "County" in the "Country" field, do NOT use the macro function "GetCounty" to insert the county name into the User or User2 field, and do NOT use the "GetCountry" to update the country field. Once support for the new field is in, my program will begin using the county field, and I'll supply folks with a macro to update their database fields automagically.

 

Cheers,

Mike.

Link to comment

Wow. Just found your app after spending many hours in the past cut and pasting datasheet info into GSAK after downloading .loc files! Thanks so much for creating this. So far I have run into a few small issues, but nothing major. Am happy to have found this to load up those stations in GSAK and Locus so I can get out there and attempt to find them.

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...