In defense of fieldbooks, they are of great use to me in troubleshooting problems. For instance, if someone physically changed their rod-height and didn't change it in the data collector, you can isolate the point(s), right click and choose "Browse to Survey Data" then edit the rod hieght in the Observation Editor and make the change there which will update the point. You can't do that with a csv file, which only contains coordinates. Also, you will see the little network/setup temporary linework which is good for determining if a bad point was shot on a reflective surface like a car headlight or sign rather than your prism.
As a surveyor, measurements are what we observe, not coordinates. I agree that editing survey figures is very cumbersome, however, it is really nice to right click figures from an import event and create breaklines that will be sent to the surface of my choice. The data base allows for a "paper trail" of files so that busts can be isolated and corrected without starting from scratch.
Also, FBK supports scale factors, so you can measure all your locations on ground with a scale factor of 1 and then edit the FBK scale factor after you have processed the control and determined it. You can't do that with an csv. It would be nice if the Translate Survey Database let you scale groups of points instead of everything.
(running C3D 2012 sp3, Win7 64bit)
I noticed you brought your data into a network so you could "easily reprocess it", doesn't the import event allow that? Does the network give you additional functionality that the import events don't? I haven't seen any real use for networks unless you are using raw survey data (shots, setups, etc).
Great video by the way.
I understand what you're saying...
As another example, we had an instance on an airport taxiway where we were checking the tie-ins to our project. On one end, the field surveyor was setup some 700' away, and used his total station to take the shots right along the joint line. That's completely against our proceedures out at airports, and if we had been using a Survey Network and FBK import, it would have been obvious in C3D that he had setup on a control point that was too far away, and we couldn't trust the elevations. As it was, it looked like we had error in our tie-ins, and it took another visit to the field and a bunch of head-scratching in the office before we finally figured out that the field guy had made a basic proceedural error in the field. The Survey Network would have clued us in a lot faster.
So I see value in the networks. But I work as a C3D Survey Tech in real life, and I see all the trials and tribulations brought about by various approaches. All things considered, we get more value out of ignoring the Survey Networks and ignoring FBK and ignoring the SDB as much as possible. That's for typical construction surveying. If you're doing other types of surveying, you may find more value in the SDB.
As far as using a scale factor, that's a topic I've gone on at in length. If you're surveying using a grid projection system such as State Plane or UTM, then you can configure your data collector to take care of all that stuff, and you don't need to use a scale factor during FBK import. I view that as preferable.
One distinction is that you can't do analysis on an import event but you can analyze a network which can be made up of several import events. Not that you would do that specifically though...
Oh and about the SDB. In a Survey only firm, yeah, i get that it can be more burdensome. But in a engineering and surveying firm where you can share the information in the SDB rather than have engineers toiling in your survey files? Lifesaving to most people.