edit multiple survey points in database

[petrocat]

Our survey department is running Carlson, while the Civil side is running Civil 3D 2012. We used to insert the point files from the text files from the survey dept. I've tried getting a .fbk file from the raw Carlson data with limited success, but that is beside the point.

The Civil side is moving toward using the Survey Database instead of just point files because of the processed linework and converting them to breaklines in our surfaces (just cuts down on CAD time by tons). I have found a few drawback to this decision that frequently cause headaches in what should be so easy. A few examples of when the survey database limits my production and why I can't get the survey department to give up Carlson:

1. For some reason 10 points out of hundred come in with "broken rods" or point that are about 3 feet higher or lower than what the should be. What I'd like to be able to do is select those points, and click "datum" to lower or raise them in the survey database. But no, in order to fix those points I have to do it one at at rime or unlock the points in the drawing, separating them from the database and ruining my chance at quick processed linework, and then datum them as a group. Why can't I select and datum multiple points in the survey database?

2. For some reason the fences on both sides are coded the same instead of fn1 and fn2, so the survey figures created with the processed linework criss cross the road which takes a lot of time to fix. What I'd like to do is select those points and edit the survey point properties of all of them in the edit window all at the same time. But no, I have to do it one at a time, or may a survey point group in the database (yeah like that's easy), or unlock them in the drawing, or any number of extremely long workarounds. Why can't this be simpler?

3. I make changes to a survey point's properties to fix a miss-key in the field, and the pop-up is to reprocess all the linework in the database, not just that in the applicable import event. I can always choose cancel and reprocess the import event I want, but I wish I could just reprocess that figure alone or have more options provided.

If Im doing some thing wrong, feel free to chastise. I guess I should post these in the wish list forum.

mark

C3D 2012

win 7

[jasoncoghlan2246]

If you were to go to www.stringersurvey.com.au, we can do all of that and more by bypassing the survey database using points and polylines. 

We can also process th raw Carlson file straight into civil3d as normal civil3d points and have it strung and added as individual breaklines to the surface automatically therefore making editing of breaklines easier and faster.

We have refresh all codes which will compare fieild codes used to that of the description key set (DKS) and tell you which ones aren't in the DKS and need to be fixed.

Also we have a function that will re-order points of the same code based on the shortest distance to the next point.

Edit point command will change a point coded wrong in the field and if a string number is added it will automatically string to that string automatically.

Have a look at the video's on these links and see what you think

http://civilsurveysolutions.com.au/resources/videos/102-survey-reducing-field-survey-data-using-stri... 

http://civilsurveysolutions.com.au/resources/videos/122-survey-editing-breaklines-and-the-surface-us...

[Sinc]

The biggest thing about your post that makes me shudder is that you're doing the Surveyor's work, and you shouldn't be.

The Surveyor should be giving you a fully-built Surface.  You should not be attempting to do this yourself.  There are many problems...  The Field Surveyor is the one who knows any "weirdness" that happened in the data collection, and is the only one capable of fixing "problem shots".  Field conditions regularly interfere with data collection, interfering with the automatic linework creation.  And when linework codes are not used, there are often multiple ways to "connect the dots", and without actually seeing the work site, you can create problems by connecting them incorrectly.  Then, if there is a problem or "missed area" that requires another visit to the field, the Field Surveyor is the only one capable of doing this.  If the Surveyors don't fully process the data they collect, there's no way they can identify and fix any problems.  And as a final bit of QC, the Field Surveyor should also visually examine the resulting Surface, and make sure it all looks right.

So really, your Surveyors are the ones that should be processing all the field data, and building fully-complete Surfaces.  They can actually do this all in Carlson if they don't want to use C3D, then you can just use the info they give you in C3D, without reprocessing the data or trying to use FBK files or anything like that.  As the Engineer, you shouldn't be in the position of processing field data and creating an EG Surface.  It's not part of your baliwick.  And if your Surveyors are responsible for processing their own data, you can bet they'll very quickly stop making mistakes like those miscoded fences, since they'll be the ones who have to clean up the mess.

At least, that's my very strong recommendation, based on my experience.

[jasoncoghlan2246]

Fully Agree with you there Sinc

[petrocat]

While not a solution to the op, I agree in part with what you have said, Sinc. It would be ideal to have the survey dept provide me with a existing topographic file to work with, and I'll be the first to admit that what they provide us is less than what I feel is the quality of work our company should produce (unfortunately, I don't make the call on that... yet). But with them using Carlson, there are some issues I have, which is why I'm trying to push for them to move to Civil 3D; Carlson can give line work but not a usable surface (unless it is XML), their points are not the same, and I will never accept a file "as is" without doing some kind of inspection of it to verify what I've been given (which is easier to do if it was all Civil3D) and even then I have missed some things that come back to bite me, hence the original post.

Don't get me wrong, I have made multiple effort to push for improvement on both sides, but again, I'm really not in that sort of position yet. I think that I'll use your post as some means of communicating what I feel is a breakdown in our company workflow. We're a small firm, but that only means your post apply so much more.

Thanks.

P.S. I still think Autodesk should address the issues I raised to make the transition from Carlson and other survey software easier.

[_Hathaway]

I agree with Sinc 100%.  Surveyors need to process survey data, period.

To answer your question:  You have to make edit to your data before it's brought in through the survey database.  You can no longer make changes to the points for datum shifts and such after the fact.  The data needs to be corrected before importing.  We used to do the other way around too, but in the end it's always better to adjust the raw data then the resulting data.

[Cadguru42]

I agree with the OP that editing stuff in the survey database is extremely annoying and flat out non-intuitive.  Autodesk thinks of the surveying side as the red-headed step-child, so they add what they think is nice and then forget about it.  I don't think any of the survey designers of the software have even used it in a production environment.  Your second question regarding the fence codes sounds like a miss-code in the field.  Are they not coding them FN1 and FN2 or are they just coding them FN?  Are they putting a space between the FN and the 1?  I too have the same problem with editing points.  It's a pain to scroll down, find the point you want to edit, edit it, save the changes, and then have to rescroll back through all the points after the first change.  Why can't the survey point list in the survey tab just stay on the selected row?

I also completely agree with what Sinc posted.  However, I'm in the same boat as the OP.  Our surveyors are just not willing to do all the work that they're supposed to be doing.   I work for a local government and our division is pretty small.  Four surveyors, three engineers and me as a designer and "CAD manager" (without the pay, I might add).  They go into the field, collect the points, download the points into the survey database, and then they're done.  They do not do any quality checks on the automatic linework nor do they even bother to add missing linework into the database.  I'm the one fixing all their miss-coded points, fixing the figures, and I'm the one making the existing ground surface.

Starting this week my boss has actually started using Civil 3D for more than a drafting board and he's seeing all the pain I've been explaining for the past few years regarding our process and how the surveyors need to do their job.

[mathewkol]

I agree with Sinc in that the surveyor "should" be doing these things.  Obviously, sometimes they don't.  But think about it this way, say the OP was the surveyor and now has to make the same changes, but he's using C3D and not Carlson.  He's in the same boat.  Some editing requirements can be difficult in C3D.

[Sinc]

---

@engrtech wrote:

I agree with the OP that editing stuff in the survey database is extremely annoying and flat out non-intuitive.  Autodesk thinks of the surveying side as the red-headed step-child, so they add what they think is nice and then forget about it.  I don't think any of the survey designers of the software have even used it in a production environment.

---

I agree with all that whole-heartedly.  In fact, over our years of using C3D, we've started to ignore the Survey DB as much as possible.  We'll create a SDB and use it to initially process linework and add the breaklines to a Surface, but then we ignore it from there on.  In our experience, the SDB is more of a hindrance to Surveyors, and its only real value is as a "Survey Data Management Center" for Engineers.  So even this feature that is ostensibly geared toward Surveyors is really an Engineering tool.  And it's actually an unnecessary one - it's arguable that the SDB really provides any real benefit as a "Survey Data Management Center" over using DWG files to manage Survey Data.

I've seen webcasts and videos that recommend using the SDB, making sure all the data in it is correct, etc.  This usually involves importing the survey data, looking around for problems, going back to the source file and fixing issues in a text editor, reimport the survey data, look around for problems, go back to the source file and fix issues in a text editor, repeat until thoroughly disgusted.  Then there's the painful process of making sure any further edits or new figures (from field shots that had no linework coding) end up in the SDB.  Then there's painful things like buildings, which the Field Guy often shoots in pieces from multiple setups, and are not combined coherently using Figure Commands...  It ends up being a giant time sink.

So what we do instead is pull in all the survey data using the SDB (so we get linework), look around for gross problems, and maybe fix some of the "big stuff" in the source data, and reimport the survey data.  But as soon as possible, we abandon the SDB.  From that point on, we work ONLY in the DWG.  Survey Figures (at least in C3D 2010 and later) are relatively easy to edit, as long as you have them at elevation, so you don't hit the "OSNAPs don't work on the ends of flattened Survey Figures" bug.  We often use the Sincpac-C3D BRKPT command (available in the Free Edition, no purchase or activation code required) to connect unconnected shots, since it automatically adds the breaklines to the Surface as they are created.  Utility Lines and Fence Lines we have coded so they are NOT breaklines in the Figure Prefix Library, so we often just explode all of them and turn them into 2D polylines with linetype generation enabled.

When we're done, we have a beautiful DWG file with all our Survey Data in it.  This is the file we then send on to the Engineers, and it's what they use for their designs.  I've noticed I seem to take about half as long to process a survey using this approach, vs. trying to use the SDB.  And it also gives us a much better deliverable...  As a Survey-only firm, we send our data to other firms.  And while we now have several clients using Civil 3D, we have yet to have anyone be interested in our SDB.  All they want is the DWG file.  Even if we had in-house Engineers, I would still highly question the value of the SDB.  All Survey data can be managed using DWG files.  In fact, that seems to work much better than what I see others doing, where everything is in the SDB, and the Engineers will create a new drawing, import all the Survey Data from the SDB into the new drawing, and then use that to start their design.

There are some drawbacks.  Starting with C3D 2010, we no longer have to use FBK files, which is great.  And it's even possible to use all drawing points that are already in your drawing, so if you need to rotate/move some Cogo Points into your coordinate system, or do something like fix a blown HR on points 11000-11024, that's easy.  You don't have to "unlock" points in the SDB, or try to edit data non-graphically in the SDB.  But unfortunately, when using the "Import Survey Data" wizard to process cogo points that are already in the DWG, the Import Event doesn't remember which Cogo Points were used as the source.  So you have to use "manual management", such as putting Cogo Points in a Point Group with the same name as the Import Event, so you can remember which points go with which Import Event.  Also, by giving up FBK files, we loose the tie between data in our drawing and the raw field observations.  So if something looks wrong, we have to go back to the raw data to identify things like the amount of a blown HR.  But in practice, we rarely need to trace errors back to the raw data, so we get a lot more value out of working quickly than out of working with the SDB.

It can all work, if in a rather non-intuitive way.  Now that we've gotten a good handle on which parts of C3D to ignore, we've gotten quite fast at processing field data.  And we've been creating pretty high-quality products, with extremely reliable TINs, high quality control, and a high level of consistency in our deliverable.  And we've also used C3D long enough that we've gotten good at that nasty "other headache", that of now sharing our C3D DWG file with people who aren't using C3D.  The majority of our clients are not using C3D at this point, mostly using either Land Desktop or Microstation (mostly Land Desktop).  (Kind of funny how we Surveyors started using C3D in 2006, yet we're usually creating files for Engineers that are still on Land Desktop...)