AI Assistant

Notifications

Clear all

Good Bye CORS96

Summarize Topic

Strictly Surveying

Last Post by gisjoel 3 months ago

19 Posts

12 Users

2 Reactions

1,743 Views

RSS

DeletedUser

(@deleted-user)

Posts: 8340

Free

Topic starter

Translate ▼

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

Posted : July 15, 2012 9:27 pm

Moe Shetty

(@moe-shetty)

Posts: 1430

Free

Translate ▼

pax vobiscum

Posted : July 16, 2012 4:22 am

paul-in-pa

(@paul-in-pa)

Posts: 6034

Free

Translate ▼

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

Posted : July 16, 2012 4:38 am

Kris Morgan

(@kris-morgan)

Posts: 3855

Free

Translate ▼

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.

Posted : July 16, 2012 6:04 am

EFBURKHOLDER

(@efburkholder)

Posts: 124

Member Founder

Translate ▼

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

Posted : July 16, 2012 9:59 am

Norman_Oklahoma

(@norman-oklahoma)

Posts: 8447

Member P&R, Founder

Translate ▼

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.

Posted : July 16, 2012 11:23 am

jhframe

(@jim-frame)

Posts: 7477

Member Founder, Sustainer

Translate ▼

So Where Did My Coordinates Go ? ? ?

Several mm per year is nothing -- we have several cm per year in parts af CA.

Posted : July 16, 2012 11:56 am

gisjoel

(@gisjoel)

Posts: 251

Free

Translate ▼

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.

Posted : May 30, 2026 10:09 am

Norman_Oklahoma

(@norman-oklahoma)

Posts: 8447

Member P&R, Founder

Translate ▼

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

This post was modified 4 months ago by Norman_Oklahoma

Posted : June 1, 2026 11:28 am

mathteacher

(@mathteacher)

Posts: 2262

Member

Translate ▼

Check the superseded data for PID AI0952. Which CORS96 position is the standard?

This post was modified 4 months ago by mathteacher

Posted : June 1, 2026 5:22 pm

MightyMoe

(@mightymoe)

Posts: 10665

Member P&R, Founder

Translate ▼

@mathteacher

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.

Posted : June 3, 2026 8:13 am

mathteacher

(@mathteacher)

Posts: 2262

Member

Translate ▼

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.

nad(83) cors(96) is not an input option.

5:24 PM

Since both NCAT and the web-based version of HTDP omit NAD 83 (CORS 96) as an explicit drop-down option, you have to use the official National Geodetic Survey (NGS) workaround. [1]

According to the official NGS HTDP program architecture, the NGS grouped all old plate-fixed adjustments together under a single mathematical umbrella code. To process your batch file, you must trick the system by using the modern umbrella option while providing your historical collection dates. [1]

The Standard Batch Option: NAD 83 (2011)

When setting up a text-based batch file for the NOAA NGS HTDP Tool, select NAD 83 (2011) as your input reference frame. [1, 2]

Why this works: Internally, the NGS code handles NAD 83 (2011), NAD 83 (NSRS2007), and NAD 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]

Step-by-Step Batch Workflow

To successfully convert a text list of points, structure your parameters using the following layout:

Format Your Text File: Create an ASCII/plain text file (.txt) where each row represents a point, formatted precisely as Latitude, Longitude, Height (e.g., 61.2181, -149.9003, 35.2).
Select Input Parameters:
- Input Reference Frame: NAD 83 (2011)
- Input Epoch/Date: 2005.0 (or your precise decimal collection date) [1, 2]
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]
Run the File Upload: Submit your batch text file to the utility.

The Final Step to NATRF2022

Once HTDP outputs your new batch text file, your coordinates are successfully shifted out of the old plate-fixed system and are safely sitting in ITRF2020 (Epoch 2020.00).

Because NATRF2022 is mathematically co-aligned with ITRF2020, no further transformation is required. You can directly import this output text file back into your GIS platform and define the coordinate system natively as GCS_NATRF2022 with a fixed reference epoch of 2020.00. [1]

If you want to automate this process locally instead of uploading text files to the website, would you like to see how to structure a Python script using the pyproj library to handle this plate-to-global transformation?

Posted : June 3, 2026 4:03 pm

mathteacher

(@mathteacher)

Posts: 2262

Member

Translate ▼

Here's the last bit of that chat with Google AI. Same disclaimer, but note the difference between a datum name ant its mathematical treatment.

So you couldn't convert CORS(96) to NAD86(2011)?

You can absolutely convert CORS 96 to NAD 83 (2011). The limitation isn't that the conversion is impossible; the limitation is simply that the dropdown labels in the NGS tools are named differently than what you might expect. [1, 2, 3]

To clear up any confusion about why the software forces you to pick alternative names, it helps to look at exactly how the National Geodetic Survey (NGS) maps out these transformations:

1. The Realization Name Change

Inside the NGS database engines, NAD 83 (CORS 96) is mathematically grouped into the exact same file bucket as NAD 83 (NSRS2007). [1, 2]

When the NGS ran the massive national readjustment in 2007, they intentionally locked all the CORS 96 station coordinates in place to prevent them from moving.
Because those coordinates were held perfectly fixed, the NGS treats CORS 96 and NSRS2007 as functionally interchangeable. [1, 2]

So, when you use NCAT (NGS Coordinate Conversion and Transformation Tool), you can convert your old CORS 96 data to NAD 83 (2011). You simply choose NAD83 (NSRS2007) as your input box and NAD83 (2011) as your output box. The underlying NADCON 5.0 engine handles the grid transformation perfectly. [1, 2]

2. The Tectonic Multiplier in Alaska

While a standard grid shift works fine in the continental United States, doing a basic CORS 96 to NAD 83 (2011) grid conversion in Alaska is where things break down due to time.

If your tool only does a static grid conversion (shifting from the 2002 snapshot to the 2010 snapshot) without asking you for the specific year your data was collected, it completely skips the real-world crustal drift that happened in between.

How to Execute This Batch Safely

If you want to convert a batch of 2005 Alaskan CORS 96 points over to NAD 83 (2011) while preserving accuracy, you must map your steps to include time:

The Tool: Open the NOAA NGS HTDP Tool.
The Cheat Input: Select NAD 83 (2011) as the input frame, but input your collection date as 2005.0 (or your precise collection decimal date).
The Output Target: Select NAD 83 (2011) as the output frame, but set the output epoch to 2010.0 (the official standard epoch for that datum). [1]

By using the same datum name but different dates, you force the software to apply the Alaska Crustal Velocity Model. It will take your 2005 coordinates and mathematically warp them to where that piece of land sat in 2010.

If you are using Esri ArcGIS Pro instead of the NGS website for your batch files, I can show you how to look for the NADCON 5.0 transformation grids built directly into your geoprocessing tools. Would that workflow be helpful to look at? [1]

AI can make mistakes, so double-check responses

I see. So that's how NGS gets away with fewer input choices. Does NCAT work the same way?

No, NCAT does not work the same way as HTDP. While they are both official NGS tools, they operate under completely opposite programming logics, and understanding the difference is key to avoiding massive transformation errors.

The Contrast: HTDP vs. NCAT

HTDP is a Time-Based Engine: As established, the NOAA NGS HTDP Tool relies entirely on dates. You provide a simplified coordinate frame (like NAD 83 (2011)) and a date (like 2005.0), and HTDP uses its velocity models to calculate the physical movement of the Earth's crust over time. [1, 2]
NCAT is a Static Grid Engine: The NGS Coordinate Conversion and Transformation Tool (NCAT) does not use velocity models or dates for historical adjustments. Instead, it relies strictly on NADCON 5.0, which is a library of pre-calculated, digital "shift grids". [1, 2]

Because NCAT is purely grid-based, it cannot "guess" based on a date. You must select the exact, explicit historical realizations to move step-by-step through time. [1]

How NCAT Groups CORS 96 Behind the Scenes

Inside NCAT, you cannot type in a date to unlock the CORS 96 parameters. Instead, the NGS built the NADCON 5.0 grids by merging CORS 96 into its passive-monument equivalent: NAD 83 (NSRS2007). [1, 2, 3]

When the NGS executed the national 2007 readjustment, they held the coordinates of all active CORS 96 satellite stations perfectly fixed. Because those base anchors never moved, NAD 83 (CORS 96) and NAD 83 (NSRS2007) are identical reference frames. [1, 2]

Therefore, to transform a CORS 96 point using NCAT, you select NSRS2007 as your input frame. [1, 2]

The Ultimate Rule of Thumb for Your Batch File

Because NCAT lacks time-awareness for historical frames, using it for Alaskan data requires extreme caution:

Use HTDP if your coordinates were captured live in the field in 2005 via an active CORS GPS broadcast. HTDP will look at the 2005 date and apply the necessary 3 years of crustal velocity math to account for Alaska's physical movement. [1]
Use NCAT (via NSRS2007) if your coordinates are already stored as static archive values that have already been converted or mathematically locked to the base datum snapshot. [1, 2]

Would you like to see how to format your batch text file so it seamlessly aligns with the NADCON grid names used by NCAT?

yes

To format your batch text file for the NGS Coordinate Conversion and Transformation Tool (NCAT), you must adhere strictly to a specific plain text template. Because NCAT uses the NADCON 5.0 grid library, it relies on strict column positions rather than header names to parse your batch data.

1. The Core Data Layout (ASCII/Plain Text)

Create a plain text file (with a .txt extension) where each row represents a single point. Every line must follow this exact sequence, separated by commas or spaces:

Name/ID, Latitude, Longitude, Ellipsoid_Height

Important Data Entry Rules:

The ID: This can be a text string or a number (up to 30 characters). Do not include commas inside the ID.
Latitude: Must be input as Decimal Degrees (positive numbers for North, e.g., 61.2181).
Longitude: Must be input as Decimal Degrees in West Positive format (this is an NGS convention, meaning a longitude in Alaska must be positive, e.g., 149.9003, not -149.9003). Alternatively, you can use standard negative longitude if you choose the explicit - option on the web interface, but West Positive is safest for raw text uploads.
Height: This is the orthometric height (elevation) or ellipsoid height in meters. If you do not have height data, you must type 0.0.

2. Sample File Content

Here is exactly what your .txt batch file should look like for three sample points in Alaska:

text

Point_001, 61.21806, 149.90028, 35.24
Point_002, 64.83778, 147.71639, 137.50
Point_003, 58.30194, 134.41972, 12.11

Use code with caution.

3. Setting Up the Web Interface Options

When you navigate to the NGS NCAT Batch Upload page, you must select the specific grid configurations that map your "proxy" CORS 96 data to your modern target system:

Input Datum (Source): Choose NAD83(NSRS2007) (This acts as your mathematical stand-in for CORS 96).
Output Datum (Target): Choose NATRF2022 (or NAD83(2011) if you are stepping through that first).
Input Units: Select Decimal Degrees.
Output Units: Select your preferred visualization format (Decimal Degrees or State Plane meters).

4. What NCAT Outputs to You

Once you submit the file, NCAT will process the batch line-by-line and download a new text file back to your machine. The output file will cleanly append new columns to the end of your original rows containing your newly transformed coordinates.

If you are dealing with a massive dataset, would you like to see a Python code snippet using the requests library to automate uploading this file directly to the NGS servers? Or would you prefer to look at how to handle the orthometric vs. ellipsoidal height settings in the batch utility?

You said: But NATRF requires a date.

You have pointed out the exact paradox that makes mixing these tools so tricky. Yes, NATRF2022 absolutely requires a date to be fully accurate. [1]

NCAT behaves differently because it applies a master assumption when dealing with the new modernized reference frames. [1]

The Secret: The Master Default Epoch (2020.00)

When you ask NCAT to output to a modernized frame like NATRF2022, the tool bypasses asking you for a custom target date. Instead, it hardcodes the destination to the official master baseline set by the National Geodetic Survey (NGS): January 1, 2020 (Epoch 2020.00). [1, 2]

Because NCAT is a static grid engine, it does not calculate live velocity over custom years like HTDP does. Instead, the underlying NADCON 5.0 grids inside NCAT were pre-computed by the NGS to strictly map coordinates from the old system straight to that fixed 2020.00 snapshot. [1, 2]

Why This is Dangerous for Your 2005 Alaska Data

Because NCAT forces everything to a single static translation, using it blindly on your batch file will cause a major error in Alaska:

You feed a coordinate collected in 2005 into NCAT as NAD83 (NSRS2007).
NCAT assumes that coordinate represents the static datum position.
NCAT applies the static NADCON grid to shift it into NATRF2022 (Epoch 2020.00).
The Error: Because NCAT doesn't know the field data was actually captured in 2005, it completely misses the 3 years of heavy crustal movement that happened between the CORS 96 base epoch (2002.00) and your actual field collection day (2005.00). [1]

The Correct Batch Strategy for Time-Dependent Frames

If you want to respect the dynamic nature of NATRF2022 and your 2005 metadata, do not use NCAT for the primary shift. Use the NOAA NGS HTDP Tool instead. [1]

HTDP treats dates as a mandatory input parameter.
When formatting your batch file for HTDP, you explicitly declare the input epoch as 2005.0 and your target output frame as ITRF2020 at epoch 2020.0.
Because NATRF2022 is mathematically anchored directly to ITRF2020 at that exact 2020.00 snapshot, the output coordinates HTDP generates for you are perfectly valid NATRF2022 numbers, with the 3 years of missing Alaskan tectonic drift perfectly accounted for. [1, 2, 3]

Are you planning to run this batch file directly through the NGS web portals, or are you looking to execute this via a desktop GIS platform where you can control the transformation parameters manually?

Posted : June 3, 2026 7:19 pm

john-putnam

(@john-putnam)

Posts: 2463

Member Founder, Sustainer

Translate ▼

@mathteacher

Okay, you got my ADHD going on this one.

First, NAD83(CORS96) was used only for CORS stations. Passive marks of the time were tied to the original HARNs for the area. Here in Oregon that was initially NAD83(91) and later NAD(98). NAD(2007) was the first attempt to align the CORS and passive marks.

As for AI0952 (and any other of its contemporary CORS) the superseded NAD(CORS) are the 'CORS96' values. In this example there were four different epoch presumably due to crustal movement. I just dug up an OPUS output from a 2002 job that calls out NAD83(CORS96)(EPOCH:2002.0000) while a CORS data sheet circa 2003 just references NAD83(CORS)[Epoch 2002.0].

Thanks, it was fun unarchiving 20+ year old projects.

Posted : June 3, 2026 7:41 pm

mathteacher

(@mathteacher)

Posts: 2262

Member

Translate ▼

@john-putnam

Great fun for me, too. According to Google AI, which doesn't have ADHD but does hallucinate every now and then, 2007 and 2011 are key years for fudging software.

There's great fun ahead don't you think?

Posted : June 3, 2026 7:54 pm

mathteacher

(@mathteacher)

Posts: 2262

Member

Translate ▼

Last one, I promise, but I just had to ask, perhaps from misinterpreting @john-putnam on the use of CORS)96).Those of us who live in ultra stable geological areas can be thankful for the problems we don't have. But this AI answer highlights so well how "solutions" for one audience create problems for another and ultimately for both. Territory, basic principles, and how software can either enhance or upset the work are becoming ever more important.

Was CORS(96) by the mapping community in Alaska?

Yes, the mapping and surveying community in Alaska absolutely used NAD 83 (CORS 96), but it was adopted with an intense degree of frustration, unique local workarounds, and ultimately structural failure due to tectonic realities.

National Geodetic Survey (NGS) (.gov) +1

Because Alaska is geodetically remote and physically dynamic, the introduction of CORS 96 fundamentally split the local mapping community into two camps: early-adopting GIS professionals and resistant traditional surveyors.

University of Alaska Fairbanks

1. The Power User: GIS and Federal Land Agencies

For federal agencies managing Alaska’s massive public lands—such as the Bureau of Land Management (BLM), the National Park Service, and academic researchers—CORS 96 was a major breakthrough.

University of Alaska Fairbanks +1

The Remote Asset Fix: Prior to CORS 96, finding physical brass survey monuments in the Alaskan bush was nearly impossible, and many had shifted due to earthquakes or frost heave.
USACE Publications (.mil)
The New Gold Standard: In 2007, an alliance of Alaskan geodetic experts formally published the Alaska GPS Best Practices Guide. This document explicitly commanded the mapping community to stop using old WGS 84 or NAD 27 baselines, designating NAD 83 (CORS96) Epoch 2002.0 as the absolute target requirement for high-accuracy GIS work in the state.
University of Alaska Fairbanks

2. The Practical Failure for Local Land Surveyors

While regional map-makers loved it, local private surveyors executing property, boundary, and construction surveys found CORS 96 to be highly problematic.

The Local Mismatch: A local surveyor's job is to ensure that a fence line matches a legal deed. Because the CORS 96 network was locked to an arbitrary 2002.00 snapshot, surveyors who downloaded live CORS base data in 2008 found that their GPS equipment calculated coordinates that were significantly offset from the actual, physical brass monuments stamped into the concrete blocks down the street.
The Denali Earthquake Disruption: The fragile truce between CORS 96 and the real world completely fractured on November 3, 2002, when the M7.9 Denali Fault Earthquake ripped across interior Alaska. The earthquake physically shifted entire mountainsides and highways by up to 5 meters (16 feet) instantly.
The System Rupture: Because the CORS 96 mathematical datum was a static "frozen" model, it had no mechanism to update for a massive localized rupture. Overnight, the official CORS 96 coordinates for stations across interior Alaska were mapping points inside rivers or entirely wrong hillsides compared to real-world ground truth.
ResearchGate

3. The Rejection and the Force-Correction

Because of the Denali earthquake and relentless plate motion, the Alaskan surveying community heavily pressured the National Geodetic Survey (NGS) for relief.

National Geodetic Survey (NGS) (.gov)

The NGS was forced to create a localized exception just for them. When the NGS executed the National Readjustment of 2007, they held the continental US stable plate fixed at epoch 2002.0, but intentionally accelerated Alaska's reference snapshot forward to Epoch 2007.00 to clean up the post-earthquake mess.

National Geodetic Survey (NGS) (.gov)

Ultimately, the mapping community used CORS 96 because they had to, but the severe mathematical warping it caused over time directly forced the NGS to abandon the "static plate" philosophy—leading directly to the invention of the dynamic, time-aware NATRF2022 system used today.

NJ.gov +1

If you are digging into legacy records from this era, let me know:

Are you dealing with data that falls before or after the 2002 Denali Earthquake?
Are you trying to reconcile civil engineering designs (like a road or runway layout) with modern satellite maps?

I can help you pinpoint exactly where these historical tectonic distortions are hidden in your map layers.

Posted : June 4, 2026 5:18 am

john-putnam

(@john-putnam)

Posts: 2463

Member Founder, Sustainer

Translate ▼

My comment on passive marks not being referenced to NAD83(CORS96) refers only to marks in the NSRS. NGS did not publish, to my knowledge, any passive marks on the CORS96 realization. That does not mean that no passive marks were set this way. Any time someone set control based on OPUS or post processed ties to NGS CORS those marks would have been on CORS96. I set hundreds of passive marks on CORS96, they just were not blue booked and included in the NSRS.

I can see why CORS96 was the gold standard in AK given the sparsity of passive marks in the NSRS. But as an example, NSRS mark 'MSB GPS 4' (T4664) does not include superseded coordinates for NAD83(CORS96) while it does for NAD83(92), NAD83(2007) & NAD83(2011).

Posted : June 4, 2026 8:14 am

jbond

(@jbond)

Posts: 3

Free

Translate ▼

@gisjoel

"PS: Assume for example the statewide CORS-based control mentioned above is precise
enough to warrant special handling."

My guess is no.

You want to adjust data collected with "sub-meter" accuracy with the underlying reference frame being CORS(1996). Were all base stations always using a consistent CORS(1996) coordinate or not? Just as someone who went through that period things were changing every couple of years at least in my neighborhood (lower 48). They were changing for cm-level work, maybe not as quickly for sub-meter.

The change mattered at the cm level, not so much at the "sub-meter" level. I'd say you are over-thinking things. Sure you could use software like HTDP to add in corrections like from earthquakes, but how often would that be the biggest error when "sub-meter" in somewhat less than ideal GPS conditions could be 2 or 3 meters.

Whatever correction methods that are created by NGS are probably fine. Could you theoretically do better if you knew exactly what the base station coordinates were for given time frames? Probably. For example in a remote area I work in NGS
software transformations suggest an accuracy of ~ 2 cm where it's really more like 5 cm based on real data. Just doesn't matter for "sub-meter" data.

Posted : June 4, 2026 10:07 pm

gisjoel

(@gisjoel)

Posts: 251

Free

Translate ▼

Hello,

Thanks to the responses @mathteacher @john-putnam @mightymoe @jbond and I can't but say again what a reservoir of input this forum brings to this question. I absolutely agree jbond, my mapping methodology, and solutions from broadcasted NAD83(CORS96) at that time are not at 5cm, but solidly submeter, and not "NAD83 (1986)". ESRI and other vendors respond to data assigned "NAD83" hence the definition of geospatial data (i.e. a PRJ file sitting alongside a "shapefile" carries with it the information software will promote a "best guess". Today, defining the data alongside with sidecar metadata is going to drive us to do as little harm transforming data if we can't re-observe. Back in the day we used "differential correction", now called PPK to hold 1 to 3 CORS solutions, and its clearly shown (thanks mathteacher), its a sliding scale of epochs during the years between late 90's and thru mid to late 2000's.

Key is for us to stay away from "NAD83" first version (1986) in certain cases, which are a bulk of GIS datasets derived from CORS stations here in AK either broadcasted or post processed holding CORS at one of the 4 Epochs. Melita Kennedy and ESRI presentations reference the time slider of "NAD83" reference frames (8 I believe), so I'm confident I'm good enough sticking with ESRI and getting datasets (not just one point, but say a trail dataset (centerline, 50 miles) and get it defined for the drift of the future.

Like John Putnman replied I also have "unarchived" data (he calls it "fun"), but the software at the time, Trimble's PFO left key metadata behind and I can directly read the reference position held at that time of processing. METADATA like that is going to save our butts, and likely the easy button will be to take the center time frame of a project dataset covering say 2, 3 epochs and transform. Its weak, and sadly I have to jump thru multiple IT hoops to get Pathfinder office installed, but thats going to be my "kit glove" approach, otherwise like jbond said, the NGS tools if needed are fine in my mapping case described above. I've never presumed better than a softball in 2 D in the best of conditions with our data.

Along that line, it also makes me think our statewide mapping inititave tied to control holding at least 2 epochs of CORS96 (it took 10 years to complete our DEM/Imagery) is likely easiest to handle again, a "mid epoch" of CORS96 and if needed extract and transform data if needed. the trick of course is NAVD88 and Geoid09 used at that time. So few GIS folks I know are even using that statewide dataset, with all the enhanced methods in last 15 years (small to large LIDAR) and structure from motion DSM's using crewed and UAV's tied to GCP's and NAD83(2011).

AI response (thanks @mathteacher) reads eerily just like our Alaska Survey and Mapping Conferences in the 2000's. I was fortunate enough to lead a panel of surveyors one of those years on the topic of "Getting off of NAD27" and later with Michael Dennis and twice having Dave Doyle present. We have an incredible suite of surveyors up here and will continue to learn from them and all of you.

Thanks. PS: Subject may be needing a change to "Hello again CORS96!"

Posted : June 7, 2026 11:18 am