Re^4: searching polygons not merged

[LanX]

> 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.

[hippo]

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.

[haj]

...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.

[hippo]

Given a vertex and centre of a regular polygon you have all you need for the circle. Can you explain how it isn't trivial?

[LanX]

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?

[hippo]

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

I don't disagree. My point is that without knowing anything qualitative about the data set it's going to be difficult to determine if the costs are similar.

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

Not sure what you mean here. The exclusion by circles should be as simple as this:

#!/usr/bin/env perl 
use strict;
use warnings;

my @circles = (
    {
        x => 3.0,
        y => 10.0,
        r => 5.0
    },
    {
        x => 4.0,
        y => 9.0,
        r => 2.0
    },
    {
        x => 12.0,
        y => 4.0,
        r => 4.0
    },
);

while (my $one = shift @circles) {
    for my $other (@circles) {
        my $dx2 = ($one->{x} - $other->{x}) ** 2;
        my $dy2 = ($one->{y} - $other->{y}) ** 2;
        my $r2  = ($one->{r} + $other->{r}) ** 2;
        if ($dx2 + $dy2 < $r2) {
            warn "Potential overlap: $one->{x}, $one->{y}, $one->{r} w
+ith $other->{x}, $other->{y}, $other->{r}\n";
        }
    }
}

[LanX]

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

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