Hello Everyone,
I am writing to ask some questions about the
public SphericalPolygonsSet(double hyperplaneThickness, S2Point… vertices)
I know from previous questions on the forum/documentation that the vertices must be defined in CCW order to define the area (the “inside” of the points) and that if I define them in the opposite way I am going to define all the earth minus the area inside the vertices. I have one more question though, is it possible from the SphericalPolygonsSet already defined to understand which area is defined?
I am trying to explain better my doubt:
Let’s say that I receive from another source (not defined myself) the vertices of the Area on the Ground and then I create the SphericalPolygonsSet. At this point I am not sure if the area defined is the “inside area (CCW order)” of the points or the “outside area (CW order)” of the points.
Is there a way to be sure of which area I am considering after the creation of the set or do I have to order the vertices before to be sure to define the area I want?
Another small question related to this; from documentation I can see that the
hyperplaneThickness should be greater than FastMath.ulp(4 * FastMath.PI) but what this value represents exaclty and how can I be sure to use the right value? Is it an error and try method or are there some general rules that I can use to define it?
I am sorry if my questions seems stupid, but I would like to have a deeper understand on this matter.
Thank you for the help.
Gabri
One thing you can do is check the area using the getSize()method. For a SphericalPolygonsSet it returns a solid angle in steradians. If you are defining some “reasonably small” area, you expect this area to be small. So just check if it is smaller or larger that 2PI (i.e. one half of the total sphere area). If it is larger than 2PI, chances are that you have defined the complementary of the region you initially wanted. So using RegionFactory.getComplement() would allow to revert it in this case.
The hyperplane thickness is used to work around problems linked to numerical noise. Computational geometry is always plagued by numerical noise and this cannot be solved in the general case as we don’t have infinite accuracy. So in most geometrical packages, boundaries are often computed not as infinitly thin lines, planes or hyperplanes, but they do have an associated thickness and the various algorithms (typically for intersection) use that thickness. There are no absolut rule to know which thickness to use. FastMath.ulp(4 * FastMath.PI) is just the minimum value and in reality it is really really small. Below this, you loose a number of significant digits. The value to use depends on your problem and your needs. On the sphere, I usually use 1.0e-10 as the hyperplane thickness, and in fact it was the internal thickness that was enforced for a long time before we made it customizable by users. Be aware that whatever the thickness is, computing regions with almost parallel edges (say a change of direction of a few nanoradians between two consecutive edges, or on the contrary a peak with a change of direction of PI minus a few nanoradians) will be difficult. This should be avoided if possible.
@luc Thank you so much for the detailed explanation.
One last question for you @luc, is the hyperplane thickness an angle to be defined in radiants or a value without unit of measure?