WEED. Autolisp - selecting ALL polylines
Accepted solution
That appears to be built to work with "heavy" Polylines, but not Lightweight ones [it's more than twenty years old, after all!]. There's another routine with the same name but written by a different author -- Skyler Mills -- on Cadalyst CAD Tips. I haven't compared them, but in response to the desire to use something like that on LWPolylines, I made PLDIET.lsp, available here:
http://cadtips.cadalyst.com/linear-objects/polyline-diet
It may operate on slightly different qualities [e.g. amount of change in direction rather than distance of offset, if I'm reading the Jerry Workman version correctly without analyzing too closely], and it doesn't have the ability to convert a Line for you, but:
A. It works on newer Lightweight Polylines, so you wouldn't need to convert them to use WEED on them;
B. It lets you choose as many as you want at one time, or just hit Enter to choose all LWPolylines in the current space.
C. It has some other enhancements, such as eliminating all intermediate vertices in a collinear stretch, regardless of the User's specified maximum distance.
Anyway, see whether it does what you need.
Kent Cooper, AIA 
@Anonymous wrote:Kent,
Thank you - this is perfect. You have saved me hours!
....
You're welcome -- that's what this forum is for. That Cadalyst CAD Tips site has a lot of stuff on it [over 3,000 tips, though some are just helpful-hint types, without routines to download], and you can Search for things, or navigate through a topical index. It's a good place to look, in addition to Searching here, before posting a question.
Kent Cooper, AIA
@Anonymous wrote:
....
However, when I use them on some of the polylines, it gives following error :-
This object does not define a coordinate system
and then the program stops.
Why is it so ? Please help
I can't imagine. 3D Polylines don't define a coordinate system, but PLDiet is made to work only on LightWeight Polylines, so it would not accept 3D Polylines and should therefore not get to the point of trying to align the coordinate system with one. And I can't think of any reason that a LWPolyline would not define a coordinate system.
Maybe if you post a drawing with some of those problem Polylines in it....
EDIT: Wait -- I found a circumstance in which a LWPolyline does not define a coordinate system. Are there any with an overall length of zero [all vertices at the same location]?
Kent Cooper, AIA
@Anonymous wrote:
....
I am not running the code for 3 D Polyline. Nor is the polyline of zero length.
....
That Polyline does, however, have its first two vertices at the same location. When I use UCS and its OBject option, and select the Polyline somewhere not right at its start point, it can use that to align the UCS, and it aligns it differently depending on where I select it, so it's obviously using adjacent vertices to the selection point. But when it is given an entity name [as the PLD command does, or Last in manual operation], apparently it uses the first two vertices somehow [though they are not actually the basis of the UCS angle, which for all-line-segment Polylines seems to go from first to last vertices], and for whatever reason, it can't handle it if they're at the same location.
If I use PEDIT and its Edit Vertex option, and Straighten that Polyline from the first vertex to the third [the first "Next" move with the Straighten option doesn't go anywhere, because the second vertex is at the same location as the first], then PLD works.
If this is a recurring problem for you, I imagine the routine could probably be made to "select" each Polyline somehow, rather than use its entity name. EDIT: Or, it could be made to check whether the first two vertices are at the same location, and if so, remove the second one and then proceed with putting it on a Diet.
Kent Cooper, AIA
@Anonymous wrote:
....
Thanks for your response. Indeed you are right. It is the problem in the Polyline itself.
Since it is a recurring problem (and I am sure that many others might also be facing the same), please modify your code and post again so that it may help all.
....
I also want to ask why do we need to change the UCS for weeding ?
....
I'll think about the best way to do that, and work on it a little later.
The reason for changing the UCS to align with the Polyline is that in order to decide whether a change in direction at a vertex is large enough that it should not straighten it there, it uses the (angle) function a couple of times, which returns angles in relation to the current coordinate system. I think it wouldn't matter if one always did it to Polylines in or parallel to the World Coordinate System, but doing it this way allows putting on a diet even Polylines that are not parallel to the WCS.
If you work only in and parallel to the WCS, I think another "fix" might be to remove the UCS alignment entirely, which would eliminate the error message. That would be easier, I expect, than altering it to account for the possibility of the two first vertices being coincident, which seems unlikely in most circumstances, but obviously something about the way yours are being created causes that sometimes.
Kent Cooper, AIA
@Kent1Cooper wrote:
@Anonymous wrote:
....
Since it is a recurring problem (and I am sure that many others might also be facing the same), please modify your code and post again so that it may help all.
....
I also want to ask why do we need to change the UCS for weeding ?
....
I'll think about the best way to do that, and work on it a little later.
....
Here's an adjusted version. Because having it select the Polyline somewhere away from the beginning would be subject to the selection possibly "seeing" some other object, I opted to check whether the first two vertices coincide, and if so, Straighten it from the first to the third, via PEDIT. It worked when I tested it on your sample drawing.
A second reason for changing the UCS is that to test whether the distance to the subsequent vertex, if one is removed, would be beyond the specified limit, it uses the (distance) function, and when that is fed XY-only points such as the vertices are in LWPolyline entity data, it projects them onto the current plane [as with the (angle) function mentioned before] and returns the effective 2D distance on that plane. So if the UCS were not aligned with the Polyline, the distances would not be correct for one that's not parallel to the WCS, and some vertices could be weeded out that shouldn't be.
EDIT: Replaced attached file with one that accounts for the possibility that more than two of the vertices at the beginning coincide, which under the previous version would cause the same error as before.
Kent Cooper, AIA
@Base12 wrote:
Regarding the PLD command... when I run this, it just prompts me to set a value (1 - 10). Nothing happens after that, what else needs to happen to get this to work?
....
I think you must have more than one command definition that use the same name. My PLD command doesn't ask for anything like that -- nothing with the word "value" in it, nor anything in a 1-10 range. The first thing it prompts for is:
"Maximum distance between non-collinear vertices to straighten: "
[You can see what all its prompts are in the rest of the code.]
If it's a conflict with another definition using the same name, and you can't find where the other definition is coming from, you could try changing the command name in mine. Change this line with the command name [the part following the C:]:
(defun C:PLD
to something else, such as perhaps:
(defun C:PLDIET
or anything else you prefer, and try that new command name. [If that fixes it, also change PLD to the new name in the other appropriate places.]
Kent Cooper, AIA
It may depend on the nature of the "overweight" contour lines, and the scale at which the results will be plotted. If you want a really random suggestion, try 15 degrees as a maximum amount of bend to straighten, and whatever would come out to about an inch or a couple of centimeters at plotted size as a maximum length to straighten. You can probably arrive at "ideal" values for your purposes with a little experimentation.
Kent Cooper, AIA
This reply has been edited by the moderation team as the legacy links were no longer valid
@Kent1Cooper wrote:.... Here's an adjusted version. ....
... and there's a further improved version >here< .
Kent Cooper, AIA
