Topic: ( C3D ) Points and Elevations - how to...?

[sinc]

OK, we've got this awesome 3D-model of our site.  Now how do we calculate stakeout points?

For example, we have a parking lot, modeled in C3D.  We now want to calculate offset points to the curb and gutter - namely, 3-foot offsets, graded to the top-back of the curb (3TBC).  There should be elevated points all the way around the parking lot, with a grade, hitting all horizontal angle points, PCs, vertical grade breaks, etc., with no more than 25 feet between offset stakes.  Exterior angle points should have TWO offset stakes, one perpendicular to the incoming course, and one perpendicular to the outgoing course.  How do you do it in C3D?

Since the TBC is a feature line, the first thought is to offset the feature line, and then place points on the offset, i.e. "Create Points - Elevation from Feature Line".  However, there is no such command.  There's a "Create Points - Polyline Vertices (Automatic)", which creates points at the vertices of a feature line, and sets the elevation correctly.  However, that's the only one, and it is not possible to control where it places points.  There's the "Interpolate" options, which kind of work with feature lines, but are inappropriate to this task.  No other Point Creation command seems to get the elevation from a feature line.

There MIGHT be a workaround, in that we can offset the curb line, and then add the offset line to the surface.  Then we can offset the curb 3 feet, and "Create Points - Elevation from Surface" commands.  However, these commands are also not very user-friendly for this task, and it involves "molesting the model" by adding breaklines that should not exist in the surface.  (I suppose we could create a "Calc surface", and put the offset lines in the "Calc surface....   hmmm...)  However, these commands are also not very convenient for placing stakes every 25 feet around the perimeter...

There also does not seem to be any command to change an existing Cogo point's elevation to match a surface elevation at that point.  If we could do that, we could create a surface from the offset lines, as mentioned earlier.  Then we could use the "Divide" and "Measure" versions of the "Create Points" command to create points at even intervals along the offset lines.  Then we could select the points, and change their elevations to fit the surface.  But there does not seem to be any "Adjust point elevation - move to surface" command, or any "Divide Object - Elevation from Surface" command, or basically ANY useful command...

Any ideas?

I have some routines that did tasks like these very easily in Land Desktop, and they may adaptable to C3D, but that's work I'd prefer to avoid right now...

[Dinosaur]

Try putting your calc surface and the offset breaklines into a new site to prevent them from interacting with your model surface.  You can also make an alignment along the offset in you new site with now ill effects and place you points at any given interval and at geometry points.

[sinc]

Try putting your calc surface and the offset breaklines into a new site to prevent them from interacting with your model surface.  You can also make an alignment along the offset in you new site with now ill effects and place you points at any given interval and at geometry points.

So, you're saying to try to use Points from Corridors for curb staking?  That seems like a lot of work...  Or is there an easier way to, say, adjust the elevation of a Cogo Point to fit a profile?

The Points from Corridors route doesn't seem like a great solution.  I think it would work, but it seems like a lot of work...  There can be a lot of different feature lines just in one parking lot, with all the islands and all, and each would need to be defined as a seperate corridor.  If it's possible to use just an FG Profile, and not a complete corridor, that would be better, but I can't find any such way...

I think I may try digging through the developer documentation, and see if I can adapt some of my old LDD routines to the task...  What I REALLY want is some way of keying in an offset distance and a "maximum gap" distance, then just selecting a feature line and having C3D place all the Cogo points automatically along the feature line, hitting all grade breaks, radius points of curves, etc.  If I discover it's easy to adapt the LDD routines to C3D, then that's going to be the best route to follow.  I asked Autodesk for a feature like this years ago, and they still don't have it, so I'm not about to wait for them to add it to C3D...

[Dinosaur]

You shouldn't have to mess with the corridor at all.  Wth an alignment on a different site there should be no effect at all on your corridor or anything else on the other site.
I am not sure how to go about placing points at your surface elevation, but you can at least create a profile of your design surface along the alignment from the offset curb and apply a band to give you elevations at your chosen interval and at any PI in the alignment.  You will not have spot elevations on your drawing but you will have the data.

[sinc]

Well, I looked through the developer documentation, and took a look around in the VBA Object Browser, and C3D is VERY different from LDD.  Also, the documentation seems to be very incomplete.  It might be possible to accomplish what I want, but not necessarily easy - it looks like it will definitely take a bit of time and trial-and-error exploration...  Anyone tried doing any C3D automation yet?

Things seem to be complicated by the fact that exploding the feature line yields a polyline that has a lot of little segments...  Related to the fact that, just like LDD, C3D can't handle curved breaklines, so the curve is modeled internally as a bunch of tiny line segments.

The easiest way I've come up with so far is still incredibly ugly, but seems to work in a small test:

Create 3' offsets for all the TBC feature lines.  Then take the 3' offsets, and add them to a "TBC Calc Surface".  Make a copy of these feature lines, and explode them, yielding polylines.  Then use the "Create Points, Elev from Surface, Along Polyline/Contour" to set points every 25' along the polyline, getting elevations from the "TBC Calc Surface".  This sets points every 25 feet, missing grade breaks, angle points, PCs, etc.  So, go back, and use "Random Points - Elev from Surface" to manually set points at all the grade breaks, angle points, PCs, curve midpoints, etc., again getting elevations from the "TBC Calc Surface".

This creates points that are out of order, and it creates extra points that aren't wanted, but the field surveyors can probably handle that OK.  It's also a real runaround for the C3D user, but at least it doesn't involve a lot of manual calcs, and it can all be done inside of C3D.

[sinc]

You shouldn't have to mess with the corridor at all.  Wth an alignment on a different site there should be no effect at all on your corridor or anything else on the other site.
I am not sure how to go about placing points at your surface elevation, but you can at least create a profile of your design surface along the alignment from the offset curb and apply a band to give you elevations at your chosen interval and at any PI in the alignment.  You will not have spot elevations on your drawing but you will have the data.

I'm not sure if you understand the problem.

I'm trying to calculate stakeout points, i.e. 3' offsets to the TBC.  The TBC is a feature line.  So I want to create points that get their elevations from the Feature Line, but C3D will not do it.  The whole idea of using the surface is kind of a hack workaround.

[Dinosaur]

Then I think there is an even easier solution for you.  I would still make the offset feature line reside in a different site to prevent interaction.
The point creation method I think will work for you is "along a line / curve".  This will allow a point to be entered along a feature line at elevation at any chosen point either by specifying a distance from the starting point - in your case 25, 50, 75 etc. or optionally just by picking a point along the feature line.

[sinc]

The point creation method I think will work for you is "along a line / curve".

You mean the one in the same group as the "Create Points - Manual" command?  If that's the one you're talking about, I've tried that option.  Not only is it really slow for this task, it forces the user to key in the elevation for every point, and does not take the elevation from the feature line.

I think Autodesk really screwed the pooch on this one...   

[Dinosaur]

I tried one of the options that behaved in this way first and I agree it is too cumbersome.  The point "along a line / curve" creation option I tried before I posted required only keying in a distance from the start of the line or picking any point and returned the point at elevation.  This is still a bit tedious, but no more so than doing the task in general.  Was your option for point elevation set to automatic or manual in your creation settings when you tried it?

[sinc]

Oh, yeah, sorry...  Still getting used to this C3D thing...   

But putting the elevation on "Automatic" just sets the default elevation, it doesn't get the elevation from the feature line.

But OH JOY OF JOYS!  I found the "Edit Points - Elevation to Surface" command!  I've wanted that one for years.  Well, that's not quite true - several years ago, I wrote one in Lisp for LDD, and we've used it A LOT ever since...  (it's available for free download here)

That means I can use any of the Create Point commands to set points along the offset line, then create the "3TBC Calc" surface mentioned earlier, and then datum adjust the points to the "3TBC Calc" surface....  A lot more work than being able to just click on a feature line, and say "Place 3' offsets along this line", but it will suffice for now....

    

[Dinosaur]

Great news . . . I am glad you found it.

I think many of the "missing" functions of Civil 3D are available, just waiting to be discovered in some weird place inside that obtuse interface.  Many very savvy users (a certain engineer/IT person comes immediately to mind) who should be able to grab this software and run prematurely conclude that if they can't make something work as desired after two tries the function is either not included or is broken.  Their patience is exhausted and the learning experience along with production work breaks down - an instant bad rap for Civil 3D.

[sinc]

Great news . . . I am glad you found it.

I think many of the "missing" functions of Civil 3D are available, just waiting to be discovered in some weird place inside that obtuse interface.  Many very savvy users (a certain engineer/IT person comes immediately to mind) who should be able to grab this software and run prematurely conclude that if they can't make something work as desired after two tries the function is either not included or is broken.  Their patience is exhausted and the learning experience along with production work breaks down - an instant bad rap for Civil 3D.

I repeat - I found a workaround.  It is not a great solution, just a way of getting around the problem without turning to some other piece of software.  The initial issue remains.

[Jeff_M]

Well, I looked through the developer documentation, and took a look around in the VBA Object Browser, and C3D is VERY different from LDD.  Also, the documentation seems to be very incomplete.  It might be possible to accomplish what I want, but not necessarily easy - it looks like it will definitely take a bit of time and trial-and-error exploration...  Anyone tried doing any C3D automation yet?

Sorry, sinc. The C3D API is not only VERY different from LDT, it isn't even from the same planet.

IMHO, the documentation is VERY thorough and detailed......but it's geared too much for the seasoned programmer and NOT for the likes of you & me who want to easily/quickly find a solution to a specific problem.

And again IMHO, but this one was beaten into me by Peter Funk of Autodesk and others..... I know that most of your customizations for LDT were via LISP, it is imperative that you cease thinking about lisp as the base language when dealing with C3D. I'll admit I've written, and posted, a few small lisp solutions but by far and large it is easier/quicker to stumble my way through the API to get to the exact object needed for my problem in VBA. Plus there is tons of VBA code provided that the program uses in day to day operations that can be picked apart to see how THEY go about working with the objects.

I've been off for nearly 3 weeks so I'm a bit rusty, but give me a few days and I might be able to come up with something for you on this.

[sinc]

And again IMHO, but this one was beaten into me by Peter Funk of Autodesk and others..... I know that most of your customizations for LDT were via LISP, it is imperative that you cease thinking about lisp as the base language when dealing with C3D. I'll admit I've written, and posted, a few small lisp solutions but by far and large it is easier/quicker to stumble my way through the API to get to the exact object needed for my problem in VBA. Plus there is tons of VBA code provided that the program uses in day to day operations that can be picked apart to see how THEY go about working with the objects.

I've used VBA before, and I don't like the syntax at all.  That's my C background talking, of course.  I actually only learned Lisp because it seemed to be the "big language" for Autocad.  And while that was true for a long time, it doesn't look like Lisp has much future anymore.  I may have to bite the bullet and start using VBA, as much as I hate it.  But compared to VBA, the Lisp syntax is obtuse, long-winded, difficult to read, and extremely clunky to use.  Lisp's only saving grace is that it is powerful and flexible.  So I should be able to switch, and just be glad I'm not programming in Lisp anymore, even if it means suffering through VBA...   

I've been intending to dig into C#.  I'm not thrilled at all by that option, either - just like VBA, it's another Microsoft "thing" that I would prefer to see go away, but Microsoft really likes it, so it's bound to stay...  C# is more like Java, which is a MUCH better language to work in than VBA.  But I'm a bit afraid of what MS might have done to Java in order to create C#...     

I *do* realize that .NET is the way MS is going, though, and an OO language that is .NET-enabled is basically mandatory for Windows systems, going forward into the future...  (...although I admit I still dream that one day Autodesk will start replacing Lisp with a superior OO scripting language, like Python...  )

And actually, I AM a seasoned programmer (my primary language is Obj-C, but I know at least 20 others to some degree or other - Lisp is a very new language for me).  I'm a lot better programmer than I am CAD engineer - I have over ten years of industry experience in software development, as opposed to three years in Autocad.  But digging through all that stuff takes TIME, something that's been in short supply lately for me...   

[Jeff_M]

$&$^*%$%&^#%^#!

Thought I had my first big & cool proggy to write for C3D but after perusing the help, discussion groups, ADN, and just brute force entity searching, it appears that Adesk has not exposed the Grading Featurelines' API to us! Without access to the featureline's internal database there is no <good> way I can see to do what Sinc is requesting........<sigh>

Sinc, I know that you are way ahead of me programming wise. I was merely trying to steer you away from trying to convert your (quite useful) LDT customizations in LISP. Most, if not all, of them really do not even apply any longer since C3D goes about getting/using/outputting the data in ways previously unthougt of. While the same idea for a shortcut may be valid, how you impement it will be far different than what you previously used.

Just keep voicing your concerns and if we can't find a workaround via Code we can try pestering the guys/gals in NH.