Topic: Survey Figure Codes

[tcopeland]

Newbie Questions here: :whistle:

I am have been working on setting up the figure prefixes and figures for the survey toolspace.  I noticed that you have to use BEG(IN),  E(ND), CLOSE etc for some of the line work commands.  Is there a way to use different commands (ST, start; CLSRECT, close rectangle)?  Can you change the defaults that C3D has in place for some of its linework commands (BEG, END, CLOSE, CURVE etc.)?  Also can you change the order in which they are taken in to this:<figure code>BEG, <figure code>END, <figure code>CLOSE?

Also do you have to use E(ND) to actually end the linework, or can you start the line feature back up when you need to use it again.  A good example would be for a toe of inslope or backslope line, when you came to an approach you would take the last shot and then jump to the other side of the approach and then start that line up again.

Any help would be appreciated.

[sinc]

You CAN do all kinds of things.  Figuring out what is easiest, and what you SHOULD do...  Well, that's trickier.   

We do something like that, and dump a CSV file out of our data collectors.  We then use a Perl script to convert the CSV file into a FBK file, which we import into C3D.  It's got drawbacks, but it works OK.  I have it posted on our website at Edward-James Surveying.

There are some third-party apps that help make the task easier.  I'm moderately-sure Stringer (from CadApps) will handle coding like you want, and I'm almost positive that Mapworks (from Dotsoft) does.

[tcopeland]

Thanks for the tips, I have done surveying in the past so I know that there are easier ways to enter (code) shots and much easier ways to do linework.  We had used Microstation before so I am kind of in that mind set when it comes to codes and linework.  I'm looking for anyway to make it more user friendly to the surveyor.  We are used to using the alpha coding versus the numeric coding.  We may need to shift our surveying pracitices to that of the numerics.

If we do shift this over to numerics this would also mean that I will need to change out alpha figure prefixes to reflect the numeric codes, is there an easier way to do this?

[sinc]

We use numeric codes because we have old data collectors that don't have alphanumeric keypads.  We can create alphanumeric codes in C3D and dump them into our data collector, but our Trimble data collector expects us to use Notes to enter the linework commands, and the alphanumeric codes do not work in Notes.   :ugly:

In theory, you should be able to let your field guys do whatever is comfortable for them, while everything in C3D works well in C3D.  But that's in theory.  As of the 2009 version, I think you need to resort to third-party help (or custom coding like that Perl script I wrote) to really realize this in practice.  We've been complaining vociferously about this issue since the 2007 version, so hopefully Autodesk will do something soon in this regard, but Autodesk does as Autodesk does.  And of course, even once they start doing something, that first version they put out is usually all-but-unusable, so it will probably be a while before this is handled nicely by C3D out-of-the-box.

[mjfarrell]

I think that in the end you should try to adapt to the line codes and process as provided by C3D.
As SINC points out what one wants to do and what one can do are not always aligned.
Also produce a list of what you want C3D to do, and use the product feedback link http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=1109794 to let autodesk know.
Send this list to your Vendor, and then post the same thing to the feed back link twice a day every day to let them  know you really want those functions.

It may not do any good in the sort term, however that seems to be the 'only' form of critical communication autodesk will allow that will not result in one being banned from the discussion groups, or having ones comments edited, or deleted.

[tcopeland]

sinc-
I was reading your topic on your website regarding the perl strings, and I noticed that you said that there are several different places that you can purchase different applications, one of those being Carlson.  We have a seat of Carlson in house and are using a TDS Survey Pro Data collector.  I know that you can set up prefixes, feature description, attridutes etc within the data collector.  My question would be can I use the data collector to draw the line work instead of C3D?... I'm not sure if this makes sense or not but if this would work I would rather set things up in the data collector instead of using the C3D commands.

[sinc]

WARNING:  I do not have, and have never used, a Carlson data collector.

But from what I've been told, the Carlson data collectors let the field guy create all the linework in the field.  You can then dump this data into C3D, but unfortunately (again, from what I've been told), it all basically comes in as a bunch of linework and symbols all on one layer.  So, from what I've been told, people might use this feature once or twice, but then it becomes a "novelty", and they go back to generating the linework in CAD.  The linework generated in the data collector is still useful for helping the field guy stay oriented and keep track of what still needs to be shot, but other than that, it is not used.

That's just what I've been told - someone who actually uses Carlson data collectors might chime in with something else.

[sinc]

Oh, and I don't know anything about the TDS Survey Pro data collector, so I can't speak about its capabilities at all.

[tcopeland]

We use numeric codes because we have old data collectors that don't have alphanumeric keypads.  We can create alphanumeric codes in C3D and dump them into our data collector, but our Trimble data collector expects us to use Notes to enter the linework commands, and the alphanumeric codes do not work in Notes.   :ugly:

I has been a couple of year but with the Trimble Data Collector we had all of the line work codes were all entered in on the screen that recorded the shot.  The notes page was for just that notes, it usually placed a note with the shot taken.  The one big difference also was that we were using Mickeystation.  Must be another quirk with C3D?!?

[Dent Cermak]

Newbie Questions here: :whistle:

I am have been working on setting up the figure prefixes and figures for the survey toolspace.  I noticed that you have to use BEG(IN),  E(ND), CLOSE etc for some of the line work commands.  Is there a way to use different commands (ST, start; CLSRECT, close rectangle)?  Can you change the defaults that C3D has in place for some of its linework commands (BEG, END, CLOSE, CURVE etc.)?  Also can you change the order in which they are taken in to this:<figure code>BEG, <figure code>END, <figure code>CLOSE?

Also do you have to use E(ND) to actually end the linework, or can you start the line feature back up when you need to use it again.  A good example would be for a toe of inslope or backslope line, when you came to an approach you would take the last shot and then jump to the other side of the approach and then start that line up again.

Any help would be appreciated.

I think you are going into "Microstation Overkill". Why have a "closerectangle" when "close" does the same thing?  AutoCad doesn't care if it is a rectangle. Why should you? You'll be able to look at it and tell what it is, I hope. You can make this as easy or as hard as you want to. We use BEG, END, CLOSE, C3 and RECALL to cover 99.9% of what we do. All of the line work is drawn in the field to include utilities (Overhead and Underground). The key is KISS. The more you add, the more the field crews will fight the system. Use the Figure Prefix Library and the Descriptor Keys to a maximum. Keep the Descriptor Keys to a minimum number of key strokes (3 letters max if possible). DO NOT go overboard with the descriptors. A power pole is a power pole. if you must know if that pole is wood or metal, that can be noted in a journal file and NOT made part of the descriptor.
The autoline draw and descriptor key symbols in AutoCad have worked great for years. It's just a matter of understanding how they work and using them efficiently. If you get that down and have you Point Group Manager load everything into the point groups when you enter the field book file, you will be WAY ahead of the game. WORK the Point Group Manage to death! There are some good tools in AutoCad that I am told only 10% of the users utilize. That's a real shame.  Set it up right and a drawing that takes you 24 hours now can be done in under 10 hours. That's what I am seeing in our office.

[Dent Cermak]

WARNING:  I do not have, and have never used, a Carlson data collector.

But from what I've been told, the Carlson data collectors let the field guy create all the linework in the field.  You can then dump this data into C3D, but unfortunately (again, from what I've been told), it all basically comes in as a bunch of linework and symbols all on one layer.  So, from what I've been told, people might use this feature once or twice, but then it becomes a "novelty", and they go back to generating the linework in CAD.  The linework generated in the data collector is still useful for helping the field guy stay oriented and keep track of what still needs to be shot, but other than that, it is not used.

That's just what I've been told - someone who actually uses Carlson data collectors might chime in with something else.

Somebody is telling you wrong because they do not have their data collector set up right or else they are using a dxf import instead of a dwg. We use Carlson ands all lines come in on the correct layers. You set the data collector up pretty much the same way as AutoCad.

[tcopeland]

You are probably right that I'm Microstationing this to death, but this is what I was used to using and it actually WORKED.  I'm sure that you already know this, the reasoning for the CLOSE RECTANGLE would be if you could only get two or three shots on the building, you would not want to use a CLOSE command and have a line draw back to the beginning point cutting half of the building out.  I understand what you are saying that you should be able to figure it out, but why not let the software do the drawing for you.

On another note, I would like to talk about the notes.  We are having troubles with the notes appearing up in C3D.  Actually I have not been able to get them to show up.  How or what is the best way for them to show up in C3D?  I would definately like them to be on their own layer unless there is a way for it to be tagged with the shot that was taken.

[sinc]

The autoline draw and descriptor key symbols in AutoCad have worked great for years. It's just a matter of understanding how they work and using them efficiently. If you get that down and have you Point Group Manager load everything into the point groups when you enter the field book file, you will be WAY ahead of the game. WORK the Point Group Manage to death!

Are you talking about LDT?  Much of what you are saying does not make sense in C3D.

[sinc]

I has been a couple of year but with the Trimble Data Collector we had all of the line work codes were all entered in on the screen that recorded the shot.  The notes page was for just that notes, it usually placed a note with the shot taken.  The one big difference also was that we were using Mickeystation.  Must be another quirk with C3D?!?

The only way that we could find to get linework to work with the default setup in our Trimble ACU was by typing the linework commands in notes, then using Trimble Link to create an FBK file from that.

But like I said, the field guys hated the notes, so I came up with the Perl routine instead.   Now, they can include the linework commands in the point description, just like with some of the other data collectors.

But documentation on all of this seems rather terrible, so if we failed to discover some easier method, it's because it was too well-hidden and not documented well enough.  We sure tried a lot of things (and wasted a lot of time) before we found something that works relatively well.

The C3D end of things still sucks big-time.  The whole idea of creating linework during a FBK import is flawed to start with.  Field guys will make errors, especially the new guys, and we really need to be able to edit and regenerate linework in an easy and coherent manner once all the data is in C3D.  Autodesk was hooked on this idea of "all the survey data is locked down and can't be changed" for too long, though, and now we have a mess.

[tcopeland]

The C3D end of things still sucks big-time.  The whole idea of creating linework during a FBK import is flawed to start with.  Field guys will make errors, especially the new guys, and we really need to be able to edit and regenerate linework in an easy and coherent manner once all the data is in C3D.  Autodesk was hooked on this idea of "all the survey data is locked down and can't be changed" for too long, though, and now we have a mess.

That would explain why when I go into edit the fbk file and then update it nothing changes.  So I assume that I need to go into the text file and make the changes and then create the fbk file and re-import it in and things should wrok???!!!

[sinc]

Autodesk has been slowly improving the editing of Survey Figures, and from 2007 to 2008 to 2009, each year lets us do a little bit more.

But by far the fastest/easiest way to fix some linework or point coding errors is to go back to the raw data, change it there, and then reimport the FBK file.  There is an option in the import settings for resetting the network each time the FBK file is imported; we set that, so the last run is automatically deleted each time we import the FBK file.

When the field guy doesn't make any mistakes, it's pretty slick.  We dump a CSV file out of the data collector, run it through the Perl script to create the FBK, then dump the FBK into C3D, and we're basically done (except for labeling, title page stuff, details, legends, etc.).  But if the field guy really screws things up (as often happens when we get a new guy, and he goes out to do this the first time), it can take a fair bit of time to clean things up.  At the moment, though, all our guys pretty much have the process down and our current procedure is working rather well.  That's probably why we haven't tried to purchase something like Stringer or Mapworks yet.

[tcopeland]

I appreciate all of the help with this, I am hoping that we can get all of this set up correctly, or close to correct, that way we won't have to purchase any 3rd Party products.  If we can get our surveyors trained using the new coding I think we will be okay.    I needed a good laugh.

Sorry for that, I did check to see if I had the import settings changed like you had said and I did have that box checked to YES.  I might be doing something else wrong, but for right know I will go through the process of changing the info in the text file and then recreate the fbk file and reimporting it.

Us rookies have to start some where and the bottom is as good as it gets, I just want to get it close to being right the first time.  I will eventually get to your Perl script and I know that will help speed things up.

Thanks again,

[tcopeland]

Is there a software that can read a fbk file other than Autodesk for editing or viewing the fbk file?

[sinc]

FBK files are just text files.

[mjfarrell]

notepad will open and edit a FBK

Points group management is still a viable work method in C3D.
Set up the groups to assign the desired point style, and label style in the DWT, then when you insert points into the drawing they automatically populate your groups, and assume the correct styles.
Also one can place a dummy surface in the DWT as well that load the correct points groups to be used in the surface construction.  Again when the point groups are updated, the surface can then be 'rebuilt' and you surface model will be near done except for adding the figures defined as break lines in the fig prefs, and you will be near done.

The real issue with line coding as a FBK process IMO is that most firms do not have the field crew process their own data.  They then commit some small procedural errors, like not ending figures, etc and then the data MUST be edited in the office by people whom never saw the site, frankly a bad idea.  The preferred method is to have the surveyor that shot the data process the FBK, and observe the results of his collection process, within a few weeks the quality of the data will approach 100% accuracy as to the line work.  If however they do not see what happens from what they do in the field, the 'mistakes' will continue and one will begin to believe that it is a myth that line work from the field will be correct.  Trust me it can be near perfect, IF they process their own field work.

There is a valid reason the survey figures are hard to edit in C3D, we may not like, however editing the figures in cad, is nearly the same as ERASING entries in the old paper fieldbook, and we all know that one should NEVER erase in a Field Book, for legal reasons.
So you edit the FBK in C3D, and re import, or you create a new figure to replace the BAD one, just like lining out an erroneous entry in your old paper books.

[sinc]

A few comments:

We prefer to use the Description Keys to assign Point Styles, rather than Point Groups.  Then the Point Groups group things at a higher level, such as "Utilities" or "Water Points" or "Pavement" or whatever.  Too many Point Groups get annoying, so we try to keep our Point Group count down.

The idea of having the field crew process the data is good in theory, but it may not work so well in practice.  First off, not all field surveyors are particularly good with computers.  Then there is the incredible learning curve in C3D, and the fact that if the field surveyor is not using C3D on a very regular basis, he forgets how to do anything.  It is not financially worth our while to have our high-dollar field crews sitting in the office spinning their wheels with C3D.

What has proven effective for us, though, is to have the field guy sit there and watch as I import the field data.  Then he gets to see some of the issues.  Within the first few tries, our field guys are typically good enough that it only takes some minor cleanup to get the data processed.  Usually, 20 minutes is the absolute most amount of time it takes, and that's when the field guy made a LOT of mistakes.  Simply sitting there and watching the process helps the field guy understand the issues, without forcing the poor guy to suffer C3D.

And I really do not agree with erasing stuff in C3D being the same as erasing in the field book.  We regularly send drawings to others, and having lots of "bad" linework in there along with the good is usually asking for problems.  Not to mention, the most-common errors are usually things like mixed-up string numbers, such as when the field guy is collecting EOA1 and EOA2 along a road, and accidentally codes one of the EOA1 shots as an EOA2 shot.  This causes a nasty jog in the linework, but it is a very obvious error, and there is no reason to keep that bad linework in the drawing.

[mjfarrell]

I can see that your sit down sessions most likely solves most of the obvious collection blunders. No argument against that.
I've just found that many do much better with a more hands on approach.  Your method probably saves a lot of those guys some serious frustration.  However when they can and do process the data in the field prior to leaving the job, there is efficiency gained in not needing to go back to get what was missed.  I'm sure there is a trade off of cost benefit in the short term that is repaid in the long term in having them do so.

The figures are of course easily edited in the FBK file and then reimporting them cleans that up, an one would always have the original Raw data file should a legal need arise to validate the field efforts.  And I am not saying that it wouldn't be nice if there wasn't a way to 'unlock' a figure so that it could be adjusted, and then 'locking' after, much as one can lock points.  However you know I'm not too keen on 'wish list items', I'd rather focus on getting the functions that don't to work.  Or some that work poorly to work better.  So I'll keep my 'wish list' items for Santa to fulfill. 

[sinc]

Yeah, but one of our field guys still gets confused when he opens a web browser - in fact, I just had to explain to him the difference between typing something in the URL bar in the browser, and typing something in the SEARCH box at Yahoo or MSN.  He didn't realize they were two different things.

Now take that, and move it to C3D.  It's a disaster.

Another of our field guys has a real "short term memory" phenomenon.  He'll try to do something in C3D, and I'll show him how to do it, and he'll do it (slowly, but he'll get it done).  Then the next time he has to do the same task, he's completely forgotten how to do it, and I have to show him how to do it all over again.  This repeats ad naseum.  He also has a tendency to ignore warning messages.  Recently, he opened a drawing in C3D 2008, and sat there for I-don't-know-how-long before he got help, to try and figure out why nothing was working.  By the time he got help, the drawing was corrupted, and I got to spend a half-hour trying to get it working again (which I was luckily able to do).

Since it seriously only takes us 15 minutes to process field data these days, it really is not worth it to our company to try and get the field guys to use C3D.  Even if we discount all the hours of training it takes to get them so they can even do simple tasks in C3D, it's not worth it, for the amount of time it takes to process field data.  Having them sit there for 15 minutes and watch a real C3D tech process the data is far more beneficial - they see whatever problems we run into, learn the mistakes they made, learn why we ask them to do certain things certain ways, and the next time they do a field survey, it's even better.

We're now to the point where a couple of our field guys pretty much have it down.  They can go out and do a field survey, and I can process the data, and BOOM it's all done, in less than five minutes.  Usually, they don't even sit there and watch anymore, although they will look at the result and make sure it looks OK.  (Then I spend maybe anywhere between one-half to six more hours doing the labeling, title pages, notes, etc., depending on the size of the survey, but the field guy doesn't need to see me do that.)

[tcopeland]

Is there a software that can read a fbk file other than Autodesk for editing or viewing the fbk file?

I should have given more detail as to why I was wanting to use another software for editing the fbk file.  I have been trying to use the edit field book command in C3D, but the problem is that it doesn't want to update the survey when I re import the data file.  The only way that I can get the survey to come back incorrectly is to go in and edit the COPIED RAW file convert that to a fbk file and then re import the file.

I do have the check box selected that would erase the survey points, reset the network, delete network figures, insert figure objects & insert survey points.  Is there something else that I could be missing?

Update: I shut my computer down yesterday and that must have fixed the problems I had earlier.  I am able to edit the field book within C3D, re import the fbk file and it is actually drawing the line work.  Whether it is correct or not is a nother topic.