NGS Datasheet Orthometric Height errors

> Am I crazy...
Maybe. How long have you had the feeling that the NGS is persecuting you?;-)

Datasheets are recalculated every time you download them. NGS is adding new data, principally from CORS, to the network daily. And things are moving both horizontally and vertically. It is very possible that datasheets downloaded months apart will show slightly different data. That is why the retrieval date is shown on them.

What is the site's PID?

Yeh, but in this situation the height I saw on Tuesday ~just~ happens to be the same height that was published using the 1995 geoid. That's no coincidence.

The height I entered into TBC on tuesday was XXX.892 meters, today/August that point is XXX.952 meters. The succeeded value using the 1995 geoid is XXX.892. There's no way that's a coincidence.. I noted this discrepancy on Tuesday and talked to my wife about the error (all my elevations are off by over 2 inches!).

I'd prefer not to disclose that, the station is located in a sensitive area.. I'm a bit paranoid to these matters and prefer to stay as anonymous as possible.. client may not like this issue being posted online.

> The height I entered into TBC on tuesday was XXX.892 meters, today/August that point is XXX.952 meters.
Thats more than a slight difference.

If I were you I'd be wishing I'd tied into more than one benchmark.

It seems I used the "right" value back in August so my numbers aren't really wrong.. I consider myself lucky.

Send a note to Mark Eckl ([email protected]) at NGS. He is in charge of the division that overseas adjustments and updates to both the horizontal and vertical control data. He should have someone in the division who could respond to you with exactly what went on.

First, thank you for this suggestion Mr. Doyle, you put me in contact with exactly the right person.

I called Mark and heard back from his team, it turns out there was a publishing error on this station. It has to do with the NGS migration to Oracle database and effected a limited number of stations. Apparently the v8.4 datasheets had the potential to show superseded orthometric values, my station was one of them. I am not an expert on the issue but I can confirm that according to my contact my station was published with an incorrect orthometric height for most of December as well as earlier this year (from 7/15 to 9/19). I would urge others to be cautious and pay close attention to the values they're using.

> ....I would urge others to be cautious and pay close attention to the values they're using.
Words to live by.

> First, thank you for this suggestion Mr. Doyle, you put me in contact with exactly the right person.
>
> I called Mark and heard back from his team, it turns out there was a publishing error on this station. It has to do with the NGS migration to Oracle database and effected a limited number of stations. Apparently the v8.4 datasheets had the potential to show superseded orthometric values, my station was one of them. I am not an expert on the issue but I can confirm that according to my contact my station was published with an incorrect orthometric height for most of December as well as earlier this year (from 7/15 to 9/19). I would urge others to be cautious and pay close attention to the values they're using.

That could explain what happened to HGCSD 58 Reset - PID AW6399. The identifier for this station has been HGCSD 58 RESET since 1999 but in the last couple of months they dropped the HGCSD and called it 58 RESET. Before if you did a search for HGCSD 58 you would get the original station data sheet (HCGSD 58 elev. 9.0') and the reset station (HGCSD 58 RESET elev. 7.82'. Now all you will get is the old HGCSD 58, and need to do a search of 58 RESET to get the new data sheet.

I emailed the NGS and got a reply that seems to indicate to me I didn't explain the situation very well.

This stamping matches the published bench mark stamping statement: " AJ6399_STAMPING: HGCSD 58 RESET 2000 ". I do not see the issue you are reporting. However, I believe what you meant to say is that the stamping does not coincide well with the designation as well as matching the parent bench mark's designation. This actually happens quite often. In this case, "HGCSD" is likely an agency acronym. NGS policy is not to include acronyms in designations. Unfortunately, in this case an acronym was used in the parent mark's designation; so, when the bench mark was reset the acronym was dropped from the designation. This was technically correct, however, in my opinion a mistake. For legacy purposes, the acronym should have been retained. Unfortunately, I can not just go back and add the HGCSD to the designation because once a bench mark is published, users upload this information to their databases. If the designation is changed, this may cause havoc or unseen errors for users. So as a compromise, an alias has been uploaded as "HGCSD 58 RESET". Unfortunately, I now see the "alias" checkbox is no longer available on the datasheet by designation NGS' website. So, I'm cc'ing this email as a bug report to NGS software so they will look into this issue for you. So once this problem is resolved, Mr. Ellis should be able to search and retrieve the reset bench mark datasheet by its alias as well as its designation.... Please also note, a bench mark searches by latitude and longitude are much more reliable

In this case, "HGCSD" is likely an agency acronym. NGS policy is not to include acronyms in designations. Unfortunately, in this case an acronym was used in the parent mark's designation; so, when the bench mark was reset the acronym was dropped from the designation. This was technically correct, however, in my opinion a mistake. For legacy purposes, the acronym should have been retained. Unfortunately, I can not just go back and add the HGCSD to the designation because once a bench mark is published, users upload this information to their databases. If the designation is changed, this may cause havoc or unseen errors for users. So as a compromise, an alias has been uploaded as "HGCSD 58 RESET". Unfortunately, I now see the "alias" checkbox is no longer available on the datasheet by designation NGS' website.

HGCSD
the Harris-Galveston Coastal Subsidence District was created by the 64th Texas Legislature as an underground water conservation district.

http://www.hgsubsidence.org/

http://www.hgsubsidence.org/assets/pdfdocuments/GPSProject.pdf

ftp://helios.tacc.utexas.edu/Projects/Houston_lidar/NGS.pdf

http://www.harriscountyfrm.org/Documents/Report_3.pdf

TSARP – Tropical Allison Recovery Project

I worked a bit on TSARP in 2000.

DDSM:beer:

I was amused to think if they drop the acronym HGCSD the point names would become 1...2...3....4.....etc.

Truncating to small numbers risks mis-identification. I can show you a set of 3 data sheets where somebody did nice job in advance of highway construction, making 5 RESET, 8 RESET, and 12 RESET.

Problem was, 5, 8, and 12 in that county weren't in the NGS data base. The office applied the offset elevations to 5, 8, and 12 in the next county over and the resulting elevations are off more than 100 feet, a fact easily confirmed from the quad sheets.
AA3903
AA3904
AA3905

Unfortunately, my recovery reports reflect a great deal of my ignorance at that time. I noted the discrepancy, but reported the condition as "Good" which the disks physically were, and naively assumed the coordinates on the data sheet were fixed. Now they bear my handheld GPS coords so my comment about coordinates in another county makes no sense. Live and learn. You NEVER assume anything on the data sheet will remain unchanged except (probably) your recovery notes.