-
Notifications
You must be signed in to change notification settings - Fork 442
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
Add new CoverageEdgeExtractor class to extract unique edges from a polygonal coverage #1084
base: master
Are you sure you want to change the base?
Conversation
…lygonal coverage Signed-off-by: N_Strahl <[email protected]>
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? |
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? |
Yes, that makes sense.
Almost! Each |
…ht polygon indexes Signed-off-by: N_Strahl <[email protected]>
Signed-off-by: N_Strahl <[email protected]>
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. |
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).