AutoCAD Civil 3D

[#1]

I've just posted a new demo on using C3D's built-in F2F functionality for processing Survey data, which may be of interest to anyone trying to use C3D for Survey:

http://www.quuxsoft.com/videos/ProcessingSurveyData.aspx

It doesn't get into details about how to setup everything, but it shows how to use things once they are setup.  It shows how C3D can be used to very quickly produce a high-quality design survey in very little time, assuming the field survey crews know how to use the linework codes.  It also shows how I use some "tricks", such as avoiding the SDB for everything but the bare minimum, keeping all my Survey Figure styles at elevation (rather tha using "Flatten to elevation"), and so forth.  Net result is I can create high-quality design surveys in very short periods of time, as you can see in the demo.

I know I complain a lot about the usability of Civil 3D, but we can do some incredibly productive work with it... 

[#2]

Good video, appreciate that. Work for small engineering/surveying firm, currently the surveyors play the connect the dot game. Trying to get field crew to use codes for F2F. Imported points via Imort survey data wizard to see how linework comes in. Field crew tried using linework code set, for road portion his shots were sections, both sides of road used same code (example EG). So I revised one side of road by selecting a point and choosing Survey Point Propeties, chagned description to EP1. Continued the same process for all points along that side. Once finished revising some shots hit escape, prompted if I wanted to re-process linework said yes. What I changed seemed to come in good. Is there a better and more effecient way to revise descriptions? For this project we had a guy shooting with GPS and one with a robot. What is the best process for having multiple data collections for a project? Also when I was revising the order of points for some figures, then revised some point descriptions for a different area, reprocessed the linework, figure sometime reverted back to before I changed the order and also seemed to make copies. Any help would really be appreciated and again thanks for video.

[#3]

I haven't had much luck with the "Process Linework" command.  But then, I find the whole approach of modifying survey data in the SDB to be a royal PITA and major time-waster, so I avoid it as much as I possibly can.

Instead, I use the SDB for the bare-minimum to get my linework initially drawn.  Then I ignore it from then on.  I get stuff done at least twice as fast as when I try to use the SDB for anything more.  And I really wish I didn't have to even create an SDB in the first place.

A key part of using C3D's F2F functionality is that your field surveyors have to know how to use the linework codes.  If they code things correctly, using appropriate strings, then everything comes in cleanly.  One of the things I'll do is that, if I pull in a survey and see the field surveyor mixed things up so that I get Survey Figures that bounce across the road, I'll fix that in the CSV and then use "Reimport" to completely blow the import event out of the DWG/SDB and pull it all in again from the CSV.

If you have multiple surveyors on the same site, then you can pull each person's work into C3D using a different import event.  A key trick is that if your field surveyors always use the BEGIN (B) linework code, it will force a new string, even if there's already one with the same name.  So we've been hammering into our field guys the need to ALWAYS "BEGIN" every string.  That automatically keeps one guys strings from connecting with another's, even if they use the same string identifiers.  But your field surveyors MUST use string identifiers...  They can't call both sides of the road "EP1".  That just doesn't work.

[#4]

Got any tips on F2F using custom linetypes. Since you mention you don't flatten things do you have 3d polylines? Or are survey figures different then 3d polylines such that you may get custom linetypes to show in plan view.

[#5]

The only things we use custom linetypes for are fencelines, guard rails, and utility lines.  And we don't consider any of those to be breaklines, so they're all set to Breakline=NO in our Figure Prefix Library, and do not get added to our Surfaces as breaklines.

So one way we can deal with those is to select them all, explode them into 3D Polylines, then convert them to 2D Polylines and turn on linetype generation.

The other way is this command, in third-party software:

http://www.quuxsoft.com/SincpacC3D_Help/SP_Extract2D.htm

The nice thing about that command is that it will maintain arcs, without the tesselation you get when you explode a Survey Figure that's at elevation.  It can also maintain the original Survey Figures as it creates the polylines.  And it has options to create the polylines on different layers from the Survey Figures, or create the polylines on the original layer while moving the Survey Figures to different layers.  That lets you automatically move the Survey Figures to some non-plotting layer, while still leaving them in the Surface, yet you get nice polylines with linetype generation enabled in their place.

[#6]

Sounds interesting. One question. Can I import a fence line into the surface as a random feature? The other program I use allows me to draw lines between the fence shots but when they get imported into a dtm the vertices are treated as random points and the line is just a graphical line. There are lines we survey (tree lines, fences, and certain area boundaries) that produce a graphical line in field to finish but create random dtm points.

Thanks.

[#7]

If I understand your question correclty, then that's what happens when you include your Fence shots in a Point Group in your surface definition, and you have Breakline=NO set in the Figure Prefix Library.  The Fence shots get included in the DTM if they're part of the Point Group (or one of the Point Groups) you use to create your Surface, so if you want those points in your DTM, just make sure they're part of your Point Group.  The Fence linework would be drawn between the points, as a Survey Figure.  But the Survey Figure only gets added to your Surface as a breakline if you have "Breakline=Yes" in your Figure Prefix Library.

Here's an example:

Notice how the Fence code "FX", along with the Fiber Optic Locate code and Gas Locate code are set to "Breakline=No".  This means they'll get linework drawn, but when I use the "Create Breaklines..." command to add my breaklines to a Surface, those lines will be ignored.  And that's typically what we want, since with things like that, the field surveyor might take shots with a very wide spacing.  And we don't want a bogus 200' long breakline between fence points, for example.

[#8]

Thanks. It sounds like the way to make a surface is to bring in point groups. Seems to be how one filters non-dtm and dtm points. Is this correct? Are point groups used a lot in Civil 3D?

I read a bit about control points and non control points. If these are both in one text file is there a way to import them into a survey database so they are filtered by control and non control.

Thanks.

[#9]

Thanks!

[#10]

---

lambertb wrote:

Thanks. It sounds like the way to make a surface is to bring in point groups. Seems to be how one filters non-dtm and dtm points. Is this correct? Are point groups used a lot in Civil 3D?

---

Definitely, on both counts.

---

lambertb wrote:

I read a bit about control points and non control points. If these are both in one text file is there a way to import them into a survey database so they are filtered by control and non control.

---

This difference is only applicable when pulling in FBK files. Some people like to use those, as they (theoretically) let you collect data and do traverse at the same time, but I don't really advocate that practice. I think you should take care of your control FIRST, then worry about your topo or design survey or ALTA or whatever you're doing after the control is set. And that means that the Survey Database becomes an immense un-needed piece of baggage that slows everything else down.

True, knowing which points were shot from which setups can be useful.  So I WOULD like to know that stuff, from time to time.  But given the benefits/drawbacks of using an FBK file vs. a simple CSV import from the field guy's data collector, the beneft swings way in the direction of avoiding FBK in favor of the simple CSV import.  That's just based on my experience.