Trimble Business Center

I am curious how other users handle points from the field software, both SCS900 and Siteworks or other, and the transfer between the field software and TBC. And potentially from TBC back to the field software.

This is something I have tried to improve over the years and have had some success but still have not perfected the process. Do other people have this issue or has someone found a sure way to keep things clean and organized?

Part 1 - Recording in the Field

When we initially started with Trimble we were trained to use the measure command when you were measuring stuff; stockpiles, utilities etc. Stakeout was more for QA/QC of staking a model surface. Yes you can use stakeout for recording points of a line but you get the tolerance screen that yells at you every time. You also do not get connecting points as a line (without the fancy codes that is). 

Are other people using measured points over stakeout points?  

The Advantages I have found to using Measure

• Can have points connect automatically to create lines
• Feature line Codes
• Can use work orders to clean up data if need be
  • Typical work orders:
    • Site Cal
    • General Layout
    • As-Built Data
    • Stockpiles
• Can still use a reference line for utilities

Part 2 - Sharing among other Data Collectors

We have a few projects that have multiple foreman on a project. Most of our projects will have more than one foreman that will be on a job. What is the easiest way of sharing point data? I could easily take all of the points from foreman 1 and dump them on one layer and work order to give to  foreman 2 but I feel like that is not helpful or productive. 

You can cut and paste work orders from from data collector to another but this also creates issues:

• When  using TCC you have to be very strict on syncing
  • Foreman 1 syncs to the cloud
  • Data manager reallocates information from Foreman 1 to Foreman 2
  • Foreman 2 syncs to the cloud to grab data
  • Foreman 1 has to sync to the cloud to "give up" these works orders
    •  If not, Foreman 1 still has these work orders on their data collector and can add points
    • Then you get duplicate work orders with overlap
  • then Foreman 2 has to try and work through someone else stuff

I would rather take the time and clean up this data and present it to foreman 2 in a more usable way. I have to do this anyway for as-builts records, so I might as well provide it to the field crews.

Benefits

• Progress of job for supervisors and project managers on their data collectors or respective devices. Replace redlines on plans
• More incentive to cleanup linework as you go
• Better as-builts

The closest I have come to getting this more usable is to "connect the dots" and provide Foreman 2 with layered linework and then put all of foreman 1's points as stakeout points. However, this creates an all or nothing scenario for viewing previous points by toggling on and off the stakeout points. 

Example:

Pat

I would not use Work Orders as a means of sharing this data with others. I can talk to the Logic of SCS900 as it was when we created it first many years ago and the philosophy has not changed much over the years

We broke the data model for SCS900 into Sites, Designs and Work Orders. 

• Site Data was data that you need every day - no matter what you are doing and includes Control, Site Map, Avoidance Zone, Site Calibration. Site Map is Dead - view only - On / Off. Control has since been broken into two parts - Office Created Control (Main Control) and Field Created (Crew Created Stations that are of lower accuracy than the Main Control). Control Points are a Point Data Type and should only be used for Control Stations - really nothing more than that.
• Design Data was data that you need to execute a task of any type. Design Data can be Alignment, Surface, Linework or Point Data. Point Data we saw as necessary, but we were trying to get people to use Linework and Surfaces more and create the Stakeout Points on the fly from Line Stations and Offsets or Line nodes etc. Point Data was geared around Point Feature locations primarily (Anchor Bolts etc.) While Point Data has a Name and Code - all point Data on import to SCS900 becomes a Stakeout Point and is in the Stake Point List etc. Stake points can be selected (tap and Hold) or selected from a list etc. While SCS900 allows Point data to be transferred as CSV or DXF, the DXF Layer info is not used for Point Data objects - Only Line Objects. The points are extracted and loaded into the Stakeout Point List. While I believe there are filters that you can use on Point Data to find what you are looking for this is likely not as efficient as it could be. In Siteworks we have added VCL support, and I just tried this and it does the same thing as SCS900 did with DXF files - the Point data is no longer Layered in Siteworks - while the points are represented as a Cross (the Stakeout point) and if you turn that off it leaves a dot the color of the point object in TBC (Layer Color) - but if I turn off all the Layers it is still visible - so not sure what that Siteworks Object Layer that is sitting on). I also saw that the Feature Codes of Point Data are lost through the VCL transfer (at least the version of Siteworks that I am running - I have flagged that to the PM today). so while you can for sure select all the Points and export them to a VCL and then use that VC as a Design, it is lacking in some areas to do what you want (unless the PM tells me different in response to my email to him this morning). I do see the Design as the right way to pass this info about - and you could create multiple CSV Designs or Multiple VCL Designs (kind of getting away from the point of using a VCL file) - a single VCL file with better integration is likely the right path for the future (I need to update my Siteworks to see if this has been improved at all).
• Work Orders - this was designed to capture all of the work executed by a crew in the completion of a task(s) and would reference a project and a Design / Change of Design in that process. people use WOs differently - small projects often use one WO for everything and change the designs used continuously - Big projects tend to use thousands of Work Orders to cover specific tasks or task types over the life time of the project - and there are many levels of grey in between these two use cases. Workorders store data as Measure Data, Stake Data, Grad Check Data etc, and within each type of data there are sub types - Points, Lines, Volume Boundaries, Boundaries etc. or Stake Point, Stake Line, Stake Surface, Stake Alignment etc.. There was never any intent to use Work Orders as a means of sharing data back to others - to do that we envisaged bringing the data into TBC and making a Design out of the data to Share Back. I would not recommend WOs as a means of sharing data back to crews on site - either we should add a new type of data like As Built Files that you can load like a design or we use Design Files as we do today to achieve this. The reality is that VCL is the way that we are heading and I would recommend to the team that we try to make that support better (use all of the Code and Description and Attributes that could be on Points, Use Layers to separate the points etc. and make this a more powerful solution as a result. 

While it may be perfect today, I know Steve DiBenedetto and Casey Cyrus are working on this currently and I would suggest that you try to influence their development efforts to make this a stronger solution using VCL.

Alan

As always great stuff and very insightful.

This confirms some of what I was thinking. 

I agree that adding as-builts to the design or maybe even a separate category for as-builts would be the best way. Create a new spot for historical point data. Maybe lock the points down but definitely give an option for the user to edit or add information; valid, invalid, notes, fxl codes. From what I am seeing, the only thing that is missing from adding these points to a vcl is the points layering for organization. 

I agree with not sharing working order. Those works orders should be unique to the person that started them. But without a lot of prep work, there is not a quick way passing this information along currently.  Especially when you get a last minute phone call that XYZ is on site and needs info. Sometimes I just do not have time to clean up all of the points and create this as linework to pass on because I am given too short of a notice. Never mind presenting the points in a clean manner. Nor is it necessarily warranted. The features installed should be close to the design, it is more for a sanity check and verification of where stuff may have deviated or actually elevation.  

Adding this information to a design/as-built group and the ability to layer points, I could grab all the points from a work order and add these to a new selection set, maybe rename so that you don't get duplicates and you know that these are definitely as-builts (add a prefix such as SEVAB) and then export these to the field, then the new foreman would have these to use and create work orders to track their data, and I could bring this in and keep appending it to that TBC file. You wouldn't have to worry about duplicate work orders with overlapping points and each foreman would have their own true data sets, which is what I tried to do from the start but that had some issues. So you would have something like gravel-JS and gravel-pl, as-builts-as and as-builts-pl. That sounds like a better workflow on all fronts. I think this would also tie in nicely with WorksManager. 

Very obtainable with some tweaks.