Civil 3D 2016 Question

Probably the fastest and easiest thing to do would be buy a license for Sincpac. Among many of the super useful tools in it is the "Extract 2D" function. Select your feature lines or survey figures, right click and select "Extract 2D". Brings up this dialogue box that gives all kinds of options for how to make the lines dumb.

BStrand, post: 453832, member: 13049 wrote: I can't seem to find a walkthrough on how to do something I'm sure is painfully basic. I want to convert survey figures to simple 2D polylines.

This is my process right now and some part of it is wrong but I'm not sure where:

1.) Create database
2.) Import survey data

3.) Quick select survey figures
4.) Explode
5.) Convert 3D polylines to 2D
6.) Under properties change elevations to 0

The problem I run into is curves lose their smooth shape. Any idea on where my error is?

If you have your survey figures come in a zero elevation, that will fix the chording problem along curves.

However, as he said above, Sincpac is the way to go. It has tons of survey specific layout, topo, and drafting tools that help alot. Adding dynamic stationing and offsets from an alignment to points and point tables is one of my favorites and is well worth the cost of the program.

Sent from my LG-M257 using Tapatalk

BStrand, post: 453832, member: 13049 wrote: I can't seem to find a walkthrough on how to do something I'm sure is painfully basic. I want to convert survey figures to simple 2D polylines.

This is my process right now and some part of it is wrong but I'm not sure where:

1.) Create database
2.) Import survey data

3.) Quick select survey figures
4.) Explode
5.) Convert 3D polylines to 2D
6.) Under properties change elevations to 0

The problem I run into is curves lose their smooth shape. Any idea on where my error is?

Why would you want to explode 3D polylines? If that's the case why use the survey data base? Why pay for C3D? Sounds like LDD drafting in the 21st century..

But you can set your points to come in on a zero elevation and ignore z values.

StLSurveyor, post: 454068, member: 7070 wrote: Why would you want to explode 3D polylines?

Can't speak for BStrand but I use this on fences for example. When my field generated linework from Captivate gets processed into the database it comes in as Survey Figures. I don't need or want (95% of the time anyway) my fence lines being at elevation because I don't want them accidently added to the surface as a breakline. The same generally goes for a building outline. Pushing them to 0 and making them simple 2D polylines also adds flexibility with linetypes and scales.

Is there a way to automate that step through the database import?

In Civil 3D (not sure about ordinary AutoCAD) there is a function to convert 3D polylines to 2D. Xplode on a 3D polyline gives lines. Also, feature lines (instead of using 3D polylines) are "better" for handling linetypes etc in terms of printability, and when they are closed they can be hatched.

Cameron Watson PLS, post: 454076, member: 11407 wrote: Can't speak for BStrand but I use this on fences for example. When my field generated linework from Captivate gets processed into the database it comes in as Survey Figures. I don't need or want (95% of the time anyway) my fence lines being at elevation because I don't want them accidently added to the surface as a breakline. The same generally goes for a building outline. Pushing them to 0 and making them simple 2D polylines also adds flexibility with linetypes and scales.

Is there a way to automate that step through the database import?

Just remove fence points (point groups) from the surface. I do this as well with trees, vegetation line, DR shots on buildings, etc.

I'm with StLSurveyor on this. Whenever someone talks about exploding C3D entities I cringe and move on.

StLSurveyor, post: 454087, member: 7070 wrote: Just remove fence points

I use the points to augment the surface (if they have a valid ground elevation), I'm talking about the lines, as was the OP. If the linework is drawn as it's collected in the field using Captivate as Leica intends the XML that gets processed into the Survey Database turns all those lines into figures a.k.a. feature lines with elevations. Most of the time I don't want my surface to break at a fence but I do want the elevation at that location included as a topo point. Driving the line to 0 elevation and converting it to a 2D poly ensures that either myself or someone down the road won't/can't use that line for anything other than graphical representation for the position of the fence.

I know the OP didn't say anything about Leica or Captivate, I'm just giving a real world scenario and workflow where rolling back a C3D smart object to 2D dumb linework makes sense. In general I agree, exploding C3D objects is bad but that's a guideline not a rule.

Exactly what Cameron said.

We import survey data to have Civil 3D draw the vast majority of the linework but this makes the lines come in as survey figures with elevations, which we don't want to use in the surface. If there's a simpler way to make these lines 0 elevation I'm all ears.

Can't comment on Captivate as we use Carlson controllers for our Leica robots. Our Carlson f2f is set up to draw 2 lines for some features (edge of pavement, top of retaining walls, etc.) One 3d and one 2d. The 3d is for the surface and goes on the layer "3d" the 2d line goes on the appropriate layer for the feature. Also, 100% on points at 0. Nothing more irritating than trying to get a horizontal distance between two monuments and getting the slope distance.

Sent from my SM-G900P using Tapatalk

Cameron Watson PLS, post: 454102, member: 11407 wrote: I use the points to augment the surface (if they have a valid ground elevation), I'm talking about the lines, as was the OP. If the linework is drawn as it's collected in the field using Captivate as Leica intends the XML that gets processed into the Survey Database turns all those lines into figures a.k.a. feature lines with elevations. Most of the time I don't want my surface to break at a fence but I do want the elevation at that location included as a topo point. Driving the line to 0 elevation and converting it to a 2D poly ensures that either myself or someone down the road won't/can't use that line for anything other than graphical representation for the position of the fence.

I know the OP didn't say anything about Leica or Captivate, I'm just giving a real world scenario and workflow where rolling back a C3D smart object to 2D dumb linework makes sense. In general I agree, exploding C3D objects is bad but that's a guideline not a rule.

BStrand, post: 454112, member: 13049 wrote: Exactly what Cameron said.

We import survey data to have Civil 3D draw the vast majority of the linework but this makes the lines come in as survey figures with elevations, which we don't want to use in the surface. If there's a simpler way to make these lines 0 elevation I'm all ears.

I have to go from memory since this now falls outside my regular duties, but I'm sure that you can specify within the figure prefix library if survey figures are to be used or not be used for surface creation. Concerning points, I know that I set up a point group for surface creation where I added any descriptors that I'd like to have included and any descriptor that matched automatically were added to that point group. I would have a surface created, with break lines, in no time. I didn't need to tell it which break lines to add or which points to add to the surface.

Regarding survey figures coming in at elevation 0, Mark Mayer pointed out a while back that even if you set your figures to come in at 0, they didn't actually do that. For me, it's not a big deal because I knew that a fence line wasn't having an impact on my surface. Yeah, it might cause confusion if someone actually looked at the elevations for the fence, but since most people I've worked with don't even know how to work with survey figures, it's not been a problem for me.

I know we all do different kinds of work and skin our cats differently, and I respect the heck out of Cameron, but for me, not exploding a C3D entity is not a guideline, but a rule. Heck, even Sinc must have had a reason to do that if he wrote a routine for it!

BlitzkriegBob, post: 454128, member: 9554 wrote: I have to go from memory since this now falls outside my regular duties, but I'm sure that you can specify within the figure prefix library if survey figures are to be used or not be used for surface creation. Concerning points, I know that I set up a point group for surface creation where I added any descriptors that I'd like to have included and any descriptor that matched automatically were added to that point group. I would have a surface created, with break lines, in no time. I didn't need to tell it which break lines to add or which points to add to the surface.

Regarding survey figures coming in at elevation 0, Mark Mayer pointed out a while back that even if you set your figures to come in at 0, they didn't actually do that. For me, it's not a big deal because I knew that a fence line wasn't having an impact on my surface. Yeah, it might cause confusion if someone actually looked at the elevations for the fence, but since most people I've worked with don't even know how to work with survey figures, it's not been a problem for me.

I know we all do different kinds of work and skin our cats differently, and I respect the heck out of Cameron, but for me, not exploding a C3D entity is not a guideline, but a rule. Heck, even Sinc must have had a reason to do that if he wrote a routine for it!

I approve this message. :stakeout:

BlitzkriegBob, post: 454128, member: 9554 wrote: not exploding a C3D entity is not a guideline, but a rule

Don't get me wrong Blitz, to me there are 2 distinctly different kinds of C3D entities. There are those the software forces you to create and those you intentionally create. Blowing up an intentionally created deliverable entity leads to misery for all end users. Exploding something I was forced to create as a C3D entity by the software but never wanted (or needed) to be a C3D entity in the first place is entirely different.