Importing Precision GPS Data

[Anonymous]

First of all, I must say I'm a novice working with GPS data. have solved a lot of my problems just by browsing the vast knowledge from previous posts, but there's still one bug that I can't overcome. I have shapefiles that are using WGS84 projection with GPS points gathered with High-Precision Starfire RTK receiver using the newest WGS84 (G1762) datum. About a 1 suare mile area. Everything works great, importing the shapefiles, but I feel the points should have more accuracy.  Iit seems like when I compare points to real world distances it is off by about +/- 1'. I suspect the WGS84 coordinate systems in AutoCAD compare to the original WGS84.  Is anybody familiar with this?

Thanks.

[CivilFlow]

 Hi-

Try to edit your ACAD UNITs precision and the Civil 3D Drawing Settings\Ambient Settings for Lat Long Precision.  Then reimport you .shp files.

It may just be that there is rounding going on due to truncated significant figures in your default drawing settings.

I hope this helps.

[Anonymous]

Thanks, I checked these settings, the ACAD UNITs precision was at 8 decimal places, and set Lat Long and similar settings to 8.. I reimported and points were at exact same place.  I have also tried using the HARN coordinate system, points imported within 1' of WGS84 but there still looked like some error somewhere. I attached a few snips of important settings. But since me being an amateur, there still might be something else. 

[CivilFlow]

Hi there-

Sorry my thought didn’t help.  I checked your Civil 3D Units\Zone pic and it looked correct.  I would not check that anything in the transformation tab though, as you’re not doing a secondary transformation in your case.  I use this Tab for converting between GRID and Ground coordinates or User defined systems to published coordinate systems.

May I ask...how are you checking the accuracy of the shape files?  You have survey control points or monuments that you have imported into Civil 3D to check against?

[Joe-Bouza]

What’s off xy or z?

What does comparing to real world mean, are you checking this compared to the shp file data?

[Anonymous]

---

@CivilFlow wrote:

Hi there-

Sorry my thought didn’t help.  I checked your Civil 3D Units\Zone pic and it looked correct.  I would not check that anything in the transformation tab though, as you’re not doing a secondary transformation in your case.  I use this Tab for converting between GRID and Ground coordinates or User defined systems to published coordinate systems.

May I ask...how are you checking the accuracy of the shape files?  You have survey control points or monuments that you have imported into Civil 3D to check against?

---

Thanks for the info. Sorry if this gets to long, but I'l try to fill in the details My checking of accuracy may sound a bit clouded but here goes. The drawing is for utility mapping for about a roughly 1 square mile area. The drawing consists of buildings and roads sized and placed with real world measurements and a Google Earth mosaic made with Plex Earth. I have found the mosaic to be near exacting with real world measurements with some exceptions. Also the third-party GPS software is based off of Google Earth. Entering the Lat Long points of two GPS points in Google Earth they show at the exact right place, so I measured the distance between them (about 8500'), then measured the points in Civil 3D and found a 4' difference. I don't have direct access to surveying equipment to check the distance in real world, but could if needed.  Another example would be points near monuments for reference points, also show error. The error progressively increases away from my main control point. The GPS system I use for acquiring points is a RTK farming guidance system with sub inch accuracy, so I have no doubts there. I'm using MAPIMPORT to import the .shp files.  thinking there's a glitch occurring somewhere with the datum or coordinate system as the AutoCad WGS84 datum still looks the original one. 

[Anonymous]

---

@Joe-Bouza wrote:
What’s off xy or z?

What does comparing to real world mean, are you checking this compared to the shp file data?

---

X and Y, I'm really not working with elevation. My area is fairly flat for the most part but that could likely be my problem. My Google Earth Imagery is flat and slopes could  throw that off. But I was hoping working with flat plane would butter that over. I likely don't fully understand how to take elevation in consideration. 

Not sure if I use the right terminology but comparing to real world would mean checking with a tape measure or survey. Checking against the .shp data.

[CivilFlow · Accepted solution]

Thanks for providing the additional information.  It sounds like you have a handle on your RTk-GPS Survey equipment tolerance.  You’re correct that your RTK-GPS is referencing a correction source that is most likely using the latest WGS84 Datum.  It is hard to pin point which realization of WGS 84 Civil 3D uses, so I would try to format your .shp data to UTM Northing Easting coordinates prior to bringing into Civil 3D to take Civil 3D out of the equation when applying the UTM mapping projection (if Civil 3D has an older version of WGS 84).

Also with regard to your overall Site size and the 8500 foot distance measurement check you mentioned.  Distances measured in Civil 3D will be “GRID” distances not “GROUND” distances.  Google Earth distance inquiries are “ellipsoidal” distances (which factor in the curve of the WGS84 ellipsoid)...these aren’t technically ground distances either.  Knowing how to work with Grid, Ground, and Ellipsoidal distances is part of the Professional Surveying craft and depends on lots of factors (e.g., where you’re at relative to the mapping projection Standard Parallels, how much elevation relief you have, etc).  So my point is that the 4ft error you’re seeing Civil 3D over that almost 1.6 mile distance is most likely due to the difference between Grid (Civil 3D) and Ellipsoidal (Google Earth) distances.  Apples and oranges with respect to measurements.

In summary it sounds like you’re doing mapping level stuff with solid GPS equipment, so don’t sweat if you’re measurements aren’t exact in Civil 3D.  You will always have the raw WGS84 data to fall back on.  When you go to Engineering Design and then construction, you will need to worry about this tightening the accuracy further.

I hope this helps.

[Pointdump]

D,

Here's a graphic to help visualize Mike's post:

Dave

[Pointdump]

D,

A couple of observations. Your selected Coordinate System is Metric and your drawing is in Feet. And I can't find UTM84-14N with that "CGCF" extension. It's not in the Map Library.

 Can you post your Shapefiles and drawing?

Dave

[Anonymous]

---

@CivilFlow wrote:

Thanks for providing the additional information.  It sounds like you have a handle on your RTk-GPS Survey equipment tolerance.  You’re correct that your RTK-GPS is referencing a correction source that is most likely using the latest WGS84 Datum.  It is hard to pin point which realization of WGS 84 Civil 3D uses, so I would try to format your .shp data to UTM Northing Easting coordinates prior to bringing into Civil 3D to take Civil 3D out of the equation when applying the UTM mapping projection (if Civil 3D has an older version of WGS 84).

Also with regard to your overall Site size and the 8500 foot distance measurement check you mentioned.  Distances measured in Civil 3D will be “GRID” distances not “GROUND” distances.  Google Earth distance inquiries are “ellipsoidal” distances (which factor in the curve of the WGS84 ellipsoid)...these aren’t technically ground distances either.  Knowing how to work with Grid, Ground, and Ellipsoidal distances is part of the Professional Surveying craft and depends on lots of factors (e.g., where you’re at relative to the mapping projection Standard Parallels, how much elevation relief you have, etc).  So my point is that the 4ft error you’re seeing Civil 3D over that almost 1.6 mile distance is most likely due to the difference between Grid (Civil 3D) and Ellipsoidal (Google Earth) distances.  Apples and oranges with respect to measurements.

In summary it sounds like you’re doing mapping level stuff with solid GPS equipment, so don’t sweat if you’re measurements aren’t exact in Civil 3D.  You will always have the raw WGS84 data to fall back on.  When you go to Engineering Design and then construction, you will need to worry about this tightening the accuracy further.

I hope this helps.

---

Thanks for clarifying that really makes sense. I will see about formatting the .shp data. For what I'm doing I could live with this degree of precision, but for me I'm always ready to learn the unknown and have a good understanding whats going on. Geo surveying is definitely a specialized craft. i have also gotten in contact with the  company of the GPS guidance system www.navcomtech.com/en. about importing into third-party software. The tech I'm using is for equipment guidance lines and field mapping so its not full featured for working with surveying points but possible..

Thanks, this is a very friendly, helpful forum.

[Anonymous]

---

@Pointdump wrote:

D,

A couple of observations. Your selected Coordinate System is Metric and your drawing is in Feet. And I can't find UTM84-14N with that "CGCF" extension. It's not in the Map Library.

 Can you post your Shapefiles and drawing?

Dave

---

That picture is a nice reprersentation of what I'm working with. I figured I needed to use this coordinate system, so following some information from this forum I used ADEDEFCRDSYS and made a separate coodinate system identical to this one except its in feet hence the -CGCF. Not sure if that was the right thing to do but the points imported correctly, and not out of skew like they would with a metric coordinate system. The drawing is private, but I can post some of my .shp files.

[Joe-Bouza]

How do we know the shp file is so dead on?
If you told me you compared a tape measure in the field to surveyed monuments I would be so dubious. Mike and Dave are checking on you coordinate settings. They’ll get you to the finish line 🏁

[Pointdump · Accepted solution]

D,

"The error progressively increases away from my main control point."
All Map Projections have distortion. There's accuracy, and then there's precision. It's not always easy to decide which you have.

UTM Coordinate Systems are 6 degrees wide, so your grid-to-ground scale might be considerable. And you can import those Shapes into any Foot-Unit projection that fits your data, for example a SD83-SF Projection.

As for those WGS Datums, they mostly just have greater and greater accuracy, and an averaging of tectonic plate movement. They don't necessarily need a transformation, which is good because I don't know any way to transform between WGS Versions.

Dave

[Anonymous]

---

@Joe-Bouza wrote:
How do we know the shp file is so dead on?
If you told me you compared a tape measure in the field to surveyed monuments I would be so dubious. Mike and Dave are checking on you coordinate settings. They’ll get you to the finish line 🏁

---

I would say the shape file is as accurate as the lat long coordinates get transformed to grid. In the picture Dave posted you see how I'm comparing. I built a Google Earth Image mosaic with Plex Earth. Then I placed all the buildings in relation to how they measured in size and distance from each other and with the mosaic in the background to keep in check. I have found the mosaic matches very closely to what i measured in the field. And yes, the GPS points show up very close (maybe +/-6")to real world points. Keep in mind I'm not a surveying professional, but I've gotten things to work for what I need to do. So I think like Mike said the measurement variation over 8500' is from earth curvature. I think my biggest question is what the correct geo coordinate system to use is.

[Anonymous]

---

@Pointdump wrote:

D,

"The error progressively increases away from my main control point."
All Map Projections have distortion. There's accuracy, and then there's precision. It's not always easy to decide which you have.

UTM Coordinate Systems are 6 degrees wide, so your grid-to-ground scale might be considerable. And you can import those Shapes into any Foot-Unit projection that fits your data, for example a SD83-SF Projection.

As for those WGS Datums, they mostly just have greater and greater accuracy, and an averaging of tectonic plate movement. They don't necessarily need a transformation, which is good because I don't know any way to transform between WGS Versions.

Dave

---

Thanks for troubleshooting that really makes sense. The margin of error I'm dealing with is pretty acceptable. I just want to glean the most that I can from the GPS-RTK setup. Originally I used the HARN-SD-SF projection to import points. But I thought since Google Earth uses WGS84 and the GPS setup uses WGS84, to gain more accuracy I should switch to UTM but I actually I found the degree of error actually increased. So I'm probably best off to stay with HARN-SD-SF. Or would NAD83 be better?

[CivilFlow]

Love this WGS 84 realization breakdown Dave!  You’re the man!  

Thanks for your wise input as always!

Happy Holidays!

Mike

[CivilFlow]

Hi @Anonymous

NAD83 is actually a different reference frame than WGS84.  There are lots of realizations of NAD83 too.  Datum transformations between WGS84 and NAD83 can be tricky, so I would keep it simple.  

Mike

[Pointdump]

D,

"So I'm probably best off to stay with HARN-SD-SF. Or would NAD83 be better?"

All the cool kids create a <<<Low Distortion Projection>>>. Look <<<Here>>> for a great video on LDP creation in Civil 3d by a much-missed Forum member.

Dave

[Anonymous]

---

@Pointdump wrote:

D,

"So I'm probably best off to stay with HARN-SD-SF. Or would NAD83 be better?"

All the cool kids create a <<<Low Distortion Projection>>>. Look <<<Here>>> for a great video on LDP creation in Civil 3d by a much-missed Forum member.

Dave

---

Thank you Dave that really makes sense. .That really looks like the only way to gain the accuracy of my GPS RTK setup. So I'll keep working on it. Thanks all for being patient with my limited expertise. I'm open for any tidbits and advice. The help files are often simply not comparable to real experience. I'm taking Christmas break for 4 days.

Happy Holidays.