Datum Shift (Civil 3d 2010)

Acad does not do a conversion when you just change the grid. The coord values and elevation will remain the same but the lat/long values will change. If you want to go from one grid to another you need to set up a second drawing in the zone you want to convert to and then use query and bring the first drawing into it.

In case I misread your post are you trying to do a coordinate conversion or an elevarion conversion.

What are you trying to change?

Most things respond to the MOVE command. You can run into exceptions, though, if you're using the Survey Database.

> I am trying to shift from the ‘88 back to ‘29 datum in the auto-cad program.... AutoCAD help was no help.

There in lies your answer

The problem I am having is that the years given are for vertical datums but I think he is asking about a horizontal shift.

I was presuming the OP wants an elevation adjustment, not horizontal. My earlier comment only applies to an elevation adjustment. You wouldn't want to use the MOVE command for a horizontal transformation.

Points menu
edit points
datum shift

My apologies, I am trying to adjust the vertical datum. I recently did a project and assumed our field crew used the NGVD’29 Datum, but they used '88. My boss reviewed my project and he caught that the crew used the ’88 Datum. I am trying to do the change without re-importing the points.
*I did the points menu, edit points, datum. That was one of the commands that did nothing.
Thank you so much for your guys help.

You were just about there. The datum shift in edit points will add or subtract globally a value that you give it to all or some (if you tell it a range of points or select some points) of the elevations for points in the drawing. If the 29 value is 2.01 feet lower than the 88, put -2.01 when it promps you. It does not automatically shift between 88 and 29. To figure out what the shift should be, look at some of the published bench marks in the area on a NGS datasheet. Hopefully, there is a bench mark tied to in the project that gives you the shift. There are also some programs that will give you the shift at a long and lat. I can't say for where you work, but for me the shift is pretty consist over a small area; say a few square miles.

Also you can use this program to calc datum shifts if you have SPC or LAT LONG. Useful if you are trying to adjust your own GPS derived values that have no data sheet to consult.

If that command did nothing, then you're probably trying to adjust Survey Points. These are "special" Cogo Points that were created from a Survey Database, and are locked to the Survey Database.

You can adjust points like this by going to the Survey Database, finding the Points, and selecting "Unlock in drawing" first. Then you should be able to use the "Datum..." command in the drawing. However, that may leave you with incorrect elevations in your Survey Database... So it may be better to go back and change the Survey Database, instead.

Unfortunately, once the Survey Database is involved, things get a little bit messy. The ideal procedure depends on what you've done, and what you plan to do, and how you've done it. We tend to avoid the Survey Database as much as possible, since it's such a pain to deal with.

I was going to stay out of this BECAUSE I don't know squat about CIVIL-3D, BUT...

I would caution folks about these overly simplistic “datum shift” routines in some (maybe most) software. As others have pointed out above, IF (BIG IF) we are talking about a SMALL (quite small sometimes) project, and somewhat loosey-goosey tolerances, then a simple linear shift will work just dandy.

On the other hand, depending on WHERE you are, and WHAT you are trying to accomplish, even the more robust programs like VERTCON & COPRPSCON can bite you on the butt from time to time.

MOST (probably the VAST Majority) of the time, these kinds of variances are trivial for MOST practical applications. BUT, UNLESS you have a good “feel” for the nature and magnitude of these variances in your particular area of interest, you REALLY don't know what you CAN & CAN'T do (do ya?).

Just a word to the wise,
Loyal

>We tend to avoid the Survey Database as much as possible, since it's such a pain to deal with.

Sinc,

I'm starting to agree 100%, however I wonder what else you use to get the field data into Civil3D instead? Are you advocating using the Survey module to get data in, and then un-linking it permanently and moving on?

Thanks!

Bob K.
Anchorage, AK

I agree with you 100%, I love the Corpscon 6.0 but I will double and triple check the numbers it gives to me. My boss used the Verticon program for the vertical conversion. I gave up on adjusting them in Civil. I think Sinc hit it on the nose; "once the Survey Database is involved, things get a little bit messy." The Survey Database will not let me unless I re-import. I will make the necessary notes and have the surveyor get in contact with the appropriate parties. Thank you all so much, for everything. I have learned so much from all of you on this board (over these past few years) that a book couldn’t compete. A special thanks for Wendell and Angel for all you do on a day to day basis to keep this board up and running. 🙂

We pretty much just use the Survey Database process the F2F commands and generate linework. From that point on, we work only in the drawing. Editing Survey Figures is a lot easier when all you worry about doing is getting them to look right in the drawing, without worrying about what's going on in the SDB. We'll also connect remaining field shots as necessary, usually with a simple 3D poly that we add to the Surface, without worrying about getting a corresponding Survey Figure into the SDB.

In effect, we use the SDB only as much as necessary. Then we simply ignore it.

One of the other issues is the "lock down" on Survey Points, when importing things from a file. It's possible to import the points into the drawing first, then use the Drawing Points in the Import Event (rather than pulling points directly in from the file), and your Cogo Points don't get locked down. This has some caveats, though... You can no longer use "Connect by Import Order", and are constrained to only using "Connect by Point Number". The Import Event also doesn't remember which points were used for it, either, meaning you have to select the points again if you need to redo the Import Event. I wish Autodesk would fix that, but judicious use of Point Groups can mitigate the problem.

Most of the time, I use the Import Event, and import CSV data from a file. (We let our data collectors process the data into CSV, rather than use C3D to process a FBK file.) This locks down the points as Survey Points, but that's usually OK. As a general rule, it's a bad idea to move points that were located in the field. And from what I've seen, people usually want to move points because they're trying to fix crossing breaklines. However, it's relatively easy to fix crossing breaklines in C3D, at least when you aren't worried about maintaining the SDB. So I like that option better.

I think I process field data at least twice as fast now, compared to before, when I was trying to follow "Autodesk Approved" processes with the SDB. Over the last few years, I've really cultivated a severe dislike of the SDB. Ostensibly, it appears to be a tool for Surveyors. In practice, I find it to be more of a "Survey Data Management Tool" for Engineers. But of course, DWG files can also be used to manage Survey Data, so it strikes me as unnecessary, even for Engineers.

And of course, its ability to perform Traverse adjustments is very weak, compared to something like Star*Net, or even TGO. So we don't even use the SDB for traverse adjustments. The thing is mostly a distracting time-waster, in my opinion.

If you create 3D linework with F2F and then use the datum shift to edit your point elevations I don't think that will also adjust your 3d polylines. This could be one of the reasons the survey points get locked in the database.