Investigate Centroid Computations for Meshes with Convex Polygons & Other Edge Cases

[philipc2]

trafficstars

          > > > I would say that our test `test_centroids_from_mean_verts_scrip` is pretty comprehensive, since it runs the algorithm on a dataset that already has `Mesh2_face_x/y` and the results match up. This dataset is also made up of quads, which checks off the first point.

However, additional tests would be good to have.

So does this SCRIP dataset use a real spherical surface presentation (curved) or an approximate one using triangles? The point is that only averaging the coordinates without normalization (our current implementation), the centroid is not actually on the sphere (Unless that's exactly what we want)

I believe so

*SCRIP: A Spherical Coordinate Remapping and Interpolation Package (SCRIP) is a software package used to generate interpolation weights for remapping fields from one grid to another in spherical geometry. It was developed at the Los Alamos National Laboratory by Philip W. Jones. The SCRIP library was converted from Fortran to ANSI C and is used as the base for remapping operators in CDO.

A spherical coordinate system doesn't necessarily mean they are using a curve surface here. Many application utilizes triangles to approximate the sphere, which works fine as well. It's just our project definition of the unit sphere is an actual curved spherical surface. So it's always good to clarify that in our description and definition

Again, in the geometry calculation, directly averaging the cartesian coordinates of a curved "triangle" in the 3-D spaces, the resulted "centroid" shouldn't be on the spherical surface.

However, the normalization process can project this "centroid" to the surface.(By calling the _get_latlon_from_xyz, which is done in the centroid function, good work). But I am not sure if this "projected" centroid is the real centroid according to the definition. This projection might cause the projected point outside the polygon under some extreme circumstances (even for a convex polygon).

The curved surface is way more complicated than the normal plane surface. And it's understandable that we want to stay with the current implementation to expedite the process as well. Just make sure to clarify that in the comment and do some precheck for the input data. Again, we don't want the program to crash silently if the users apply it to some weird polygons.

That's what I was talking about. If we can only confirm this will only be valid within a convex polygon, we should include that in the description. And if the input polygon is not convex, a warning should be raised. Otherwise, someone will get a silence crash when they're trying to apply this function on a concave polygon, which we don't want to see happening.

Another thing that brought up my concern here is that we are working on the spherical surface. So my questions here are:

The coordinates averaging works in the 3-dimensional space for "planes" like n-dimensional simplex. Does it work for the spherical surface?

Even though we assume it works, we need to add the normalization step for your centroid calculation function (I also added a comment there). After we project it to the spherical surface using this naive method, How can we confirm that the projected centroid (if we assume it's the centroid we want) is still within the polygon on the sphere? Because the edge might arc up on the sphere

Originally posted by @hongyuchen1030 in https://github.com/UXARRAY/uxarray/pull/466#discussion_r1349144017