Vertex insertion threshold

[micycle1]

Is it possible to set a threshold such that a vertex is ignored from being inserted into a Tin if it is within X distance of the nearest vertex?

I can't spot any methods related to this on IncrementalTin, but it does looks like something offered by org.tinfour.common.Thresholds.

[gwlucastrig]

Tinfour provides about half of what you want.

Recall that Tinfour does not use perfect arithmetic. So for many of the calculations, it needs to define tolerance and threshold values for deciding how to construct a tin using imprecise floating-point calculations. If two vertices were unique, but too close together, it would lead to problematic geometries (geometries that were correct in a mathematical sense, but troublesome in a computational sense). So there is a feature called a VertexMergerGroup that is used for lumping closely spaced vertex specifications into a single vertex.

So, the question arises on how we define "too close". The constructors for IIncrementalTin instances can accept an estimatedPointSpacing argument. This argument is intended to tell Tinfour what is the "meaningful precision" of the data. For a Lidar survey, a 1 meter sample spacing is meaningful. For vertices based on weather-observing stations with their horizontal coordinates given in meters using a projected coordinate system, 100 or 1000 meters is probably meaningful. For mold spores on a petri dish, maybe one millionth of a meter is meaningful. Based on this setting, the Threshold constructor computes several thresholds. The default vertex spacing threshold is one ten thousandth of the estimated sample spacing.

Now for the stuff that you might need, but which isn't available at this time. Ideally, the Threshold class would have a mechanism for allowing you to control your own vertex spacing factor. And, ideally, you would be able to construct your own Thresholds instance and pass it into the IncrementalTin constructor. Neither of the features exist.

If you would like, you can post some more specifics on what you need as part of this issue and I can see about enhancing IncrementalTin, SemiVirtualIncrementalTin, and Thresholds accordingly.

Gary

P.S. You might want to take a look at the VertexMergerGroup class to see how it behaves. The design choices it represents may or may not be a good fit for your application.

[micycle1]

ideally, you would be able to construct your own Thresholds instance and pass it into the IncrementalTin constructor

👍

For my use case i'm not even concerned about averaging Z values or merging vertices. Just a simple mechanism to reject vertex insertion if the distance to the nearest Tin vertex is less than some given value.

[gwlucastrig]

Here's one approach that you could take. It has the advantage of not requiring changes to the existing code. It uses the "navigator" class to allow you to lookup the nearest vertex to your insertion point, and then decide if it is too close. There is one consideration that is a little tricky. When I designed Tinfour, I was focused on my really big data sets and sometimes too concerned about performance. The navigator class maintains state data to expedite searches. But when you add a new vertex to the TIN, that state data becomes invalid. However, again for performance reasons, the navigator doesn't know that the TIN changed. So you have to call resetForChangeToTin() to let it know. I need to come up with a more "developer safe" way of handling this. But in the meantime, that's the way it works.

List<Vertex>vertexList = new ArrayList<>(); // populated somehow
IIncrementalTin tin = new IncrementalTin(1.0);
tin.add(vertexList, null);

double x = 0.5;
double y = 0.5;
double z = 0.5;
double proximityThreshold = 1.0e+6;
int index = vertexList.size();

tin.getNavigator();
IIncrementalTinNavigator navigator = tin.getNavigator();
Vertex v = navigator.getNearestVertex(x, y);
if (v.getDistance(x, y) > proximityThreshold) {
  tin.add(new Vertex(x, y, z, index++));
  navigator.resetForChangeToTin();
}

A lot of the Tinfour features have the same pattern of access, including all the Interpolators.

[gwlucastrig]

One thought I've had with this is to add an AtomicInteger to IncrementalTin to keep count of changes. The Navigator could first check to see if there had been a change and would act accordingly. Though the big question is whether "acting accordingly" means resetting its state data or throwing a ConcurrentModificationException. These later, rather harsh, approach might be necessary in view of the possibility of a multi-threaded application. If one thread was changing the TIN and the other was accessing it via the Navigator, there would just be no cure.

My general pattern is that multi-threaded applications can ALWAYS access the TIN if the application code does so on a read-only basis and no other threads are currently modifying the TIN. But Tinfour definitely is not a robustly thread-safe API.