Trimble Business Center

I just made a rather disappointing and disturbing discovery in one of our very large site projects. It seems that, for what appears to be random linestrings in the project, the VPI nodes have been eliminated while the Horiz nodes remain elevated. The only command that I am aware of that could do such a thing at a wholesale level would be changing the elevation of the linestring to undefined, however, that also sets the horiz nodes to ? as well, which is not the case. There are hundreds of VPI nodes that have been eliminated on multiple linestrings. I certainly did not eliminate them and I do not believe anyone else purposefully or nefariously did so either. Are there any commands or actions that a user can unknowingly take, short of purposefully doing so, that would eliminate only and all of the VPI nodes of a linestring while leaving the Horiz node elevations unaffected?  

This is going to cost us days of man-hours to resolve and I need to understand what is going on to prevent it from happening again.

Any help will be greatly appreciated.

Example:

Project File (vce): Transfer - Dropbox 

"Project cleanup" is the culprit.

Project clean up removed not only 4 Horizontal. vertices but also all Vertical vertices.

Normally only run vertice removal on contours but that's not to say it wasn't inadvertently run on the grading lines. We'll certainly try to be aware of (not) doing that moving forward if offing PVI's is a possibility. Is that the intended functionality of the command? We do use it on basically every job.    

More like "Project Destroy" in this case. It completely zapped my curb machine model and that's a crap load of work to get back.  That can't be the intended functionality. Even at .001 it got everything?

Have you ever tried to generate Surface Boundary on 3D surface provided from a 3rd party software?

All triangulation goes high-wire. Even adding surface members re-triangulates the surface as TBC is not treating provided triangles as breaklines.

Another thing to remember when working with TBC.

It's probably the same issue as with the zero length lines, they only test in 2D.

The help file says the following, it doesn't say anything about elevation check.

"Check this to delete redundant points between two line segments where the point does not deviate from the previous segment's tangent by more than the specified tolerance."

And just to mention it the "remove zero length fragment lines" is only looking for the 2D distance of the line.

Long vertical lines will disappear if their 2D distance falls within the selected length tolerance.

I've asked ages ago that the text is more clearly on that and an option for 3D length is added.

TBC does not know that a line is vertical really - Line Length on Vertical Lines is 0 as far as it is concerned today at least and has been that way since the product was released many years ago. While it is a 3D Modeling package, it still thinks in 2D which in many respects is a good thing. It allows you to add Elevation and interpret elevation in a smart way along 3D linework unlike AutoCAD and Microstation that cannot handle any geometry in 3D and do not have true Alignments (Spirals, Vertical Curves, Asymmetrical Vertical Curves). 

The Power Cleanup Tools maybe the issue here - I will have the Trimble Dev team take a look at this post and see if they feel we should not do something we are currently doing. The Power Tools do great things but also can do some things that you don't like. 

I made a post a while back on Selection Methods and which ones work on what is visible, and which ones work at a database level and will affect hidden linework at the same time as visible linework.

When you select e.g. by Window or Polygon, those are examples of selecting data graphically. These methods only select visible data. However selection methods like Find all Polylines or all Linestrings or Select by Elevation Range etc. are Database level searches and can select data that is visible or invisible. It is possible that you used a Global Selection Method like Select All or Select by Type and inadvertently selected the elevated linework and blew it up using Project Cleanup - so be very careful on which selection methods you use to pick data and save model revisions regularly so that you can backtrack if needed.

Sorry that you had this issue, let me know if you find any other culprit here.

Alan 

Alan - thank you for your response.

I am convinced that the Project Cleanup function was inadvertently run on the "Entire Project" with the "Filter Vertices" checked. Most likely while cleaning up newly imported layers and trying to eliminate unused block definitions. I understand how and why this happened so we will be implementing workflows to try to help eliminate the chances in the future. However, this doesn't mean that the function shouldn't be looked at and fixed. 

Taking @Marian Plucinski's example at face value, the function absolutely eliminates VPI's unexpectedly. I would have expected that no more then 3 of the VPI's  in the example should have been removed from the line with VPI's when the function is run. As a user, there is no way that we should be expected to anticipate that removal of all of the VPI's is the intended functionality, which I find hard to believe that it is. If it is, then it needs to be changed. Also as the user, the circle radius is interpreted as any deviations, whether horizontal or vertical, is controlling the vertice filtering. If it isn't, then it needs to be. In fact, why is it eliminating VPI's in the first place? 

Trimble needs to do whatever it needs to so as to make all users keenly aware of the potentially disastrous outcome of settings/functions such as running "Filter Vertices" on the entire project. (like the entire dialog box turns red or a warning pops up when these selections are made LOL) While I suspect that one of our new users unknowingly made the mistake, the ease of making this mistake, even for seasoned users, is such that the issue deserves immediate attention and resolution. 

I guess we just learned a costly lesson the hard way. The very hard way!

Thanks again for your help,

Rich

I also want to add that the issue appears random. A good portion of the line work remain unaffected as you will see if you open the project.

Richard,  I learned this lesson a long time ago using the same method you did.  I tell my guys to not use the filter function in data prep clean up without adult supervision.  Tough lesson to learn but I bet you will not do it again.

Personally, I'm very careful when using the Project Cleanup as I've learned (the hard way of course) that it's quick to fubar a lot of things if your not paying attention. 99.99% of the time, the filter box as well as duplicate lines, zero length lines, join lines, and line loops are all unchecked and are only ran on specific objects if needed. I'll just need to do a better job of expressing this to subordinates. 

In my opinion, deleting the VPI's the way it does as shown in Marians example is either a bug or very poor designing. How could it ever be desirable, mistake or not, to randomly delete VPI's especially when the change in elevations is outside of the designated filter parameter?

I try to only use Project Cleanup at the beginning of building data, never later in the process, unless something comes up that I did not notice before.  If that happens, I make sure to only cleanup the current selection, not the entire project.  So far, that has been a good practice for me.

I talked to development and they have already made a change to Project Cleanup in the next release to mitigate this issue .

The fix that has been implemented is as follows

"We changed the project cleanup command to ignore linestrings when vertical overrides have been applied"

Let me know whether you feel this doesn't fix the problem 

Alan

Hi Alan,

I am afraid that it does not solve the problem. Proposed changes will not "destroy" the strings but it will also not filter all of the strings.

Terramodel has a handy function named BLFILTER, I believe it could be used as a basis for the fix.

Filter excess points from breaklines.
Replace straight set segments with fewer segments using a filter "tube" on the selected layer within any boundaries.

The initial filter tube is of the specified width, length and height and is orientated to the first segment on the set. The width is perpendicular to the segment and height is vertical.

BLFILTER checks for additional points within the limits of the filter tube. Any points inside the tube are discarded. The first point BLFILTER finds outside of the tube is kept, and the last discarded point inside the tube is added back to the set. The tube is then reoriented to the last two points, and the process is repeated.

This is what the Filter Line Vertices function does in Project Cleanup. Are you saying that this did not / does not work in 3D? I need to check that as I was under the impression that it worked in 3D as well as 2D - most use cases are 2D on Contours, but it should also work in 3D as well the same way in my view.

Alan

On Sat, Mar 21, 2020 at 11:29 PM marian.plucinski@seymourwhyte.com.au <

It is what the Project Cleanup does. But as discussed earlier, the Project Cleanup does it only on the vertices defined in the Horizontal Tab of the Linestring Definition. As long as Linestring has only "horizontal" definition it's all good.

What if some one applied "vertical" definition to the linestring that could use removal of the horizontal vertices?

Since vertical definition for the linestring is "chainage" based, just like the definition of the vertical alignment, I can't really see how we could filter the horizontal vertices without affecting vertical definition.

I'd propose changes as follows:

Removal of all "excess" vertices:

1) Program should "temporarily" convert all vertical vertices to horizontal vertices (so from "CH and ELEV" to "XYZ").

2) Any vertice "n" should be removed only if it is co-linear (in 3D) with vertices "n-1" and "n+1" (I can already see a problem with 3 vertices located on the same spot )

3) After that we could "safely" revert to the independent Horizontal and Vertical definitions.

Filtering of "superfluous" vertices:

1) Program should "permanently" convert all vertical vertices to horizontal vertices (so from "CH and ELEV" to "XYZ").

2) Line vertices should be filtered based on the defined "filtering radius".

Obviously in that scenario it is impossible to revert back into two independent definitions of the Linstring.

I have also notices some dramas with Editing Linestrings with applied Vertical Definitions.

Option "Insert Before Current Segment" while using "Edit Linestring" works fine when working on the segments non-including vertical overwrites.

Macro "Insert Line Segments" creates Frankenstein linestrings when applied to a line with Vertical Definitions, regardless of the location of the inserted vertice.

You cannot just do that because some VPI can be vertical arcs or vertical curves - it is tricky

Will discuss with Dev tomorrow

Alan

Sent from my iPhone

What is a Frankenstein Linestring ?

Alan

Sent from my iPhone

Option "Insert Before Current Segment" while using "Edit Linestring" works fine when working on the segments non-including vertical overwrites.

Macro "Insert Line Segments" creates Frankenstein linestrings when applied to a line with Vertical Definitions, regardless of the location of the inserted vertice.