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

[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.