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.

[sinc]

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>

Yep!  I discovered that, too.  I also ran into a LOT of other documentation that was missing, broken links everywhere, etc.  But I know how to use an object browser, so I might be able to figure it out on my own.  But often you can only see so much with those object browsers, and it isn't enough.  It would be a helluva lot easier if Autodesk would publish some documentation...   

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.

I'd already intended that.  In the process of writing the routines I've already written (most of which I made public), I discovered how painful it is to try to do anything large in Lisp.  Lisp is a neat language, incredibly powerful considering its relative simplicity, but its weaknesses really show through when attempting any large project.

I was only hoping I could whip out a quick one in Lisp, since I've already written a bunch of stuff in Lisp for Autocad, and none in VBA.  But I'm still thinking of trying C#, just so I can see what's up with that language...  I still might end up deciding VBA is the way to go, but my dislike of VBA goes back over a decade, so I'm even willing to tackle Microsoft's new language if it shows promise of being "not VBA"...   

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

I've already submitted feature requests.  Hopefully, others do too.  We were really getting into this C3D thing, until we realized Autodesk has included almost no support for construction staking...  It's a huge problem, and seems difficult to believe that Autodesk has gone this far into the product development without realizing it.  So hopefully, they'll grasp the enormity of the gap very quickly.  At least that "Edit Points - Elevations from Surface" command is flexible enough that it can be forced to work for a lot of tasks.

The problems would largely be fixed by a simple set of routines for creating offset points for feature lines, and ways to datum-adjust points using feature lines.  Although I STILL really like the idea of a "self-calculating parking lot", where the user only has to specify something like "3' offsets spaced no more than 25' apart", and all the points are created automatically... 

[Dinosaur]

I am going to insert a quick question here.  There is a distinction being drawn between the elevation of a point on a surface and the same point on a feature line that defines this surface.  I was under the impression that any point on that feature line was identical in elevation to the some point on the surface.  If it is not identical, how much might the difference amount to?

[sinc]

I am going to insert a quick question here.  There is a distinction being drawn between the elevation of a point on a surface and the same point on a feature line that defines this surface.  I was under the impression that any point on that feature line was identical in elevation to the some point on the surface.  If it is not identical, how much might the difference amount to?

The problem is that we need to calculate OFFSETS to points.  Therefore, the elevation of the point is actually the elevation of the surface some distance away.  For example, the 3TBC points should be 3' from the TBC, but have the grade of the TBC, not the sidewalk or the dirt 3' behind the curb.  The difference varies, depending on the exact conditions.

[Dinosaur]

If you know what your design cross section is, can you not throw in a calculation of the slope times the offset (in this case assuming a 2% slope from the back of curb would be +0.06 feet)?  I think an expression could be added to do this calculation.

[sinc]

If you know what your design cross section is, can you not throw in a calculation of the slope times the offset (in this case assuming a 2% slope from the back of curb would be +0.06 feet)?  I think an expression could be added to do this calculation.

No.  It is almost never a consistent difference.  Maybe when staking curb that is attached to a sidewalk, but that's far from a standard occurance, especially in parking lots.

Also, as surveyors, we generally stake offsets to EVERYTHING.  There's not any consistency at all in the elevation difference between the point of interest and the offset point.  That's why we really need the ability to create graded offset points from feature lines.

Thanks for the thoughts, though.  Keep em coming...   

[Jeff_M]

OK, someone just shoot me. I took an oath, of sorts, to abandon any thoughts of prgramming C3D in lisp. Yet here I am, about to post something that does pretty much what Sinc is wanting.......and the only way to do it was with lisp (well, i could have tried to kludge along in VBA accessing the lisp (vlax-curve-*) functions, but this seemed much more elegant). The only thing I'm not sure about is what to do at angle points...you'll see what i mean if you try this on a parking lot's curb.
Use, modify, crucify as you please but DO NOT USE ON A PRODUCTION DRAWING until you've tested it out....PLEASE! I know that featurelines act like parcel lines and can 'disrupt' things in drawings.

Have Fun!

Code: [Select]

*deleted* due to revised code further on in the thread

[Dinosaur]

Thanks for sharing your effort Jeff.  The interactions with other drawing elements by a feature line like you are concerned with can be prevented by the creation of a new site for the feature line.  It is probably the wise path to have a site already created and reserved for any staking operations such as this.

[Jeff_M]

Thanks Steve. The Sites is something I strictly adhere to, but I'm not sure how I can specify which site an offset of a featureline gets placed in. Without time for testing, does it go to the parent line's Site or maybe to the Current default Site?

I wish I had a bit more time to focus on this, maybe while watching the games tomorrow.......

Have a good weekend!

[Dinosaur]

I would suspect it would go into the current default site, but I would think it safer to either create a new site or one alresdy in place to recieve any similar objects if possible.  I have only seen the site selected via the dialog box where the current default is displayed.  Others can be selected from a list box or a new site can be created in the dialog box.

[sinc]

Thanks, Jeff!

I'm currently distracted by what's higher-priority items, but hopefully I'll get a chance to look at what you did over this weekend.

Looks like you're using params on the feature line.  Something that I noticed is that C3D puts breaks in feature lines around curves.  For example, say we start with a polyline that has an arc segment in it.  When I create the feature line, I'll usually use a mid-ordinate distance of 0.1 feet.  Then when I explode the feature line, I now have a polyline made only of line segments, with lots of little lines going around the arc.  (All this because, despite its fancy features, C3D still can't handle a curved breaklines.  Guess they're too disruptive to the whole TIN theory...)

This is one of the things that screws up the "Create Points - Vertices of Polyline - Automatic" command.  That command is the only one that currently takes its elevation from the feature line.  Unfortunately, because of the issue mentioned above, it tends to spray a ton of points on every curve.  (It's also basically impossible to control, which means the command is not useful for this task.)

Don't know if this has an impact on what you did - I'll find out when I try it out.  Or you may notice it if you work on it tomorrow.

[Jeff_M]

Hi Sinc,
You're welcome!

Yes, I know what an exploded feature looks like <yuck!> but I was pleasantly surprised to see that all the test feature lines I tested started with a 0.00 param and ended with a param corresponding to the number of vertices in the FeatureLine. For instance, 1 feature line is composed of  "tangent, arc, arc, tangent, tangent" which has 6 vertice and returns an end param of 5.0 (params are 0 based).

Give it a try, I think you'll be somewhat surprised. I know I was.....

[sinc]

Hi Sinc,
You're welcome!

Yes, I know what an exploded feature looks like <yuck!> but I was pleasantly surprised to see that all the test feature lines I tested started with a 0.00 param and ended with a param corresponding to the number of vertices in the FeatureLine. For instance, 1 feature line is composed of  "tangent, arc, arc, tangent, tangent" which has 6 vertice and returns an end param of 5.0 (params are 0 based).

Give it a try, I think you'll be somewhat surprised. I know I was.....

Great!  I'm actually stuck in styles at the moment, so I can try and get some Topo surveys put togther, but I'll definitely check it out when I get back to Survey calcs.  So much to do...   

[Jeff_M]

Just for the record, the lisp program I posted above really isn't useful for anything other than to demonstrate that the (vlax-curve-*) functions appear to work with FeatureLines. I have a pretty good idea of how to adapt that code to a real world working program, but it will take some time to iron out the kinks.

Stay tuned......

[Jeff_M]

OK, here's a version that correctly measures the intervals along the feature line. It also handles angle points better....if the offset is to the outside of an angle point then 2 points will be set, one on each tangent 0.01 units from tha actual angle point. Still not sure how to handle an angle point where the offset is to the inside.....right now 2 points are set at the offset's angle pt. Maybe someone that actually does stakeout calcs can advise how to address this?

Code: [Select]

*deleted* due to revised code further on in the thread
There are some other minor issues to work out, but I'm out of time for this. Maybe when I need to do some staking, if no one else has taken on ironing out the wrinkles, I'll pick it back up.

Issues still need addressing:

• Interior angles
  
• Closed featurelines, the last point stakes as the first point (to see what I mean, create a rectangular featureline and run routine.....)
• Add description to the points....best done by setting the default to what is desired then set it back to what t was.
• Check for/add a Site specifically for the offset featurelines?    (Even though they get deleted, it could still cause problems in sites with other data).

[sinc]

OK, here's a version that correctly measures the intervals along the feature line. It also handles angle points better....if the offset is to the outside of an angle point then 2 points will be set, one on each tangent 0.01 units from tha actual angle point. Still not sure how to handle an angle point where the offset is to the inside.....right now 2 points are set at the offset's angle pt. Maybe someone that actually does stakeout calcs can advise how to address this?

Create an offset of the polyline.  The vertex on the offset line is where we usually put points in situations like this, e.g. if we're staking 3' offsets to TBC we'd call that point "3x3 TBC".  The actual distance between the corner and the offset would vary depending upon the angle.  I'm not sure the easiest way to handle it in code - you probably don't want to actually create an offset polyline.  So some trig would be involved - maybe using the First Derivative at points just before and just after the vertex, and using those bearings to calculate the offset point.

[Jeff_M]

I've reworked the code so the offsets at exterior angle points are placed correctly and I eliminated duplicate points being set on the interior angle offsets.

Yes, Sinc, I am actually crating an offset featureline since there are NO properties available via Activex it would be impossible to calculate any data along a curved section otherwise.

Code: [Select]

;|routine to demonstrate placing 'stakeout' points along a C3D FeatureLine.
  This has had limited testing and may cause instability issues due to
  the adding/removing of feature lines. Use at your own risk!
  Jeff Mishler - Nov. 2007 - written/tested in C3D2007-SP3
  additions to the code could include setting the descriptions to something meaningful.
  As it is, it just places a point at a specified offset and interval along a selected
  featureline. All vertices are included along the way.
  Version 2.0 measures along original featureline instead of the offset line
  and addresses angle points a bit better. Nov. 25, 2006
  Version 2.1 - minor tweaks to improve actions taken at angle points. Nov. 27, 2006
|;
(defun c:stakefeatures (/    *acad*     c3d c3ddoc
coords    dist       disttonextparam
ent    flatlist   interval offcoords
offdist    offpt      points secondpt
ss    startpt    thisparam tmpline
totaldist  *error*
       )
  (defun *error* (msg)
    (if msg
      (princ (strcat "\n....." msg))
    )
    (mapcar 'vlax-release-object (list points c3ddoc c3d))
    (princ)
  )
  ;;function to determine if vertice is angle point or curve start/end.
  (defun isAnglePt?
(obj idx / p1 p2 p3 dist1 dist1a dist2 dist2a angpt)
    (defun 2dpt (pt)
      (list (car pt) (cadr pt))
    )
    (setq p1 (2dpt (vlax-curve-getpointatparam obj (1- idx)))
  p2 (2dpt (vlax-curve-getpointatparam obj idx))
  p3 (2dpt (vlax-curve-getpointatparam obj (1+ idx)))
  dist1 (distance p1 p2)
  dist2 (distance p2 p3)
  dist1a (- (vlax-curve-getdistatparam obj idx)
    (vlax-curve-getdistatparam obj (1- idx))
)
  dist2a (- (vlax-curve-getdistatparam obj (1+ idx))
    (vlax-curve-getdistatparam obj idx)
)
    )
    (if (and (equal dist1 dist1a 0.0001)
     (equal dist2 dist2a 0.0001)
)
      (setq angpt t)
    )
    angpt
  )
  (setq *acad* (vlax-get-acad-object))
  (setq C3D (vla-getinterfaceobject
      *acad*
      "AeccXUiLand.AeccApplication.4.0"
    )
  )
  (setq C3Ddoc (vla-get-activedocument C3D))
  (setq points (vlax-get C3Ddoc 'points))
  (if (not *offdist*)
    (setq *offdist* 5.0)
  )
  (if (setq offdist
     (getdist
       (strcat
"\nOffset distance, use negative value for left offset?<"
(rtos *offdist*)
">: "
       )
     )
      )
    (setq *offdist* offdist)
  )
  (if (not *interval*)
    (setq *interval* 25.0)
  )
  (if (setq interval (getdist (strcat "\nStakeout interval?<"
      (rtos *interval*)
      ">: "
      )
     )
      )
    (setq *interval* interval)
  )
  ;;initiate selection loop...goes until nothing selected.
  (while (setq ss (ssget ":S:E" '((0 . "AECC_FEATURE_LINE"))))
    (setq ent (ssname ss 0))
    (setq startpt  (vlax-curve-getstartpoint ent)
  secondpt (vlax-curve-getpointatparam ent 1.0)
  offpt    (polar startpt
  (if (minusp *offdist*)
    (+ (angle startpt secondpt) (/ pi 2.0))
    (- (angle startpt secondpt) (/ pi 2.0))
  )
  (abs *offdist*)
   )
    )
    ;; must use the (command) to offset as there is no ActiveX method for this for featurelines
    (command "offset" (abs *offdist*) ent offpt "")
    (setq tmpline   (entlast)
  thisparam (vlax-curve-getstartparam ent)
  coords    (list (vlax-curve-getclosestpointto
    tmpline
    (vlax-curve-getpointatparam ent thisparam)))
  totaldist 0.0
    )
    (while (< thisparam (vlax-curve-getendparam ent))
      (setq disttonextparam
     (vlax-curve-getdistatparam
       ent
       (1+ thisparam)
     )
      )
      (if (< (vlax-curve-getdistatparam ent thisparam) totaldist)
(setq
  coords (cons (vlax-curve-getclosestpointto
tmpline
(vlax-curve-getpointatdist ent totaldist)

       )
       coords
)
)
      )
      (while (< (setq totaldist (+ totaldist *interval*))
disttonextparam
     )
(setq
  coords (cons (vlax-curve-getclosestpointto
tmpline
(vlax-curve-getpointatdist ent totaldist)

       )
       coords
)
)
      )
      (setq thisparam (1+ thisparam))
      (if (and (< thisparam (vlax-curve-getendparam ent))
       (isAnglePt? ent thisparam)
  )
(progn
  (setq dist (vlax-curve-getdistatparam ent thisparam)
tmp1 (vlax-curve-getpointatdist ent (- dist 0.01))

tmp2 (vlax-curve-getclosestpointto tmpline tmp1)
  )
  (if (equal (vlax-curve-getdistatparam tmpline thisparam)
     (vlax-curve-getdistatpoint tmpline tmp2)
     0.001
      )
    (setq coords (cons tmp2 coords))
    (progn
      (setq tmp2   (vlax-curve-getpointatdist
     tmpline
     (+ (vlax-curve-getdistatpoint tmpline tmp2) 0.01)
   )
    coords (cons tmp2 coords)
      )
      (setq tmp1   (vlax-curve-getpointatdist ent (+ dist 0.01))

    tmp2   (vlax-curve-getclosestpointto tmpline tmp1)
    tmp2   (vlax-curve-getpointatdist
     tmpline
     (- (vlax-curve-getdistatpoint tmpline tmp2) 0.01)
   )
    coords (cons tmp2 coords)
      )
    )
  )
)
(setq
  coords (cons (vlax-curve-getclosestpointto
tmpline
(vlax-curve-getpointatparam ent thisparam)

       )
       coords
)
)

      )
    )
    (entdel tmpline)
    (setq flatlist (apply 'append (reverse coords)))
    (vlax-invoke
      points
      'addmultiple
      (length coords)
      flatlist
      'added
    )
  )
  (*error* "Finished!")
  (princ)
)
While it would be possible to incorporate other items, I think that, for now, letting the user manually set a correct site, current point number, point group, etc. prior to running the program is the way to go.......

[sinc]

I've reworked the code so the offsets at exterior angle points are placed correctly and I eliminated duplicate points being set on the interior angle offsets.

Yes, Sinc, I am actually crating an offset featureline since there are NO properties available via Activex it would be impossible to calculate any data along a curved section otherwise.

I haven't had time to work with it yet, so I'm not entirely sure what you're doing.  Are you just getting a 3D point along the feature line?

Have you tried using the First Derivative?  If it works, then I think you should be able to use routines like the following to calculate an offset at any point:

Code: [Select]

  (setq *VLutil:quad*    (/ PI 2)) ; radians in a quadrant

  (defun VLutil:azimuthAtParam (entity selPar / dvec)
    (setq dvec (vlax-curve-getFirstDeriv entity selPar))
    (angle '(0 0) dvec)
    ;; note: angle projected on xy plane
  ) ;defun VLutil:azimuthAtParam


 ; value of dir: 1 = clockwise (right) -1 = counterclockwise (left)
  (defun VLutil:offsetAtPoint (entity point dir offDist)
    (if (= offDist 0)
      point
      (polar
point
(- (VLutil:azimuthAtParam
     entity
     (vlax-curve-getParamAtPoint entity point)
   ) ;_ VLutil:azimuthAtParam
   (* dir *VLutil:quad*)
) ;_ +
offDist
      ) ;_ polar
    ) ;if
  ) ;defun VLutil:offsetAtPoint


  (defun VLutil:offsetAtParam (entity param dir offDist)
    (if (= offDist 0)
      (vlax-curve-getPointAtParam entity param)
      (polar
(vlax-curve-getPointAtParam entity param)
(- (VLutil:azimuthAtParam entity param) (* dir *VLutil:quad*))
offDist
      ) ;_ polar
    ) ;if
  ) ;_ defun

This came from my standard utility library.  There are two routines in there - one to calculate an offset point at a given Param along the entity, and one to calculate an offset at at a point along the entity.  The azimuthAtParam routine is a utility routine used by both of the others.

[Jeff_M]

I've never used the FirstDerivitive or SecondDerivitive, mainly because I don't have a clue what they represent.....

Essentially, yes, I am getting 3d points along the featureline then casting them to the offset featureline (getclosestpointto). Where there is an external angle I use 2 points, 0.01 units in each direction from the actual angle point, find the corresponding point on the offset line, then move those points back the 0.01 units to be exactly offset from the angle point. On Interior angles, the closestpointto always returns the offset angle point.

HTH

[sinc]

I've never used the FirstDerivitive or SecondDerivitive, mainly because I don't have a clue what they represent.....

Oh, OK, try the little library routines I posted, then.

First Derivative is essentially the direction vector of the object at the specified point (or of a tangent at the point, if the point is in a curve).  So by adding or subtracting 90° (PI/2 radians), you can get the direction vector for an offset.  The direction of the entity is the direction of increasing parameter numbers.

The routines I posted simply take an object, a point/param, a direction (clockwise or counterclockwise), and an offset distance.  Then they return the coordinates of the offset.  You may or may not have to deal with the elevation separately - I haven't tried running the routines on 3D linework.  But they might return a point with the correct elevation as they are.  If not, a minor tweak might correct that issue.

Net result is that, by using those little library routines, you should be able to eliminate the need for creating the offset.

Second Derivative is basically the "rate of change".  A line ALWAYS has a second derivative of 0.  I think clockwise arcs have second derivatives less-than zero, and counterclockwise is greater than zero (or maybe it was the other way around).  The absolute value of the second deriv is bigger for sharper curves.  It probably isn't useful in this particular situation, but it is very useful in other situations.

When I get a chance, I'll start playing with it.  But right now, I'm still stuck setting up Styles so we can get our pilot project done...   

[Jeff_M]

OK, thanks for the quick lesson on derivitives! Based on this information and using revised versions of your functions I've come up with a routine that does the best job, yet, of staking the offsets. And now there's no worry of corrupting sites due to offsetting featurelines!

The only thing left, if it's really required, would be to set the descriptions of the points. However, to do so would mean setting the points one at a time and setting the description immediately after creation...the 'AddMultiple method of the Points object will no longer be able to be used. It may slow it down a bit.

Code: [Select]

;|routine to demonstrate placing 'stakeout' points along a C3D FeatureLine.
  This has had limited testing and may cause instability issues due to
  the adding/removing of feature lines. Use at your own risk!
  Jeff Mishler - Nov. 2007 - written/tested in C3D2007-SP3
  additions to the code could include setting the descriptions to something meaningful.
  As it is, it just places a point at a specified offset and interval along a selected
  featureline. All vertices are included along the way.
  Version 2.0 measures along original featureline instead of the offset line
  and addresses angle points a bit better. Nov. 25, 2006
  Version 2.1 - minor tweaks to improve actions taken at angle points. Nov. 27, 2006
  Version 3.0 - removed code to offset featureline, replaced with code to calculate
    the offset points direct (thanks to Sinc for the functions to do this)
|;
(defun c:stakefeatures (/   *acad*    ang1      ang2
c3d   c3ddoc    coords    disttonextparam
ent   entity    flatlist  interval
off1   off2     offdist   points
pt1   ss     thisparam tmp1
tmp2   tmp3     totaldist *error*
       )
  (defun *error* (msg)
    (if msg
      (princ (strcat "\n....." msg))
    )
    (mapcar 'vlax-release-object (list points c3ddoc c3d))
    (princ)
  )
  ;;function to determine if vertice is angle point or curve start/end.
  (defun isAnglePt?
(obj idx / p1 p2 p3 dist1 dist1a dist2 dist2a angpt)
    (defun 2dpt (pt)
      (list (car pt) (cadr pt))
    )
    (setq p1 (2dpt (vlax-curve-getpointatparam obj (1- idx)))
  p2 (2dpt (vlax-curve-getpointatparam obj idx))
  p3 (2dpt (vlax-curve-getpointatparam obj (1+ idx)))
  dist1 (distance p1 p2)
  dist2 (distance p2 p3)
  dist1a (- (vlax-curve-getdistatparam obj idx)
    (vlax-curve-getdistatparam obj (1- idx))
)
  dist2a (- (vlax-curve-getdistatparam obj (1+ idx))
    (vlax-curve-getdistatparam obj idx)
)
    )
    (if (and (equal dist1 dist1a 0.0001)
     (equal dist2 dist2a 0.0001)
)
      (setq angpt t)
    )
    angpt
  )
;;;; 
  (defun VLutil:azimuthAtParam (entity selPar / dvec)
    (setq dvec (vlax-curve-getFirstDeriv entity selPar))
    (angle '(0 0) dvec)
    ;; note: angle projected on xy plane
  ) ;defun VLutil:azimuthAtParam
;;;;
  (defun VLutil:offsetAtParam (entity param offDist)
    (if (= offDist 0)
      (vlax-curve-getPointAtParam entity param)
      (polar
(vlax-curve-getPointAtParam entity param)
(- (VLutil:azimuthAtParam entity param) (/ pi 2.0))
offDist
      ) ;_ polar
    ) ;if
  ) ;_ defun
  (defun VLutil:offsetAtPoint (entity point offDist)
    (if (= offDist 0)
      point
      (polar
point
(- (VLutil:azimuthAtParam
     entity
     (vlax-curve-getParamAtPoint entity point)
   ) ;_ VLutil:azimuthAtParam
   (/ pi 2.0)
) ;_ +
offDist
      ) ;_ polar
    ) ;if
  ) ;defun VLutil:offsetAtPoint
;;;;;;;;
  (setq *acad* (vlax-get-acad-object))
  (setq C3D (vla-getinterfaceobject
      *acad*
      "AeccXUiLand.AeccApplication.4.0"
    )
  )
  (setq C3Ddoc (vla-get-activedocument C3D))
  (setq points (vlax-get C3Ddoc 'points))
  (if (not *offdist*)
    (setq *offdist* 5.0)
  )
  (if (setq offdist
     (getdist
       (strcat
"\nOffset distance, use negative value for left offset?<"
(rtos *offdist*)
">: "
       )
     )
      )
    (setq *offdist* offdist)
  )
  (if (not *interval*)
    (setq *interval* 25.0)
  )
  (if (setq interval (getdist (strcat "\nStakeout interval?<"
      (rtos *interval*)
      ">: "
      )
     )
      )
    (setq *interval* interval)
  )
  ;;initiate selection loop...goes until nothing selected.
  (while (setq ss (ssget ":S:E" '((0 . "AECC_FEATURE_LINE"))))
    (setq ent (ssname ss 0))
    (setq thisparam (vlax-curve-getstartparam ent)
  coords    (list (VLutil:offsetAtParam ent thisparam *offdist*))
  totaldist 0.0
    )
    (while (< thisparam (vlax-curve-getendparam ent))
      (setq disttonextparam
     (vlax-curve-getdistatparam
       ent
       (1+ thisparam)
     )
      )
      (if (< (vlax-curve-getdistatparam ent thisparam) totaldist)
(setq
  coords (cons (VLutil:offsetAtPoint
ent
(vlax-curve-getpointatdist ent totaldist)
*offdist*
       )
       coords
)
)
      )
      ;;;set points at the desired interval along the segment
      (while (< (setq totaldist (+ totaldist *interval*))
disttonextparam
     )
(setq
  coords (cons (VLutil:offsetAtPoint
ent
(vlax-curve-getpointatdist ent totaldist)
*offdist*
       )
       coords
)
)
      )
      (setq thisparam (1+ thisparam))
      ;;we're at the next param, is
      (if (and (< thisparam (vlax-curve-getendparam ent))
       (isAnglePt? ent thisparam)
  )
(progn
  ;;;it's an angle point, now see if it's an internal or external angle
  (setq pt1  (vlax-curve-getpointatparam ent thisparam)
ang1 (VLutil:azimuthAtParam ent (- thisparam 0.01));;;get azimuth back
ang2 (VLutil:azimuthAtParam ent (+ thisparam 0.01));;;get azimuth ahead
off1 (polar pt1 (- ang1 (/ pi 2.0)) *offdist*)
off2 (polar pt1 (- ang2 (/ pi 2.0)) *offdist*)
tmp1 (polar off1 ang1 20)
tmp2 (polar off2 ang2 -20)
tmp3 (inters off1 tmp1 off2 tmp2 nil);;calc intersection point of offsets
  )
  (if (not (equal ang1 (angle off1 tmp3) 0.001))
    ;;it's an internal, return the point of intersection
    (setq coords (cons tmp3 coords))
    (progn
      ;;;it's an external, use both offset points
      (setq coords (cons off1 coords)
    coords (cons off2 coords)
      )
    )
  )
)
(setq
  coords (cons (VLutil:offsetAtParam ent thisparam *offdist*)
       coords
)
)

      )
    )
    (setq flatlist (apply 'append (reverse coords)))
    (vlax-invoke
      points
      'addmultiple
      (length coords)
      flatlist
      'added
    )
  )
  (*error* "Finished!")
  (princ)
)


[sinc]

Cool!

I may expand what you've done, when I get a chance.  One thing that I want is the ability to automatically set the radius point of smaller-radius curves, and give the radius points a description like "4.5 RP" for 4.5-foot radius, or "3 RP" for 3-foot, etc.  If the radius is bigger than a user-specified value, then no radius point should be set.

If you're interested, you can try and do it yourself.  I'm attaching my VLutil.LSP library.  It has the routines I posted earlier, plus more.  They can be pretty useful.  For example, there's a MarkPoint routine which draws a temporary X on the screen at the specified point (the X goes away when the user PANs or ZOOMs the screen).  This is useful in lots of routines, for indicating a spot to the user without adding any elements to the drawing.

The key routine for setting a Radius Point of a polyline is the VLUtil:rpOfSegment routine, near the end.  It uses the Second Derivative and the Bulge to set the radius point.

Once I looked at it, I remembered that I steered you a bit wrong.  You can't determine which side of the polyline by using Second Derivative, but the magnitude of the Second Derivative is the same as the radius point of the curve.  (This gets a bit funky with splines, and may not work as expected, since Splines do not have a consistent radius point).  Instead, use the Buldge to determine which side the radius point is on.  Then (ABS Second Deriv) is the same as the length of the radius.  In other words, I use 2nd deriv to get the radius, 1st deriv to get the tangent bearing, and Buldge to figure out which side of the polyline I want to be on.  That lets me calculate the Radius Point.

(I also have a similar library of utility commands for Land Desktop.  It's available in that SincPac thing I posted in another thread.)

[Jeff_M]

Thanks for the VLutil.lsp! I'm sure it will come in handy even though I'm trying to steer away from lisp. I have an "Xmarksthespot.lsp" that I wrote quite some time ago for use in a pline editting function.

As for calc'ing the radius of these feature lines....I wish you luck! These things don't have Bulges so I think that comparing adjacent firstderiv's may need to be used (but now I'm talking over my head so it's more of a best guess effort here). But feel free to do with it as you please, even if it's only a starting point for what you need.

For me, I learned quite a bit about those 2 (vlax-curve-) functions as well as what the C3D programmers decided waht we didn't need to mucking around with....ie: they seem to think that we will damage the database if they allowed us access to the featurelines. (Good possibility since those are some of the items that CAN destroy your drawing, if not handled correctly....sounds like I'm talking about nitro-glycerin here :-/)

I have, and use, your functions you previously posted - SincPac. Quite nice to not have to roll my own for everything! Thanks for those, too!

[sinc]

I have, and use, your functions you previously posted - SincPac. Quite nice to not have to roll my own for everything! Thanks for those, too!

Yeah, some of those have really cut our calc times.  The XGRD, PT2ALIGN, and PT2SURF commands in particular have become real workhorses for us in Land Desktop.

I sent a feature request to Autodesk.  I actually asked for a full-fledged "Stakeout Object".  This object could be linked to a whole series of Feature Lines, and options like "Offset Distance", "Maximum Gap Distance", "Set Radius Points", etc. could all be set in the Stakeout Object.  The parameters in the Stakeout Object could be overridden for specific feature lines, for example, if one line need 4-foot offsets instead of 3-foot offsets for some reason.

Then if the feature lines change, the Offset Points also change.  If the user changes the Maximum Gap Distance, the points are recalc'd.  If the user adds a grade break to a feature line, the points are recalc'd, and a point is added at the new grade break.  The points in a feature set auto-renumber, so that they stay in a coherent staking order for field guys.  And any other features that come up.

We'll see how they respond...   

[Jeff_M]

.....  I actually asked for a full-fledged "Stakeout Object".  .....
We'll see how they respond...   

Now THAT would be too slick! Great ideas, who'd you send these to? Might I suggest you also send this request to Nick Zeeben? He's a programmer recently hired  to be on the C3D team...I think he has somewhat of a survey background as well. nick.zeeben At Auodesk dot youknow

Here's hoping they respond kindly!

[sinc]

Hard to believe it's been nearly three months, and I'm finally getting to construction calcs.  That's what winter in Colorado can do...   

But construction calcs are becoming a hot item again.  I finally got a chance to start digging through this.  I seemed to find some errors in the code.  1) totaldist seemed to be calculated incorrectly and 2) the routine would blow up if two segments were tangent, such as when there's a grade break in a long straight section.  I fixed those.  Also, to make the code a bit more readable, I changed "totaldist" to "currentdist", and "disttonextparam" to "distatnextparam".  And I went ahead and made the angle-point check a little tighter (param±.0001 instead of ±.01 to get azimuth forward and azimuth back).  It's very likely that the .01 is safe in all real-world situations, but .0001 made me feel better.  And I added Undo marks.

I think it's all working now.  We're slowly getting this beast whipped into shape...   

Code: [Select]

;|routine to demonstrate placing 'stakeout' points along a C3D FeatureLine.
  This has had limited testing and may cause instability issues due to
  the adding/removing of feature lines. Use at your own risk!
  Jeff Mishler - Nov. 2007 - written/tested in C3D2007-SP3
  additions to the code could include setting the descriptions to something meaningful.
  As it is, it just places a point at a specified offset and interval along a selected
  featureline. All vertices are included along the way.
  Version 2.0 measures along original featureline instead of the offset line
  and addresses angle points a bit better. Nov. 25, 2006
  Version 2.1 - minor tweaks to improve actions taken at angle points. Nov. 27, 2006
  Version 3.0 - removed code to offset featureline, replaced with code to calculate
    the offset points direct (thanks to Sinc for the functions to do this)
  Version 3.1 - bug fixes, add undo marks Feb 21, 2007 (by Sinc)
|;
(defun c:stakefeatures (/   *acad*    ang1      ang2
c3d   c3ddoc    coords    distatnextparam
ent   entity    flatlist  interval
off1   off2     offdist   points
pt1   ss     thisparam tmp1
tmp2   tmp3     currentdist *error*
                        usrcmd
       )
  (setq usrcmd (getvar "cmdecho"))
  (setvar "cmdecho" 0)
  (defun *error* (msg)
    (if msg
      (princ (strcat "\n....." msg))
    )
    (mapcar 'vlax-release-object (list points c3ddoc c3d))
    (princ)
  )
  ;;function to determine if vertice is angle point or curve start/end.
  (defun isAnglePt?
(obj idx / p1 p2 p3 dist1 dist1a dist2 dist2a angpt)
    (defun 2dpt (pt)
      (list (car pt) (cadr pt))
    )
    (setq p1 (2dpt (vlax-curve-getpointatparam obj (1- idx)))
  p2 (2dpt (vlax-curve-getpointatparam obj idx))
  p3 (2dpt (vlax-curve-getpointatparam obj (1+ idx)))
  dist1 (distance p1 p2)
  dist2 (distance p2 p3)
  dist1a (- (vlax-curve-getdistatparam obj idx)
    (vlax-curve-getdistatparam obj (1- idx))
)
  dist2a (- (vlax-curve-getdistatparam obj (1+ idx))
    (vlax-curve-getdistatparam obj idx)
)
    )
    (if (and (equal dist1 dist1a 0.0001)
     (equal dist2 dist2a 0.0001)
)
      (setq angpt t)
    )
    angpt
  )
;;;; 
  (defun VLutil:azimuthAtParam (entity selPar / dvec)
    (setq dvec (vlax-curve-getFirstDeriv entity selPar))
    (angle '(0 0) dvec)
    ;; note: angle projected on xy plane
  ) ;defun VLutil:azimuthAtParam
;;;;
  (defun VLutil:offsetAtParam (entity param offDist)
    (if (= offDist 0)
      (vlax-curve-getPointAtParam entity param)
      (polar
(vlax-curve-getPointAtParam entity param)
(- (VLutil:azimuthAtParam entity param) (/ pi 2.0))
offDist
      ) ;_ polar
    ) ;if
  ) ;_ defun
  (defun VLutil:offsetAtPoint (entity point offDist)
    (if (= offDist 0)
      point
      (polar
point
(- (VLutil:azimuthAtParam
     entity
     (vlax-curve-getParamAtPoint entity point)
   ) ;_ VLutil:azimuthAtParam
   (/ pi 2.0)
) ;_ +
offDist
      ) ;_ polar
    ) ;if
  ) ;defun VLutil:offsetAtPoint
;;;;;;;;
  (setq *acad* (vlax-get-acad-object))
  (setq C3D (vla-getinterfaceobject
      *acad*
      "AeccXUiLand.AeccApplication.4.0"
    )
  )
  (setq C3Ddoc (vla-get-activedocument C3D))
  (setq points (vlax-get C3Ddoc 'points))
  (if (not *offdist*)
    (setq *offdist* 5.0)
  )
  (if (setq offdist
     (getdist
       (strcat
"\nOffset distance, use negative value for left offset?<"
(rtos *offdist*)
">: "
       )
     )
      )
    (setq *offdist* offdist)
  )
  (if (not *interval*)
    (setq *interval* 25.0)
  )
  (if (setq interval (getdist (strcat "\nStakeout interval?<"
      (rtos *interval*)
      ">: "
      )
     )
      )
    (setq *interval* interval)
  )
  ;;initiate selection loop...goes until nothing selected.
  (command "._undo" "_begin")
  (while (setq ss (ssget ":S:E" '((0 . "AECC_FEATURE_LINE"))))
    (setq ent (ssname ss 0))
    (setq thisparam (vlax-curve-getstartparam ent)
  coords    (list (VLutil:offsetAtParam ent thisparam *offdist*))
    )
    (while (< thisparam (vlax-curve-getendparam ent))
      (setq currentdist
     (vlax-curve-getdistatparam
       ent
       thisparam
     )
            distatnextparam
     (vlax-curve-getdistatparam
       ent
       (1+ thisparam)
     )
      )
      ;;;set points at the desired interval along the segment
      (while (< (setq currentdist (+ currentdist *interval*))
distatnextparam
     )
(setq
  coords (cons (VLutil:offsetAtPoint
ent
(vlax-curve-getpointatdist ent currentdist)
*offdist*
       )
       coords
)
)
      )
      (setq thisparam (1+ thisparam))
      ;;we're at the next param, is
      (if (and (< thisparam (vlax-curve-getendparam ent))
       (isAnglePt? ent thisparam)
  )
(progn
  ;;;it's an angle point, now see if it's an internal or external angle
  (setq pt1  (vlax-curve-getpointatparam ent thisparam)
ang1 (VLutil:azimuthAtParam ent (- thisparam 0.0001));;;get azimuth back
ang2 (VLutil:azimuthAtParam ent (+ thisparam 0.0001));;;get azimuth ahead
off1 (polar pt1 (- ang1 (/ pi 2.0)) *offdist*)
off2 (polar pt1 (- ang2 (/ pi 2.0)) *offdist*)
tmp1 (polar off1 ang1 20)
tmp2 (polar off2 ang2 -20)
tmp3 (inters off1 tmp1 off2 tmp2 nil);;calc intersection point of offsets
  )
          (if (null tmp3)
            ;;could not get intersect; must be tangent segments, return one point
            (setq coords (cons off1 coords))
            (if (not (equal ang1 (angle off1 tmp3) 0.001))
              ;;it's an internal, return the point of intersection
              (setq coords (cons tmp3 coords))
              ;;;it's an external, use both offset points
              (setq coords (cons off1 coords)
                    coords (cons off2 coords)
              )
            )
          )
)
(setq
  coords (cons (VLutil:offsetAtParam ent thisparam *offdist*)
       coords
)
)

      )
    )
    (setq flatlist (apply 'append (reverse coords)))
    (vlax-invoke
      points
      'addmultiple
      (length coords)
      flatlist
      'added
    )
  )
  (command "._undo" "_end")
  (*error* "Finished!")
  (setvar "cmdecho" usrcmd)
  (princ)
)

[sinc]

Oh, wait, I think I understand what you were doing with the totaldist thing.  You were setting points on every even station, so a 25' spacing would have a stake at 0+25, 0+50, 0+75, etc.  Sof there's a PC at Sta 0+30, there's still a Cogo point at Sta 0+50.  The way I changed it, it now restarts measuring for every segment.  So if there's a PC at Sta 0+30, the next point is now 0+55 (25' from the PC).

I beleive the crash I was experiencing was caused by the fact that the last segment was shorter than the station interval.  Basically, there was an angle point between the last even 25' station and the end of the feature line.  That caused an unexpected nil value to jump in there.

I think I'll play with this a bit, and see if I can make it a bit more flexible.  Unfortunately, after working a bit in C#, I'm not exactly jumping in joy to be working in Lisp...   

Hopefully Autodesk has exposed more of the API in 2008, the feature line stuff in particular.

[Jeff_M]

Yes, you are correct about how I used the stationing. I wasn't sure how these items are normally calc'ed/staked so I just used that method.

For the Lisp vs C#....I had started converting this to C# but had to give it up in favor of Real Work. I did get most of the Lisp functions you provided converted and was working on setting the points when I got pulled away. If you'd like that code, I'd be more than willing to share it....although my variable & function naming may not be too great (that's one area I seem to lack a knack for).

Keep wishing for the 2008 API....it ain't there. The only access to FeatureLines are to Corridor FeatureLines, which is pretty much what 2007 offered us.

[sinc]

Which functions did you convert?  That might be useful.

I was thinking of doing the same thing, but the big problem I see is that, without the Feature Lines API, the only way we have to work with these things is through the vlax-curve functions.  Did you figure out how to call those from C#?  I wasn't sure how to accomplish that.

And just for info, I notice that the vlax-curve-secondDeriv function is broken for feature lines.  vlax-curve-firstDeriv works, but the second deriv always returns 0.  I suspect Autodesk did something really funky with these things.  The only way the second deriv should return (0,0,0) is when the segment is a line, so at it's heart, the feature line might really be broken into line segments, just like what you get if you try to explode a feature line with curves in it.  The curve part seems to be some sort of "overlay".

This is really frustrating.  Autodesk doesn't provide us with all the functionality we need, and they also fail to provide API support so we can write it ourselves.  But I suppose that just makes it more satisfying when we actually manage to hack through the problems and get something working the way we want it...  It just takes a lot of brain-damage.   

[Jeff_M]

The Curve functions are exposed in the .NET environment...no need to try to use the lisp functions. Yes, it was the helper functions for obtaining the points along the Feature lines that I worked on. I'm attaching my Class1.cs file from my VS2005 project. I think SharpDevelop can read this....if not just open in Notepad and copy it from there. Feel free to use what you can. This is the project that I had posted to the Adesk group about the multiple warnings coming up. It is in no way a finished, or even close to, project but it should give you some ideas (more on how not to code, probably, as this was my first major venture into the land of C#)

[sinc]

Here's what I have now.

I finally realized that the SecondDerivative works when the feature line is in a 2D plane, but not when it's in 3D.  That means it can't be used.  Working without the bulge or the SecondDerivative makes things more difficult, but I found a way of using geometry to work around the problem.

This version sets points at equal intervals between angle points and grade breaks.  It also sets radius points and point descriptions, and remembers its settings.  I also broke up the code, and got a couple of basic utility libraries started.  The libraries are probably bound to change a fair bit moving forward, though, since I just started with C# and .NET last weekend, and I'm still figuring out the language.  But it should be a decent start.

There's also a compiled DLL in the zip package if anyone wants to try it without compiling the code.  You should be able to just NETLOAD the DLL into Civil-3D, and type STAKEFEATURES to run it.

[sinc]

New version.  This version tags vertex points as GB, AP, PC, PCC, or PRC, as appropriate.  This means that if you then use the stored points to create cut sheet reports, the point descriptions in the cut sheets will also contain the additional tag.  It also makes things like PCCs and GBs jump out.

There are also some additional options.  You can now toggle it, so that it sets points at even intervals in each segment, or you can set it so that it sets points on even stations, as in your (Jeff's) original Lisp version.  The option to "force midpoints" is only available when evenly-spaced points are being set.

There is also now an option to set radius points on both sides of the line.  If this option is set to false, then radius points will only be set if they fall on the same side as the offset stakes.

[sinc]

OK, this version seems to be working well enough for now.  I improved the prompting.  At some point, I'll probably change it again, so that all the configurations come up in a single GUI window.  It's gotten a fair number of options, and it would probably be easier to change the options in a GUI rather than cycle through them all in the command line.  But I think I'm happy with it for the time being, and will move on to other tasks.

I also cleaned up the code a bit, refactoring it into the start of an Autocad-C#.Net utility library.

[sinc]

This routine has undergone another significant revision.  The "new and improved" version of this routine is now available at:

http://www.ejsurveying.com/sincpacc3d.htm

Any further changes will also be posted to the same place, so this link should always yield the most-recent version.