locationtech
ShapeReader conversion does not always correctly identify holes
ShapeReader can give unexpected (at least to me...) results in some cases, I believe because the assumption within isHole(Coordinate[] pts) does not always match the underlying Java AWT representation.
Here is a short example, subtracting a small rectangle from a larger rectangle:
import org.locationtech.jts.awt.ShapeReader;
import org.locationtech.jts.geom.Geometry;
import org.locationtech.jts.geom.GeometryFactory;
import java.awt.Graphics2D;
import java.awt.Rectangle;
import java.awt.geom.Area;
import java.awt.image.BufferedImage;
// Define large & small rectangles
int bigSize = 100;
int smallSize = 50;
Rectangle rectBig = new Rectangle(5, 5, bigSize, bigSize);
Rectangle rectSmall = new Rectangle(30, 30, smallSize, smallSize);
// Subtract small from large
Area area = new Area(rectBig);
area.subtract(new Area(rectSmall));
// Print out areas from corresponding Geometry objects
ShapeReader reader = new ShapeReader(new GeometryFactory());
Geometry geomBig = reader.read(rectBig.getPathIterator(null));
Geometry geomSmall = reader.read(rectSmall.getPathIterator(null));
Geometry geomCombined = reader.read(area.getPathIterator(null));
System.out.println("Area of big rectangle: " + geomBig.getArea());
System.out.println("Area of small rectangle: " + geomSmall.getArea());
System.out.println("Area of combined geometry: " + geomCombined.getArea());
System.out.println("Area of combined geometry (with buffer): " + geomCombined.buffer(0).getArea());
System.out.println("Combined geometry: " + geomCombined);
// Create a binary image for an extra check
BufferedImage img = new BufferedImage(bigSize+10, bigSize+10, BufferedImage.TYPE_BYTE_GRAY);
Graphics2D g2d = img.createGraphics();
g2d.fill(area);
g2d.dispose();
int[] px = new int[img.getWidth()*img.getHeight()];
img.getRaster().getSamples(0, 0, img.getWidth(), img.getHeight(), 0, px);
System.out.println("Area from raster: " + Arrays.stream(px).filter(i -> i > 0).count());
This prints the following:
Area of big rectangle: 10000.0
Area of small rectangle: 2500.0
Area of combined geometry: 12500.0
Area of combined geometry (with buffer): 10000.0
Combined geometry: MULTIPOLYGON (((80 30, 80 80, 30 80, 30 30, 80 30)), ((5 5, 5 105, 105 105, 105 5, 5 5)))
Area from raster: 7500
I would expect the Geometry area to also be 7500 if the hole was correctly identified.
My aim is to switch easily betweenShape and Geometry representations. Given the diversity of possible Shape implementations, I am unclear on what assumptions can be made about the PathIterator in general - however the javadoc for java.awt.geom.Area states
- The interiors of the individual stored sub-paths are all non-empty and non-overlapping [...]
- The geometry of the path describing the outline of the Area resembles the path from which it was constructed only in that it describes the same enclosed 2-dimensional area, but may use entirely different types and ordering of the path segments to do so.
Therefore I figured that converting closed shapes to Area objects first would be the simplest/most reliable way to approach this, giving a PathIterator with more predictable behavior.
Any corrections / tips for how to do this conversion better would be much appreciated!
I have the exact same problem. The holes in my area are converted to solid in the geometry.
I though at first that it was a winding rule issue: the PathIterator created from the area was set to WIND_NON_ZERO with no way to change it.
So, I used Path2D instead:
Path2D.Double path = new Path2D.Double(area);
path.setWindingRule(PathIterator.WIND_EVEN_ODD);
Geometry geomCombined = reader.read(path.getPathIterator(null));
System.out.println("Area of combined geometry: " + geomCombined.buffer(0).getArea());
However, even with the winding rule set to WIND_EVEN_ODD, the hole remains incorrectly identified.
Note: the problem is not just with the area of the geometry. Using intersects and intersection with points in the hole also detect the presence of points where none are expected:
Coordinate coordinate = new Coordinate(55, 55); // center of hole
org.locationtech.jts.geom.Point center = (new GeometryFactory()).createPoint(coordinate);
System.out.println("Center intersects hole? " + geomCombined.intersects(center)); // returns true instead of false
I returned to this when trying to convert binary images to valid multipolygons, via Java Area objects (I'd happily skip the Area step if possible).
It seems to be safer to convert via Polygonizer than ShapeReader. The following code mostly worked for me (passes the above test):
private static Geometry convertAreaToGeometry(final Area area, final AffineTransform transform, final double flatness, final GeometryFactory factory) {
PathIterator iter = area.getPathIterator(transform, flatness);
PrecisionModel precisionModel = factory.getPrecisionModel();
Polygonizer polygonizer = new Polygonizer(true);
List<Coordinate[]> coords = (List<Coordinate[]>)ShapeReader.toCoordinates(iter);
for (Coordinate[] array : coords) {
for (var c : array)
precisionModel.makePrecise(c);
LineString lineString = factory.createLineString(array);
if (lineString.isRing())
polygonizer.add(lineString);
else
polygonizer.add(lineString.union());
}
return polygonizer.getGeometry();
}
However it does still fail sometimes. Specifically, it can be thwarted if a ring is duplicated by the PathIterator, which happens in the following 5x5 image:
After tracing a corresponding Area and requesting the PathIterator, it results in the following input to Polygonizer
LINESTRING (2 2, 2 3, 3 3, 3 2, 2 2)
LINESTRING (3 1, 3 2, 4 2, 4 3, 3 3, 3 4, 2 4, 2 3, 1 3, 1 2, 2 2, 2 1, 3 1)
LINESTRING (0 0, 0 5, 5 5, 5 0, 0 0)
and the exception
java.lang.NullPointerException: null
at org.locationtech.jts.algorithm.locate.IndexedPointInAreaLocator.locate(IndexedPointInAreaLocator.java:90)
at org.locationtech.jts.operation.polygonize.EdgeRing.isInRing(EdgeRing.java:261)
at org.locationtech.jts.operation.polygonize.EdgeRing.findEdgeRingContaining(EdgeRing.java:87)
at org.locationtech.jts.operation.polygonize.HoleAssigner.findShellContaining(HoleAssigner.java:106)
at org.locationtech.jts.operation.polygonize.HoleAssigner.assignHoleToShell(HoleAssigner.java:78)
at org.locationtech.jts.operation.polygonize.HoleAssigner.assignHolesToShells(HoleAssigner.java:72)
at org.locationtech.jts.operation.polygonize.HoleAssigner.assignHolesToShells(HoleAssigner.java:40)
at org.locationtech.jts.operation.polygonize.Polygonizer.polygonize(Polygonizer.java:255)
at org.locationtech.jts.operation.polygonize.Polygonizer.getGeometry(Polygonizer.java:188)
caused by tryEdgeRing.isInRing(testPt); being applied to a coordinate that is null here. This seems to trace back to all points in the first linestring being present in the second.
I'm not sure if that's a polygonizer bug or just that the input is bad and so it's expected not to work, but in any case the input is what Java's PathIterator gives me. I haven't yet found a way to prepare the coordinates from the PathIterator in a way that is always acceptable.
Sorry, I should have thought a bit harder... the following code works without the NPE:
private static Geometry convertAreaToGeometry(final Area area, final AffineTransform transform, final double flatness, final GeometryFactory factory) {
PathIterator iter = area.getPathIterator(transform, flatness);
PrecisionModel precisionModel = factory.getPrecisionModel();
Polygonizer polygonizer = new Polygonizer(true);
List<Coordinate[]> coords = (List<Coordinate[]>)ShapeReader.toCoordinates(iter);
List<Geometry> geometries = new ArrayList<>();
for (Coordinate[] array : coords) {
for (var c : array)
precisionModel.makePrecise(c);
LineString lineString = factory.createLineString(array);
geometries.add(lineString);
}
polygonizer.add(factory.buildGeometry(geometries).union());
return polygonizer.getGeometry();
}
I have only tested it with integer coordinates, but it seems to give the right results where ShapeReader does not - including in a particularly complex noise image.
(I'd appreciate any fixes if it's wrong or there's a better/faster way to do this)