• Two coordinate-coincident Random points [21 & 22] with the same elevations.
• Point #22 - GONE

• Two Random points [19 & 20] that fall precisely on a Breakline vertex with the same elevation assigned to them.
• Points #19 & 20 - GONE

• Two Random points [17 & 28] that fall precisely on a Breakline vertex with different elevation assigned to them.
• Points #17 & 28 - GONE

• One Random point [23] that falls directly on a Breakline, not on a vertex, with the same elevation as the interpolated Breakline elevation at that location.

Of the 24 total points that existed in the survey Fieldbook, 17 are in the surface DTM, and 7 are gone from the surface.

Looking at the Surface Properties confirms this.

The Resolve Crossing Segments command reveals nothing about any problems because in this case, like a plot from a mob movie, the offending points have been permanently eliminated with the only trace left in the Surface Properties dialog box. And these fingerprints can be easily removed with the Compress Surface command.

Clean as a whistle; not a trace left.

And at no time in the whole process, from Survey, to the export, to the triangulation, to the display, to Resolve Crossing Segments, the Error Log, View Crossing Segments or anywhere else was there even the slightest hint that something was amiss.

The example that was shown here was using a survey Fieldbook as the source of the 3D data. There was nothing special about this process that makes this problem unique to the export of survey data. This issue would occur just the same had I placed that Random data directly into the DTM using one of the Surface Design tools, or the SurfaceImport tools or any other method of introducing 3D data into a surface model. 

(If I happen to mysteriously disappear someday, without a trace, you'll know why ; )

The reason that I used the Fieldbook was to maintain a 'database' of my 3D information. Had I not done that, each time I would have entered data into the surface, using the Place Feature command for instance, it would have disappeared as soon as I triangulated it and been lost forever (you can't recover deleted surface data). And then I would have had to reenter it to do further testing. 

Okay . . . Oh how badly I wish I were done.

As an aside, I can't stress enough that you need to be very attentive to the construction and results of your surface models. Just because you plug 3D data into a surface does not mean that all is necessarily well. Call me a fanatic, I don't care because I generally do not have odd things going on with my surfaces because I'm very conscious about what I'm doing each step of the way, constantly checking my work. And if I see anything unusual, I am all over it running it down until I'm completely satisfied that I understand what's going on.

Let's look at one last oddity before I attempt to walk away from this subject.

This is the resulting triangle display formed by this data.

In addition to the unannounced removal of Random point features there are other oddities that can occur when point data is coordinate-coincident with other data. And it's at this stage, regarding the cause and effect of all the possible variations in the software reactions that I begin to become a generalist and assume a posture of a skeptic. In other words, because of the amount of possible 'conflict combinations', fused with the various differences between software versions, and the untested nature of this subject, I tend to just be really alert to anything unusual.

We already know that InRoads deleted some Random points without our permission, but at least it left us some to build the surface model from, right? Now let's take a look at the connectivity of the data that remained in this surface by viewing the triangles, shading them, and rotating the view to look for any anomalies.

To illustrate this a little better, I'm going to take the Random point that is positioned along and on top of one of the Breaklines and change its elevation. Right now it was set to 311.50 to match the interpolated elevation along the Breakline at that exact location. So currently there isn't an elevational conflict between the Random point and the Breakline. But what would happen if there were an elevational conflict? It will be changed to 315 to illustrate something new.

Now, with the revised elevation, the first question is - When this is triangulated it will be introducing an elevational conflict into the surface model, so what will InRoads do with it? Will it delete it? Will it 'ignore' it?

Well, how about that? It didn't delete it. So now what?

Okay, this is a test - Do you see anything odd about the formation of these triangles?

The Triangulate Surface command forms 3-sided figures (triangles) that interconnect all of the data to each other forming relationships amongst and between the data. Each 'point' of data, whether it's a single stand-aloneRandom point or one of many vertices along a Breakline, should be connected to every point surrounding it.

Notice that there is something odd about the triangles in the area of that cyan point on that breakline (remember, that point is not actually 'on' the Breakline).

Let's look at it in a rotated view with and without the 3D Feature data.

Let's look at a couple rendered and shaded views to get a different look at this.

Switching the MicroStation rendering Display Style from Wireframe to Smooth Shadows or Illustration, or one of the others on the View Attributes, is commonly done to obtain a different view of the surface.

Rotating the model to get different views of that area of triangulation is more revealing.

What has happened here is the Random point that fell along and on top of the Breakline was retained even though it introduced a conflicting elevation into the surface model. The retention of that particular Random point has created a triangulated surface that defies the basic rules of DTM construction, and obviously needs to be corrected.

WINDING DOWN 

Here's what I've found out about how InRoads is handling duplicate points.

InRoads addresses duplicate Random features by physically removing one of the Random features from the DTM.  The removal appears to occur in order of placement with the first point that is encountered retained and all subsequent conflicting points deleted from the DTM. It's as if the DTM processing identifies a coordinate location and its associated elevation and stores it, then when another point is encountered with the exact Northing / Easting the elevation is compared to it. If the elevation of this later point is different than that newly encountered random feature, it is deleted from the DTM.

Earlier in this document, all of the discussion focusing on linear Breakline data and the methodology that InRoads addresses any linear conflicts can be summed up by saying:

"When InRoads encounters conflicting 3D data in a surface it will 'ignore' something, retaining only a single elevation so that it can complete the triangle formation."

Here is the not-so-subtle difference between how the InRoads triangulation routine addresses Breakline-Breakline conflicts and Random-Random or Random- Breakline conflicts. In the case of Breakline -Breakline conflicts, something is 'ignored' in order to 'resolve' the conflict. In the case of Random-based conflicts, something is 'deleted' in order to 'resolve' the conflict. Yes, 'deleted', as in "good-bye".

Here are some of my 'thought bullets' that I've found during my testing:

• If a Random point falls on a Breakline vertex and results in a conflicting elevation value that Randompoint is then physically removed from the DTM.
• If a Random point Feature falls on a Breakline vertex that Point Feature will be deleted from the DTM, even if the Random shot does not have a conflicting elevation with the Breakline.
• Depending on the version of the software I found that the deletion of data has changed.  In an earlier version of InRoads Survey, if a shot is double-coded during survey field collection, and that data is pushed to a surface model both points are retained. This is not true in the current version. In my testing with an earlier version of InRoads Survey it only deleted a feature when the point conflicts with a piece of linear data.
• When Random points are imported from graphics as a Feature group, any duplicates are weeded out at that time. One point will remain for each unique X / Y location. At this stage conflicts with Breaklines are not checked or considered. There is really no way to tell which specific points were brought in and which ones were deleted but it appears that the same logic described above is being applied. (First point taken and subsequent ones tossed out.) The only important thing to note here is that if there are multiple points at a single location the first point encountered establishes the elevation of that location.
• The rule appears to be that if a Random point is located on a Breakline vertex point then that Randompoint is deleted. If all Random points coincide with points along a Breakline then the entire Random point Feature is deleted.
• In processing (triangulating) Breakline points and Random points, any duplicate or elevationally deviantRandom points, (compared to the Breakline vertices), are deleted from the DTM.
• If the Do Not Triangulate option is turned on for that Random Feature then that data is retained.

RANDOM POINTS SUMMARY

InRoads addresses duplicate Random points by physically removing one of those points from the DTM. If aRandom point falls on a Breakline vertex and results in a conflicting elevation value that Random point is also physically removed from the DTM.

The removal appears to occur in order of placement with the first point that is encountered retained and all subsequent conflicting points deleted from the DTM. Elevation plays a very small role in the addressing of these duplicate Random points.  If a point falls on a Breakline that point will be deleted from the DTM even if the Random shot does not have a conflicting elevation with the breakline.

In an earlier version of the InRoads software if two Random points were directly on top of one another and had the same elevation then the last one checked was retained. It was as if the DTM processing identified a coordinate location and its elevation and stores it, then when another point was encountered with the exact N/E the elevation was compared to it. If the elevation of this later point was different, then that random feature was deleted from the DTM, but if the elevations were the same, it (the second point) was used and the earlier one was deleted from the DTM. In the current version of the software it seems to always retain the first point it encounters and deletes any subsequent points in the surface, regardless of the elevational relationship.

I think the biggest issue I have with this whole Random point removal is that it is not reported on during theTriangulate Surface processing, or anywhere else, so that the user is made aware of the lost data. And believe it or not, I logged this problem back in October 2001 while I was working at Bentley Systems, and it was filed as CR CV37734.

So the cat is out of the bag. What do you do now? Stay alert. The software is a tool, not a co-worker doing your job for you. Using software requires you to be smarter, not more complacent. Check, check, check your work and let others check it too.

CLOSURE

Okay is this subject exhausted? No, not in my mind, but I'm done for now. Although I still have these items on my hit list:

1) How does InRoads triangulation address the conflict created by 2 breaklines when one starts where another ends, and the elevations are different? I've always seen this as a Mismatched Elevation scenario. My initial testing done a while back showed that it is taking the lower elevation and ignoring the higher one, but it's not reporting on this nor is this conflict area being identified when using the View Crossing Segments command. 

2) How does the latest version of InRoads address partially overlapping breaklines? Earlier version of InRoads would not recognize partial overlapping breaklines. The overlapping had to be a complete duplicate in order for InRoads to acknowledge it in both commands and the reporting.

3) Is it true that the ResultsError Log report lists the problematic areas starting from the lower left to the upper right? (Increasing X & Y values.)

4) What's the deal with UntriangulatableData!!! And how should it be addressed? I know what I do to address this, but what is really going on here?

That is it!! . . . What a road this has been. I'm really done!!

Coming next . . . something new (and hopefully shorter for me and more digestible for you) - ZI Issue 87: Contour Smoothing