Hi all, We are having a problem and I can't seem to resolve it. Civil3D database corruption occurs after to many FBK imports and I am not finding anything out there to resolve it. to understand what I am about to share, I will explain our procedure.
Our procedure:
- Import JOB files from Trimble TCS to PC
- Convert JOB files to FBK with Trimble provided "ASCII File Generator" program, found here. I also am using Trimble recommended stylesheet converter found here.
- Make any known corrections to FBK coding and such.
- Import FBK to Civil3D database
- look for errors in drawing
- edit any visible errors in FBK and re-import (or delete and re-import)
- this process goes on until the FBK comes in with no errors
?ÿ
The situation:
ERRORS:
- PROCESS TOPO:
- Day one comes in perfect. All codes correct
- Bring in day two and a big giant "S" Survey Figure connects, as one line, all over the drawing, including points from day one.
- Check codes in day two FBK. All good
- Delete all FBK files from DWG
- Bring in day two alone and everything is perfect
- Bring in day one and a totally different Survey Figure connects all over the place
- Both files codes are perfect
- Combine the two into a single FBK file
- Process
- Try a second time with new database and drawing
- I decided to get screenshots of everything to post here, not wanting to mess up our actual project:
- I decided to create a new drawing and database.
- I impost my CSV of adjusted control
- I bring in the day one FBK
- I bring in the day two FBK
- Everything works perfect
- CONCLUSION:
- When you process FBK files over and over eliminating the errors in coding, rod heights, etc, it corrupts the database with each process. There must be some way around this.
- Choice #1: combine all FBK files and process at once
- This option can screw your database on a large job from way back as it will inevitably jack up your database should you ever add field data at a later date.
- Choice #2: Create a new database and drawing for every import of a FBK file, export a coordinate file and then import to main database. (Coordinate file seem to do less damage to the database)
- Choice #3: Fall prey to the forced proprietary regime of proprietary systems, of which I am not a proponent of (I am more for open source and decentralized resources), and buy Trimble Business Center.
- Choice #4: Make all edits in the data collector, then process and check for errors, which would start the cycle all over again.
- ?ÿ
- I decided to get screenshots of everything to post here, not wanting to mess up our actual project:
Any one experience these problems or have a solution?
?ÿ
SIDE NOTE: We have tried using TRIMBLE LINK from within Civil3D and found it to mess up the prism constants erroneously.
Just export and import csv files.?ÿ FBK files are getting extremely dated and have always been a little finicky at times.
It sounds like you're using Trimble equipment so I assume you have TBC. Bring all your data into TBC and make the appropriate adjustments, if any, to your conventional data.?ÿ Then just export a csv file.?ÿ That's what we do and have done for a decade and it works just fine.
Yeah, I've actually never used FBK files but they always sounded buggy to me.?ÿ Clean up the things that need fixing in the data collector (what I prefer) or during processing and then use an excel file or even a simple text file.
As far as that big whacky line it looks like a field code mistake is all.
One thing I discovered is not to end a line. ?ÿJust beginning a new line with the same code will end the previous line. ?ÿThis may or may not be your problem.
I use Trimble for all my GNSS work, Leica for TS, Star*Net for corrections, then create a txt file from Star*Net that I import into C3D.?ÿ?ÿ
I tried the Survey Database route with C3D and found it buggy and inflexible.?ÿ To me, it has the feel of software that was designed as an afterthought.?ÿ
Once I edit and adjust my points in Star*Net, all my linework that was generated with both Trimble Access and Carlson SurvCE will be slightly off from my adjusted points.?ÿ Sometimes the separation is negligible, but usually it's a problem that needs fixing.?ÿ The quickest way I've found is to take the txt file containing the adjusted points and import them into a new job in SurvCE.?ÿ SurvCE automatically redraws all the lines, and does a better job with curves than C3D.?ÿ Then I simply export the dxf.?ÿ Sounds like a pain, but it is much faster than messing around with C3D.
?ÿ
Good point David, that is the way we do it as well. Can't get much easier when having a properly coded set of points to simply export and import a .txt or .csv file with all your linework and breaklines together.
Civil3D is good for drafting, but clunky, inefficient and occasionally flawed for linework, or adjusting/QCing data.
I have never used FBK imports for the reasons stated upthread. When I have had to use the survey database, I have always found CSVs to work far better. But the process of importing/fixing codes/reimporting is still a pain, and we often had to wipe the database and reimport in a new one due to errors similar to the OP. That would be the easiest fix for the time being.
If you don't have TBC for QC/QA, get it. Not only is it far faster and easier for QA/QC of raw data, it will let you process the linework and fix it on the fly without having to reimport over and over. It'll save tons of time and money...plus allow for analysis and adjustment of control data at the same time. What are you currently using for adjustment of control, baseline processing, etc.?
I control F to F by coding and .csv files. It works well in C3D. In fact that has worked through autocad since I first set up coding in 1987. Although at that time is wasn't .csv coordinate files.?ÿ
I have only very briefly tried out surveying routines in C3D and each one has been a disappointment. So I don't use FBK files, adjustment routines, ect.
The import I use from Trimble to C3D is a simple point file, the problems are taken care of before importing into C3D.?ÿ
I'm assuming you don't have TBC so you are using a trimble import/export program to get it to the PC instead of importing the DC into TBC which would allow for a more robust editing environment.?ÿ
I would be editing the HI issues in the DC before export or be sure and keep the job in the DC in case you need to edit it later when you find an issue.
Code editing can be done in an editor outside C3D.
We do this all the time for partner engineers that use our data. There always seems to be something in the coding sequence that needs an adjustment.?ÿ
We create a debug database to import the initial field data to make sure it got coded correctly and then once cleaned up export all points to a final DB that doesn't receive new import events but can have objects like blocks or similar added but not import through the database import process.
Autodesk changed the database platform in the 2019 to 2020 and that also created a littany of issues.
The problem the OP is experiencing isn't in the .fbk files specifically.?ÿ C3d just doesn't like data added to the survey database piecemeal, no matter what form is used.
That said, the .fbk format is a legacy format. I use other means to reduce my data to coordinates (principally StarNet in my case). I recommend moving away from .fbk. Too limiting.
I agree.?ÿ Each day needs to be imported either completely separately or multiple days need to be imported at once.?ÿ Never ever re-import data already in the database as that's a recipe for disaster.?ÿ I prefer an import event for each day as it's much easier to keep track of and process.
@david-livingstone conversely, I never begin lines for C3D, I only end lines. C3D by default will draw lines when the code is setup in the figure prefix database.
I appreciate the responses to my questions here. Thanks all.
