I am writing code that will build an oriented bounding box (obb) tree for a (not necessarily convex) polygon in 2 dimensions.
So far, I'm able to find the area-minimal obb of a polygon by finding its convex hull and using rotating calipers on the hull.
The picture below is an example of this. The yellow-filled polygon with red lines and red points depicts the original polygon. The convex hull is shown in blue with black lines and the obb is shown as purple lines.
(Edit) As requested: Interactive Version - tested only in chrome
Now I want to extend my code to build an OBB tree, instead of just an OBB. This means I have to cut the polygon, and compute new OBBs for each half of the polygon.
The recommended way to do this seems to be to cut the polygon by cutting the OBB in half. But if I cut the obb through the middle in either of its axes it looks like I would have to create new vertices on the polygon (otherwise how do I find the convex hull of that partition?).
Is there a way to avoid adding vertices like this?
If not, what is the easiest way to do it (with respect to implementation difficulty)? What is the most runtime-efficient way?
Here's an example of a concave polygon that we want to create an OBB tree for:
In order to split it into a new set of concave polygons, we can simply cut our current polygon by cutting the bounding box down the middle and adding new 'intersection' vertices as appropriate:
:
This can be done in O(vertices) time because we can simply iterate through all of the edges, and add an intersection vertex if the edge crosses the red splitting line.
The polygon can then be divided in terms of these intersection vertices to get a new set of smaller (but still possibly concave) polygons. There will be at least two such polygons (one per side of the red line) but there may be more. In this next picture, the new polygons have been colored for emphasis:
Recursively computing the oriented bounding boxes for these smaller polygons gives the desired result. For example, here are the boxes from recursion depth 2:
Hopefully this is clear enough to help someone who's struggling the same way I was!
I'm not really sure this is what you need without further context, but here goes...
Subdividing a concave polygon into a set of convex polygons
In my comment above I suggested recursively subdividing the concave polygon in order to obtain a set of convex polygons instead. One (common) approach is the following:
If the polygon is convex, stop. (add the polygon to an array, I suppose)
Select an unmarked edge of the polygon. Mark the edge.
Split the polygon across the edge (actually: the infinite line coinciding with the edge).
Recursively repeat this algorithm for both result polygons (if non-empty).
Note: This is exactly how a BSP tree is built. Except in the algorithm above we're not building tree nodes and storing polygons in them. Maybe a BSP-only solution would be a solution to your problem as well (instead of using OBBs).
Testing a polygon for convexity (step 1)
For each edge, classify each vertex as on, in front or behind the edge. All vertices should be on or in front of the edge. If not (at least 1 vertex behind the edge), the polygon is concave. For details on the 'classifying' part, see my answer to a different question, which does this as well.
The rest
Once you have the list of convex sub-polygons, you could generate OBBs for them as you've done in your original post. You would not have an OBB tree though...
With the subdividing, you are adding vertices (a concern in your question). Depending on your application you may not need to use the subdivided polygons though: If you were to use a BSP tree and only needed simple collision you'd just traverse the tree and do some point/edge classifications and not deal with any polygon vertices.
Anyway, not really sure what to recommend further since I don't know what you want your application to do, but hopefully this is of some help.
Edit: I just realized that maybe this is what you want to do: Build a BSP tree and generate OBBs for each node, from root to leaf nodes. So the root node OBB would contain the entire concave polygon, and leaf nodes only convex sub-polygons. I remember the original Doom engine does something similar (except with axis-aligned BBs).
Related
I'm looking for an algorithm or tried & tested method for analyzing irregular polgygons and reducing them to primitives (squares, rectangles, trapeziums). A way of recurrsively looking over shapes to determine the best fit for regular polygons.
see image blow
The black shapes are the irregular polygons and the blue depicts the desired regualar, which fits inside. The left example should be straight forward but that's because it's a case of finding the a rectangle that can fit in the largest shape. The polygons will be of an undetermined size (but let's say they have less then 32 sides) What I'm hoping for is to be able to break up polys into several regualar ones - which is where I'm a little lost.
Sadly, I've no code at this point as I'm stuck to know the best way forward. The script will be done in pure JavasScript. This isn't homework :)
First of all, you need to check whether your polygon is convex or concave. If it is the latter, then you need to view it as several convex polygons "put together" and handle them separately. (It is easy to your mind to imagine a large pair of scissors which cuts the polygon into several smaller polygons). When this is done, you either have a single polygon, or several polygons.
For each polygon, calculate the gravity point of the polygon and (P(i), P((i + 1) mod n), G) will form a trivial form, a triangle. These triangles will solve your problem.
If you need shapes with four angles, then four consecutive points form a shape of four angles. But this approach might leave you with a smaller polygon with lesser number of angles in the middle of the main polygon, which will have to be handled.
I am working on a data set of coordinate points(many dots in area) either (x,y) or (lat,lon) which fall into multiple categories. What I am trying to do is get polygons of areas from those points which are called concave or non-convex as far as I know, but also those polygons have to be next to each other with no gaps between them.
These are the initial points(example)
This is the approximate result I am aiming for
Real life example would be European geopolitical map, if you had all of the addresses of all countries and wanted to get area of each country as a polygon and end up with a map.
I have come across many questions related to getting polygons from set of points, but were unable to use it in my scenario. If you need any more information please let me know. Thank you for your help.
You could use a Voronoi tesselation of the input space. Instead of having point you have sets of points though. Basically, you take each point in space, and look at the closest point to it. It then gets the same "class" as that point. For smoother outputs you could look at a k majority out of N nearest points. It would mean working with a bitmap image rather than 2D coordinates, but you'd get something workable. You could then use simpler image manipulation tricks (edge detection, binary set operations etc to get just the edges, and then perhaps superimpose those on the image).
As an alternative, you could run a convex hull algorithm on each data set, and then try to fix the overlap areas.
I'm developing the open-source JavaScript plugin for Waze -- well-known free GPS navigator -- specifically for online editor. The idea of this userscript is to make it possible to quickly select large uniform colored map areas to convert them to landmarks.
So far I've successfully implemented the tool you would call "Magic Wand" in graphic editors like Photoshop: user clicks somewhere on the map (say, on the lake or forest) and script selects whole area covered by same color and creates a polygon for landmark.
Everything works great except that I am using convex hull algorithm to obtain the... well... convex hull :) That is: the polygon connecting the most outer points of the found points cloud.
But as everyone understand only few landmarks have a convex shape while most of real world objects have a polyline shape with concave areas. On the picture above you can see that the area has few sharp edges and a farmfield in the right bottom corner covered by convex hull -- that's wrong.
I was Googling for suitable algorithm and digging through math papers but still have no luck finding one. The most popular question about concave hulls here on Stackoverflow refers to Alpha-shapes along with Delaunay triangles. Though I don't understand how to use it in case: all points are connected to each other forming a continuous polyline thus it seems that I cannot find suitable alpha-radius as even circle with radius equal to 1 pixel with be alpha-exposed.
Any ideas how to archive the goal of building a concave hull will be much appreciated! May be I am moving in a wrong direction and need to look at bitmap vectorization algorithms?
Alpha shapes is defined by finding the delaunay triangulation of a set of points and then delete edges that exceed alpha. You need the delaunay triangulation but not the circles. It's also works with lines. To calculate the shape with JS you can use TopoJSON or try this answer:Calculate bounding polygon of alpha shape from the Delaunay triangulation. You can also try my php package http://concavehull.codeplex.com/.
You can read how to implement concave hull algorithm in this paper. The basic idea is to build the convex hull and flex (concave) edges inward.
There is JavaScript implementation of this algorithm: hull.js.
What is the neatest (code design) and most per-formant way of getting an array of points for an arc (polyline), for the purpose of animating using Cesium's timer/clock.
Variable inputs include (start/end location), height (highest point) from earth's surface and number of points for drawing.
I'm currently using a polyline collection, so the answer should describe how to generate the points for existing polylines or convert to a different approach.
I would also need the arc (color) to fadeIn or fadeOut to opacity 0.
Multiple arcs may be added or removed from the collection per second. Each arc will have different start and end points
The start and end location should have height 0 (touching the earth).
(For Cesium version b26)
Just to be sure I understand your question, you have a bunch of polylines on a map and you want to get a bunch of data points along the line for use in animating the something along the path. I'll also assume you want geodesic lines/arcs for the polylines rather than the straight lines that are normally drawn on Mercator maps as geodesic lines actually follow the spatially accurate path of the polyline i.e. the same path a plane would take. If this is the case then take a look at this blog post: http://alastaira.wordpress.com/2011/06/27/geodesics-on-bing-maps-v7/ This post describes how to calculate data points along the geodesic path of a polyline.
CesiumJS includes several spline functions that can be used. One of the easier ones to use that an accomplish what you want with just three points is the Catmull-Rom Spline:
http://cesiumjs.org/Cesium/Build/Documentation/CatmullRomSpline.html
You will need to produce a middle point. To do this you can take a mean of the lat/lon coordinates and add a large height. Because of the spline used and the low number of points, it does end up looking a little egg shaped. The benefit to this is that you can ask the spline object for an arbitrary number of points, so the arc can be as smooth as you want. Just don't forget to add the first and last points to the array returned by the spline as those are omitted.
There are other types of splines, but I found the Catmull-Rom spline the easiest to use. You can search the CesiumJS documentation for some of the other included splines.
I've been looking into the same thing (minus the time aspect) and I found Cesium.EllipsoidGeodesic(start, end, ellipsoid), which allows you to get points at fractions of the path. It seems to me that you can choose the fraction based on the distance and calculate regular points using the result.
https://cesiumjs.org/Cesium/Build/Documentation/EllipsoidGeodesic.html
I haven't tried it yet, but it's on my list of things to do.
I am creating a piece of javascript code where it's necessary to identify every polygon created from a number of randomly generated intersecting lines. The following screenshot will give a better explanation of what I'm talking about:
Now, I need to calculate the area of each polygon and return the largest area. The approach I'm taking is to identify every intersection (denoted with red dots) and treat them as a vertex of whichever polygon(s) they belong to. If I can somehow identify which polygon(s) each vertex/intersection belongs to, then arrange the vertices of each polygon in a clockwise direction then it would be simple to apply the shoelace theorem to find the area of each polygon.
However, I'm afraid that I'm completely lost and have tried various (failed) methods to achieve this. What is the best way to compile a list of clockwise-arranged vertices for each polygon? I'm working on acquiring which segments are associated with every given intersection, and I think this is a step in the right direction but I don't know where to go from there. Does this require some vector work?
I can think of one possibility. Here I've labeled each of the vertices.
(source: i.imm.io)
I'm assuming that if you know the lines involved and their intersections, you can find all the line segments that intersect at a particular point. So lets start with a particular point, say K, and a directed segment, IK. Now we have four directed segments that lead from the end of that, KI, KJ, KL, and KM. We are interested only in the two that are closest to, but not on, the line KI. Let's focus on KM, although you can do the same thing with KJ.
(Note that if there are more than two lines intersecting at the point, we can still find the two that are closest to the line, generally one forming a positive angle with the initial segment, the other a negative one.)
We notice that IKM is a positive angle, and then examine the segments containing M, choosing the one with the smallest positive angle with KM, in this case MF, do this again at F (although there are only two choices here) to get FG, and then GH, and then HI, which completes one polygon, the hexagon IKMFGH.
Going back to our original segment of IK, we look at our other smallest angle, IKJ, and do a similar process to find the triangle IKJ. We have now found all the polygons containing IK.
Then of course you do this again, each other segment. You will need to remove duplicates, or be smarter about not continuing to analyze a path when you can see it will be a duplicate. (Each angle will be in at most one polygon, so if you see an angle already recorded, you can skip it.)
This would not work if your polygons weren't convex, but if they are made from lines cut through a rectangle, I'm pretty sure they will always be convex.
I haven't actually tried to code this, but I'm pretty sure it will work.
Two methods I can think of that are probably not the most efficient but should help out:
You can figure out the set of points that make up the polygon containing an arbitrary point by drawing an imaginary line from the arbitrary point to each other point, the ones that draw a line not intersecting any lines in your image are the vertices that make the convex polygon you care about. The problem with this method is I can't think of any particularly good method to reliably get all of the polygons (since you only care about the largest perhaps random/periodic sampling will suffice?)
For each possible polygon check to see if there is any line segment that lies within that polygon (a line segment that bisects 2 edges of the polygon) and if there is remove that polygon from your set. At the end you should only be left with the ones you care about. This method is very slow though.
If my explanations were unclear I can update with a couple pictures to help explain.
Hope this helps!