Civil 3d Survey Database versus just ASCII files
Having spent the weekend dug in to the books I have a fundamental question. I see no real value in using the Survey database for our generally derived RTK points. They carry no double sets of angles.
However that said, I work with a dozen and often more when we have a collaboration project with others such as the COE, ODOT and others. I find the concept of the survey database and the ability to check in and out points for other users to be intriguing. Just check out the Survey Control for a control map or just inverts to check flows. They can check them out and even erase them in their drawings without ever TOUCHING the raw database that only two of us will access to change.
I’d a appreciate any pro’s or cons on the issue from those more experienced than I am. I have a lot of experience with databases though and use to make the database in TGO jump some hoops. And also our projects often involved years of work from conception to build to maintenance. (oops, there is the BIM concept)
Deral-Brush Ape
- 11 Replies
We use the survey data base. Drawing points are drawing points, not all of the survey points need to be in every drawing. On a large project I want to keep tract of the field points used, even if the drawing produced just involves some of the points. Who ever is getting a drawing does not need to see the check shots. Sometimes besides point files we run Fbk files also and I have not figured out how to run a Fbk file without usiing the survey data base.
From what I’ve seen most surveyors using Civil3D are more comfortable with their existing software for processing and analyzing the raw data – not really surprising. As a designer I am quite happy to receive point files from the survey crew as it gives me the opportunity to manipulate the point identifiers to suit. We do not use numbers any more, all of our points are identified by point name and the format ensures that we never get a duplicate point.
I do use the Survey database for projects where I want to have point data appear in multiple drawings without actually copying the original data. For example I have a project spread across several hundred square kilometers with various order control points scattered throughout. All of these points exist in a single drawing, with point groups to help organize them. The survey database has an import event which reads these control points in. Other drafters who need to display these points or use them to build control tables can read from the database as they need to.
Mike…
I don’t think you can run .fbk w/o survey d.b.
Deral,
I find that, like you’ve said, I just pull in a .txt file when using GPS…there is nothing to really ‘run’ in the .raw file.
I still pull them in using a database though, it makes them easier to handle.
I also pull in most of my total station stuff via a .txt file. I double all my angles, make all my necessary adjustments in the D.C. then just pull in the coordinate values.
I am going to school for 3 days next week to learn allllll about points…yeah for me..:-|
If I understand well, you need an FBK to import the raw observations and line work into the survey database. When you import a list of type Name,E,N,El,code you’re bypassing the survey database.
One reason to choose for the latter is that your dc stores the raw data in its own format and that needs to be converted to an FBK. Here comes the first problem, some converters do not convert all the (new) coding options (parellel lines, ofsets,extending, …) but support only the basic line work. Don’t know if someone is working on that. These converters are not built by autodesk, your survey brand X does write them …Some brands deliver a custom import toolbar in C3d which lets you download your dc directly in C3d, raw data is converted in background but the same problem as above rises here, only limited support for the new linecodework.
One more thing to consider … I prefer downloading, evalutating and calculating my data in the software delivered by the brand of my survey equipment. A new gun, receiver or antenna comes with the right drivers, calculating in another environment can be a disaster when the file format changes slightly. (I do remember issues with changes in the format of prism heights, different format of entered notes …)
I feel confident when I can export E,N & codes, that way I know the E,N is ok and I can focus on my linework codes.Exchanging data can always be done with ascii files, but the new way to go is by the xml format, most recent survey software will read and write points, lines, dtm’s in this format.
Chr.
It was just a quick question from work and now I’ll provide a little more information as maybe this will help.
When we do a small network using GPS then this is LS Adjusted in Topcon Tools and then exported as a ascii file. But we still have codes for the point so it goes through Foresight and then into Eagle Point. No problems and no line work associated with these files. I can go either way with them.
When we do have to traverse and then adjust we adjust in our survey software and then export through Foresight into Eagle Point and EP does the reducing of the codes.. So it’s still arriving in an ascii format.Our raw data is stored outside our CAD programs.
And 99.9% of the time it’s pure RTK gps points. We still use Foresight to bring these in to the EP environment and it does the reducing of our field codes.
The latest version of Civil 3D includes a link to download straight from our collectors (Rangers running Survey Pro) At least that is what the documentation says.
What we do now is download, process, build the surface models and then our Engineers (and others) use this for the basis of their work. We keep the original copy on a ‘private’ drive (set up by IT for just us) so when someone does break the drawing but moving things or erasing things then we can send them another copy. It sounds like the idea of the survey database where they can check out datasets but never harm the database sounds like it would save so many multiple drawing floating around. Everyone could work on the same set of data.
So it appears we would not need the FBK files but could utilize the survey database in our work flow.
And yes, we are expecting a learning curve in point groups, styles and other things that will replace our EP modules.
I did use the parcel editor and like it a lot. Civil 3D appears to be a lot more dynamic on updates that EP was for some things. I love the surface modeling and the ability to edit things so easily.
Thanks for all the advice. Keep it coming.
Oh..This is likely a newbie question but the layers in the basic Civil 3D start with a letter. This is a huge assumption but does the A stand Architech, C for Civil and V for Surveyor? That’s all that I could think of but we will not use an of these unless there is some fundamental reason we should.
> The latest version of Civil 3D includes a link to download straight from our collectors (Rangers running Survey Pro) At least that is what the documentation says.
This option would likely be bringing the data into the Survey database, which you indicated earlier you may not want.
> What we do now is download, process, build the surface models and then our Engineers (and others) use this for the basis of their work. We keep the original copy on a ‘private’ drive (set up by IT for just us) so when someone does break the drawing but moving things or erasing things then we can send them another copy. It sounds like the idea of the survey database where they can check out datasets but never harm the database sounds like it would save so many multiple drawing floating around. Everyone could work on the same set of data.
The data available in the survey database include the points, and the automatic linework – called “survey figures” but NOT the surfaces, alignments, profiles etc. There are other methods for making this data available to multiple users which you will need to think about.
> And yes, we are expecting a learning curve in point groups, styles and other things that will replace our EP modules.
This is the point where you need to be talking to your AutoDesk resller or some other expert about how you need the software set up to work for your methods.
> I did use the parcel editor and like it a lot.
Heh – then you’re probably the only one. Most C3D users hate the way that the parcel tools work, especially the labels.
> Oh..This is likely a newbie question but the layers in the basic Civil 3D start with a letter. This is a huge assumption but does the A stand Architech, C for Civil and V for Surveyor? That’s all that I could think of but we will not use an of these unless there is some fundamental reason we should.
Those layers are based on the NCS CAD standard. Again – you need to think now about your CAD standards for layers, linetypes, fonts etc as these will be embedded into your Civil 3D styles and settings.
Thanks but I’m leaning toward using the database. It seems like it has some advantages for sharing.
Are you planning to use Vault?
I, personally, find little value in the SDB, and would prefer to avoid it entirely. The ONLY reason I use it is that I can’t create auto-linework (F2F) in C3D without it. But as soon as I import that data and do the initial creation of my linework and breaklines, I forget about the SDB.
I’ve NEVER had any company I work with want a SDB as a deliverable. It may be a different story if you do everything in-house, but at that point, the SDB becomes more of a “Survey Data Management tool for Engineers” than anything. It doesn’t really provide any value for the Surveyors themselves.
Just my opinion, of course… 😉
> This is a huge assumption but does the A stand Architech, C for Civil and V for Surveyor?
Yeah, that’s what they stand for. I guess surveyors got “V” because structural engineers already took “S.”
Log in to reply.