Programmically find all the quadrant points of a polyline
@zph wrote:
You could compare the X and Y coordinates of the quandrants and boundary box and apply a fuzz distance using the EQUAL function.
....
EDIT: or rather compare the boundary box min and max X and Y coordinates to the points on the spiral and match them using the EQUAL function. And when they do match...you've found the quandrant points.
The first suggestion isn't an option, because [if I understand correctly] they don't have the coordinates of the quadrants to compare -- they're trying to find them.
The second suggestion depends on what you mean by "the points on the spiral." If you mean the vertices of the Polyline, I don't think it can be assumed that the quadrant points are at vertices. [The OP can certainly clarify that with a screen shot showing the spiral selected with grips showing.] My assumption is that the quadrants will be at some random distances along arc segments, not necessarily at vertices. The only way I can imagine to find them from "points on the spiral" would be to step along it at tiny increments and try (equal) at each step [not absolutely precise, but some tolerance would be involved, depending on the step size].
But I can imagine a way for a routine to get them precisely. I first thought of an approach involving temporary Xlines through the Osnap-center locations for each arc segment, and (intersectwith) functions, but this should be simpler:
1) Get the spiral's bounding box and extract the extreme X and Y coordinate values.
2) Step through the Polyline, if a spiral like the one in the image is made of relatively few comparatively long arc segments, at a parameter value increment of, say, every .25 [0.0, 0.25, 0.5, 0.75, 1.0, etc.], and apply (osnap ...thatpoint... "_qua") at each one. That will return a quadrant point for any segment that includes one, including potentially multiple returns of the same point. With longer segments there's the possibility that one segment might include more than one quadrant point, which is why you should Osnap at multiple locations along each segment. If it's made of a lot of comparatively short segments, Osnapping at just the midpoint parameter values [0.5, 1.5, etc.] should be enough.
3) Eliminate the duplicates, if any, and compare the results to the bounding box's extreme X and Y coordinate values. Any that match within a reasonable tolerance will be one of the outer-perimeter quadrants.
@marko_ribar wrote:
Please check attached DWG....
I keep forgetting about the ClosestPointToProjection approach -- that would be a lot simpler to write a routine to do than my idea.
@john.uhden wrote:
....
@(defun GetRadius (Object Param / @Anonymous Param1 Param2 P1 P2 P3 P4 Ctr Radius)@Anonymous Param1 Param2 P1 P2 P3 P4 Ctr Radius)
@(defun @Anonymous (p)(list (car p)(cadr p)))@Anonymous (p)(list (car p)(cadr p)))
....
@Those first two lines need the extraneous repeated stuff [from the second occurrences of @ followed by 2d in each line onward] removed. EDIT: The website did the same thing to my post [that combination must be code for "2 times" in webpage language somehow], so I've changed my description.
But in any case, I think this will accomplish the same thing:
(defun getrad (Object Param / pt)
(distance
(setq pt (vlax-curve-getPointAtParam Object Param))
(osnap pt "_center")
); distance
); defun
@john.uhden wrote:
Oops. Should have mentioned that one needs to verify that the point selected is actually on a segment whose bulge is non-zero.
That can be done without digging into entity data to look at bulge factors, by way of that same Osnap to the center, because that will return nil if it's a straight segment:
(defun getrad (Object Param / pt ctr)
(setq pt (vlax-curve-getPointAtParam Object Param))
(if (setq ctr (osnap pt "_center"))
(distance pt ctr)
); if
); defun
The overall function will also return nil in that case, which in the context of this thread would presumably be to trigger ignoring this segment and moving on to the next segment to look for a quadrant point along it.
But note that in routines that do that kind of Osnapping, it can be worth temporarily setting the APERTURE System Variable [the Osnap target box] to the [typically much smaller] size of the PICKBOX System Variable or even smaller. This helps ensure [and pretty much guarantees, when the point comes from a User object selection, rather than a parameter as here] that if you're on a line segment but there happens to be some curved element close by, it won't snap to the center of the latter, and give erroneous results.
@Anonymous wrote:
....
'(0 1.5708 3.14159 4.71239 360)
....
Even given the math adjustment in Post 14, the values in that list would all need to be in radians:
'(0 1.5708 3.14159 4.71239 6.28319)
Or better yet, with real precision [and less code to boot!]:
(list 0 (/ pi 2) pi (* pi 1.5) (* pi 2))
But I assume this is all a step along the way, since that code seems to leave you with the segments that cross quadrant points, but doesn't appear to determine where those points are.
@Anonymous wrote:
.... in determining if 0 is between the 'StartAngle and 'EndAngle. So, I corrected as shown below:
(if (< endang startang)
....
If the end angle is less than the start angle, couldn't you simply skip all of the figuring and immediately put that Arc in the category of those that cross quadrant points? It will necessarily cross the 0-degree-direction quadrant. You should need to do the figuring only for those whose end angles are greater than their start angles, to check whether they cross any of the other quadrant points, which would also mean that you could omit 0 and 2-pi from the list of directions to consider.
Here's a suggested somewhat shorter and fewer-variables version of the (foreach) part of the (vexplode) function [untested]:
....
(foreach obj (vlax-safearray->list (vlax-variant-value xlst)) (if (= (vlax-get-property obj 'ObjectName) "AcDbArc") (progn ; then (setq startang (vla-get-StartAngle obj) endang (vla-get-EndAngle obj) ); setq (if (or (< endang startang); crosses E quadrant (member T ; crosses N/W/S quadrant(s)? (mapcar '(lambda (x) (<= startang x endang)) (list (/ pi 2) pi (* pi 1.5)) ); mapcar ); member ); or (setq qss (ssadd (vlax-vla-object->ename obj) qss)) ; then -- add Arc that crosses a quadrant to set (vla-delete obj); else -- delete Arc not crossing quadrant ); if ); progn -- then (vla-delete obj); else [a Line] ); if [Arc or not] ); foreach
....
I also notice that you have some variables that I would think you want to use later -- 'qss' and/or 'quadss' -- that are in the localized-variables lists and therefore will not survive past the end of the command/function. Those should be removed from the localized lists, along with the names of variables -- 'cval' and 'delflag' and 'rlst' -- that I think are no longer needed [if I interpreted the intent correctly].
