Need Professional for Coordinate System & Datum Understanding (CO83-CF vs. NSPS11.COCF)

[CodeDing]

Hey all,

Please review my linked video as it describes my problem in depth and hopefully with clarity:

In Short:

Take the following 2 coordinate systems and their EPSG codes:
- CO83-CF (EPSG: 2232)

- NSRS11.COCF (EPSG: 6428)

Per the definitions of these 2 systems, they utilize 2 different Datums, yet when the same coordinate is provided to each of the 2 coordinate systems in Civil 3D, the SAME Latitude and Longitude is recorded for each point, when per the NGS NCAT tool, we should expect to see 2 different Latitudes / Longitudes.

Any help on understanding this matter further is appreciated.

Best,

~DD

[rl_jackson]

The C083-CF is the original realization of the position on earth, the NSPS11.COCF is the updated realization of the position on earth, based on NSPS11. The NSPS11 datum is 99.99% the datum that should be used, as that is what's being transmitted to your RTK unit.

In simple terms CO83-CF had a error of .1' in northing and .3.' in easting (numbers are not exact) that was corrected under NSPS.

@Pointdump might explain this a little better, but that's my take on it.

[CodeDing]

---

@rl_jackson wrote:

The C083-CF is the original realization of the position on earth, the NSPS11.COCF is the updated realization of the position on earth, based on NSPS11.

---

Yes this is my understanding, and perhaps C3D is not applying the difference in new & old realizations, because when I provide the same coordinate (X & Y) to both reference systems, the same Latitude & Longitude is also returned (which should not be the case given the difference in the updated 2011 realization).

thanks for the quick reply, still hoping to understand if C3D can get this resolved. Might need to send to Autodesk development 😅

[rl_jackson]

So that shift was the entire datum, not just a specific location. It was all locations. What will be interesting is when we move to the new realization of NSPS which incorporates vertical and horizontal adjustment. That could be a mind bender.

i.e. the start position was wrong in NAD83 not the coord or lat long.

[CodeDing]

---

@rl_jackson wrote:

So that shift was the entire datum, not just a specific location. It was all locations.

.....

i.e. the start position was wrong in NAD83 not the coord or lat long.

---

Yes, the entire Datum moved, however, if I understand correctly there was an updated realization and not JUST an origin shift. The realization adjusts the Lats/Longs across the datum. Have you ever used the Rubber Sheet image alignment tool within Raster Design? The realization performed a similar process, adjusting Lats/Longs across the same datum shape.

This is why we can see that when the datums are defined, they use the same datum definition:

EPSG: 6269, North American Datum 1983, OGC WKT:

DATUM["North_American_Datum_1983",
    SPHEROID["GRS 1980",6378137,298.257222101,
        AUTHORITY["EPSG","7019"]],
    AUTHORITY["EPSG","6269"]]

EPSG: 1116, NAD83 (National Spatial Reference System 2011), OGC WKT:

DATUM["NAD83_National_Spatial_Reference_System_2011",
    SPHEROID["GRS 1980",6378137,298.257222101,
        AUTHORITY["EPSG","7019"]],
    AUTHORITY["EPSG","1116"]]

... but since the realizations are different, the lats/longs across the same shape will differ. 

The software implements the realization. So I believe Civil 3D is incorrectly implementing the realization for the NAD83 datum (EPSG: 6269).

This can be verified when you provide a coordinate within the NGS NCAT tool and it will return DIFFERENT Lats / Longs for the 2 different datums (as exampled in my video).

[rl_jackson]

@CodeDing,

I didn't watch the video until just now... Had some stuff going on. Now I have

When the datum in the SDB is set to No Datum/No Projection is not a good idea in this instance. Your data is in NSRS11 so you should report it as such in the SDB, when you do it will report the data in the drawing as I've shown when imported into a drawing in CO-CF.

See the PM I sent if you would like to discuss.

[rl_jackson]

Screenshot of SDB (NSRS11) vs. DWG (CO-CF83).

Note: I would not recommend using C3D to do this conversion as TBC in your instance would be the best solution if you need the data to be in 83 vs. 11

[CodeDing]

@rl_jackson ,

Thank you for the effort put into this.

So with your proposed solution, I pose the question to you of Why should I have to CONVERT my coordinate? That shouldn't be necessary. 

If I provide a Northing/Easting value to a drawing that has EITHER CO83-CF or NSRS11.COCF assigned as a coordinate system. The Correct Lat/Long should be returned for the provided N/E. This Lat/Long should still be DIFFERENT depending on which coordinate system is assigned (even given the same N/E).

Am I wrong? Because when I provide a single coordinate to the NGS NCAT tool, I receive 2 different Lat/Longs for the same coordinate, one for each different datum.

Best,

~DD

[awhiteQ38RQ]

I have the same question

[rl_jackson]

Your data is in NSRS11 but you're not telling C3D the data is in NSRS11 by setting the SDB to No Datum. Therefore, it's just a plain coordinate. You're basically telling C3D you're working at 5000,5000 even though the data in NSRS11. As I showed, the SDB was in NSRS11 and the drawing was in CO-CF83 since C3D knows the system of the SDB it converts the data, to reflect what the drawing is basically doing a transform.

I do not run C3D without the SDB and DWG having a matching coordinate system. This is 2-fold, as I'm trying to make sure that someone else that looks at the SDB instantly knows what system the data was collected in, and that C3D does not apply a conversion as I've shown in the drawing I provided, those conversions are better left for TBC/Infinity since that work with all aspects of the data, from elevation to geoid etc... CAD is still a FLAT (paper) space mimicking a sphere.

EDIT: C3D does not adjust the coordinates in the drawing just because you change the Datum, while that would be nice once it's imported that is where it is.

[CodeDing]

---

@rl_jackson wrote:

 Therefore, it's just a plain coordinate. You're basically telling C3D you're working at 5000,5000

---

Yes, this is my problem with C3D. It should be treating this point as an arbitrary point, but I'm receiving incorrect Lat/Longs.

Follow me:
- I have a single point, defined by X1,Y1 and let's call it Pt1.
(the system doesn't matter... it's an arbitrary point. this is the same as saying I have 2 points, with SAME X/Y values, from different coordinate systems. Now remove system info, and remove duplicate points, I am left with 1 arbitrary point)
- Now I go to Computer1, open C3D, assign NSRS11.COCF, input Pt1. This will provide me with a Lat/Long, let's call it Lat1,Long1.
- Now I go to Computer2, open C3D, assign CO83-CF, input Pt1. This will provide me with a Lat/Long, let's call it Lat2,Long2.
- According to NGS NCAT tool, Lat1,Long1 should NOT equal Lat2,Long2... But in C3D Lat1,Long1 DOES equal Lat2,Long2.

That is my issue

[rl_jackson · Accepted solution]

The coordinate has not changed therefore the LAT LONG has not changed. The difference between the CO-CF83 and NSRS11 are shown in the picture in POST#7 they are indeed different LAT LONG values (very minor). By having the SDB at NONE there is nothing to change you MUST provide the datum of the data to the SDB for it to articulate between the 2 datums. If the datum is set in the SDB (NSRS11) and you import points into a drawing set to NSRS11 then they will be equal to each other. If you import the same data from the database into a drawing set to CO-CF83 then they will be different. The SDB must have the datum assigned for any conversion to any datum other than the source data.

Even you NCAT conversion knows it's in NSRS11 and you want CO-CF83 as your telling it that. Same holds true for the SDB to get the CO-CF83 it must know that its data is NSRS11.

[CodeDing]

@rl_jackson 

I started to see some holes in my interpretation of the differences. Looks like I was making some false equivalencies. Not going to say that I fully understand why this is happening, but it's starting to make more sense. Thank you for indulging me and helping through the process 

Best,

~DD

[Pointdump]

Hi Denon,
Following with interest. I see your point, and nice video by the way.
You should start a support ticket.
Dave