So long NAD83(CORS96)(Epoch 2002.0), it has come time to say good bye as I see you were phased out today, you were a good friend and outstanding in your youth, but 10 coordinate years is a long time, even longer than 10 dog years, so while I am sad to see you go, you lived a nice long productive life but quite frankly have outlived your usefulness, times have changed and so have the positions you were still trying to represent and so we must say good bye, I look forward to working with your successor.
It is with both great sadness and great expectation I bid you farewell.
SHG
pax vobiscum
So Where Did My Coordinates Go ? ? ?
Or more importantly where are they going? And how fast?
I have projects on going since 2002. Now I have to do additional work to keep them tied together.
Paul in PA
This sucks. I guess I'll have to learn how to take the newest reference frame and work it back to the old one just to keep, oh I don't know, 5 of my biggest clients databases working together.
Oh well.
Do right, but don't make it more difficult than it is.
Several points/comments:
1. Fighting progress is a losing battle.
2. Although the magnitude of coordinate shifts is likely quite small in most cases, the fact it, they are different.
3. The saving grace is that, except for ground movements or unstable monuments, the local differences remain unchanged (within some tolerance).
4. If you need the "best" coordinate values in the new system, build your survey on high quality control monuments for which you have reliable new-epoch values.
5. Aside from that, be aware that the global spatial data model (GSDM) provides easy access to coordinate values - both geocentric and local. The ability to work with coordinate differences is a powerful tool for the surveyor - or any spatial data user.
6. In many cases, the coordinate differences (especially geocentric)in one epoch, if not identical, are very close to the coordinate differences in a different epoch.
7. That provides a convenient way to move from one "datum" to another. (With the understanding that the simplistic definition of a dataum change is any time you have different coordinate values for the same undistrubed monument).
8. See http://www.globalcogo.com
So Where Did My Coordinates Go ? ? ?
> Or more importantly where are they going? And how fast?...I have projects on going since 2002. Now I have to do additional work to keep them tied together.
In Shelby's part of the world those monuments have significant velocities- up to several millimeters a year. Positions determined in in 2002 are going to be a bit more complicated to reproduce than a simple OPUS.
So Where Did My Coordinates Go ? ? ?
Several mm per year is nothing -- we have several cm per year in parts af CA.
Resurrecting this thread with JhFrame's last comment 14 years ago. My question is this.
Today as we roll closer to replacing all variants of NAD83 and NAVD88 what transformation (Helmert, 7 parameter) is the "best" to transform to NAD83(2011) so NCAT can in due time move said data to the new reference frame. We in GIS (ESRI based) have discussed with @Melita Kennedy, Linda Foster and asked this question, and it clearly appears CORS96 is what I call a "GHOST" version of NAD83.
Richard Snay/Soler (ret. NGS) did provide 14 parameters for CORS96 (best article describing Transforming WGS 84 (G1150) Coordinates to NAD 83 (CORS96) Coordinates ) while ESRI has baked in 7 parameters. Both are for the version of WGS84 at that time. I get that. But say today, I want to treat with kit gloves the data tied to CORS at that time (CORS was "in" CORS96 for a decade) but NCAT today does not, nor will it have the baked in parameters for transforming thru to NAD)83(2011) or the new Datum.
In a pickle up here in Alaska. Why? Maybe more than anything, our entire state Imagery and DEM (Statewide Mapping Initiative) was tied to control set to CORS96 (again, thats what NGS CORS was in). I also know this since I'm old enough to have used for a decade NDGPS radio broadcast signal from CORS and that transmitted position was in NAD83 (CORS96). Yes, my equipment (Trimble Pro XR) was not dual frequency, but it was a helluva signal USCG broadcasted for years, and thousands of data points were held to this Datum. I encounter CORS96 datum stamped on many survey plats generated during that historic time too. So, at least up here, we Alaskan's are sitting on a ton of very high quality data held to this "ancient" reference frame (and vertical - Geoid09AK).
CORS96 appears to me to be a bit of a "GHOST" datum so maybe a Helmert BACK to ITRF00, live with the time dependency, then translate again thru ITR00 to ITRF08, then to NAD83(2011). Solar/Snay reference the time "1997" the defined epoch for ITRF00. This is where I want to go, and leverage the 14 parameters provided at that epoch. Head starts to spin at this time, so I'll stop.
PS: Assume for example the statewide CORS-based control mentioned above is precise enough to warrant special handling.
At the PLSO Conference in January a rumor circulated that there would be an NATRF Beta rollout in June of this year. It is now June......
Check the superseded data for PID AI0952. Which CORS96 position is the standard?
There is no standard, only a set of observations over time. We don't have 96 locally most all the control is referenced to 80(93) for the first generally recognized "precise" locations, overriding the more crude 83(86) which shifted about 2' to the 93 epoch.
If you want a more concise progression, I'd suggest looking at a HARN monument. CORS will have the inherent issue of "too much" data.
Okay, now, I'm not a surveyor nor a GIS guru. I just do math and research its applications, of which surveying and GIS are vast reservoirs.
On the research side, I asked Google's AI about CORS(96) and transforming coordinates to NATRF1922. It was a long discussion, but here is the bottom line last question and answer.
Take it for what its worth. I assume no responsibility for its accuracy or suitability to solving the problem at hand. I'm just passing it along for consideration, not rote implementation, to anyone interested.
- Why this works: Internally, the NGS code handles
NAD 83 (2011),NAD 83 (NSRS2007), andNAD 83 (CORS 96)using the exact same mathematical plate-fixed parameters. - The Key Factor: The software relies on the input epoch date (which you will set to 2005.0) to determine the behavior of the transformation. Because you input a 2005 date, HTDP bypasses the 2010.0 baseline equations and applies the exact 2005 velocity grids required for a CORS 96 point. [1, 2]
- Format Your Text File: Create an ASCII/plain text file (
.txt) where each row represents a point, formatted precisely asLatitude, Longitude, Height(e.g.,61.2181, -149.9003, 35.2). - Select Input Parameters:
- Select Output Parameters:
- Output Reference Frame:
ITRF2020(This is the true, underlying geocentric parent frame for NATRF2022) - Output Epoch/Date:
2020.0(The mandatory reference epoch for NATRF2022) [1]
- Output Reference Frame:
- Run the File Upload: Submit your batch text file to the utility.
GCS_NATRF2022 with a fixed reference epoch of 2020.00. [1]pyproj library to handle this plate-to-global transformation?