Update centroid calculation of geo_shape for geo-centroid

[talevy]

where things are now

As the geoshape-doc-values branch stands today, the centroid is
defined as the centroid of all the geometry's vertices.

Why the update?

After a re-visit of this strategy, we decided that it would be worth
modifying this calculation to be closer in line with how popular
geo-spatial data-stores compute the centroid.

After exploring existing implementations for some of these, it seems there are a few commonalities. I'll list in the detailed definition below.

Proposed detailed definition of a centroid of a geo_shape field

Geometry Type	Centroid Calculation
[Multi]Point	equally weighted average of all the coordinates
[Multi]LineString	a weighted average of all the centroids of each segment, where the weight of each segment is its length in degrees
[Multi]Polygon	a weighted average of all the centroids of all the triangles of a polygon where the triangles are formed by every two consecutive vertices and the starting-point. holes have negative weights. weights represent the area of the triangle in deg^2 calculated using The Shoelace Formulate
GeometryCollection	The centroid of all the underlying geometries with the highest dimension. If Polygons and Lines and/or Points, then lines and/or points are ignored. If Lines and Points, then points are ignored

Proposed definition of a geo-centroid of a bucket

The un-weighted centroid of the centroid of each shape within the bucket.

Below is a summary of the descriptions from various sources:

• OGC Standard

"No specific algorithm is specified for the Centroid function; answers may vary with implementation."

- OpenGIS® Implementation Standard for Geographic information - Simple feature access - Part 2: SQL option

The OGC standard does not specify any specific way one
should calculate the centroid.

• Oracle SQL

Returns a point geometry that is the centroid of a polygon, multipolygon, point, or point cluster. (The centroid is also known as the "center of gravity.")

For an input geometry consisting of multiple objects, the result is weighted by the area of each polygon in the geometry objects. If the geometry objects are a mixture of polygons and points, the points are not used in the calculation of the centroid. If the geometry objects are all points, the points have equal weight.

The Oracle definition does not specify how one should implement and define weight.
It interestingly also does not describe the behavior for line-strings.

• PostGIS

Computes the geometric center of a geometry, or equivalently, the center of mass of the geometry as a POINT. For [MULTI]POINTs, this is computed as the arithmetic mean of the input coordinates. For [MULTI]LINESTRINGs, this is computed as the weighted length of each line segment. For [MULTI]POLYGONs, "weight" is thought in terms of area. If an empty geometry is supplied, an empty GEOMETRYCOLLECTION is returned. If NULL is supplied, NULL is returned. If CIRCULARSTRING or COMPOUNDCURVE are supplied, they are converted to linestring wtih CurveToLine first, then same than for LINESTRING

The centroid is equal to the centroid of the set of component Geometries of highest dimension

Similarly, this description does not go into detail about how either the "center of mass" or the "weighted length" is calculated.

Discussion Item

• Is this new definition of centroid the one we would like?
  For example, there can be multiple interpretations of how
  the centroid as an aggregate function should be calculated.
  These specs define ST_Centroid as a simple function on one
  field value. Geo Centroid aggregation is the centroid of a field
  in multiple documents. Should all these field values be treated as
  a singular GeometryCollection which the centroid is derived from,
  or should we treat each document as a singular point (computed using above)
  with equal weight.
• should weight be measured in degrees and degrees^2, or meters and meters^2?

[elasticmachine]

Pinging @elastic/es-analytics-geo (:Analytics/Geo)

[talevy]

Here is a proposed WIP implementation of above: talevy@a713f5c

Updating the CentroidCalculator seemed pretty straightforward. The one extra requirement that has yet to be tackled is how to determine which types of shapes exist in the geometry. There are two ideas I have there: one requires yet another iteration of the geometry, another requires more space/variables for each dimension.

[talevy]

We discussed this in our analytics/geo team meeting and concluded that:

• the scope of this centroid definition is to the geo_centroid aggregation, not necessarily all definitions of centroid in other future contexts
• the centroid of a bucket is that of all geometries that reside in that bucket treaded as one geometry-collection. not a centroid of centroids of shapes
• center of mass calculations as described will be implemented in degrees and degrees^2

[talevy]

Information about a shape's dimension for centroid calculation is introduced in #50104.

[jpountz]

the centroid of a bucket is that of all geometries that reside in that bucket treaded as one geometry-collection. not a centroid of centroids of shapes

+1 this is also more consistent with the current behavior of the centroid aggregation on points in the case of a multi-valued field

[talevy]

excuse me. I forgot to mention that there is more than just the shape's type/dimension that needs to be serialized: the sum of the weight (can be negative)

[talevy]

this was implemented in #50297. closing