Does anyone have the parameters handy for creating a NAD83(CONUS) datum in TBC? I’m working with a surveyor to create drone data in EPSG 2965, which doesn’t match NAD83(2011) coordinates…
PROJCRS[“NAD83 / Indiana East (ftUS)”,
BASEGEOGCRS[“NAD83”,
DATUM[“North American Datum 1983”,
ELLIPSOID[“GRS 1980”,6378137,298.257222101,
LENGTHUNIT[“metre”,1]]],
PRIMEM[“Greenwich”,0,
ANGLEUNIT[“degree”,0.0174532925199433]],
ID[“EPSG”,4269]],
CONVERSION[“SPCS83 Indiana East zone (US survey foot)”,
METHOD[“Transverse Mercator”,
ID[“EPSG”,9807]],
PARAMETER[“Latitude of natural origin”,37.5,
ANGLEUNIT[“degree”,0.0174532925199433],
ID[“EPSG”,8801]],
PARAMETER[“Longitude of natural origin”,-85.6666666666667,
ANGLEUNIT[“degree”,0.0174532925199433],
ID[“EPSG”,8802]],
PARAMETER[“Scale factor at natural origin”,0.999966667,
SCALEUNIT[“unity”,1],
ID[“EPSG”,8805]],
PARAMETER[“False easting”,328083.333,
LENGTHUNIT[“US survey foot”,0.304800609601219],
ID[“EPSG”,8806]],
PARAMETER[“False northing”,820208.333,
LENGTHUNIT[“US survey foot”,0.304800609601219],
ID[“EPSG”,8807]]],
CS[Cartesian,2],
AXIS[“easting (X)”,east,
ORDER[1],
LENGTHUNIT[“US survey foot”,0.304800609601219]],
AXIS[“northing (Y)”,north,
ORDER[2],
LENGTHUNIT[“US survey foot”,0.304800609601219]],
USAGE[
SCOPE[“Engineering survey, topographic mapping.”],
AREA[“United States (USA) - Indiana - counties of Adams; Allen; Bartholomew; Blackford; Brown; Cass; Clark; De Kalb; Dearborn; Decatur; Delaware; Elkhart; Fayette; Floyd; Franklin; Fulton; Grant; Hamilton; Hancock; Harrison; Henry; Howard; Huntington; Jackson; Jay; Jefferson; Jennings; Johnson; Kosciusko; Lagrange; Madison; Marion; Marshall; Miami; Noble; Ohio; Randolph; Ripley; Rush; Scott; Shelby; St Joseph; Steuben; Switzerland; Tipton; Union; Wabash; Washington; Wayne; Wells; Whitley.”],
BBOX[37.95,-86.59,41.77,-84.78]],
ID[“EPSG”,2965]]
Is this what you wanted?
You can always type in EPSG 2965 at Google Search and it will find the definition for you - you can create a Coordinate System in Coordinate System Manager that has these parameters
Alan
The parameters for EPSG 2965 seem to be the same as those in TBC for Indiana East / NAD83 / 2011 so I am not sure that they will make any difference in the outputs.
I would check your units US Feet vs International Feet
Alan
I agree that the parameters for EPSG 2965 seems to match Indiana East / NAD83(2011), or EPSG 6459. However, there is a known datum shift between NAD83(CONUS) and NAD83(2011). When I export the NAD83(2011) images from TBC and insert into Civil 3D on EPSG 2965, I’m seeing a discrepancy of a couple feet. When I use QGIS to do a best estimate of converting to 2965, the images correlate with the control points in Civil 3D 2965. But I can’t get the point cloud to convert well and show up nicely in Civil 3D, so I’m wanting to process the drone data based on EPSG 2965, and to do that I need the NAD83(CONUS) datum in the TBC coordinate system database and correct. Perhaps there is a US Feet versus International feet conversion happening behind my back somewhere.
You should be able to use Coordinate System Manager to create a Custom Coordinate System to meet your needs - have you tried that
I had a user yesterday saying that Images that matched control in TBC did not match up in C3D and they were off by ~1 to 2 feet, that was probably this issue - I am waiting for the data so I can poke around a bit to see if I can find the problem - I suggested that he do a full check that the Coordinate System being used in TBC 100% matched the Coordinate System selected in C3D because that was the most likely source of the issue as the Orthophoto stores the coordinate system in its header records, and is read by C3D to place the image correctly, if the coordinate systems don’t match, that will cause the shift of the data in C3D.
Would be good to get to the bottom of this issue
Point clouds will have similar issues I am sure as we have had to work around a number of TBC issues when we export and re import Point Cloud data in e.g. Point Cloud Processor because it gets shifted / scaled incorrectly by TBC standard importers, so we have to apply a reverse shift / scale on output to get it to import correctly - I saw that TBC’s attempted copy of Point Cloud Processor fell into the same hole itself so hopefully they may now fix that! Going out of TBC into C3D for Point Clouds could present new issues also
Key is to keep it all in TBC (yes I know that is not realistic but we can all dream …)
Alan
This may not work if a person is looking for the simplicity of processing drone data in TBC, but sending to UASMaster and processing in US Survey Feet was the key to getting usable imagery for Civil 3D.