One note about the "bruteforce" method you present is that if the set of
lines is fully noded, you don't need to check *all* vertices, just the
endpoints of the LineString components.
But yes, in fact there is an alternative approach in JTS, which I think
counts as slicker. This way uses to ability of JTS to define different
BoundardNodeRules, and to use them in the BoundaryOp class. One
BoundaryNodeRule is called the MULTIVALENT_ENDPOINT_BOUNDARY_RULE. Under
this rule, only endpoints which have valence (occurrence count) > 1 are
considered to be on the boundary. So you can invoke the BoundaryOp using
this rule, and the computed boundary will contain only the endpoints which
occur more than once. If the set of lines is represented as a
MultiLineString, this can be done in one line of code:
Geometry intPoints = (new BoundaryOp(lines,
BoundaryNodeRule.MULTIVALENT_ENDPOINT_BOUNDARY_RULE)).getBoundary();
Another good question for the FAQ! Keep 'em coming...
On Mon, Nov 19, 2012 at 5:52 PM, Mark Coletti <mcoletti@...> wrote:
>
>
> I've a follow up question: Given a set of line strings that have been
> properly noded, what is the best approach to finding the points
> corresponding to their intersections? One brute force approach would be to
> pull out their coordinate strings and note the points that occur more than
> once. That works, but my intuition is that there may be a slick "JTS Way"
> that would give me those points in one go. If so, how would I use JTS to
> give me those intersection vertices?
>
>
>
