Lisp for creating circles by diameter from point description?

[Anonymous]

Hey everyone, first post.

Thanks in advance for taking a look and for any suggestions you have.  I'll try to keep it as simple as possible:

I'm importing a ton of points into a drawing from CSV files. 

Format is Point | Northing | Easting | Elevation | Description. 

For example:  4011026 | 51105.600 | 6553.000 | 352.631 | 0.352

What I'd like to do seems like a fairly simple automated task... but I'm totally unfamiliar with LISP programming.

The jist of the programming should look for any point, create a circle (center is point N/E/Z) and define the circle diameters from the point descriptions.

I would be forever in your debt if you could suggest any sorcery to aid me.

Thanks again.

[Joe-Bouza]

This can be done OOTB with description keys either by using a block of predefined size or I am pretty sure by using a block scale by description

[hencoop]

It is true that Description Keys can do this OOTB and they are very easy to make use of; however, they are not very easy to set up so that you can make easy use of them.  The following "code block" contains the introduction to the instructions from Autodesk regarding setting up a description key to format a full description and scale a point block (the full article including 23 steps to actually do this type of description key is here)

Note: The following paragraphs are intended to help you understand this example. They do not provide a complete overview of description keys. For an overview of description keys, see About Description Keys. Before beginning this example, you should complete the example that shows you how to create a basic description key. For more information, see Example: To Create a Basic Description Key.
When you create a point, the description you enter at the command line is the raw description for the point. The raw description can consist of one element, such as TREE, or it can consist of more than one element, such as TREE OAK 7. The leading element in a raw description is compared against description key codes during description key matching. The remaining elements in the raw description are called parameters. You can use parameters to create a full description for a point or to rotate or scale a point.

In this example, you create a description key that translates a raw description with the format TREE <tree type> <tree size> into a full description that reads: <tree size> inch <tree type> tree, and you will scale the point symbol using the <tree size> value. For example, the raw description TREE OAK 7 will be translated to a full description 7 inch OAK tree. The point symbol will be scaled using a value of 7.

In the raw description TREE OAK 7, OAK is the first parameter and 7 is the second parameter.

If you want your points (#, Description, elevation) to be independently displayed from your graphics (point symbols) then you have even more work to do BEFORE you can easily use description keys.  Years ago I used them on a 16" water transmission pipeline project that was several miles long... and I regretted it.  I have custom tools (autolisp) that quickly takes care of all our needs regardless of the widely varying descriptions surveyors have sent us (up to 3,191 today).  I've still got dozens and dozens of point styles I never use any more but I did not need to create hundreds of them before I stopped doing that.  I have myriad reasons for not using them but this isn't the thread for them.

[rl_jackson]

If using the survey database (SDB) this is eazzey pezzey, lemon squeezy.... Its either 3 shots to create the circle, or is a single shot with the code for the size (radius) which is a super easy concept to teach (oh! ok this is the center of a 8' circle, CIR 4 done, or XX code CIR, two more and done, just need the code in the SDB, for it go to the right layer etc.)

[Pointdump]

Hi Rick,

I really like the 3 shots method. GPS doesn't work well under a tree canopy, and you can't hold the rod in the middle of the tree trunk.
Dave

[jefflambert9091]

LOL. GPS is getting there though. Maybe close enough for a tree survey. We use the Trimble Geo7X and connect to the states VRS/RTK network. 

[TomBeauford]

Once you have your trees properly scaled using Description Keys adding those circles to selected trees can be done with code like:

(defun C:CPZ ( / ss ent obj hscale pt clayer ) (princ "\nSelect Tree to add CPZ ")
(TBR)
(setq hscale (vlax-get-property obj 'XYScale))
(princ "\nhscale")(princ hscale)
(command-s "_Circle" pt "Diameter" hscale)
(setvar 'clayer clayer)
(princ)
)

[TomBeauford]

Sorry left out required supporting code:

(defun TBR ( )
;(defun TBR ( / ss ent obj hscale pt clayer )
(setq ss (ssget "+.:E:S" '((0 . "AECC_COGO_POINT")(8 . "V-SITE-VEGE")))
ent (ssname SS 0)
obj (vlax-ename->vla-object ent)
east (vlax-get-property obj 'Easting)
north (vlax-get-property obj 'Northing)
pt (list east north)
hscale (*(vlax-get-property obj 'XYScale)(getvar 'cannoscalevalue))
clayer (getvar 'clayer)
)
(princ pt)(princ "\n")
(if (/= (getvar 'annoallvisible) 1)(progn(setvar 'annoallvisible 1)(princ "\nDisplays all annotative objects. ANNOALLVISIBLE")))
(setvar 'clayer "V-SITE-VEGE")
)

[rl_jackson]

@Pointdump that's what an instrument and offset distance comes into play. @jefflambert9091 GPS is a great tool to have in the toolbox for land surveying, but I find that it is relied on far more than its true capabilities. It can't set 3 points in a line, only a transit can.

[Pointdump]

Hi Rick,
"...that's what an instrument and offset distance comes into play."
Oh I know. I've used them all, both GPS and Total Station, with Survey Pro and Trimble Access. Good tools, but for the 3 shots method you don't have to awkwardly hold the rod with your elbow while you fumble with your tape measure. And you don't have to key in the offset. Less chance for error.
Dave

[TomBeauford]

First if you're upgrading 2020 introduced a new quirky way of inserting blocks that was greatly improved in 2021, I'd recommend skipping 2020 and upgrade to at least 2021 which is still based on 2018. We usually wait awhile before installing the latest version but it's time for us to upgrade to 2022 we just haven't gotten to it yet.

When I set up our Description Key Sets I made a separate one for trees to keep it simple since there's a lot of different kinds. As the Code determines the Style if you want the block displayed different for an Oak -vs- Pine -vs- Palm you could need to use a different code for every tree type. A point "10,20,55,ABA 14" with a Label Style that only labels Description with the Format set as "$*" American Hornbeam" Scale Parameter of "Parameter 1" checked and Fixed Scale Factor of 1.000 checked would places the block we setup at coordinates "10,20,55" scaled by 14 with a description of "14" American Hornbeam". It's more work to set up but reduces how much the field crews have to enter with great results.

I also made a separate Description Key Set (copied and modified) for when the amount and density of the trees worked better with a tree table which labels only the tree number with the same field code.

If you right-click Description Key Sets and pick Properties you can pick one and move it up and down with the arrows on the right to modify the Search Order. The higher ones take precedence allowing me to pick which tree Description Key Set to use for the current job. I can even change it in the middle of the project and Apply  Description Keys by right-clicking my Trees Point Group in Prospector to change them.

[hencoop]

Creating and managing of point styles and description key codes (and, in our case, also training surveyors to use very specific descriptions without making mistakes) makes using description keys such a hassle for us.  Therefore, we use a custom application to draft our existing base file from survey points.  The descriptions the surveyors use is largely unimportant.  They only need to adequately describe the point for our experienced CAD Technicians to read them.  A single point description can even describe multiple features without disturbing our process.

We have our own version of description keys.  It is simply a CSV file with a list of explicit descriptions and feature definition data associated with that description, one description and data set per line.  When using our automated "Field-To-Finish" tool these are matched against each survey point description as the points are imported.  Our description key list is automatically appended to whenever a point description does not match any of the current content and the user is advised of the descriptions added and their line number in the CSV file so that they can be edited and conformed to our needs before reimporting the points. (This point import method only imports the point data for our f2f automated drafting use.  It does not create C3D point objects).  This is how we built our description key list over the years.  It now contains a little over 3,100 explicit survey point descriptions and feature definition data.  It is rare to have a survey add more than a dozen or so new descriptions.  When a survey point description is matched, the data associated with that match in the CSV file determines the layer name, layer color, layer linetype and whether it defines a point symbol (by specifying the block name), a point on a 2D polyline or line, or a 3D breakline point.

All the point features are as easily drawn as the pine trees are in the video example which I've referenced here.  We can even automate the entire process while importing point files, very much like Field-To-Finish but without the need for point styles; however, to automate drafting of linear features, careful coordination with the surveyors to use specific keyed descriptions is required.  In this case if they make mistakes in the descriptions the process becomes more difficult and time consuming (just like they would be with AutoCAD's Field-To-Finish… because linear features will be incorrectly drawn).  Typically, we use the Temporary, 3D, and Circle options and draw circles with elevations at linear feature points... by description.  The necessary order of the points are instantly recognizable by the pattern of the circles drawn.  We have a companion tool that uses the circles to draw the linear features.  It will optionally draw 2d polylines, 3d polylines (breaklines) or both on the appropriate layers.  The user only needs to select the starting circle explicitly and then all of the other circles can be randomly selected.  The program draws from the start point and successively to the next nearest point until all circle center points have been used.  This method saves us survey time and eliminates any requirement for keyed descriptions.

The next image shows our interface.  The program reads points and creates a list of unique descriptions in the Points List window.  Each description is linked to a list of discrete points that share that description.  The selection shown was made using wildcard matching of *PINE*.  It contains many more selected descriptions than are visible in this image.  About 1,200 individual Pine tree symbols were drawn (blocks were inserted), each at an appropriate size calculated from the trunk size in the description.  If the size could not be determined for any description the user is prompted with the description and asked to provide the trunk size.

Our "description keys" CSV file contains about 3,100 lines similar to those in the image below.

We have used this method for at least two decades.  It has been refined and improved over those years.

My point is to encourage others and demonstrate that users can get much more out of AutoCAD while addressing their very specific needs better than OOTB AutoCAD can by creating their own tools,  Not every company or user is able to do this; however, if they can it could pay them substantial dividends for many years to come.  It has for us.

[TomBeauford]

You have a different code for every size of every tree type? I couldn't even imagine the hours put into that. We only need to add one or two new point codes a year.

Using Field to Finish Feature lines have the advantage of being able to both draw curves like a 2D Polyline and be used as a Breakline with elevations like a 3D Polyline which cannot contain curves. Without Feature lines creating a proper surface for a street intersection would be impossible though using 3D Polylines breaking each arc into 30 straight line segments would appear close.

As long as you're happy with your method that's all that really matters but for most OOTB Civil 3D is simpler and more powerful.

[Joe-Bouza]

wasn't so hard. took about ten minutes. but I see your point.

Points are a PITA to deal with I never use them in design. This was more of a curiosity for me

[hencoop]

---

@TomBeauford wrote:

You have a different code for every size of every tree type?...

No, there wouldn't be any point to writing code if it had to account for every possibility separately.  What I don't have to do is account for every size and type in AutoCAD's in description key(s) and make sure that the surveyor uses the correct key.

We very rarely deal with roads and intersections but when we do it is ALWAYS a new road for which there is nothing to survey.

Interestingly, the code to turn a polyline with arcs into a polyline straight segments a a user specified deflection angle along the curve was completed in may of 1996.  It has paid dividends for 25 years now.  It mostly gets used to make a polyline with "curves" that Wipeouts like and can use.  It was originally to make grading do a smooth(ish) radius instead of just using the chords of the corners (as it did in 1996).

[TomBeauford]

Sorry lookin at your "description keys" CSV file that contains about 3,100 (Wow!) lines it appeared you added a line for every size of each tree while using Civil 3D's Description Keys I only need one for each tree type to autoscale and label them all no matter the size. Glad you're happy with your code to turn a polyline with arcs into a polyline straight segments a a user specified deflection angle along the curve that roughly approximates what a Civil 3D Feature line can do OOTB. As you don't work with any existing roadways I suppose that should work fine for what you're doing.

[hencoop]

You may have missed that those descriptions are added automatically little by little... and that they were collected from a whole host of different individual surveyors over the past 20+ years, none of whom have ever had to conform to any description key format (and from our experience a significant number simply could not).  Don't be so hasty to discard out of hand solutions that are different from your experience.

I am happy for you that the OOTB tools from Autodesk satisfy your needs.  Don't assume they must or even can for everyone.

Here's a good example (IMHO).  BIM has absolutely nothing to offer our workflow.  We simply never have any projects where its features can add any benefit our workflow.  You may not be able to imagine that; if so, that just means you cannot imagine our workflow.

[hencoop]

BTW, the CSV is ONLY for when we choose to draft directly from the survey point file and is editable from within AutoCAD using a custom editor dialog whenever some new descriptions get appended.

When we are not drafting directly from the point file the program collects the raw point data from either the point file or from the AECC-COGO-POINT objects in the drawing.  And then the user selects certain descriptions (like *PINE*) as shown in my earlier post, specifies the block to insert at each point and the rest is automatic.  Code reads each *PINE* description and extracts the size from it.  It does not need to be in any particular format.  In the short video I shared I inserted over 1,100 pine blocks (blocks named CG_T18) were inserted at the different scales calculated from their descriptions.  Those symbols did not require C3D points and they did not require styles.  I also have a custom tool that will label all 1,100+ of them in about one second if that's what I need... and I don't need to change/swap a point style to make that happen.

You should understand that I am not advising anyone to NOT use AutoCAD's OOTB methods and tools.  I am merely demonstrating that there are other ways to approach tasks that MAY work better for them.