从折线中去除环的有效算法

发布于 2024-12-17 09:50:03 字数 1374 浏览 0 评论 0原文

我有一条折线,以一组有序的 (X,Y) 坐标给出,它可能会交叉自身以形成一个或多个循环。由此,我想提取一个已删除循环的多边形,其中将包括线与自身相交的交点。我目前有一个粗略的暴力算法,其工作原理如下;

int RemoveLoops(CoordType Points[],int NoPoints)
{
    int n = 0;  // Start of first line segment
    int m = 2;  // Offset to n of second line segment
    int p = NoPoints;
    while (n + m + 1 < p)
    {
        CoordType Ip; // Intersection point
        if (Intersect(Points[n],Points[n+1],Points[n+m],Points[n+m+1],Ip))) 
        {
            Points[n+1] = Ip;
            int d = m - 1;  // Number of points to delete
            for (int i = n + m + 1; i < p; i++)
                Points[i - d] = Points[i];
            p -= d;
            m = 2;
            continue;   // Restart from intersection point 
        }
        m ++;
        if (n + m + 1 >= p) // Reached end of line, change starting segment
        {
            m = 2;  // Reset offset
            n++;    // Increment starting segment
        }
    }
    return(p);  // Return the number of points in the new poly line
}

虽然我对上面的内容做了一些优化,例如通过计算连续线段之间的累积角度,我们知道在经过 360 度之前我们不可能遇到交叉点,但该算法仍然是一个非常糟糕的 O(n^ 2)。我知道我可以做得更好,例如使用 所有相交线段的集合 例程作为起点。然而,鉴于积分已经排序,我认为我应该能够做得更好。请注意,上面的版本可以正常工作,并返回剩余点数,这很方便,但不是必需的。

对于上述问题有什么好的算法吗,O(n log n) 或更好?

I have a polyline, given as an ordered set of (X,Y) coordinates, that may cross over itself to form one or more loops. From this, I want to extract a polygon that has the loops removed, which will include the intersection points where the line crosses itself. I currently have a crude brute force algorithm that works as follows;

int RemoveLoops(CoordType Points[],int NoPoints)
{
    int n = 0;  // Start of first line segment
    int m = 2;  // Offset to n of second line segment
    int p = NoPoints;
    while (n + m + 1 < p)
    {
        CoordType Ip; // Intersection point
        if (Intersect(Points[n],Points[n+1],Points[n+m],Points[n+m+1],Ip))) 
        {
            Points[n+1] = Ip;
            int d = m - 1;  // Number of points to delete
            for (int i = n + m + 1; i < p; i++)
                Points[i - d] = Points[i];
            p -= d;
            m = 2;
            continue;   // Restart from intersection point 
        }
        m ++;
        if (n + m + 1 >= p) // Reached end of line, change starting segment
        {
            m = 2;  // Reset offset
            n++;    // Increment starting segment
        }
    }
    return(p);  // Return the number of points in the new poly line
}

While I've made a few optimizations to the above, e.g. by counting cumulative angle between successive line segments we know we can't have hit an intersection until we've gone through 360 degrees, the algorithm remains a pretty terrible O(n^2). I know I can do much better than this, e.g. using a set of all intersecting line segments routine as a starting point. Given that the points are already ordered however, I reckon I should be able do better. Note that the above version works in place, and returns the number of remaining points, which is handy but not a requirement.

Any ideas on a good algorithm for the above, O (n log n) or better?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

半仙 2024-12-24 09:50:03

尝试使用扫描线算法方法。直观上,最好以图形方式思考该算法。您将这些点放置在平面上并从左到右“扫过”它们。在扫描时,您可以保持已发现的线的状态不变。如果两条线之间存在交点,那么它一定发生在我们已经“发现”的两条线之间。从技术上讲,您不必“扫描”平面:每次偶然发现一个点时,您都​​可以检查不变量。因此,您可以按点的 x 坐标对它们进行排序,并逐一检查它们。

该算法的瓶颈是排序,其时间复杂度为O(nlogn)。我很确定你不能比 nlog n 做得更好,因为这些类型的问题通常可以简化为排序。您可以将这个问题简化为找到一组点的凸包,这在小于 n log n 的情况下也是不可能的。

Try to use a sweep line algorithm approach. Intuitively, it's best to think of the algorithm graphically. You place the points in the plane and "sweep" over them from left to right. While sweeping, you maintain an invariant on the state of the lines you have already discovered. If there is an intersection between two lines it must happen between two lines we have already "discovered". Technically, you don't have to "sweep" the plane: you can check the invariant every time you stumble upon a point. So you can order the points by their x coordinate and go over them one by one.

The bottleneck of the algorithm is the sorting which can be done in O(nlogn). I'm pretty sure you can't do better than nlog n because these type of problems usually are reducible to sorting. You can probably reduce this problem to finding a convex hull of a set of points that is also not possible in less than n log n.

浮世清欢 2024-12-24 09:50:03

导致加速或更好算法的通常假设是当多边形链是简单的或凸的时。一开始,你的链条两者都不是。

可能有一个增量数据结构可以进行 O(log n + s) 行——简单的多边形链相交测试,但我怀疑即使它存在,它也比仅仅进行线段相交更复杂并且可能更慢。

The usual assumptions that result in a speedup or a nicer algorithm are when the polygonal chain is either simple or convex. At the outset, your chain is neither.

There might be an incremental data structure that can do O(log n + s) line–simple polygonal chain intersection tests, but I suspect that even if it exists, it's more complicated and probably slower than just doing segment intersection.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文