Nad27 to nad83 ncat

How much is a lot?

@bill93 about a 3ft. Only in easting. It could be a glitch on my end tbc lost connection to server so i am hoping when it gets working again its solved. Surely its not on ngs ncat side.

This happened to me about two years ago.  Same scenario.  At that time, the nadcon conversion in TBC was still the "old style" pre ncat (still the case as far as I know).  There was no way (that I could find) to have TBC do an NCAT conversion.  It is not merely a matter of having TBC point at the newer interpolation files--the interpolation type itself is fundamentally different.  

But bottom line, the difference between NCAT and "classic" nadcon conversions wasn't just a systematic shift--the differences were variable (this was over a 9 mile long project corridor).

In my case, it was important to honor the old NAD27 values, so I scrapped any ncat involvement and just used the "classic" nadcon conversions.  This is what is canned in TBC, in Trimble Access, and  available using legacy Corpscon utilities, and probably still somewhere on the NGS website.

@frozennorth gotcha i just received a email saying tbc has a coordinate system update.   That supposed to solve this we will see. I will try. Only issue i see is nadcon will not convert to latest realization of nad83 2011. So its going to be off a little as well. Ncat from ngs can output all and i have checked different outputs like nad83 harn nad 83 cors etc and nad83 2011 not the feet i am seeing in the easting of tbc. I assume if i set my base up on the monument and have Trimble Access set up in nad27 and use that do a one point vertical shift for ngvd29 i might be ok never used nad27 in Trimble access or tbc. Before. Or even traversed in Trimble Access on grid with nad27.  I have traversed a lot on nad27 but it was all hand comps using clark1866 and tables to reduce the ground to grid.  How would you approach. Gos rtk will save a lot of time if i can make it work

Staying in NAD27 (meaning set TBC and your controller to NAD27) would be an option if it is a horizontal-only job.  Reason I say that is I'm not sure how well the Geoid files will mesh with a NAD27 setting since they are expecting a NAD83 datum.

Alternative to that, if you want your day-to-day to be in NAD83, I would just convert control from  NAD27 to NAD83 using TBC Nadcon and check it using Corpscon or legacy Nadcon.  It sounds like you're starting and ending with NAD27, so you don't really care about being gnat's a$$ to the datum realization of NAD83.  You're just using NAD83 as an intermediate datum of convenience for RTK.

@frozennorth that’s exactly what it is. I have to hold there monument anyway so if this upgrade doesn’t work i will just do like you say i could even do a translate rotate and vertical shift as i do need elevation but they don’t know which vertical datum they are on lol. I assume its ngvd29 but who knows. I have never seen so many mix and match than here in this state all over. I need gos survey and build my own geoid model lol

All i just upgraded the TBC 5.81 new coordinates system manager because of this. I now match ncat via ngs within the error of what ngs sais so this site is around a tenth northing and easting on high side. I output the estimates from ngs ncat and all my points seem fine. Well i am not feet off now. 

We've run into this fairly recently too, and my suspicion is there have been some changes to NCAT in recent years that I'm not sure TBC has been able to incorporate, mainly due to the fact that TBC (like most post-processing programs) does not convert between different flavors of NAD83 on the fly, whereas NCAT will apply the cumulative shifts from a particular NAD83 realization all the way back down to NAD27.

As a result there's always going to be a discrepancy between the two.

The best (recommended) method is to observe all control and come up with a custom (local) transformation to lock everything down without relying upon the approximate shift that NCAT gives you.

However, if that is not an option, I would run the entire project in NAD83, process all your points in NAD83, then run the final adjusted points through the multipoint conversion utility in NCAT.

Then you can start a TBC project in NAD27, import the converted points (make absolutely sure that if you are importing geodetic NAD27 you choose to import Local NOT Global), process linework as usual and spit out the result.

TBC projects from NAD27 Local to Grid just fine in TBC, but the datum transformation going between NAD83 Global and NAD27 Local is not going to match NCAT.

@frozennorth see my lower post that’s exactly what was going on nadcon and ncat. Tbc was trying to use nadcon but was confused lol.

@rover83 yeppers. Once I updated my tbc today coordinates system manager it’s doing a fine job matching ncat now. I did use the multi ncat tool as i had several points. Now i am all good except for converting the ngvd29 to navd88. But this control is a bit hard to follow as they seem to have a mixture of meters and feet for elevation by my first glance and looking at topo map. Why do people mix datums and units like this. When you see 3 points around something you know is flat and less than 50 feet apart it’s easy to spot but geezers what a mess.

Latest CSM embedded in TBC (since October 22) is a huge enhancement with the control of datum handling.  You could do this for controlling the horizontal shift...

As @Rover83 states "TBC projects from NAD27 Local to Grid just fine in TBC, but the datum transformation going between NAD83 Global and NAD27 Local is not going to match NCAT"

Load NAD27 data as "NAD83", tricking TBC to think the data is plain vanilla NAD83. Maintain Molendensky 'Do nothin' 3 parameter shifter, putting you on NAD27 in the field.  Stay in this lie, keeping NADCON or any of the WGS84 to NAD27 shifters out of the way (which will never match NADCON).  This keeps local = global.  You'll be "in NAD27" throughout this process.

@gisjoel yeah. When I updated the coordinates system manager. And took the grid points nad27 to nad83 2011 grid it solved the issue and matched ncat within the tolerances ncat posts. Prior to updating the most recent coordinates system manager it was off. Unfortunately though after doing further investigation I found that someone else took nad83 2011 values scaled to ground then did the transformation to nad 27. So what i have is an assumed coordinates system that looks like nad 27. Lol. I also spoke with a ngs employee about ncat and making sure i was on track correctly.  Ncat and tbc seem to match now and ncat had no issues doing what i was trying. The issue was on TBC side. And of course on the last user side of how they derived the values. If only the earth was flat we could all get along lol.

3 feet? Check on the US feet, Int'l feet thing before going further. 

TBC didn't calculate the same way as NCAT, but NAD27 is actually monument based. So a NAD27 coordinate system only really works when you're tied into the existing control; if there is any available. 

Conversions from NAD83 to 27 will be off no matter what program you use. 

NEVER use the Molodensky 3-parameter transformations.  These were all computed by the old Defense Mapping Agency (DMA), now the National Geo spatial-Intelliegence Agency (NGA).  In their own publication -- file:///C:/Users/User/Documents/PUBLICATIONS/WGS/NGA-STND-0036-1-0-0-WGS84.pdf on pages 156 & 157 of 207 you can see that they break the lower 48 states into CONUS, East and West and their estimates the 3-D 1 sigma (68% confidence) uncertainty ranges from 6.5 to almost 10 meters!!  Regrettably these estimates never show up in the array of tools that many developers provide.  ALWAYS use NADCON/NCAT from NGS.  This is well defined by a Federal Register Notice from 1990

If it helps I did a short YouTube video on the subject of transformations.

NEVER use the Molodensky 3-parameter transformations.

Joel is using Trimble-speak. "Molodensky" where NAD83 job coordinate systems are concerned = shorthand for null transformation in Trimble-World. Not technically correct but functionally correct.

@base9geodesy yeppers. One of the very reasons i used ncat as a check before proceeding on. I know all about the 3 parameters issue. I always do a check for anything in usa by using NGS tools.  I know the issues of software developers being behind getting things updated. I truly think the way the new datum is being handled is going to be much better than the past. Now the manufacturers will not have an excuse lol

@norman-oklahoma yes that was my first guess but it was not. It was TBC. I have confirmed that. Ncat proved that. NCAT gives you the error estimates from any transformation. I trust the designer's of both datums more for transformations vs off the shelf software. So any time I even go from one datum to another i use the ngs tools for those. Outside of conus thats a different story.  But ngs is very solid and if a issue did arise i would rather go to the source.

@mightymoe tbc with new update nailed ncat. It was the older version of tbc coordinate system manager that was bad. They even stated that in the latest coordinates system manager update. It has not been out long at all.