Community
Civil 3D Forum
Welcome to Autodesk’s Civil 3D Forums. Share your knowledge, ask questions, and explore popular AutoCAD Civil 3D topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Survey Database settings change on import of FBK file

7 REPLIES 7
Reply
Message 1 of 8
dewarp1
3292 Views, 7 Replies

Survey Database settings change on import of FBK file

Hi,

 

Recently we have discovered a problem (bug?) with the survey database. We usually import our field data from our Trimble controllers into the survey database (SDB) through Trimble Link. We have been very careful to get all the survey database settings right, so that the data comes through correctly and have been successful up until the last few weeks. We find this a good workflow, where we are able to make edits to our field data (change target heights etc) easily in the SDB and comparisons with Trimble Business Center and direct output on-screen in the controller confirm that our data is reliable. We often have both GPS (long Network RTK vectors from the nearest network base station) and total station observations in the same file.

 

The issue is that, as the fbk file is imported, the survey database settings change to reflect the content of the fbk file. The "Atmospheric conditions" and "Curvature and Refraction" settings, which I have purposely left unticked (the controller applies these corrections), become ticked. This throws out our heights, especially on the long GPS lines.

 

We do have the option for a workaround, which involves going back into the Edit Survey Database Settings after import and updating the data in the sdb, but this is clumsy.

 

This seems to be similar to the issue that was discussed here.  However, we have only just encountered this issue in the past month or two, which coincides with when we rolled out C3D 2012 Service Pack 4 across the office. We are planning on implementing 2014 soon, so I have tried it out on 2014 as well, with the same result.

 

Is this something that others are dealing with too? Perhaps there's some sneaky setting somewhere that I haven't found which locks down the SDB settings preventing them from being changed on import? Otherwise, I think this is a bug.

 

I am also bracing myself for some comments regarding the dangers of using GPS in the SDB!

 

Thanks for your assistance.

 

Phil Dewar
Fox and Associates
Christchurch, New Zealand

Civil 3D 2012 SP4

 

Phil Dewar
Fox and Associates
Christschurch, New Zealand
7 REPLIES 7
Message 2 of 8
cbaildon001
in reply to: dewarp1

Hi Phil

 

We don't like how Civil3D handle FBK's of RTK data. So we always import RTK data as CSV files into the Survey Database.

 

I did not realise that FBK's can turn on and off various measurement corrections in Civil3D, I'll have to check that. If it does though surely you can just change the FBK to have the correct settings in the header.

 

The only thing I use Trimble Link for is exporting setout data to the controller, I stopped using it for import years ago.

 

Cheers

Caleb Baildon
Senior Surveyor
Opus International Consultants Ltd
Wellington, New Zealand
Civil3D 2015 - Windows10
Message 3 of 8
IanMcClain
in reply to: dewarp1

I'm a SurveyPro user and FBK reduces my GPS vectors to NEZ statements. I'm curious how Trimble Access (?) and survey link reduces those observations for FBK. Would you mind posting a sample file?

Ian McClain
Message 4 of 8
dewarp1
in reply to: IanMcClain

Ian
Here is an FBK file, showing both gps and total station data.

Trimble Link reduces the data to vectors as if it were total station observations - the base station becomes the setup point, the first observation becomes the backsight, and all subsequent observations from that setup are listed as sideshot observations. This makes for very long observation lines, especially for us where we use Network RTK - the resultant vectors come from the nearest network RTK station and can be up to 10km long.  Regrettably, it does not have an option to download as reduced coordinates instead.

I can imagine that there may be a number of people cringing the thought of this - I do too. I have tested the data quite a lot and I'm confident that, for the data we use the SDB for, we have it sorted (there may be 1-2 mm floating around from time to time, but that is insignificant for the purpose of the data). I think it comes down to making sure all the Survey Database Settings are set correctly too.

Cheers

Phil Dewar
Fox and Associates
Christschurch, New Zealand
Message 5 of 8
MATRIX3DSURVEYS
in reply to: dewarp1

I was a Chief Surveyor for a Major Oil Company and for an Aerial Mapping Company, part of my job was to evaluate and verify new software. As well as develop job specific software.


The FBK format (SoftDesk) and the RW5 format (TDS) are 1980’s software and I do not believe the software has been upgraded since AutoDesk bought SoftDesk in 1997.  That said the both formats were developed to understand Conventional PLATE ANGLE SURVEYS. With distances normally encountered in civil surveying (less than 1000m). Errors become apparent in surveys covering large areas, particularly at high latitudes. (This varies dependent on the map projection) While the software has a reduction to Sea Level (Grid Distance) there are no projection scale factor of convergence corrections applied. And there are no Geoid corrections. The atmospheric and prism offset corrections should have already been applied by the instrument software in the field.

Use the Instrument Manufactures Software to process field data and make adjustments. Especially if using mixed TPS (conventional survey) and GPS methods. The manufactures software allows all of the capabilities of the instruments to be used.  Free Station setups, Resections, Solar Leap-Frog, Smart-Station setups, Reciprocal Trigonometric Leveling to be used. I use LGO to process the field data both from the Leica instruments and from other instruments (import in TDS *.RW5 format). When mixing GPS and TPS (conventional) data recommend using GPS native WGS84/UTM83 coordinate systems in the field to prevent errors. Process the data apply Geoid and datum corrections in the office, then convert to local grid. If any adjustment is needed I use Move3 or StarNET.   Export processed data in PXYZDA format (point, easting, northing, elevation, description, attributes). The point file in C3D can be customized to include the attribute notations. Since C3D 2012 FBK files have not been required to get line work, the CSV files are a lot easier to edit and import a lot faster.  Import the PXYZDA file into C3D and apply description keys to get line work and put point on proper layers. I import the survey data in to a new clean drawing and attach it to the other drawing sheets (aerial images, surface, parcels, ground, ect.) then use the Map Import function to assemble a complete drawing.  

 

 

Jim

Matrix3dSurveys

C3D 2014 IDS 2014

Leica LGO 8, Move3

Leica GPS1230GG, TPS1200R1000

 

Message 6 of 8
cbaildon001
in reply to: dewarp1

Good points Jim, I'm currently doing a though review of how Civil3D handles survey calculations so I'll keep these in mind.

 

Phil - We also stopped using FBKs for total station data created by Trimble Link because in about version 2012 of Civil3D, the survey database stopped applying the prism constant to individual oberservations and applied it to setups, so that all obervations from each setup had the same prism constant applied. Not good.

 

I do not know if this has been fixed because the prism constant is not exposed in the survey database and I can no longer open the database in MS Access to check.

FBK's from Trimble Link output raw distances and put in "prism constant" commands. We export an SDR file and convert to FBK, as the SDR has distances with the prism constant applied.

Caleb Baildon
Senior Surveyor
Opus International Consultants Ltd
Wellington, New Zealand
Civil3D 2015 - Windows10
Message 7 of 8
MATRIX3DSURVEYS
in reply to: dewarp1

I did a lot of work in the 70’s and 80’s before we had GPS. Hell we had the first generations of EDM and Total Stations and still used a lot of triangulation for control. Most of my work was in the Rocky Mountains and Alaska. We would run control using 2 and 3 Instrument Helicopter traverse. Each Instrument would be moved 4 – 6 times per hour. So you had 5-10 minutes on station. Hit the ground, setup the Tripod level and position the prisms, once the previous instrument had a distance, the prisms would be replaced with and instrument and a set of angles would be taken on the previous instrument. That instrument would then be cleared to move. While the helicopter is moving the instrument, there is a short period of time to monument and panel the control point and possibly take a Sun Shot. When the other instrument is setup you complete your set of angles on each other and swap out prisms for a distance and pack the instrument. Got the distance tear down. Stash the prisms and run for the helicopter and repeat the process.  We used forced centering and zero “0” Instrument and target height for traverse. Instrument alidade and center of prism assembly were matched. To prevent error caused by measuring Instrument height, so it would not affect the traverse. HI drops were recorded as Side-shots. So only the takeoff HI and final HI could be in error.  Any side shots would be to a standard 2m rod. We would also shoot a side shot offset from each Instrument point and shoot it as a check shot from all 3 instrument locations. This gave us a way to check out how bad refractions was and adjust for it.

We could cover 100 miles in 3 hours. With a HP 3820 we could get up to 10km shots; with a T2002/DIRO3002S over 20km in a single shot. So we would use Reciprocal Trigonometric leveling to compensate for differences in refraction in the carried elevation.

Most of the current software uses the USGS values for corrections for Curvature and Refraction. Which was computed for lines of sight less than 2m above the surface.  For Mountain traverse the NGS values work better.

Curvature and Refraction

 C/R M = 13.9336286"/1000m; C/R F = 4.24697"/1000 ft. USGS VALUES (line of sight < 2m above surface)

 C/R M = 13.83067585"/1000m; C/R F = 4.219559ft /1000 ft. NGS VALUES (line of sight > 10m above surface Peak to Peak)

 

On long conventional traverses I like to take Sun Shots where ever I can. 

 

Traverse Adjustment:  Check the closing Azimuth and divide by the number of setups if more than 15” check index in the instruments and then run the Sun Shots.  Run Angle Balance and check closure. Distance error:  divide by the number of setups if the result is 35-65 mm probably a bad prism constant.  Larger than that oops.

I don’t like the SW that goes right to least squares, it will zero things up but you still have a blunder in the survey.

 

Check Prism Constant:

 

Peg Test.

 

  1. Setup 3 tripods and tribrachs in a straight line.

  2. Set Instrument on Tripod 1 and measure 1 to 3

  3. Move Instrument to Tripod 2 (center) and measure 2 to 3 and 2 to 1

  4. Add the results 2-3 + 2-1 total should equal 1-3 if the prism constant is correct.

Check if Prism constant applied to recorded in RAW distance.

 

  1. Set Instrument on tripod 1 measure to 3

  2. Change Prism Offset in instrument

  3. Measure 1 to 3

  4. Compare recorded results

  5. Return Instrument to proper offset setting.

     

 

Most modern instrument apply the corrections to the recorded data.

 

Consider GPS points to be control points.

 

The FBK files are not needed any more to get Line Work and point Descriptions. Compute with the instrument manufactures software and export as PXYZDA.csv file.

 

Jim

Matrix3DSurveys

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

 

 

 

 

Message 8 of 8
dewarp1
in reply to: dewarp1

Thanks very much, Jim and Caleb, for your time and input.


Caleb, in terms of the issue you raise with the distances, I see you've also been discussing this on another forum post and I've made some comments, especially around the survey database settings. In short, I carried out some extra trials on some data with varying prism constants and found that the SDB was correctly handling the changed values.


I understand where you're coming from, Jim. To have the best level of certainty around data accuracy, the best approach is to use the manufacturer-specific tools for processing that data. We have a few other factors that conflict, to varying degrees, with this ideal approach.


We find that the survey database, coupled with Trimble Link within Civil 3D, provides a very smooth workflow from field to CAD. This is especially the case for our more junior staff, who carry out both field work and office processing of the surveys with which they are involved. To that end, I would guess that about a third of the surveys that are processed within CAD require minor edits to the data (ie. Pole height changes, point description edits, instrument height blunders to amend).


Our field to finish workflow, which uses Trimble Link to create the FBK file, also utilises the Trimble field coding for linework and any deviation from that will require a further mindset shift to relocate the coding commands after, rather than before the point description in the field.


The survey database, contains all the observations and requires no global reimport if an error needs amending. The inclusion of another step in the process to carry out the initial processing to derive a CSV file, which would probably involve at least basic competence in a third party software package, adds another level of complexity to this process. It also removes the survey data from the drawing, and easily locks down the point locations so that they cannot be accidentally moved in an absent moment.


Of course, data integrity comes first, and to that end I continue to test and confirm that I am happy (within our accuracy standards for the particular work in question) to continue working with Trimble Link/Survey Database combination. In comparisons I've made, our data as imported into Civil 3D is 95% within 1mm of the equivalent coordinate as exported via third party software. For those odd occasions where we are chasing millimetres, I lean heavily on the third party software and avoid the SDB at all costs. The vast bulk of the work that we put through the SDB is for topographic surveys and we rarely use the SDB for cadastral work.


In terms of my initial problem to which this forum topic relates, I logged a support query with AutoDesk and they have confirmed it as an actual and repeatable issue. This has been forwarded to the development team, whom I implore to include in the next service pack!


We will continue to workaround by going into "Edit Survey Database Settings" after import and setting the "Curvature Refraction" and "Atmospheric" corrections to No.


I would be interested in seeing if there are others out there who are using Trimble Link to import FBKs into the Survey Database and how that's going. Perhaps we're the only users who don't import CSVs direct.


Thanks for your assistance folks.

Phil Dewar
Fox and Associates
Christschurch, New Zealand

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Rail Community


Autodesk Design & Make Report