Merge Survey DB's?

[dan.higgins]

Anyone done this yet? I need to and and see no way. If you insert existing db1 objects (figures, points) into a dwg. and then close db1. Now open existing db2 - I want to get the info from db1, dwg into db2.
Any Ideas?

[sinc]

I don't think there's currently any particularly good way to do that...

Although, I would also tend to not want to do that. I'm kind of the position that the Survey Database is a useless detour that complicates Civil 3D and slows down production without adding any real value, and I try to use it as little as possible.

I would seriously like it if Autodesk improved functionality so that we could process Survey data without ever creating a Survey Database at all. That would dramatically simplify and speed up our processes, allowing us to complete projects more quickly and easily, as well as eliminate several good potential sources of error, and all-in-all make C3D much more usable for Surveyors.

[dan.higgins]

We have been using this product for 3.5 years now and I am still leaning. Been using cad since 1989 and this is by far and away the steepest learning/using curve. I understand the thought behind the db, I think, in keeping the survey information away from folks (designers) who have zero clues about it. There are quite a few nuances you have to be on top of all the time but the process works the same. Survey crew collects data, turn into field book, import into cad. Voilà - finished product. Yea if only but you get the picture. It's just another example of people wanting more control over all aspects of a product. Along with that granularity comes complexity. You have to learn which hole to go down and which branch in the tunnel to take to get to the right control (style,setting) to change what you want. Oh and you have to hope the code behaves like it should. Anyway thanks for the reply.

[sinc]

Yeah, I think "protecting Survey data" was a key part of the thought process behind it. But it leads to problems.

For example, one standard workflow it's created is to import a CSV or FBK, creating linework, but then look at the DWG to find any errors, go back and fix the problem in the raw CSV/FBK file, reimport the file, look at the DWG again, go back to the CSV/FBK again to fix any problems, reimport the CSV/FBK, repeat ad complete naseum.

People follow this process because it's the easiest way to make sure all the Survey data comes in as Survey Figures, and all the Survey Figures are complete and correct in the Survey Database. Then, in theory, they can pull this survey data into whatever drawing they happen to be working in.

I personally abhor this workflow. It is incredibly time-consuming and painful for the Surveyor. Plus, there's really little value in it for the Engineer, compared to simply having a separate DWG with the Survey data in it, and maybe some good tools to let us work with THAT kind of data in easy ways.

There is also some thought that the Survey Database can maintain all your raw survey observation data, so that if you adjust your control network, all the sideshots adjust with it. This is nice functionality in theory, but not in practice, at least given C3D's implementation. The major problem is that the field surveyors are the ones who generally know whats going on with a job, know when an adjustment needs to be made, and know exactly what to do. So the field surveyors are the ones who typically need to perform the adjustments. But we've found C3D to be so complex that our field surveyors do not use C3D. In order to keep any usable level of C3D skills, they would need to spend far too much time in the office, and that is not economically feasible for us as a company. A solo person, who does ALL the field and office work, might like C3D's setup, and find it useful. But for most companies, it is far more useful to have the adjustments done as a pre-process, prior to bringing data into C3D. This approach also allows us to use software that is far more capable of survey adjustments than the Survey Database, things like TGO/TBC or Star*Net.

Really, when you get down to it, the Survey Database adds little extra functionality, but carries a great price in terms of making the software more esoteric and difficult to use, with a lot more potential for error (because there are so many settings that need to happen in both the DWG and the Survey Database), and just a lot of headaches all around. So I'd like to see the whole thing kaboshed.