|
in reply to Better maps with Math::Geometry::Voronoi, and a Challenge for Math Monks
I realise that Voronoi diagrams have their own (many) uses, and that you cannot talk about your work application, but...is there any way that you can describe or analogise an application for deriving a single encompassing polygon from a set of points?
I'm having trouble envisaging the application that starts with a set of points, needs to construct a single polygon that "encompasses" them all, and for which the simplest or best mechanism is to go through the construction of a voronoi diagram and then coalesce the polygons.
I worked on an application years ago, something to do with x-ray microscopy, that given a very large set of points needed to calculate the smallest area that encompassed all the points. That too did not want a convex hull solution. I'm trying to remember the details (and name) of the algorithm we ended up using, but I remember that it was fairly simple and very much faster than the first couple of attempts. And it definitely didn't calculate a voronoi diagram at any stage. I think it used vector math?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
|
Re^2: Better maps with Math::Geometry::Voronoi, and a Challenge for Math Monks
by samtregar (Abbot) on Jul 02, 2008 at 01:47 UTC
|
The classic Voronoi Diagram use-case is phone-booths on a campus. Let's say you need to use the phone and you want to know which phone is closest to your current location. A map that shows you this in the simplest way is a Voronoi diagram where the points are phone-booths and the polygons are the area around each phone where that phone is the closest one. Find out which region you are in and you know which phone to head for, no measuring required.
Generally speaking I think Voronoi diagrams are useful any time you have a collection of points and you want to visualize them as geometric areas instead of clumps of points.
My use-case isn't so different from the campus phone maps, but I don't want to get into specifics. Our competitors are everywhere!
-sam
| [reply] |
|
|
| [reply] |
Re^2: Better maps with Math::Geometry::Voronoi, and a Challenge for Math Monks (minimal covers)
by tye (Sage) on Jul 02, 2008 at 00:41 UTC
|
Given a large number of points and wanting the smallest area that encompasses all of the points but not wanting the convex hull, the answer would be a shape with an area of zero (assuming the at-least-not-clearly-stated additional requirement of a single connected area, a series of line segments can suffice).
So I think there must be another requirement hiding in there that I'm not inferring. :)
| [reply] |
|
|
Hm. Good point. I wasn't involved in the sourcing of the data, and don't really know what it represented. The description I was given, as best I remember it, was that the points represented scintillations on the memrane that forms the cell walls of an amoeba-like thing. The creature can stretch bits of itself out into limb-like appendages, much like you see here.
The problem is that being 3 dimensional, you get scinitallations from all over the outer membrane, not just around the 2D edges. So reconstructing a top-down, 2D representation of the thing, required connecting the dots that formed the outer edge of it, whilst ignoring those that came from the top of it. If you plot the points, your eyes/brain allow you to "see" the outline, and people would spend hours manually tracing the outines in GDDM so that they could extract the creatures image from the background before processing it further.
Effectively it was an "edge tracing algorithm", but as the entire image was constructed of dots, and the background had plenty of them also, it was rather more complex. First you had to low-pass filter the points to exclude noise and as much of the background as possible without lossing too much definition in the creature. then attempt to draw a single line around the thing. As the points were digital on a defined grid, you end up with a complex polygon.
Maybe that "single line" is the extra qualification you are after?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
That sounds a lot like a convex hull algorithm. Drawing a line around all the points pretty much defines a convex hull. If it's not then you need some other rule that tells you when to prefer to cut into the shape rather than go around...
-sam
| [reply] |
|
|
|
|
Then one way to fill in the missing requirement would be a "local" convex hull, where the definition of "local" can vary. My first idea would be to define a radius length that is a bit longer than the maximum "distance to closest neighbor point" (or just set by some person), pick an extreme point (leftmost, for example), draw the radius starting at that point and pointing "away" from the other points (to the left, using the same example), then sweep it clockwise from there until it hits another point. Then draw the radius from this new point back toward the previous point and then spin the radius clockwise again to find the next point. Continue until you get back to the starting point, at which time your sequence of points will have defined a closed polygonal border at least around some (at least two) of the points (if there are points left over, repeat the process for them).
| [reply] |
|
|
|
|
