Hello fellow C3D'ers. We here at work have recently implemented using the survey database feature in CAD as a better way of manipulating and organizing points in our drawings. However, we have begun to notice a few issues with how the survey database imports points (?).
Sometimes, and I say sometimes because it is very sporratic, some drawings exhibit the issue and some do not, the points will be skewed off the linework (we are converting existing projects to the survey database). In these situations I find that the Northing and Easting don't match the ascii file it was imported from, instead the "Grid Northing" and "Grid Easting" do. Also, some drawings will have a slightly different Grid Northing and Grid Easting vs Northing and Easting, whereas some drawings will have the exact coordinates for both sets of fields. I believe the issue is one and same.
Our points handling goes like this, Data Collector--->TBC (where ground to grid and scaling is performed)---->exported to ascii file------>Imported to CAD.
This is very confusing and irritating at the same time, and really counterproductive to be troubleshooting why our points keep moving. Redrawing the linework is NOT an option, we'll sooner go back to simple ascii file imports (where the problem is NOT present) then have to redo all of our work on our projects.
Solved! Go to Solution.
In an offending drawing, check the drawing drawing settings Units and Zone tab and the Transformation tab. Also check check under Survey pulldown -> Edit Survey Database Settings -> Units-> Coordinate Zone and also Distance: those should be set to US Foot or International Foot to match the definition of your local datum projection. Otherwise C3D will make an adjustment for you.
Checked, and checked. Both say US Foot. I wish it were that simple, I originally figured out that the points were off in some drawings because the survey database was set to International foot. Now though when I set them to the correct units, and reimport the points they come in skewed. However this should be a non-issue as we previously before were not using the survey database and all of our drawings are set correctly to use US survey foot.
I had the same problem once with a file. I found it was because the scale factor on the adjustment software was changing. I had it set to "average scale factor" instead of a scale factor at a specific point. Also, if you already are on grid, turn off any conversion that Civil 3D is doing on import.
Hope it helps.
This whole functionality is implemented incorrectly in C3D, much to our dismay.
Probably the most-annoying feature is that coordinates will be "silently" converted, with no indication to you as the user. This starts if you use a FBK file (which we never do anymore, as of C3D 2010). The FBK file can specify what units/zone you are in, and if they are different that the Survey Database (i.e. "SDB"), your observations will be "silently" converted. This can be a good thing, if everything is setup right, but it can also be a bad thing if you don't understand EVERYTHING that is happening.
As of C3D 2010, we find it much easier to import a CSV file from the data collector, rather than use the SDB and a FBK file. There are many reasons for this, some of which get rather esoteric. I don't want to get too involved with that in this post, but it goes back to how older systems (such as NAD27) used a "Scale Factor", "Sea-level Factor", and "Grid Factor", while newer systems (such as NAD83) use a "Grid Scale Factor", "Elevation Factor", and "Combined Factor". When it comes to improrting FBK files, Civil 3d only understands the older system (which is falling out of use these days).
The next thing that happens is you can get another "silent" conversion between the SDB and your drawing. The SDB will ALWAYS assume you have "grid coordinates". And the SDB cannot see any Transformation Tab settings in your drawing. So it basically assumes that your field surveyor is ALWAYS working in the grid system (UTM, State Plane, whatever). This is usually NOT the case, because your field surveyor is probably using Project Coordinates. And since the Transformation Tab is what converts between Project Coordinates and Grid Coordinates, you get an "incorrect" transformation when importing survey data. I don't really know why Autodesk hasn't fixed this problem yet.
When using "Project Coordinates", the way I work around it is to go into my Drawing Settings, and disabling the Transformation Tab settings when I import my Survey Data. This lets me import survey data without applying an unwanted transformation. Then, once the data is imported, I'll go back into Drawing Settings and re-enable the Transformation Tab settings, so that I once again get correct (well, approximately) "Grid Coordinates" for every point. Of course, if I'm using the Transformation Tab, the "Grid Coordinates" are not EXACTLY right, but they're often "good enough". And it's usually more important that my northing/easting are on the ground (aka "Project") system... By disabling the Transformation Tab during import, all of my data comes in using the Project northings/eastings. And then when I renable the Tranformation Tab after import, I get "grid coordinates" that are typically pretty close to the grid coordinates. And this usually works. We actually need a rather large project (going over 7+ miles horizontally, or over 400 ft vertical elevation difference) to create a real problem.
Is that making sense?
For anyone struggling with my response, here's some useful posts... First, a PDF document that explains exactly what we mean by the "Grid to Ground" problem:
The second is a link to a PowerPoint presentation that I did at AU 2010 (but was unfortunately not recorded, and is not on AU Online):
Since this topic is getting so important to our industry these days, I'm planning on submitting a proposal to AU this year to re-teach this class, yet split it up into two different ones. The first will be the "fundamentals", explaining the whole "Grid to Ground" issue, and what a "Low Distortion Projection" is. The second will be on how to actually implement this stuff in Map3D/Civil3D. This is based on feedback I got from the previous class, where some people already understood the basic theory, and only wanted to know the implementation in Map3D/C3D, so didn't need to sit through the first part.
And of course, over the last two years, I've been teaching this stuff to more and more people, so I think I'll do it even better than before...
Sinc, thank you so much for your explanation of C3D points handling. We do not use C3D to transform or scale anything which is why I don't understand why this is happening. All the cooridinates and points we work with are at grid, none of the transformation settings are enabled and still they are getting skewed.
Anyways, not sure how, but I think I have it working again. No idea what I did, but this was a huge waste of time today and I hope autocad gets a better grip on points manipulation in the future, its bad enough we have to tip toe around the points editor, we need our points to stay where they are.
BTW, we are working with 1-2 townships per project (but have has as many as 6 before in one project) so you can see how 6-12miles of skewed points can be a problem. Thanks again.
Have you configured your default Survey Database Settings...?
The basic idea is that you setup a Survey Database (SDB) the way you want it, then export the settings to an .sdb_set file. Then make sure your Survey Settings are pointed to that file (as illustrated by the red circles in the image above). Then, from that point on, every SDB you create will be in the correct units.
I suspect that you are using the default settings, which are in International Feet, but really want to use US Survey Feet. The SDB has different settings than your drawing, and if they mis-match, C3D will "silently" convert from one type of foot to the other. (I REALLY wish it wouldn't do this "silently", and would instead give you a warning, since it is almost always an error, but C3D has never claimed to be user-friendly.)
Then, from that point on, every SDB you create will be in the correct units.
Oops, sorry, overstepped that...
Every SDB will be created in the format of your .sdb_set file. This is all well and good, if you ALWAYS work in the same units and coordinate zone. If you work in multiple coordinate zones and states, then this is not true, and you're back into problems.
This gets back into my long-standing "Project rant" that I've been harping on for the last five years.
I don't think your database is applying a grid to ground factor on import, you would have to be using a .fbk with a scale factor and the measurement correction would have to be on in the survey database settings (see below). You said you were using a comma seperateed file, so that shouldn't be an issue, but it's something to be aware of.
I would check the output of settings of TBC. If that is fine then the only other thing I can of is the survey database was "remembering" the old settings. I have seen theis happen when I make edits to my input files and try to re-import from the the right click context menu in the survey database. The best thing I have found is to delete that survey import event and then re-import completely fresh.
Log into access your profile, ask and answer questions, share ideas and more. Haven't signed up yet? Register
Start with some of our most frequented solutions to get help installing your software.