Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve MultiPolygon centroid robustness #118

Merged
merged 4 commits into from
Aug 22, 2017
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -153,7 +153,6 @@ else if (ptCount > 0){

private void setBasePoint(Coordinate basePt)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about we rename this to setAreaBasePoint? Makes it a teeny bit more descriptive, and indicates that this functionality is only necessary for areas.

{
if (this.areaBasePt == null)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

interesting This fixes the issue?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the test case I included, yes.

this.areaBasePt = basePt;
}

Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
package org.locationtech.jts.algorithm;

import junit.framework.TestCase;
import org.locationtech.jts.geom.Coordinate;
import org.locationtech.jts.geom.Geometry;
import org.locationtech.jts.io.WKTReader;

public class CentroidTest extends TestCase {

private static final double tolerance = 1e-10;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A minor style point - I like to make static final fieldnames uppercase, so it's obvious that they are constants.


public CentroidTest(String name) {
super(name);
}

/** Compute the centroid of a geometry as an area-weighted average of the centroids
* of its components.
*
* @param g a polygonal geometry
* @return Coordinate of the geometry's centroid
*/
private static Coordinate areaWeightedCentroid(Geometry g) {
double totalArea = g.getArea();
double cx = 0;
double cy = 0;

for(int i = 0; i < g.getNumGeometries(); i++) {
Geometry component = g.getGeometryN(i);
double areaFraction = component.getArea() / totalArea;

Coordinate componentCentroid = component.getCentroid().getCoordinate();

cx += areaFraction * componentCentroid.x;
cy += areaFraction * componentCentroid.y;
}

return new Coordinate(cx, cy);
}

public void testCentroidMultiPolygon() throws Exception {
// Verify that the computed centroid of a MultiPolygon is equivalent to the
// area-weighted average of its components.
Geometry g = new WKTReader().read(
"MULTIPOLYGON ((( -92.661322 36.58994900000003, -92.66132199999993 36.58994900000005, -92.66132199999993 36.589949000000004, -92.661322 36.589949, -92.661322 36.58994900000003)), (( -92.65560500000008 36.58708800000005, -92.65560499999992 36.58708800000005, -92.65560499998745 36.587087999992576, -92.655605 36.587088, -92.65560500000008 36.58708800000005 )), (( -92.65512450000065 36.586800000000466, -92.65512449999994 36.58680000000004, -92.65512449998666 36.5867999999905, -92.65512450000065 36.586800000000466 )))"
);

assertTrue(areaWeightedCentroid(g).equals2D(g.getCentroid().getCoordinate(), tolerance));
}

}
Original file line number Diff line number Diff line change
Expand Up @@ -242,6 +242,30 @@
<test><op name="getCentroid" arg1="A" > POINT (56.52883333335 25.21033333335) </op></test>
</case>


<case>
<desc>A - almost degenerate MultiPolygon</desc>
<a>
MULTIPOLYGON (((
-92.661322 36.58994900000003,
-92.66132199999993 36.58994900000005,
-92.66132199999993 36.589949000000004,
-92.661322 36.589949,
-92.661322 36.58994900000003)),
((
-92.65560500000008 36.58708800000005,
-92.65560499999992 36.58708800000005,
-92.65560499998745 36.587087999992576,
-92.655605 36.587088,
-92.65560500000008 36.58708800000005
)),
((
-92.65512450000065 36.586800000000466,
-92.65512449999994 36.58680000000004,
-92.65512449998666 36.5867999999905,
-92.65512450000065 36.586800000000466
)))
</a>
<test><op name="getCentroid" arg1="A" >POINT (-92.6553838608954 36.58695407733924)</op></test>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A similar comment here. This seems brittle WRT numeric precision. Not your problem, but it would be nice if the XML test syntax allowed defining a precision tolerance for expected results. (For centroid computation the tolerance can be quite fine, since the algorithm should produce very close results).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the XML Test format doesn't provide a way of expressing a tolerance value, this is fine as it stands. If it breaks in the future, that will be motivation to add a tolerance!

</case>

</run>