Trimble Business Center

Is there a method or setting that prevents the elevation snap on a line or object and has the program pause for a user input elevation? Otherwise it's a 5 step process to revise the elevations which, when you have many hundreds to do, is very very time consuming. Thanks.

I think this is a bug. I don't remember this happening prior to 5.2

There is currently not a way to snap to a 3d point and not get the elevation with this command.  The most common use of a linestring is to connect 3d points, so the command has been optimized to minimize the number of clicks to do so.

The command does allow you to edit the elevation using the following steps.

In the coordinate control click on a 3d point. The command will advance to allow you to enter the next point.

Click on the < to the left of "Adding New Segment", this puts you in editing mode for the previous point.

Click on the elevation and make your change.  Enter "?" to make the point 2d.  This control allows you to use simple math to change the current elevation.  For example, enter +5 after the current elevation to add 5.

Click save

Click the middle icon with the green down arrow to return to adding to the current linestring after the last node

If you want a simpler way to create a linestring that does allow you to enter XY and then Z, run the _Quick Line TML macro.

For more details on using linestrings refer to the following document.

Understanding and Using Linestrings.pdf 

I could be misspeaking but I don't think Richard is trying to override data from a 3d point and make it undefined, although the quick line tip is good to know. I think the issue is the the create linestring command since 5.2 is applying a zero elevation when snapping to an entity with an undefined elevation. Previously it used to leave this as undefined.

I have seen the same thing and it is very frustrating.

Exactly Pat thanks! I gotta get me a video app.  

Thank Tim but,

Every line you see in that clip has an undefined elevation (?) so they are in fact not 3d lines for this very reason. Yet the program is still grabbing a zero elevation, accepting it as good, and moving on.  The program should stop on a zero or undefined elev snap and wait for user input. (The first clip is the initial snap. The second clip is the corrected, desired output.)
Also know, when actually snapping to 3d items, the elevation snapping in TBC is inconsistent in picking up the correct elevation, or any elevation at all, at times. Occasionally, the snap even picks up an elevations that has no rhyme or reason to the location snapped and seems random, however close to correct (which makes it more dangerous) but still wrong. I find myself having to scrutinize each and every elevation that the 3d snapping picks up due to the inconsistent and erroneous elevations that are offered by the vertical snapping. I simply don't trust the program to get it right without fail. I am aware of the snapping priorities and have tried all sorts of combinations without improved results. I've also changed the sizing of the pick box aperture to no avail.  In summary, the vertical snapping is sloppy, inconsistent and untrustworthy more so then not and should be looked at for further "optimization".

Thank you for suggesting the Quick Line TML. It looks like it will probably do the trick for the particular task at hand. However, it would be a big help if the focus was on the Name field when the tml is invoked, and the "Apply", "New", "Close" and "Close All" controls were to be added to the right click context menu.  

Got it.  There was a change made for cutting planes that caused elevation zero to be used. I am putting in a bug to fix this.

I have also asked our graphics team to look again at the 3d snapping.  Its a bit tricky when you have vertical exaggeration to consider, the "center of the aperture", and multiple XYZ objects to check.  You have to consider the apparent distance as well as the real world distance.  This is compounded by the graphics using less precise numbers than the objects.

It does seem to work better without the vertical exaggeration, but I will see if we can improve it overall.

tim

Thanks again Tim

Thank Tim!

I noticed this too that i was getting a lot of 0 elevations in my linestrings when snapping to undefined and thought i was doing something wrong.

Again thank you!

Tim - this elevation snapping issue is becoming a real detriment to production. Please ask development to expedite a solution and issuance of a patch. Thanks. 

TBC v5.20.2 appears to have fixed the issue. Thank you!!!