Thanks for your answer Martin,
I will review the code with your advices in mind and let you know.
And of course, if the code could make its way to JTS, I would be very
pleased to contribute,
Michaël
Le 15/12/2015 07:12, Martin Davis a écrit :
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] <mailto:[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
