Trimble Business Center

First, I do hope this is the correct forum to post this. I cannot find a forum (or any place else) to ask questions and receive answers about Access specifically.

Here's the situation: We have used SCS900 since forever. We now are going to move to Siteworks. SCS900/Siteworks does not support the use of the SX10. That means having to use Access.  I have read through both the Siteworks and the Access 2018 user guides this week (700+ pages) and I cannot figure out how the two can work together easily.

1) Siteworks maintains a folder structure that 'passes' the site map, control, site calibration to all designs and work orders as the project progresses. This can amount to hundreds (or more!) 'work orders' over the course of a project. Siteworks file system maintains the integrity of the data structure.

2) Access (please correct me if I am wrong and missing a step) utilizes a Project folder to hold the site map, control points etc but does not pass the calibration/control data to individual job files within the same project? It seems to be a manual process each time you create a new "job". (Is this correct?) It also has no mechanism that I can find to sync up multiple controllers so that each has the same data (designs etc). The manual references "editing xml system files" to make them available in other controllers via copy and paste but I cannot find another way to do it.

3) Access creates each "job" as a file, and not a folder. Does this mean that every job's data has to be exported manually  and, if so, what is the best way to track that?

So, given that Siteworks and Access have fundamentally different data structures what is the best practice for coordinating their use through TBC over the course of a project?

Marshall

Marshall

All good points. Having been the person that started the SCS900 Product line back in 2003, that was fundamemntally our design concept - that being our "target user" would be working on the same site for many days, weeks, months or years vs the average Land Surveyor using Access jumps from job to job on a daily basis. While a "Surveyor" may work for a Contractor on a Project (and in that process would need to use the same approach as SCS900 / Siteworks) so that each visit would just be a new task on an existing project etc.the Survey / Geospatial Team have never supported this approach as far as I know. While they adopted a Project Folder, the concept of Sites, Designs and Work Orders in SCS900 is way better for a Contractor.

I understand that you are moving over to Access to support the SX10, and that unfortunately puts you in this situation of having to work out how to best manage the data from the two systems on the same Projects.

I will try to put some thought into this over the next week to give you some guidelines, and will talk to a few customers that I know who are doing this very thing today (but are maybe also struggling with the concepts and processes).

I have not used Access for a long time, so I will need to discuss with some of my Geospatial colleagues tomorrow when I am next in the office to find out what options you have available to you).

Alan

Alan: Fist, kudos to you for the concept and execution of SCS900. It is truly a fine piece of software and continues to be so. I have spoken to Steve about its new features and it is very impressive. Second, thanks for the honest answer. I rather suspected Access might be a bear to deal with for use in construction. I have since checked with some friends on other construction sites (all of us “real” surveyors who happen to work in construction) and they all say it is really a pain-in-the-can to use Access. In my case, wanting to use the SX10 for construction has presented the problem of using Access.

After I posted my questions I re-read deeper about “managing projects” in Access (2018) and was very surprised to find that even to customize the software across multiple controllers requires granular editing of system files etc. Odd in this day and age to be doing that sort of thing unless you are working with an SDK and even then it’s rare.

I look forward to hearing what others have to say about organizing the use of Access on a construction site. The standards for survey data integrity on our provincial highway projects is getting ever more stringent so sorting this out now is important.

Thank you again for the clear answer.

Marshall

I have interviewed a couple of my Geospatial colleagues and will find time this week to write up my notes for you Marshall - sorry for the delay but this is a "biggie" to answer in the right way to help you and others

Alan

Sent from my iPhone

Alan,

   I would love to get a copy of the work around you come up with. I am also a surveyor that has had to move over to Access because of the SX10. I still use TBC to create projects and design data like I would for SCS900 and then I copy the files to Access. It would be nice if you could just export the SCS900 design to an Access job with dxf, alignments, control points, and stake points attached to it.

I hope to get to this over the next 24 hrs and get something out to you all by Monday

Alan

Sent from my iPhone

Hi Alan - add me to the list of SX10 users now out of their Siteworks comfort zone as I re-learn Access.  

I understand the complex nature of the SX10 with the camera, scanner and wifi connectivity but is there any chance this jigger could connect to Siteworks?  Even if the scanning ability was disabled and just the standard instrument functionality was available.

Alternatively, could a PRO file with the road definition be incorporated into Access Roads?

Cheers

Ben

Hey Marshall,

I've only used Access so don't know anything about how Siteworks is set up to distribute jobs and files for comparison, but I can give you a brief runthrough of how we manage data.
Basically it's all about file structure and breaking down the job into smaller sections (usually for large, multi-year jobs.  Smaller job could be done in a few files.)

You can see the below photo for a file structure of a current job that has or will have several thousand elements.
We try and name files intuitively so that they make sense or match the drawings they are programmed off of as there is usually some rhyme or reason to them.  The jobs are setup daily under the project and the control file is usually the only linked file and the rest are added using the active map as needed.

This collective data is the synced to a master data collector file structure (we use a 3rd party sync but it can be done manually easily too.) After that, the master file is synced to each data collector so that every controller has the same files while at the same time the job files from the data collector are synced back to the PC/server.  This could include any exported CSV/JXL but right now we have the controllers setup so they can exported directly to a NAS drive as we are split across several offices so need a central location.  In the below pic, the Master syncs the import folder to the bottom 5 controllers; 2 T10s and 3 TSC7s.  It is a one way sync for this folder so it mirrors exactly so as to not have superseded files.

A good sync tool really helps the process.  Trimble's office synchronizer only works wireless with the new tablet collectors and is really slow for anything over 1mb (forget about scan data, use a usb) so I recommend finding out what works best for your situation. 
Finally, the incoming data is sorted by year/day/crew and the processed from there for checks or any deliverables.  There is also a survey request folder that has individual folders for the request/field file/working vce/outgoing data, as required.

That's basically it in a nutshell, let me know if you have any questions.  On the other side, if anyone has any ideas to improve this workflow or has a different one, please share!  Always looking to streamline.

Cary: Thanks for the screenshots. Like you I use intuitive file naming conventions to keep everything 'readable'. You are obviously on a power project (Site C?) so the depth your file structure is pretty complex. Mine are not quite that deep usually.

I guess my original question to the Trimble folks comes from a frustrating experience with Access' folder structure. You have obviously mastered it. My objection is that Jobs are all dumped in the same location and when you create them files need to be linked/copied. Forgive my negative attitude but after SCS900/Siteworks this rudimentary by comparison.

In SCS900/Siteworks the data structure is automated. You create a Site, a series of designs, sync to the controllers and that's it. This is usually done in TBC in the office but can be done in the field if needed. SCS900/Siteworks automatically  spits out Machine Control in the field if needed as well.  I have attached a screenshot of the data structure. There is zero need to copy or link anything in SCS900/Siteworks. All Work Orders (1000's if needed) get their own folder No copying to an export folder required. This is where I have very "readable" folder names (EG 190221 AB SG 100+00 To 200+00 Rt MCC = Date, As-Built, Subgrade, Station Range, Surveyor's Initials). Designs can be as complex and as deep as needed. In the field you create a Work Order (a Job in Access) and in the process choose a design if needed. That's it, go to work. There is ZERO copying or linking of anything. At the end of the day sync the controllers to the office (using whatever connections you use) and that's it.

The other awesome feature with SCS900/Siteworks is that for most tasks little, or nothing, needs to be done to the output from a Work Order. SCS900/Siteworks creates an output file called an .spj file. It is a data rich format (sort of like a .vcl file in TBC). Measured surfaces sometimes need to be trimmed and some linework cleaned up but basically the data is as measured/collected in the field. No playing with points to create surfaces etc in the office. You get to play with CSV files only if you want to...

It kind of escapes me why new equipment so obviously useful for construction surveyors (ie the SX10) is reliant upon software that is, sorry to say, kind of old fashioned and outdated (yes, even Access 2018).

Ok, I'll stop raving  

Thanks for the peek at your data structure. I can see I have some thinking to do about organizing my (future) Access files. Have a good weekend.

Marshall

Nice deduction, Site C is correct!
I agree with you on how Access handles files is very rudimentary and becomes a mess very easily if you don't keep an eye on the files.
I tried Trimble Connect too and, while it has potential, was a hot mess for my requirements but was a little more structured.

Wish I had used Siteworks to know what I am missing!  But thanks for the explanation that helps me picture it and makes me think that Access should be able to incorporate something similar (if only as an option).  Not saying it would be easy (or hard) but, most of the pieces are there already!

Cheers,

Cary

Cary: Seems to me that a simple programming step would be all that is required to make Access as good as Siteworks (in terms of file handling at least) but there's no way to know how the original file structure was locked into Access. It might not be changeable.

I did hear from the Siteworks folks and adding SX10 controls (video, scanning etc) might be beyond their capability with the program's structure. My opinion is that Access should fold into Siteworks like TBC (finally!) became one with TBC-HCE.

Trimble likes to (for some misguided reason) maintain a distinction between "construction" and "geospatial" and somewhere along the line decided that, for example, the SX10 would be a "geospatial" tool. In spite of the fact that the SX10's entire product page speaks of its ability to construction oriented tasks: topo, as-builts, scanning etc.

Thanks again for the details on using Access. Much appreciated.

Marshall