I need to find the outermost lines (example: red lines in the snapshot below )from a bunch of lines. Any help in this regards will be highly appreciated. Thanks.
Outermost line
In that particular set of Lines, sorting by the X coordinate of their midpoints would give the answer, and wouldn't be too hard to make a routine do. But I don't expect that would always be the right thing to compare. Can you post some more real-world configurations showing the extremes of the kinds of variability you might encounter? For example, are they always going to run sort-of in the same general direction like the ones in your image, or sometimes might there be greater angular differences? Might some of them sometimes intersect? And if so, and if they could be "outer" ones, what criteria could be used to decide which is considered "outermost"?
Etc.
Kent Cooper, AIA 
Hi John
Your method works only for parallel lines.
In OP, the lines are not quite parallel and, in some condition, your average angle is wrong. See the result of your function.
In the image, some angles are almost 0 or pi. The green line is from p1 to p2 and the red lines are from mid to ip1 or ip2.
Your sorting method is ok, but the average angle is not.
Of course, any attempt must assume parallel lines or almost parallel.
This is my offer, pretty much the same. The average angle is better approximated and the sorting method uses trans instead of distance.
EDIT: OOPS... Code removed. My average angle is also wrong. 🙂
Hi Marko
It's not that. The average angle must approximate the orientation of all lines. Obviously, the Green line in my image is not.
Your lisp is checking the distances on a "perpendicular" line, which is as hard to find as the average angle. Try your lisp on a bunch of perfectly horizontal lines.
Finding the average angle is the key. Then you can apply John's code, or you can use a +-90deg angle and apply your code.
The average angle is quite a challenge. I thought I had it but it didn't work. Now I have this new version but I'm not sure is foolproof.
(defun c:test ( / m2p ss i e p1 p2 a l u ang n)
(defun m2p (a b) (mapcar '(lambda (a b) (/ (+ a b) 2.0)) a b))
(if
(or
(setq s (ssget "_I" '((0 . "LINE"))))
(setq s (ssget '((0 . "LINE"))))
)
(progn
(sssetfirst nil nil)
(repeat (setq i (sslength s))
(setq e (ssname s (setq i (1- i)))
p1 (vlax-curve-getstartpoint e)
p2 (vlax-curve-getendpoint e)
a (+ pi (angle p1 p2))
l (cons (list (m2p p1 p2) e) l)
)
(or u (setq u a))
(if
(or
(equal a u (/ pi 2))
(equal u (- a pi pi) (/ pi 2))
(equal a (- u pi pi) (/ pi 2))
)
(setq ang (cons (rem a (* pi 2.0)) ang))
(setq ang (cons (rem (- a pi) (* pi 2.0)) ang))
)
)
(setq u (/ (apply '+ ang) (length ang)))
(setq n (list (cos u) (sin u) 0.0)
l (vl-sort l
'(lambda (a b)
(<
(car (trans (car a) 0 n))
(car (trans (car b) 0 n))
)
)
)
)
(sssetfirst nil
(ssadd
(cadr (car l))
(ssadd (cadr (last l)))
)
)
)
)
(princ)
)
@phanaem wrote:
....
Finding the average angle is the key. Then you can apply .... Now I have this new version but I'm not sure is foolproof.
Here's a brute-force but I think foolproof [though lightly tested] way to find a kind of "average" angle of sort-of-same-direction Lines, regardless of in which comparative direction each was drawn, and/or whether their directions vary slightly crossing that pesky 0-degree direction, etc.
It Copies each Line other than the first one to put the copy's start point at the start point of the first one. If the copy's endpoint is farther from the first one's endpoint than their common start point is, the copy is "aiming" the wrong way, and it spins it around 180 degrees. Then it adds its endpoint into a running sum, and deletes the copy. When it's done that with all of them, it averages the endpoints [divides the coordinates of the accumulated sum by the quantity], and finds the angle from the common start point to there.
(setq osm (getvar 'osmode))
(setvar 'osmode 0)
(setq
ss (ssget '((0 . "LINE")))
qua (sslength ss)
start0 (vlax-curve-getStartPoint (setq line1 (ssname ss 0)))
sumend (setq end0 (vlax-curve-getEndPoint line1))
length0 (distance start0 end0)
); setq
(repeat (1- (setq n qua))
(command "_.copy" (setq line (ssname ss (setq n (1- n)))) "" (vlax-curve-getStartPoint line) start0)
(if
(> (distance end0 (vlax-curve-getEndPoint (setq line (entlast)))) length0); aims away?
(command "_rotate" line "" start0 "180"); then -- spin it
); if
(setq sumend (mapcar '+ sumend (vlax-curve-getEndPoint line)))
(entdel line)
); repeat
(setq angavg (angle start0 (mapcar '(lambda (c) (/ c qua)) sumend)))
; angle from common start point to averaged endpoint
(setvar 'osmode osm)
The result will not always be the true mathematical average of the directions, but [again, when they're not too far from parallel] should be close enough for purposes of this thread. It does give a "better" result from one point of view than a true mathematical average of only the angles of the Lines, in that it's "weighted" -- a longer Line has a greater impact on the result than a shorter one has. It seems to handle a fair degree of angular difference, but certain combinations of a Line's direction being more significantly different than the general direction of the rest, and [because of the distance comparison] its length relative to that of the first Line in the selection, can throw off the result.
Because of the Copying, it requires that the selected Lines not be on locked Layers -- that could be worked around if necessary.
Kent Cooper, AIA
