Survey Linework Sequencing

[bburnworth]

Hey,

I'm working with a survey database and the survey points and figures associated with it.

I have a centerline that was surveyed in segments, and the points numbers might jump by 1 or 200 between different segments. I want to edit the points themselves so that the 'Process linework' function draws the line correctly. I can edit the figure itself and move the points around, however I would prefer to edit the points in the survey database.

Should I offset the point numbers in question and then renumber them appropriately for the linework to process correctly? I have attempted simply renaming the point description, such as CL30 B and down to CL30 E. While this creates the CL30 figure, it also creates long straight lines between sections because the middle section was surveyed last, with the two outer sections having been surveyed earlier.

Therefore, I am thinking that the easiest thing is to simply create new numbers in the order that I want the points to be processed. Looking for more experienced opinions though.

- Barrett

[rl_jackson]

There is really no easy way or right way if the field data wasn't collected correctly.

Sounds like you have a situation were the data may be going in multiple directions or out of order, instead of a continuous situation. There is really no right way to fix this. But editing the ascii file may be your best solution, as you can import the data view it on screen and renumber the data accordingly.

[bburnworth]

I have read other posts (you, Sinc, etc...) with different workflows and opinions on using the survey database. This is our first project using it and the line codes, but it is rather large (554 figure lines, 3k+ points) and the generated linework has saved hours. Thus, I do like using the survey processing functionality. I've seen where someone recommends importing the points from the ascii (not from the survey database points) and only using the survey database to generate linework. Is that what you are proposing?

Would my workflow be something similar:

Import Points from File (ImportPoints)

Edit the points (edit in notepad or in autocad?)

Import edited points into the survey database

Process Linework and add figures to drawing

(repeat as necessary)

Thanks for any input.

[rl_jackson · Accepted solution]

Generally my workflow is to import the points into the database, then make the edits necessary first in the asccii file itself. Once I have just about everything done in the ascii file, which I import and test often. I'll make the additional edits necessary using the survey figure properties.

One option you might have with your centerline, is to let it begin and end often within the ascii file (as the field crew shot it from each setup), then use the SDB figure properties to reverse and join things together. This would eliminate the need of renumbering things, as the edits would not care, and you end result would be a continuous figure.

On a side note it is a lot easier to train the crew to collect the data in a chaining fashion so that you don't have to do this. Initially it difficult but once they start doing it and even watch what is happen when you import the data it will really make things run like a well oiled machine.

[_Hathaway]

As long as the points were sequential it shouldn't matter how many gaps you have. If you have pnt 101 which is a CL and then shoot 15 other points before you get to your next CL point, point 116 your linework will connect up just fine. If they are out of sequence, lets say you need to connect point 116 with point 120 and then point 117 you will have to either: Edit the figure in Civil3d (that is what we do) or renumber the points in your input file and reimport.

Your method described above would work. We always always use the survey database, there is much more security over your data when using the database.

[bburnworth]

I like this workflow. It makes sense and it works well. I have to process by point number or else there are weird line processing errors.

Our surveyors are really good with the linework. But I suppose sometimes things flow better in the field certain ways that might not jive with the codework.

Thanks for your solution.

[bburnworth · Accepted solution]

RL,

Will you please humor me once more and give me your thoughts on this workflow. I used your method, but modified it to this current workflow, which I think is much faster. Please point out any possible problems or complications I might not realize.

1) Import "Original" CSV to Survey Database & "Process Linework"

2) Edit survey point descriptions in the "Survey Point Properties" (this diverts from working in the ascii file)

3) "Process Linework" as necessary (much like you re-importing the ascii to test updated point descriptions)

4) When finished, generate a new "Edited" CSV by: Prospector > Points > Export (Points here will be updated with your edits)

5) Back to Survey Database: Remove "Original" CSV import event and associated data. Import "Edited" CSV & process linework.

6) End with 2 .CSV files: Original and Edited. Original should be archived.

To me, this has the exact same end result as modifying the ascii file through excel or notepad. It removes the tedious process of switching windows and finding the point number, and possibly removes error of accidently deleting something in the original file.

Again, thanks for your input earlier, it has brought me to this point. I figured I would share that workflow since it seems to improve upon your method.

Regards,

Barrett

[jmayo-EE]

Did you try toggling the Process Linework Sequence?

[rl_jackson]

It's really just a matter of choice. I find it much easier to edit the ascii. With it open, and going throught the list finding stray or errant lines and fixing the code as I move to the various locations in the drawing. I generally don't worry about having the additional ascii, since the raw data from the collector is what really holds as far as an electronic file for achieve purposes is concerned. In general in the SDB is harder to edit descriptions and the like and gets somewhat flakey and annoying sometimes. Whereas having the ascii on one screen and the drawing on the other I can just run down the list fixing things as necessary. Some of this is just from doing it for so long, I have been coding linework since 1997 with fbk and now ascii, so the edit method I use is just my solution, to an age old problem. I also prefer to have the final ascii as far as I can go with linework, and then make any edits or joins (when things get flip around in the field) in the SDB in the end.