Hi, Michael. Glad to hear you're making improvements to OpenJUMP! Sorry to say that I don't have much good news for you, though.
1/ i admit that preserving high-dimension ordinates hasn't had much attention, especially in code such as the overlay algorithm which predates the use of CoordinateSequences. Even Z isn't well-looked after. The only things I can think of there are: a) Go through the code in detail and figure out how to preserve high-dimension values b) (more reasonable) keep a map of input coordinates, and post-process to copy the high-dimension ordinates to the output 2/ In this case the removal of duplicate points was deliberate. It's not very appealing to try and fix the algorithms to handle duplicate points. Possibly a similar approach to 1(b) above could be used to add them back in post-processing. 3/ As you've no doubt observed, there's a lot of cases that need to be handled to provide a full "validification" solution! It looks like the code is handling a lot (or maybe all?) of them. After scanning the code there's a couple of things I noticed: a) Do you need to remove duplicate linework after noding (AKA dissolve) ? Correct polygonization will required this. This is done currently in the GeometryGraph class. b) You might want to experiment with the Polygonizer extractOnlyPolygonal option. This ensures that the Polygonizer output is a valid polygonal geometry, which is required to be used further in overlay operations. Of course it has to use a heuristic to decide which polygons to keep in the output, but I believe the implemented logic is reasonable (if you see anything otherwise feel free to comment). As for performance, the only thing I notice that might improve performance is to *not* use difference to remove validified holes, but to do this more directly (possibly merging this with the noding/polygonization phase?). But this would likely be more complex and harder to "tune" to handle odd cases. There's often a tradeoff between using higher-level operations to obtain simpler implementations, and gaining performance via implementing more targeted, lower-level code. Hope this helps! And maybe this code would be a nice addition to JTS, if you're willing to consider a contribution. On Mon, Dec 14, 2015 at 3:45 PM, Michaël Michaud < [email protected]> wrote: > Hi Martin, > > I have added a MakeValid plugin for OpenJUMP and met some difficulties : > 1/ I wanted to keep the original coordinate dimension (either 2, 3 or 4) > by using CoordinateSequence instead of Coordinate. > I could keep coordinate dimension for simple checks on coordinate values > or coordinate number (point and linestring checks), > but as soon as I use high level functions like union or polygonizer to > repair invalid polygons, forth dimension seems to be lost. > Is it expected ? > > 2/ Specification accepts features with duplicate coordinates as valid. > But high level functions (union, polygonizer), used to > repair invalid polygons, tend to de-duplicate linestrings. Any hint to > keep the geometry as close as possible to the original ? > > 3/ My plugin makes 3 kinds of operations > - remove coordinates with NaN x or y > - check number of points (0 or > 1 points for linestrings and 0 or > 3 > points for linear rings) > - union linear components for noding and polygonize to repair invalid > polygons > Any hint to make it closer to the spec or to improve performance ? > (source code of current function is here : > > http://sourceforge.net/p/jump-pilot/code/HEAD/tree/core/trunk/src/com/vividsolutions/jump/geom/MakeValidOp.java > ) > >
------------------------------------------------------------------------------
_______________________________________________ Jts-topo-suite-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
