Works Manager and Dependent Objects

I was asked some questions about generating data for Works Manager today, and it has been a while since I looked into this so I thought I would check out the state of the union on this

The issue in question was that there was a lot of extra data going out to the machines that seemed unnecessary and that had not been specifically selected by the user for export from the TBC project - so what is really happening. Here is an explanation that I hopes

The change to VCL file as a Design Format brings many benefits but also some “baggage” that has to be handled in the right way. It is taking time for that to be resolved programmatically but it is getting better and better gradually and I was pleasantly surprised with the quick tests I did this morning.

Lets take a surface model in Trimble Business Center. There are a number of Surface Model Types including the following

  • Planes
  • TIN Only (from an imported LandXML TIN or a TTM file TIN) i.e. No Source Data
  • Surface Model either created by you in TBC or imported from eg LandXML that includes Source Data i.e. Points, Lines, Boundaries etc.
  • Layer Surface - created in a takeoff from Categorized Layers for your Existing and Proposed surfaces, this has source data from the categorized layers and also any objects added to the surfaces using Add Remove Surface Members
  • Corridor Surface - created from a Corridor Model as a Surface Output - its source data is the alignment and the vertical alignment and the corridor template instructions, 2D lines, Reference lines, surfaces etc. that are referenced together in the corridor model

So as you can see a Surface can be a TIN only or a TIN based on source data objects that are used to create the model. Those source data objects are called “Front End Dependent Objects” i.e. the surface (unless it is just a TIN Model) has objects on which it depends for it’s existence and its definition. If those objects change position, elevation or if they are removed then the surface changes form because of those dependencies.

On the back end of a Surface there are also objects that can be created that are also dependent on the surface model - these include Quick Contours, Full Contours, Contour Labels that are dependent on the surface for their existence. i.e. if the surface changes because a point is moved or re elevated, the contours change to reflect the change etc.

There are also chain dependencies in Trimble Business Center e.g. a Corridor Model will reference an Existing Ground Model for its Tie Slopes or for a Surface Instruction, and those surfaces will depend on their source data for their existence etc. so if you select a corridor for export, then it requires its dependent objects for it to be able to remain a corridor in a VCL file format (keeping the Intelligent Data alive by incorporating the chain data dependencies together. A side slope also is a similar thing here, it depends on its source line, the sideslope properties and the target surface for its existence. Drill holes refer to a target Design and a Rock Surface layer and so on. So Dependencies is an important factor in the data management process.

If you write a VCL file out to be able to copy and paste or export / import data between projects, then you likely want the dependent objects to move with the selected objects i.e. if I pick a contour that depends on a surface and the surface depends on points lines and boundaries, then I can either send just a dumbed down line that has no dependency anymore (it is correct in 3D but it is no longer dynamically linked to the models from which it was derived, or I can send it as a dynamic / dependent object but then I need it to carry with it all data on which it is dependent through all associations in the project…

OK so that is the background, so what is happening in Works Manager World as of today using 5.7.1 of TBC and Latest Greatest Works Manager Account.

When you create a Works Manager Project and then link to it in TBC, it will appear in the Project Explorer tree of TBC. If you click on the Project Name level, and review its properties you will find a property called “Cleanup VCL file”. If you do not want to send dependent objects to the field systems then set this to Yes. If you want all the dependent objects to go to the field system then set this to No.

Question is does this work and work in all scenarios - based on my tests this morning the answer is no but it certainly helps specifically with surface models. Before the results of todays testing here is another point to be aware of

In the past we used a TTM for a surface model and a DXF file for linework. now when you write a file for works manager it combines the surface model selection and the design linework selection and puts it all in the same VCL file package, Remember that a contour in a Design Linework Selection is dependent on a surface that is dependent on points, lines, boundaries etc. that make up the surface, so if you are adding a surface and design linework together to make up a design package for field use that either could / can contribute dependent objects.

What I found were the following when set to Yes i.e. remove dependent objects

  1. A surface model goes out as a TIN model only, all source data dependents are removed
  2. If you select a contour line or a Quick Contour Line as Design Linework, they don’t appear to be checking these at all so by having model set to none, if I have a road model that is built from points and lines that I used to generate a contour map, picking one contour will pick the contours, contour labels, Surface model and the linework and points of the surface.

If (2) is a need, then you can use our Convert to Linestring command to convert the contours to linestrings and remove the surface dependency (a checkbox in that command) and filter the line vertices in the contours before selecting them as design linework for field use and then select those lines to export as dependent free data. Currently the Convert to Linestring command supports full contours only and does nothing with Quick Contours. You can use the Explode command with Quick contours to turn them into polylines (I will get this supported in Convert to Linestring going forwards).

If you want to separate your modeling process from your field data process you may want consider having a modeling project and a Field Data project. Then write out simple dependent free data forms from the modeling project e.g. TTM files or CAD files of Contours and Linework etc. and then import those into the Field data project and use that to serve up data for the machines and rovers etc.

I thought I would give Reference Files and Reference Surfaces a try out but that is a step too far right now - they don’t seem to be supported at this time and the Exceptions started flowing at that point so I reported the issues to Trimble and stopped here.

Hopefully this helps