civil3d.com

We will see if this one makes it through the nite without James posting ahead of me. Enjoy
Nick

So to wrap up my little discussion on how Civil 3D handles corridors I am going to explain how the surfaces get built from your corridor model and the impact of your assembly on the surface. In the last post I briefly mentioned codes, what I failed to mention is all the pieces of the corridor model get assigned a code, both the points and the links are coded. A lot of you might not even realize it is happening, but if you scroll all the way to end of the help topic for any sub-assembly you will see what is called a coding diagram, its is the most important piece of information you have in troubleshooting problems with corridor surface creation. If I had my way it would be the first diagram shown, but I think the bookend position is also a hold over from CAiCE because every CAiCE fragment help file I have seen also had them at the end. I have included a sample from the help file below.

At any rate when we build a surface from our corridor model there are two possibilities presented to us, both are dependant on codes. The first option available is by links. This builds the surface by connecting similar coded links and then triangulating between those links. The other option is to build based on feature lines, this is more akin to adding a bunch of breaklines in to build a surface model.

I won’t debate which is better, a lot of times I try both just to see which result I like better. So after 2 pages of ranting and rambling I am finally going to talk about what prompted this post. Someone in the newsgroup was having a problem with a sub-assembly not creating the datum surface properly to get accurate earthworks volumes. The answer to their problem lied in the information I gave you previously. The sub-assembly in question was the urban curb and gutter series, in the attached screen shot I have shown how the datum was being generated with the assembly as designed. As well is a picture of the assembly.

Now that you have seen the problem here is the resolution, by looking at the coding diagram for the two sub-assemblies involved here we can see both have the datum code applied(I have labeled my images for simplicity, when the software is working from the centerline outward it gets to the bottom back of curb and then the datum surface flies upward, this is because the software although nifty and intelligent isn’t a mind reader, it operates on pretty simple logic which states if you find a sub-assembly with the datum code the surface needs to hit it. The spiking here is caused because no decision can be made if it should be connecting to the upper sub-assembly or the bottom of the curb sub-base, the surface just ends up bouncing between the two. My correction for this problem requires an extra sub-assembly be used, in this case one without the datum code applied. As I need a simple link at grade I have used a generic link at slope, for codes I have applied only a top code to the link. In the screen shot you can see the surface generation problem has been resolved.

I am not going to document this one but another common cause of these problems is stacking two basic lane sub-assemblies ontop of each other, while the software will often manage to connect them properly, in corners it will very often get confused and result in similar spikes. This is because you end up with 2 sets of point codes that are identical just separated in the z direction. Hopefully this helps you get a little deeper view into how a model is built and lets you make some better choices when you are building your assemblies.