As a CG novice I was wondering does there exist Voronoi partition that is not based solely on euclidian distance between sites but some other measure, and would such partition still conserve properties of Voronoi diagram?
Reading a textbook I've encountered an example of Voronoi diagram where sites on 2D plane represent football players, and if ball happens to be in Voronoi region of certain player it meant he should go towards it since he's closest to it. Now what if instead of just accounting for the Euclidian distance between players we also considered their speed, with faster players having a larger Voronoi cell.
Would the fact that we lose bisection ruin the structure of Voronoi diagram itself?
Take a look at Power Diagrams and Weighted Voronoï Diagrams. They are generalized Voronoï Diagrams with weights (a circle radius in the case of Power Diagrams) associated with each site.
You can use it to weigh each site with the speed or alter the notion of distance to include speed. By doing so, you will loose the straight line property of bisectors because they might become curved depending on the new distance calculation (look here).
In the case of football players, the new distance function from a point p to a site p_i with player speed v_i is:
d(p, p_i) = EuclideanDistance(p, p_i) / v_i
which can be better interpreted as the time that it takes to reach the point if the player runs at speed v_i. This can produce diagrams like this, where the displayed numbers are the weights 1/v_i:
Related
Given a set of points (GPS coordinates), and a polygon that contains all those points, can one determine how well those points are covering the area or what the longest distance from any location within the polygon to the nearest point is?
For example, if I have all fire departments within the city boundary of New York, I want to know how long a fire truck has to drive (in case of an emergency) in the worst case.
Any ideas on what the name of this problem is or what this problem can be reduced to? Or are there any existing algorithms for that?
Thank you :)
First construct the Voronoi diagram of the set of sites (GPS coordinates). The Voronoi diagram is a data structure representing a partition of the plane into cells, one cell for each site, such that each site's cell consists of all the points closer to that site than to any other site.
Constructing the Voronoi diagram can be done in O(nlog(n)) using Fortune's sweep-line algorithm where n is the number of input sites.
Then iterate over the Voronoi cells. Each cell is a polygon. For each cell compute the distance between the cell's site and each of the polygon's vertices. The longest distance between a site and a vertex of the site's cell is the longest distance one would have to walk in order to reach the site.
The running time of the algorithm is O(nlog(n)) as the second phase of the algorithm (iterating over the vertices of each Voronoi cell) requires only linear time. This is because the total number of vertices in the whole diagram grows linearly with the number of sites. Namely, it's not too difficult to show using Euler's formula for planar graphs that the total number of Voronoi vertices is bounded from above by 2n-5.
You can find some open source implementations of Fortune's algorithm on the web. This one for instance.
There are quite many algoritms for finding Voronoi diagram with Euclidean distance. However, I haven't found any algorithms other distance functions, for example, Manhattan distance (perhaps, because of no practical applications).
You can see example at Wikipedia:
https://en.wikipedia.org/wiki/Voronoi_diagram#/media/File:Manhattan_Voronoi_Diagram.svg
Manhattan Voronoi diagram also consists of polygons (but non-convex), so I guess that algorithm similar to Fortune's algorithm can be constructed.
However, using more complex distance functions, boundaries won't be polygons anymore. There will be need in different data structure and algorithm.
Are there any algorithms for finding Voronoi diagram with specific distance function (in 2D for simplicity)?
Note:
I don't need an algorithm which works with pixels, it's pretty straightforward, I need algorithm, which founds the boundaries of cells.
Note 2
Practically I need Voronoi diagram with distance function abs(dx)^3 + abs(dy)^3, however, theoretically, I'm interested how one do make an algorithm for other distance functions.
Here is how Voronoi with abs(dx)^3 + abs(dy)^3 look like. Sites are continous and their edges resemble graphs of y=x^3 (just assumption).
Most likely you can use the pixel taxi voronoi and give each polygon a different color. You can then use a pixel color test to check the bounds.
There is a problem in my book that uses the concept of closest-point and farthest-point Voronoi diagrams to construct a minimum width annulus for a set of points (used in coordinate measurement machines).
What I need to know:
Say you construct the closest-point voronoi diagram (CPVD) and the farthest-point voronoi diagram (FPVD) on a set of points P. What is an efficient way to find the intersections between the CPVD's edges and the FPVD's edges (if you overlay the two diagrams) if you know there are only O(n) intersections.
I just can't think of a way that is faster than O(n^2). Is there some property I'm glossing over?
I have an application that creates an approximation to sphere by subdividing an icosahedron. The Cartesian vertex coordinates are converted to spherical coordinates so that all vertices sit on the surface of a unit sphere.
What I need to do next is find the nearest vertex to an arbitrary point on the surface of the sphere. I have come up with two simple algorithms...
Brute force search - will be OK for a small number of vertices, but will be excessive for finer subdivisions.
Sorted / Indexed search - sort the vertices into some form of order by azimuth and inclination and then create a rough index to speed up a brute force search by limiting its scope.
I was wondering if there was a more subtle, and hopefully higher performing algorithm that I can use instead of one of the two above.
Update 1: I have just recalled that for another part of the application the vertices store information about their neighbours. My new algorithm is
Pick an arbitrary start vertex. Find which of its neighbours has a smaller distance to the point to locate. Use this neighbour as the new start vertex. Repeat until none of the vertex's neighbours has a smaller distance to the point. This vertex is the closest to the point.
Scanning through the responses, I think I may be off base, but what you're after is simple. I think.
Since you're dealing with just points that sit on the sphere, you can just drop a line from the vertex to the center of the sphere, drop another line from the arbitrary point to the center and solve for the angle created between them. Smaller is better. The easiest and cheapest way I think would be the dot product. The angle basically falls out of it. Here's a link about it: http://www.kynd.info/library/mathandphysics/dotProduct_01/
For testing them, I would suggest picking a vertex, testing it, then testing its neighbors. It SHOULD always be in the direction of the smallest neighbor (angle should always decrease as you get closer to the vertex you're after)
Anyhow, I hope that's what you're after.
Oh, and I came across this page while looking for your subdivision algorithm. Hard to find; if you could post a link to it I think it would help out a lot more than just myself.
One of possible solutions is to build BSP tree for vertices: http://en.wikipedia.org/wiki/Binary_space_partitioning
If the icosahedron has one vertex at the north pole and the opposite vertex at the south pole then there are 2 groups each of 5 vertices which are in planes parallel to the equator. With a little geometry I figure that these planes are at N/S 57.3056° (decimals, not dd.mmss). This divides your icosahedron into 4 latitude zones;
anything north (south) of 28.6528° is closest to the vertex at the nearer pole;
anything between the equator and north (south) 28.6528° is closer to one of the 5 vertices in that zone.
I'm working this as a navigator would, arcs measured in degrees and denoted north and south; if you prefer a more mathematical convention you can translate this all to your version of spherical coordinates quite easily.
I suspect, though I haven't coded it, that checking the distance to 5 vertices and selecting the nearest will be quicker than more sophisticated approaches based on partitioning the surface of the sphere into the projections of the faces of the icosahedron, or projecting the points on the sphere back onto the icosahedron and working the problem in that coordinate system.
For example, the approach you suggest in your update 1 will require the computation of the distance to 6 vertices (the first, arbitrarily chosen one and its 5 neighbours) at least.
It doesn't matter (if you only want to know which vertex is nearest) whether you calculate distances in Cartesian or spherical coordinates. However, calculation in Cartesian coordinates avoids a lot of calls to trigonometric functions.
If, on the other hand, you haven't arranged your icosahedron with vertices at the poles of your sphere, well, you should have !
I am programming an algorithm where I have broken up the surface of a sphere into grid points (for simplicity I have the grid lines parallel and perpendicular to the meridians). Given a point A, I would like to be able to efficiently take any grid "square" and determine the point B in the square with the least spherical coordinate distance AB. In the degenerate case the "squares" are actually "triangles".
I am actually only using it to bound which squares I am searching, so I can also accept a lower bound if it is only a tiny bit off. For this reason, I need the algorithm to be extremely quick otherwise it would be better to just take the loss of accuracy and search a few more squares.
I decided to repost this question to Math Overflow: https://mathoverflow.net/questions/854/closest-grid-square-to-a-point-in-spherical-coordinates. More progress has been made here
For points on a sphere, the points closest in the full 3D space will also be closest when measured along the surface of the sphere. The actual distances will be different, but if you're just after the closest point it's probably easiest to minimize the 3D distance rather than worry about great circle arcs, etc.
To find the actual great-circle distance between two (latitidude, longitude) points on the sphere, you can use the first formula in this link.
A few points, for clarity.
Unless you specifically wish these squares to be square (and hence to not fit exactly in this parallel and perpendicular layout with regards to the meridians), these are not exactly squares. This is particularly visible if the dimensions of the square are big.
The question speaks of a [perfect] sphere. Matters would be somewhat different if we were considering the Earth (or other planets) with its flattened poles.
Following is a "algorithm" that would fit the bill, I doubt it is optimal, but could offer a good basis. EDIT: see Tom10's suggestion to work with the plain 3D distance between the points rather than the corresponding great cirle distance (i.e. that of the cord rather than the arc), as this will greatly reduce the complexity of the formulas.
Problem layout: (A, B and Sq as defined in the OP's question)
A : a given point the the surface of the sphere
Sq : a given "square" from the grid
B : solution to problem : point located within Sq which has the shortest
distance to A.
C : point at the center of Sq
Tentative algorithm:
Using the formulas associated with [Great Circle][1], we can:
- find the equation of the circle that includes A and C
- find the distance between A and C. See the [formula here][2] (kindly lifted
from Tom10's reply).
- find the intersect of the Great Circle arc between these points, with the
arcs of parallel or meridian defining the Sq.
There should be only one such point, unless this finds a "corner" of Sq,
or -a rarer case- if the two points are on the same diameter (see
'antipodes' below).
Then comes the more algorithmic part of this procedure (so far formulas...):
- find, by dichotomy, the point on Sq's arc/seqment which is the closest from
point A. We're at B! QED.
Optimization:
It is probably possible make a good "guess" as to the location
of B, based on the relative position of A and C, hence cutting the number of
iterations for the binary search.
Also, if the distance A and C is past a certain threshold the intersection
of the cicles' arcs is probably a good enough estimate of B. Only when A
and C are relatively close will B be found a bit further on the median or
parallel arc in these cases, projection errors between A and C (or B) are
smaller and it may be ok to work with orthogonal coordinates and their
simpler formulas.
Another approach is to calculate the distance between A and each of the 4
corners of the square and to work the dichotomic search from two of these
points (not quite sure which; could be on the meridian or parallel...)
( * ) *Antipodes case*: When points A and C happen to be diametrically
opposite to one another, all great circle lines between A and C have the same
length, that of 1/2 the circonference of the sphere, which is the maximum any
two points on the surface of a sphere may be. In this case, the point B will
be the "square"'s corner that is the furthest from C.
I hope this helps...
The lazy lower bound method is to find the distance to the center of the square, then subtract the half diagonal distance and bound using the triangle inequality. Given these aren't real squares, there will actually be two diagonal distances - we will use the greater. I suppose that it will be reasonably accurate as well.
See Math Overflow: https://mathoverflow.net/questions/854/closest-grid-square-to-a-point-in-spherical-coordinates for an exact solution