Concave hull #427

FObermaier · 2019-05-07T06:43:00Z

I hijacked @dr-jts ConcaveHull stub in jts-lab and replaced it with an implementation inspired by
@mourner 's concaveman algorithm.

It is based on ideas from the paper A New Concave Hull Algorithm and Concaveness Measure for n-dimensional Datasets, 2012 by Jin-Seo Park and Se-Jong Oh.

* Add Distance.segmentToEnvelope function * Minor javadoc fixes to BoundablePair and GeometryItemDistance * Complete unit tests and test data Signed-off-by: Felix Obermaier <[email protected]>

Signed-off-by: Felix Obermaier <[email protected]>

* Use SquaredDistance in ConcaveHull computation Signed-off-by: Felix Obermaier <[email protected]>

Signed-off-by: Felix Obermaier <[email protected]>

dr-jts

Further to my comment about needing a more precise name for this algorithm, note that for this algorithm larger tolerance values produce shapes closer to the convex hull (less concave).

In most other algorithms I've seen (such as Duckhams - implementation here) larger tolerance produce a more concave hull.

This is an important distinction. For one thing, it means that this algorithm has a different signature, so cannot be "plug-compatible" with other algorithms. It also requires a different understanding of how to choose appropriate tolerance values.

This relates to something I find problematic about current concave hull algorithms, which is that it's hard to predict a priori what a "good" tolerance distance is. Actually this algorithm might work better in this respect, since the tolerance is a ratio rather than an absolute distance.

modules/lab/src/main/java/org/locationtech/jts/algorithm/SquaredDistance.java

dr-jts · 2019-05-08T03:24:58Z

modules/lab/src/main/java/org/locationtech/jts/hull/ConcaveHull.java

+ * @since 1.17
+ * @author Felix Obermaier
+ */
+@SuppressWarnings({"ForLoopReplaceableByForEach", "ManualArrayToCollectionCopy"})
 public class ConcaveHull {


There are a few Concave Hull algorithms around. It would be good to distinguish them by name, to leave namespace room for other implementations. Is there a more specific name for this algorithm?

Alternatives:

ConcaveHullDigger (sounds like an arcade game)

ParkOhConcaveHull (giving credit to the inventors)

Anyone?

I'd prefer a name based on the algorithm concept (unless this becomes known by the names of the inventors). I agree Digger is an awkward term, but that's the one they use. Perhaps DiggingConcaveHull ?

Perhaps NearestPointConcaveHull ?

Using to excavate as a synonyme of to dig gives a less awkward so how about ConcaveHullExcavator?

dr-jts · 2019-05-08T03:27:03Z

modules/core/src/main/java/org/locationtech/jts/algorithm/Distance.java

+   * @param bounds the bounds
+   * @return the distance between AB and the envelope.
+   */
+  public static double segmentToEnvelope(Coordinate A, Coordinate B, Envelope bounds) {


This could be placed in the Envelope class, since it requires an envelope to be present anyway.

Actually this seems to be a left-over from the first attempts using real distances.
But yes, I can move it to Envelope class

If not used then just delete it.

dr-jts · 2019-05-08T17:01:17Z

Can this algorithm produce invalid topology for extreme tolerance values?

This is possibly one advantage of the triangulation-based approaches, which can be easily limited to ensure that only valid topology is produced. And it's also easy to enforce fully connected output.

FObermaier · 2019-05-09T08:07:24Z

In most other algorithms I've seen (such as Duckhams - implementation here) larger tolerance produce a more concave hull.

I have no idea how to change that for the lengthThreshold parameter. It prevents looking for further candidates when a segment's length goes below that value. The concavity value could be handled as a reciprocal value thus having greater concaveness for larger values.

Can this algorithm produce invalid topology for extreme tolerance values?

According to the short paper:

Our proposed algorithm satisfies Galton’s evaluation criteria, with the exception of
question (5). The question has no relationship to the robustness of the proposed algorithm.

Question 5 asks if the concave hull should be polygonal, or its boundary can be curved.

As the starting solution is a convex hull, I see no way of producing a not fully connected result, regardless of the input parameters.

FObermaier · 2019-05-09T08:11:35Z

An idea to improve the expected output for non-puntal input is to mark segments of the starting solution (convex-hull) that are part of the input geometry as immutable. The other concave hull implementation you mentioned proposes to densify the input geometry in such cases.

dr-jts · 2019-05-09T18:50:14Z

In most other algorithms I've seen (such as Duckhams - implementation here) larger tolerance produce a more concave hull.

I have no idea how to change that for the lengthThreshold parameter. It prevents looking for further candidates when a segment's length goes below that value.

Yes, this seems more like a quality control rather than a core parameter to the algorithm. Was this in the original paper?

The concavity value could be handled as a reciprocal value thus having greater concaveness for larger values.

Yes, I thought of that too. Best to leave it as per original paper, though.

dr-jts · 2019-05-09T18:53:30Z

As the starting solution is a convex hull, I see no way of producing a not fully connected result, regardless of the input parameters.

Another possible issue is whether the algorithm can produce edges which cross one another. My evaluation is that this is not possible, due to the closest edge-point pair always being chosen for processing. Would have been nice if they'd proved this (it's not part of the Galton criteria, but probably should be).

dr-jts · 2019-05-09T18:58:02Z

This is possibly one advantage of the triangulation-based approaches, which can be easily limited to ensure that only valid topology is produced. And it's also easy to enforce fully connected output.

Triangulation-based approaches can also produce holes - which may or may not be desirable (but obviously can be removed if not).

dr-jts · 2019-05-09T19:08:09Z

This relates to something I find problematic about current concave hull algorithms, which is that it's hard to predict a priori what a "good" tolerance distance is. Actually this algorithm might work better in this respect, since the tolerance is a ratio rather than an absolute distance.

Another comment on the intuitiveness of the concavity parameter is that (if I understand it) it's based on purely local information (a ratio of the edges of the triangle being considered for removal).

It's interesting that they propose a Concaveness Measure equation which is based on global values (perimeter length). But there doesn't seem to be any way to decide a priori on a concavity value that will produce a target concaveness measure value.

FObermaier · 2019-05-14T12:19:37Z

Another possible issue is whether the algorithm can produce edges which cross one another.

That is taken care of:
https://github.com/FObermaier/jts/blob/3a8e9f4459c2deb76b3db6f32f98a691e3dd6b7b/modules/lab/src/main/java/org/locationtech/jts/hull/ConcaveHull.java#L341-L344

FObermaier · 2019-05-14T12:21:28Z

Triangulation-based approaches can also produce holes - which may or may not be desirable (but obviously can be removed if not).

In my understanding hulls don't have holes.

FObermaier · 2019-05-14T12:55:10Z

I think the concavity parameter does not directly relate to the Concaveness Measure.

The concavity value has its representation in the smoothness parameter N introduced in 2.1.
If I understand the paper correctly, the smoothness parameter N is understood as application specific which could be addressed by adding a static property DefaultConcavity. For the concaveman algorithm that value was chosen to be 2.

* Remove Distance.segmentToEnvelope function (not-used) * Add static defaultConcavity to ConcaveHullExcavator and setter function * Rename SquaredDistance to DistanceSquared * Rename ConcaveHullTest to ConcaveHullExcavatorTest Signed-off-by: Felix Obermaier <[email protected]>

FObermaier · 2021-03-18T08:55:51Z

I'm wondering if there is an interest in this convex hull implemenation?

Imported and adapted code from /locationtech/jts/pull/427 Signed-off-by: Felix Obermaier <[email protected]>

FObermaier · 2021-07-06T06:20:31Z

The code can be found here: https://github.com/FObermaier/jts-ex

dr-jts · 2021-12-20T18:56:12Z

I haven't forgotten about this, but need to do #823 as a drop-in replacement for the PostGIS one.

It would be interesting to compare the results and performance of the two algorithms.

FObermaier added 4 commits April 10, 2019 13:58

Finish implementation of ConcaveHull

043ce40

* Add Distance.segmentToEnvelope function * Minor javadoc fixes to BoundablePair and GeometryItemDistance * Complete unit tests and test data Signed-off-by: Felix Obermaier <[email protected]>

Update javadoc, fix license

97dd999

Signed-off-by: Felix Obermaier <[email protected]>

Add SquaredDistance utility class

7153108

* Use SquaredDistance in ConcaveHull computation Signed-off-by: Felix Obermaier <[email protected]>

Improve code documentation

3a8e9f4

Signed-off-by: Felix Obermaier <[email protected]>

dr-jts reviewed May 8, 2019

View reviewed changes

This was referenced Sep 25, 2019

Implementation of ConcaveHull using simple Chi-Hull algorithm. NetTopologySuite/NetTopologySuite#339

Merged

Perf: extend Coordinate with distanceSq and distance3DSq #175

Open

FObermaier added a commit to FObermaier/jts-ex that referenced this pull request Mar 19, 2021

Initial commit

b0f0d49

Imported and adapted code from /locationtech/jts/pull/427 Signed-off-by: Felix Obermaier <[email protected]>

FObermaier added a commit to FObermaier/jts-ex that referenced this pull request Mar 19, 2021

Initial commit

1de5bc8

Imported and adapted code from /locationtech/jts/pull/427 Signed-off-by: Felix Obermaier <[email protected]>

FObermaier added a commit to FObermaier/jts-ex that referenced this pull request Mar 19, 2021

Initial commit

db9b5a9

Imported and adapted code from /locationtech/jts/pull/427 Signed-off-by: Felix Obermaier <[email protected]>

FObermaier closed this Jul 6, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Concave hull #427

Concave hull #427

FObermaier commented May 7, 2019

dr-jts left a comment

dr-jts May 8, 2019

FObermaier May 9, 2019

dr-jts May 9, 2019

dr-jts May 9, 2019

FObermaier Jul 12, 2019

dr-jts May 8, 2019

FObermaier May 9, 2019

dr-jts May 9, 2019

dr-jts commented May 8, 2019

FObermaier commented May 9, 2019 •

edited

Loading

FObermaier commented May 9, 2019 •

edited

Loading

dr-jts commented May 9, 2019

dr-jts commented May 9, 2019 •

edited

Loading

dr-jts commented May 9, 2019

dr-jts commented May 9, 2019

FObermaier commented May 14, 2019

FObermaier commented May 14, 2019

FObermaier commented May 14, 2019

FObermaier commented Mar 18, 2021

FObermaier commented Jul 6, 2021

dr-jts commented Dec 20, 2021

Concave hull #427

Concave hull #427

Conversation

FObermaier commented May 7, 2019

dr-jts left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dr-jts commented May 8, 2019

FObermaier commented May 9, 2019 • edited Loading

FObermaier commented May 9, 2019 • edited Loading

dr-jts commented May 9, 2019

dr-jts commented May 9, 2019 • edited Loading

dr-jts commented May 9, 2019

dr-jts commented May 9, 2019

FObermaier commented May 14, 2019

FObermaier commented May 14, 2019

FObermaier commented May 14, 2019

FObermaier commented Mar 18, 2021

FObermaier commented Jul 6, 2021

dr-jts commented Dec 20, 2021

FObermaier commented May 9, 2019 •

edited

Loading

FObermaier commented May 9, 2019 •

edited

Loading

dr-jts commented May 9, 2019 •

edited

Loading