Anyone out there (focus on Pennsylvania/Mid-Atlantic States/NE US) using GEOID18? We are still using 12B, but I am wondering if we should make the switch?
Thank-you in advance for your input.
Scott R.
If you are using NAD83(2011)2010.00 ellipsoid heights, you should continue to use hybrid geoid model 12B, as it was designed to mathematically get you from 2010.00 ellipsoid heights to the NAVD88 datum. GEOID18 was created to do the same for the recently released Multi-year CORS Solution 2 (MYCS2) ellipsoid heights.
https://www.ngs.noaa.gov/CORS/coords.shtml
https://beta.ngs.noaa.gov/GEOID/GEOID18/
In some areas, the difference between the 2010.00 ellipsoid height and the MYCS2 ellipsoid height can be significant. In the case of the attached CORS datasheet, it is almost 24 cm.
?ÿ
I really wish that NGS would use a new datum tag for the MYCS2 values, such as NAD83(2019)2010.00 so users realize that the datasheets have been updated.
Looking at the NGS Geoid page, I cannot find a reference to which model is considered ??official.? Both the 12B and 18 values are shown on NGS datasheets.
I note that the tabulation of NGS geoid and deflection models ( https://geodesy.noaa.gov/GEOID/models.shtml) does not include GEOID18. This omission is likely IMO a failure to update that page.
I would use the GEOID18 model as it contains more underlying data and reflects modeling improvements. I also like the tool linked from the data sheet that assesses the model accuracy in the area of interest. The inclusion of both model values on the data sheet allow easy comparison of the magnitude of the difference. As the datasheets note, the display of millimeter level values should not be misinterpreted to mean the values are accurate at that level.?ÿ?ÿ
Looking at the map of differences between GEOID12B and GEOID18 (see SPMPLS??s post for URL), raises some questions in some limited areas.
What??s the deal in the Scranton area? I hope that those in the area will be interested in doing some GPS on BM work in the area. Perhaps those in the surveying program at PSU-WB could take this up as a project?
FWIW, I attach as screen capture:
?ÿ
For the example I provided, the MYCS2 ellipsoid height is 63.467m and the GEOID height is -33.264m. Applying H=h-N yields a NAVD88 orthometric height of 96.731m.
Using the superseded 2010.00 data, we have?ÿ an ellipsoid height of 63.704 meters and a GEOID height of -33.271 meters. Applying H=h-N we get a NAVD88 ortho height of 96.975m. A difference of 0.244cm.
Unlike prior realizations of NAD83, where the orthometric heights on the datasheets did not change, but the ellipsoid heights did change, thus necessitating a new geoid height (new hybrid geoid model) to get from h to H, it appears that the MYCS2 is acknowledging that this CORS has subsided. I will take a look at a CORS that has not subsided, but expect the geoid height for GEOID18 will be very close to the same as it is for 12B.
I just downloaded the datasheet and find many of your issues addressed. See annotated screen capture below:
?ÿ
?ÿ
I am curious why the datasheet for a ground station ( PID:AH1762) my first post in this thread and for PID:DM6183 differ. Perhaps it is because DM6183 is a CORS antenna??ÿ
As SPMPLS notes, it is important to keep aware of the details when dealing with data. As the extract from the datasheet shows, data transformations to ?ÿNAD 83 (2011/PA11/MA11) were performed.
In PA I would say definitely use it. The heights of the CORS in the new adjustment changed very little, so even using GEOID18 with NAD83(2011) epoch 2010.0 coordinates/heights will not introduce any significant error.?ÿ
I would guess that the several pockets of larger change in PA from G12B to G18 were probably because of bad benchmarks in those areas, or lack of benchmarks in the model.?ÿ
If it has been a while since I have used OPUS or downloaded CORS for processing, I make sure to check the Datasheet Changes document. Good information in there, with highlights showing the changes that are made with each update.
More info on the reprocessing for MYCS2 is here. Not only did the NGS re-adjust the CORS network using a lot more data, they made the switch from ITRF2008 to ITRF2014.
Unless you are having to align to previously observed data on a legacy adjustment, the currently displayed coordinates and GEOID18 are the official positions.
This is going to cause some confusion and possibly some discrepancies depending on project location and time span.
Not many people look at the adjustment date on the CORS datasheets:
?ÿ
Am I incorrect in my recollection that the NAVD88 value reported by OPUS and its variants is merely the the ellipsoid height determined from GPS observations and the geoid model value at that point. In other words, the CORS site geoid-ellipsoid separations play no direct role in the determination of the unknown site’s geoid-ellipsoid separation.
What concerns me about the Scranton area is the proximity of both “largish” positive and negative differences between models. It would be nice if resources were available to make observations in the area.
Thanks for the link to the changes document. Good resource. I agree that many are not sufficiently interested in the details of the data shown on datasheets. It is a whole lot easier dealing with well-documented data. I was contacted for help reconciling data spanning multiple years and multiple entities. Most of the data was undocumented; mostly just coordinates for points on widely-separated sites. The money was good but not worth the frustration.
Yes, it is as you assume, the comps are all done in ECEF XYZ in ITRFxx, then transformed to NAD83(2011) epoch 2010.0, and then the geoid separation for the currently used model is applied.
I disagree with the current GPS on benchmarks map they are putting out. They are including any station that has any kind of NAVD88 associated with it, including stations with vertcon transformed vertical angle heights and decimeter level GPS stations. The BIG reason I disagree with this is that a user might dedicate a lot of time (2 four hour sessions) occupying a station that they have on their map but which will add nothing of value to the transformation model.
Example: CLINTON in SW PA (PID KX2006)
Besides the fact that is was destroyed long ago (personal knowledge, it is in an old strip mined area), it only has a vertcon derived NAVD88 height from a NGVD29 vertical angle observation. I don't see how it could possibly add anything of value to the transformation even if it was still there. There are numerous other stations around me with similar issues. In my opinion, they should only be including leveled benchmarks with published 1st or 2nd order NAVD88 elevations. I think the problem is that their overly ambitious quest to get data at 10 km spacings ignores the fact that there are not benchmarks across the country at 10 km spacing.
I have made my concerns known to NGS but I'm not sure they are seeing the issue as I am. It will require a lot of volunteer effort to observe benchmarks in time for 2022, and why waste time with stations that will add nothing to the transformation model.
While I would always argue for more data, I agree that GPS observed on vertical angle heights does not contribute to the hybrid model. I could not find on the NGS site their spreadsheet providing characteristics of points used in the GPS on BM campaign. My recollection is that the spreadsheet provided annotations about many of the points including warning about specific sites. I hope these annotations were used during the modeling process.
When I worked with the Texas Spatial Reference Center at TAMUCC (2005-2008) we initiated a campaign where we tried to obtain GPS observations on benchmarks across the entirety of the state at regular spacing. We required three days of 5.5 hours of observations and basically followed the requirements for an FBN campaign. While we were paying for observations, of the 100 points we budgeted we only had about 60 or so submissions. Not any “free” submissions that I can recall. All meeting requirements eventually made it into the GPS on BM campaign data set.
Without field crews or explicit budgeting the GPS on BM cannot provide the amount and quality of data needed to generate the best possible hybrid model.
The image below captures the levels of participation in the 2018 campaign (from: https://www.ngs.noaa.gov/GPSonBM/archive/2018/ ) Only 45% of desired points were observed.
I certainly agree that leveled marks should be required. I'm uncertain about including 3rd order, but even those are mostly better than those you describe.
A big improvement in filling in some areas would be to allow use of vertically mounted disks.?ÿ They tend to be on quite stable buildings, more so than concrete posts. Vertical disks could be used by allowing leveling to a nearby temporary mark with open sky.?ÿ GPS isn't going to give better than a cm, and one or two turns should transfer within 1 or 2 mm.
I proposed this and it seemed to be unthinkable to NGS.
I recollect projects (not individual submissions like GPSonBM) where offsets from vertically set disks were used. ?ÿ
The NGS Instrumentation and Methodologies has done some work on the subject of transferring heights from vertically set disks. They did explore issues related to the use of digital levels in this activity. The offset work must be documented.?ÿThe notes must be sufficient to clearly show how the work was performed, the equipment used and how standards were satisfied.
I would look at the NGS BM Reset guidelines ( https://geodesy.noaa.gov/PUBS_LIB/Benchmark_4_1_2011.pdf ). ?ÿSee also this observation form: https://geodesy.noaa.gov/heightmod/Leveling/Manuals/Observations_for_Relocation_of_Bench_mark.pdf
Unfortunately, as far as I understand, the GPS on BM program is not set up to assimilate these data. Dealing with non-automated records like leveling offset observations would likely be put in the BM reset queue. ?ÿMy experience is that these observations are treated as ??additional work as required.? In other words, the activity is not assigned to anyone but addressed when either the pile gets too high or someone complains.
As I have been retired for over a decade, things might have changed.
HTH,
?ÿ
?ÿ
A difference of 0.244cm.
Make that a difference of 0.244m, or 24.4cm, or 0.80 feet.
Oops, you are correct. That error certainly muted the dramatic point I was trying to make. Have you looked at the new datasheet for P271? Looks like the MYCS2 ellipsoid height is about 13cm lower than the 2010.00 eh.
Ironically, when I reported the change at P565 as 0.80 feet to Dru Smith during a webinar a couple of months ago, although he didn't mention me by name, he chastised the "submitter" for working in feet. He knew it was me, so he had to give the "surveyor" a little guff for working in "uncleansed" units. I should have stayed in feet in this thread!!!
On the Scranton area in Northeast PA with the opposing geoid heights in mirror image: PennDOT put significant resources into collecting more GPS data on area benchmarks. They worked really well together and with me, had folks from a couple different Districts and their Photogrammetry & Surveys Section (aka Central Office) up there in that area more than once.
The problem was lack of existing benchmarks. Without more GPS on leveled marks, there's not much more that could be done. There was a 2nd Order mark right around the "peaks" of both the positive and negative change areas but ... wait for it ... both had been destroyed.
Or maybe one was just totally overgrown with woods, I can't exactly recall now. I know the easterly mark was gone, and more than once person searched. Nevertheless, the PennDOT folks filled in around the centers with other GPS on BM occupations, but with no BMs to observe the difference between models (18-12B) maintained that funky appearance.
"Props" (whatever that means) to PennDOT for their efforts though.
I was hoping to see involvement from Penn State in general, but didn't see any. It is what it is.
Technically, submission of GPS ties to vertically set BMs is/was acceptable for the GPSonBM program. The problem is this: the only mechanism to ingest the data would be to perform a Benchmark Reset as @GeeOddMike referenced below.
It would work something like this:
1 - set a new permanent BM near the existing vertical disk, IAW the 2011 Reset Procedures documents
2 - follow all observation and submittal requirements also in the 2011 documents
3 - after submission, the "Reset" BM you've set will get a new PID
4 - now go collect your static data on the new mark and submit it to OPUS Shared based on the PID of this "Reset" mark
5 - results are a new GPSonBM tie based on new ("Reset") permanent mark, set near the old vertical one
See the issue? Who the @#$% wants to go set a new mark just to tie a vertical disk to a GPS observation?! No one, because no one has done it.
Sure, there are at least two simpler ways this tie could be achieved, and just as accurate and precise, but the above described way is the only way NGS could ingest all the necessary data.
I hope this clarifies that situation. I know I brought the vertically set issue up multiple times to GPSonBM Team, but there was never time to develop a new process for ingesting data, the bureaucracy of the Government got in the way.
I used one method to convince myself my data on a regular disk was good, by going to a nearby vertically mounted disk, setting the level the line on the diskzdx and setting the ARP 1 mm above the level sight (OPUS doesnt like 0 ARP heights). Results matched well enough.
I used another method in another case where a horizontally mounted disk was too close to a building, by setting the level to the ARP and reading the rod on the disk. (Sure rod zero point was good.) This was a RESET that was way off the data sheet, probably blundered by 1.000 ft, so no good for GPSonBM anyway.