survey linework field codes

[perry]

When doing linework in the field during survey our crews awlays had used JUST the BEG code to begin a new line segment.  In LDD this would break an existing figure line or "END" it and begin a new one.  I've just finished our figures, descriptions, points styles etc. and when I bring in a field book (converted from the SDR alpha RAW format to FBK) the figure linework will not break at the new BEG command.  You can definietely see the BEG in the fieldbook, but C3D (we use 2011) doesn't seem to want to recognise that code and so continues the line - makes for a very confusing survey.

We don't use codes in the desciption or notes section of the point. Our crews keep things simple by running with only EP or EPL, EPR, etc.  EP's usually work, but its the NP (entrance paved) that really gets things mixed up as they can do all entrance (say in urban area) on once side of the street at a time.  They don't do the END code as the BEG always used to work.  Doing separate codes (ie NP1, NP2) for each entrance may not be practical as it could tend to get confusing.

I had a look at the C3D settings and I had the PROCESS LINEWORK set to ON.  Is there somewhere else I can find some settings that may prevent this from happening, or do we have to rethink the way the survey crews do the coding.  I'd prefer not to import using the notes field as 99.9% of the time we convert the raw SBK to FBK format and let the software process it that way.

Thanks

[Sinc]

I can't really identify your issue...  I think I understand what you are saying, I just don't see the same thing.  For example, in the attached image, the B in shot 10013 starts a new EOA1 figure.

Part of the issue may be that there are actually now TWO separate linework coding systems built into C3D, and the Help is very vague on this point.  There's the old FBK linework, controlled by Notes in the FBK file, and there's this new system introduced in C3D2010, controlled by linework codes in the point desriptions.  The FBK system uses the Survey Command Language, with linework commands like BEG, C3, CLOSE, CLOSE BLD,  etc.  The new C3D2010 system uses the Linework Code Sets from the Survey Tab, which include commands like B, BC, EC, OC, CLS, etc.

So I suppose the big question is "Which system are you using?"  I think with the old FBK system, we needed to have an END command in there.  But with the old system, we were using linework codes in the point descriptions, and the field guys would just dump out CSV files.  Then we had a pre-processor that converted the CSV files into FBK files, and the pre-processor took care of things like adding required END or CONT commands automatically.

The image above is using the new C3D2010 linework system, and it seems to handle things similarly, where a B linework command forces a new figure.

The annoying thiing that I'm running into is that, with our old system, a linework code would not be connected UNLESS it contained a string identifier.  So in our old system, the EOC commands in the above image would NOT have linework connecting them.  We would only get linework if there was a string identifier, like for EOC1 (where the 1 is the string identifier).  Now, it appears that C3D automatically connects ANY points that use linework codes, regardless of whether or not they are in a string.  That's quite annoying...

[n2itive]

Try re-importing your fieldbook with the "PROCESS LINEWORK" set to OFF. As sinc was saying - the process linework command is more related to the new linework code set. I have a feeling that if you do this and import the points as you normally would you'll see the results you want.

[perry]

I have played a bit with the settings, and have noted that with that setting to off it won't do the crazy linework.  When it was ON there were actually 2 sets of lines - one that looked correct and the other continuous line on top.

Another question though, I have the figure prefixes set for some point codes (like EP, etc) to be breaklines.  Will turning off the PROCESS LINEWORK setting not affect that?  Will we now have to manually define what is a breakline?

Thanks again.

[Sinc]

No, you should be OK there.

The really confusing thing is that there are now TWO different ways that create linework, and that "Process linework during import" only applies to the NEW way.

If you import a FBK file that has Survey Commands like BEG and C3 as "Notes" in the FBK file (e.g. linework commands on separate lines from the shots), then those commands get processed, regardless of the setting for "Process linework during import".

That "Process linework during import" option turns on the new coding system, which uses the Point Descriptions instead of the old "Notes".  And it will automatically begin figures, even if you don't have a B command in there.  That's why you end up with two sets of linework...  One is coming from the Survey Commands in the "Notes" in your FBK file, and the other is coming from the "new" system that is only looking at the Point Descriptions.

It's horribly confusing, I know, especially since there's no mention of any of this in the Help....

[Sinc]

And to clarify one final point, if you have the old-style Survey Commands as "Notes" in your FBK file, those will ALWAYS be processed when you import a FBK file.  There is no option for disabling it.  So if you have all your linework codes as "Notes" in your FBK file, you'll want to use the "old system", and leave that option for "Process linework during import" turned off, so you don't get duplicates of the linework generated by the "new system".

To use the new system, you must have all your linework codes in the Point Descriptions, instead of the old "Notes".

Overall, I'd say the new system works better, so for future surveys, you may want to change your standard operating procedures to use the new system.  But that probably means your field guys will have to change the way they do some things during the data collection phase.

[perry]

Thanks Sinc for the answers/clarifications. Hopefully I can get back into this in a couple days to sort this out.

As to your comment "But that probably means your field guys will have to change the way they do some things during the data collection phase." I would LOVE for that to happen, but last week when I mentioned to the crews that they might have to alter their procedures a little all I got was - "You mean we will have to do even MORE thinking out in the field" and "Then why are you bothering updating from LDD to C3D?"

Ah well.

[peterfunkautodesk]

You should sit down with the crews and look at the new system. While it is different than LDD and the FBK file, it should require less coding and field shots to get the same results.

Regards,

Peter Funk

Autodesk, Inc.

[Sinc]

Tell them they won't have to do MORE thinking, it will just require them to enter the codes in a slightly different way.

And the big selling point for our guys...  With the "new" linework coding system introduced in C3D 2010, they can collect multiple curves simultaneously, and all they have to use are the "BC" (Begin Curve) and "EC" (End Curve) commands...  No more needing to collect one curve at a time, as is necessary with the MCS/MCE commands in the "old" system.  And better yet, no more obnoxious C3 command!  The OC (On Curve) command is also handy for getting those short curb returns, noses of islands, etc.

[perry]

I understand that yes it would/will be much more efficient to use the new coding, its just a matter to find some examples and help files where we can work from instead of reinventing the wheel.  The help files are rather sparse in this regard.  Any links you might be able to list would be very much appreciated.

[_Hathaway]

We experienced the very same thing when updating from LDD to 3D 2010.  We did jump right in and change the way we code in the field to utilize the 'new' process linework command.  Essentially that got rid of all the BEG or B on our linework codes.  The issue we ran into was that we would end up with ALOT of one particular code, say EA for instance.  On a recent project we were up to EA85.  Since there doesn't seem to be a way to have multiple lines for the same code you just have to keep on increasing the # after the code.  This has gotten a little troublesome but not too bad.

In the end, its really nice though.  It makes any edits back in the office really easy since all we have to do is modify the csv or txt file and reimport.  All in all we find the new method better, just requires a little more effort in the field.

[Sinc]

---

@_Hathaway wrote:

The issue we ran into was that we would end up with ALOT of one particular code, say EA for instance.  On a recent project we were up to EA85.  Since there doesn't seem to be a way to have multiple lines for the same code you just have to keep on increasing the # after the code.  This has gotten a little troublesome but not too bad.

---

So are you not getting results as in the following?  Note how the "B" in shots 1008 and 1009 start new figures.  End result is four figures, two named EOA1 and two named EOA2.

[_Hathaway]

Hmm...with our current method there are no line codes at all, none. Just import the csv file and voila' instant linework. 

Are you saying we can implement codes such as the ones in your example and still import just .csv files? 

[Sinc]

Oh yes, and more...

For example, add in the the BC (Begin Curve) and EC (End Curve) commands, and you can collect figures like this:

The curves look nicer than when the shots are connected with just straight line segments.

[TWGDA]

While on this subject when using TDS software in the data collecter:

I know the “new” way of entering codes into the description field of  Civil 3D can do this:

TC1 B SW1 B

TC1 = TOP OF CURB 1

SW1 = SIDEWALK 1

Is this possible (double coding)  with the old method where the field code goes in the description field and the BEGIN code goes in the note field of the TDS RAW/RW5 format file?

Thanks, David

[_Hathaway]

Yes with Civil3d you can run multiple codes such as EC1 SW1 OP1 EG1 all in one code and if applicable the linework will connect.

[TWGDA]

But if you use start and stop codes you can not put them in the notes of a TDS RAW file but must put them in the decription field--correct?

You must do this instead: EC1 B SW1 B OP1 B EG1 E ---oops more than 16 characters

must be instead EC1 B SW1 B OP1 (15 characters-the B EG1 E will not fit)

[IanMcClain]

You may have already discovered this, but to answer your question: No, the old style raw note coding does not support multiple lines at once. And yes TDS SurveyPro (now spectra) has a 16 character limit, unfortunately. I usually put my overflow coding into a raw data note and then copy paste it into the description after I make a .fbk file.

The new coding method is also compatible with .txt, .csv, etc. files. It works off of descriptions only so the format is irrelevant. Which is good because .fbk hasn't been updated in a long time, it doesn't work well with RTK data.

[Sinc]

I'm curious as to why you'd eve want to use the Notes...?

We always found that as much more convoluted, and were very happy to get rid of them.  In fact, I even wrote a routine that let our field guys code everytihing in the description fields, back in C3D 2008, a couple of years before Autodesk finally gave us the capability in C3D 2010.

[TWGDA]

I don't want to use notes.  However, some of our field crews were so set in their ways they wanted to keep using Notes.  I told them they could not and use the new coding method.  They did not believe me and hence the question so they could hear the answer from someone else.

David