Trimble Business Center

I've got a file with a corridor model. There must be some kind of error in the corridor instructions which prevents TBC to load the model now. It throws an exception error on loading it, and that's it. Prior to saving the file the last time I inserted a new template into the corridor using "copy existing template".

Is there a way to rescue any data in such a case, load at least the data that seems ok and than export/copy it to a new file?

I always increment the file name by day, not every time I save. I now have our IT guys trying to restore a previous version on the server.

Ronny,

If you want to send me the file, I will troubleshoot it.

David

Hello David,

in the meanwhile I redid my work, but if you want to have a look for bug fixing TBC the file is attached.

I had a few encounters with TBC throwing exception errors in the last few days, but luckily no corrupted files.

TBC seems to have issues with adding reference lines in a later stage to the corridor. After that and after referencing or copying templates, TBC seems to randomly mix up, use wrong node numbers.

In this example the instruction is Offset 0 and vertical down, but the node is offset both ways. It seems like a slope/slope instruction in this case.

Have to find out what's going on there. This is really annoying and time consuming.

The issue with the above was that it somehow didn't accept the zero in the offset. The workaround was for the time being to use a node to node which gives me zero.

But I just came across another quite dangerous quirk. Just connecting two nodes in one of the templates shifts one of them. What the heck?

I see that you create points 35 and 36 using offset Elevation instructions, and that you then add a Connect to join 35 and 36 and I see 36 moves - I dont see 35 in your image though - I will try to create something similar but not sure if a simple test will recreate what your template is doing here.

It does look like a bug based on the images but without the model it is hard to be 100% sure. Let me see if I can recreate something here.

Alan

Hi Alan,

both points 35 and 36 where created by offset 0 and dh -0.15 m. Point 35 stays correct, Point 36 for some reason moves with changing chainage.

Don't ask me why but it all was somehow connected to another template. After deleting that one the point didn't move anymore. I also deleted all my referenced templates and put in copies instead. Now I don't get error messages anymore while sliding forth and back in my corridor.

Somehow TBC didn't like the referenced templates and adding more reference lines at a later stage.

I've attached my old model from yesterday.

Edit the following Template, go to chainage 1+258 

 if you delete that template the line won't jump anymore

That will be a Template Transition kicking in - I have written about this a few times recently

When you have two or more templates in a corridor model, unless you take specific actions (one of the following) the nodes of one template will try to transition to nodes of the next template based on a set of Template Transition rules that I avoid 100% through use of one of the techniques below. The Template Transitions will be applied to all nodes of a Template unless one of the following is done

1) Put a Null Template before the insertion of each new template - leave a gap of e.g. 0.005m between templates. This causes the prior template to stop and the new one to start 5mm later, and stops all transitions from occurring - allowing you to transition nodes / instructions as you want rather than as the program wants to do (Use 2D lines, Reference lines and Tables including Tables with Offsets, Tables with elevations or tables containing offsets and 2D lines combined to manage your transitions.

2) For each instruction use a Table rather than a single entry in the main instruction - i.e. if you want a 3.5m offset at -2% use a table for the offset or a table for the slope and enter a single value in the first line of the table. Tables stop a node from transitioning because of a template transition - the table for the node always wins.

When I build a corridor I try to build it with a single template - if I have to use a second or third template I will typically drop a null template and start the new template clean so that no transitions can occur. If you only have one template then no transitions can occur. Failing that I will use Tables for all instructions to take ownership of all instructions and not allow any Template Transitions. This works well for me.

Template transitions use the node sequence from the centerline and the setting on each instruction "Type of code above" to determine which nodes can be grouped together - i.e. all "Lane Edges"and all "Shoulders" and all "Undefined" are grouped and then they are connected by sequence from the centerline - sometimes this can work well, other times not so well in my view which is why I don't let them happen. Transitions will be why your point moved.

How Do Template Transitions Work

I see a number of questions relating to corridors “not doing what they should” and many of those issues tie back to the way that Templates transition between each other. I am not a huge fan of using multiple templates to build corridors, I try to build my corridors with a single template and use Tables and lines to transition widths and slopes etc. I also try to create a master list of nodes that need to be built to cover all of the needs of the corridor, and then try to build one instruction for each node in the “overall cross section”. This way it is easier to track what is happening.

Having said that, it is clear that many users, especially those that used Terramodel in previous lives, want to still do Templates the same way as they used to. In that case then you really need to understand how they transition.

The main challenge with Templates is that each template inevitably defines a different type of section based on “typicals” provided in the plans. One way you can stop transitions from happening is to create a reference template at the end of the station range for the “typical” that references to the template that is placed at the start of the station range. This way the template cannot transition. Then the next template that has a new section definition is placed 1mm or 0.01 feet up from the reference template so that any transitions happen over the 1mm distance and will not be noticeable, however be aware that some things may step in offset or slope or elevation because they cannot transition over a distance.

Next option in templates if you want to stop them transitioning, is to use Tables for all instructions. Tables take control 100% of the element over the entire station range of the template. so you can create an Offset Table or a Slope Table etc. and only need to enter 1 row in the table - the start station and the start offset or slope and the elements will not transition as a result. If you then want to transition the widths or slopes, you can enter the station at which you want the transitions to start or end and the value at that location for the offset, slope or elevation and you have 100% control over what the element is doing.

Next option in templates is to use the 2D line or a table with 2D lines in them to control the offsets or use a shareable slope table to control the slope. When you do this, those act the same way as tables and take ownership 100% for how the element is computed.

But if you don’t do any of the above then you are down to how templates transition for offsets and slopes. In this case, the template transitions are there to try and work out what you intended to happen between template 1 and template 2. Bear in mind Template 1 and 2 may have completely different elements, element widths, elements slopes and node elevations. The software has to try to work out how to link Template 1 to Template 2 and that is always going to be a guess, unless you help it in some way. The following notes hopefully give you a guide to help you figure it out

• Currently template transitions do not use the names of nodes in one template and link those to the same nodes in the next template. I have put in a request that node names should be observed as the first thing that guides a template transition.
• In the corridor instructions, depending on the type of instruction and the configuration of the instruction, there is a setting named "Type of code above" and the options are Undefined, Lane Edge or Shoulder. The transition process groups instructions based on the setting value applied to each element. Note, the terminology is a little misleading, it was initially developed for the Intersection design capability, to help TBC understand how to map pavement and shoulders / other elements in a mainline corridor int a side corridor at a T or X or Roundabout type intersection. It was then picked up as a part of the corridor model to help in Template Transitions. Basically items tagged as Lane Edge are grouped in one template and the next template, and the software tries to map Lane Edge to Lane Edge. If there are more than one lane edge and the number of lane edges match from one template to the next, then they will be matched Lane Edge 1 to Lane Edge 1 and so on. If the number of elements tagged Lane Edge do not match, then the software

The video below explains the offset transitions in some detail, slope transitions work in the same way.

Alan

Hi Alan,

thanks for the explanation. I suspected something like that. I'll have to add a lot of Null templates then to make sure that it doesn't happen again.

It would be a good enhancement to be able say don't use node numbers that have been used in previous templates, or say node numbers are unique to this template, or to deliberately set a specific node number.

A quick test revealed that using node names wouldn't help much to prevent this automatic transition either.

Sounds like you solved the problem but I thought I'd add a note just in case anyone isn't aware.  TBC generates the a second file in the source directory with an extension of .vce~ this is for the undo feature and keeps track of all changes up to the penultimate save.  So if you rename the extension and remove the tilde at the end, you will have a copy of your project that is one save old, hopefully before the error/bug was introduced.

Cheers!

Hi Cary,

thanks for mentioning it, but the .vce~ was already corrupted as well. Unfortunately our IT was also not able to retrieve a previous version from the server. So, I had to do some rework. Hence my question if we somehow could retrieve any data or force TBC to load it anyway, but saying there were errors in the templates and they'd need to be checked.