I want to calculate intersection points of polyline and a closed 3D surface (given as a set of polygons).
For simple 2D cases I can use shapely. Can you advice me something for 3D case?
P.S. My programming language is Python, but C++ libraries can be useful too.
Consider every line segment and every polygon independently and build their axis-aligned bounding boxes. Now for every pair of overlapping boxes, rotate the polygon to the horizontal plane, and the segment accordingly, and find the piercing point of the supporting line of the segment.
Then check if the piercing point belongs to the segment and to the inside of the polygon.
Related
I'm trying to find the maximum projected area of distorted-3D-closed-polygon.
This one is original polygon, which is regular.
I distorted this polygon by randomly choosing two point, and bending the structure of polygon around the line that connects two points.
This is the distorted polygon.
What I want to do is calculating the projected area of this polygon.
I initially thought that this could be calculated like other self-intersecting or overlapping ones, however, it wasn't.
For example, the two different shapes above have the same topology when projected.
However, the areas that has to be concerned is different.
Therefore, it is necessary to take 3D topologies into account, and this is where I stucked.
How can I handle the complexity of this problem?
I have a set of 3d points in a txt file in the form of (x,y,z) as shown in figure 1. I want to specify the boundaries of these points as in figure 2 such that if any new points were added outside the boundaries they are deleted as the blue points, and if they are inside the boundaries as the green ones they are kept. How can I achieve that in python? I tried convex hull but it only gets the boundary points !
The real data can be found here, I used figures for simplification. https://drive.google.com/file/d/1ei9NaJHN922pYItK2CRIXyLfwqm_xgrt/view?usp=sharing
Figure 1
Figure 2
For 2D points, you can apply the test as described in Wikipedia:
One simple way of finding whether the point is inside or outside a simple polygon is to test how many times a ray, starting from the point and going in any fixed direction, intersects the edges of the polygon. If the point is on the outside of the polygon the ray will intersect its edge an even number of times. If the point is on the inside of the polygon then it will intersect the edge an odd number of times. The status of a point on the edge of the polygon depends on the details of the ray intersection algorithm.
The n-dimensional case involves a convex hull test and requires linear programming techniques as described here.
I have an algorithm which generates from three to six points of intersection between a plane and the edges of a cube which contains that plane. For drawing the plane (which gets drawn a polygon) OpenGL needs the vertex to be ordered as in the following picture:
If the vertex are unordered, this result may be drawn:
Edit: I found this question but I don't know how to code it in Python and that's not exactly what I need
If points were built as intersections between a plane and the edges of a cube, then they form convex polygon.
To properly order vertices of this polygon, make projection onto some plane - or onto section plane, or onto one of OXY, OXZ, OYZ planes - just choose one not normal to section plane and make corresponding component zero.
Then choose the leftmost point in that plane as base and sort other points by polar angle relative to base.
I have a set of co-planar points in 3D. Some of these points that are co-planar form a circle while some co-planar points do not.
Is there a way for me to program (ideally python) and determine what points are forming a circle and what points do not?
I have seen solutions for this problem in 2D space here which probably won't work in 3D while the solutions proposed here are "mathematica" focused that I am unable to apprehend fully.
Can someone please guide me towards the possible solution?
Any three points always lie on a circle. Find one circle, then test any other points. Doing that in 3D is almost the same as in 2D (https://www.gamedev.net/forums/topic/489058-how-to-draw-a-circle-given-three-points-in-3d-space/)
I have no real experience with GIS data, so when what I believed to be a simple problem has turned out to have more subtleties to it, I am dangerously unprepared!
I want to be able to classify a GPS position as inside/outside a polygon defined by GPS co-ordinates. It turns out this is the well-known (but not to me) point-in-polygon problem. I have read many questions/answers on https://gis.stackexchange.com/ (and here e.g. this).
Shapely seems a good solution, but assumes the co-ordinates are on the same cartesian plane, i.e. not GPS? So I would first need to transform my GPS points to UTM points.
Do I need to introduce this extra step, however, if the points being compared (i.e. the point and the polygon) are always going to be naturally within the same UTM zone. They should always be within the same town/city, so can I just leave them as GPS and use the lat/long co-ordinates in Shapely?
I also came across this UTM-WGS84 converter so I could convert my lat/long pairs using this package, and then use those UTM pairs in Shapely, but I would like to avoid any extra dependencies where possible.
Point-in-polygon already assumes a 2D restriction, and GPS coordinates are 3D. Right away, that gets you in trouble.
A simple workaround is to discard the GPS height, reducing it to 2D surface coordinates. Your next problem is that that your 2D surface is now a sphere. On a spherical surface, a polygon divides the surface in two parts, but there is no obvious "inside". There's a left-hand side and a right-hand side which follows from the order of points in the polygon, but neither side is the obvious "inside". Consider the equator as a trivial polygon - which hemisphere is "inside" the equator?
Next up is the issue of the polygon edges. By definition, these are straight, i.e. line segments. But lines on a spherical surface are weird - they're generally known as great circles. And any two great circles cross in exactly two points. That's not how cartesian lines behave. Worse, the equations for a great circle are not linear when expressed in GPS coordinates, because those are longitude/latitude pairs.
I can imagine that at this point you're feeling a bit confused. You might want to look at this from another side - we have a similar problem with maps. Globe maps are by definition attempts to flatten that non-flat surface. Since that's not exactly possible, you end up with map projections. You can also project the corner points of your polygons on such projections. And because the projections are flat, you can draw the edges on the projection. You now see the problem visually: On two different projections, identical polygons will contain different parts of the world!
So, since we agreed that in the real world, the edges of the polygons are great circles, we should really consider a projection that keeps the great circles straight. There's exactly one family of projections that has this property, and that's the Gnomonic projection. It's a family of projections because you can pick any point as the center.
As it happens, we have one natural point to consider here: the GPS point we're considering. If you put that in the center, draw a gnomonic projection around it, project the polygon edges, and then draw the polygon, you have an exact solution.
Except that the actual earth isn't spherical. Sorry. How exact did you need the test to be, anyway?