http://qs321.pair.com?node_id=1224788


in reply to Re^2: searching polygons not merged
in thread searching polygons not merged

The minimum circle is more expensive to compute (for an irregular polygon) but that's O(n). Since the circle is smaller it will be no worse and maybe a good bit better for weeding out non-overlaps and the bonus that brings will depend entirely on the dataset being examined. Without seeing sample data, would you take the O(n) hit for an O(n2) gain? I probably would.

(I bet it's not)

It's a gamble either way. :-)

Replies are listed 'Best First'.
Re^4: searching polygons not merged
by LanX (Saint) on Oct 28, 2018 at 12:07 UTC
    > Since the circle is smaller 

    This is generally not true.

    A pointy triangle could be idealized as an edge, the resulting circle will always be bigger than a bounding box.

    (The corners of the box are on the circle, see Thales's theorem)

    You might now claim that something like a regular octagon is better represented by a circle (probably).

    But how does the average polygon look like?

    I bet it depends on the randomization

    • random vertices
    • random edges
    • random angles
    will produce totally different samples

    Furthermore it'll be more difficult to fit circles into a quadtree search.

    I think using circles in a Cartesian system causes too many headaches.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

      A pointy triangle could be idealized as an edge, the resulting circle will always be bigger than a bounding box.

      Indeed. Any particularly flat (in either Cartesian direction) ploygon is going to be better suited to a bounding box. Whether these are plentiful or rare in the data set is only something which the OP can answer.

      You might now claim that something like a regular octagon is better represented by a circle (probably).

      I'd claim that not only is any regular polygon with n>4 better represented by a circle, the circle is trivially easy to compute. If the data set were all regular polygons (and I'm not assuming for one minute that they are in this case) then circles would be the obvious choice.

      A little domain knowledge here would help to inform the choice of bounding box or circle. Horses for courses.

        ...the circle is trivially easy to compute.

        Quite on the contrary, I'd say that it is the bounding box which is trivially easy to compute, whereas the circle is rather straightforward but still needs quite a couple of floating point operations. Both are linear with the number of points, but you just need to write down the subs for both algorithms for a triangle and you'll easily spot the difference.

        Regarding performance, I guess that floating point operations are slow compared to if/then/else branching.

        I'd claim any advantage of a circle could be countered by a set of disjoint covering boxes, and the computational cost would be similar.

        Quadtree decomposition is only one way to do it.

        And decomposing in smaller circles wouldn't lead to a disjoint set.

        (Though the "best" approach is probably partitioning a polygon into triangles anyway )

        The inherent catch is that we prefer a cartesian system, hence we'll always prefer a compatible coverage if the costs are similar.

        Remember that the OP wanted to preselect (spatial index) plausible candidates, how would you do this with circles?

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

        > . Any particularly flat (in either Cartesian direction) ploygon

        Does "flat" already cover a crescent or other concave bodies? ;)

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery FootballPerl is like chess, only without the dice