Add new CoverageEdgeExtractor class to extract unique edges from a polygonal coverage

[nstrahl]

Since CoverageValidator will only return the invalid edges of a coverage, it would be very convenient to be able to extract the valid edges of a coverage. This is what CoverageEdgeExtractor is for. The idea is to expose this functionality in the ports of JTS (e.g. in GEOS by adding a GEOSCoverageEdges funtion to the CAPI).

[dr-jts]

Yes, this functionality had occurred to me as well.

What is your use case for this?

Seems like it would also be nice to provide a reference back to the parent neighbour geometries for each edge (in some way - perhaps in the userData field). Would this be useful?

[nstrahl]

Yes, I had the exact same idea. Though I was shy to implement it since I was unsure whether it would be deemed necessary, or possible.

The extraction of ring edges is extremely useful because the caller can then manipulate these as desired and and then rebuild the coverage polygons from these.

I can add the change to the CoverageEdgeExtractor in this PR. Perhaps the user data can be the index of the parent polygon(s). From a GIS perspective, it would be useful to be able to add the feature ids of the parent polygons. Is there any way to retrieve the parent polygon indexes for any given CoverageEdge from the CoverageRingEdges class?

[dr-jts]

Perhaps the user data can be the index of the parent polygon(s). From a GIS perspective, it would be useful to be able to add the feature ids of the parent polygons.

Yes, that makes sense.

Is there any way to retrieve the parent polygon indexes for any given CoverageEdge from the CoverageRingEdges class?

Almost! Each CoverageEdge has the indexes of its neighbouring coverage geometries [here] (https://github.com/locationtech/jts/blob/master/modules/core/src/main/java/org/locationtech/jts/coverage/CoverageEdge.java#L131-L132). However, they currently aren't ordered to indicate which is left and which right. That will need to be done when the edge is created, here. The CoverageEdge.addIndex method needs to take a flag indicating which side of the edge the polygon ring lies. This can be determined by comparing the orientation of the point sequence in the CoverageEdge to the ring section which is matched to it.

[nstrahl]

The user data is now set. I ended up implementing the orientation logic inside the CoverageEdgeExtractor class to ensure zero-cost abstraction in the other coverage classes. (Only pay what you use for). I tried using the Orientation function for the checks but because the testHolesAndFillWithDifferentEndpoints test case failed using this approach (The coverage polygon was surrounding the edge) I ended up using a contains predicate with a (hopefully) sufficient precision model. Let me know if you think of a better/more elegant solution.