Civil 3D or ???

Our firm hasvused Land Desktop for a number of years so Civil 3D seemed like the natural next step. Long story short, our engineers on the design side of things love it & surveyors, well... don't.

We are considering a few things. going with something like Carlson on AutoCAD so our design guys are at least getting a dwg. or two, going with something like Eagle point that is basically a suite of add on tools to make C3D more surveyor user friendly.

Is it just me, or have others just about had enough of Autodesk's solution for survey?

Yes, it does seem to be inordinately unfriendly to users, and it does seem to need add-on tools to really make it a powerhouse for Surveyors.

But a fair bit also falls back on how it's used.  C3D is a pretty powerful, and flexible in a number of ways.  But it suffers from some major drawbacks in that Autodesk concentrated more on Engineer workflows than on Survey workflows.  And if you attempt to use it the way Autodesk seems to think it should be used, then it can really get frustrating.

I recently saw a webcast from one of the largest Autodesk-authorized training centers around, in which the instructor was advocating a method of importing survey data via FBK, looking at the results in the DWG, going back to the FBK and fixing any problems, re-importing the FBK, looking at the result in the DWG, going back to the FBK and fixing any problems, re-importing the FBK, repeat until thoroughly disgusted....  That sort of approach is extremely time-conuming and frustrating.  But when one of the largest authorized training centers around is advocating this as an ideal method to use C3D for Survey, that's a sign there's some severe problems.  (And for the record, NO, this is not the only way to use C3D for Survey...)

We've got 5 seats of AutoCAD that we run with the Carlson Suite.  We recently decided that we needed another seat.  We bought the Carlson suite with Intellicad.  So far the guy hasn't said anything negative about it.

thanks for the responses. I sort of want to stick with C3D because we already have it & have put a lot of time into learning & configuring templates & there is a benefit to the design folks getting a native format. But I was really dissapointed when I saw 2012 and they hadn't done anything with survey to speak of. but yes, it's the convoluted work flow that is so time consuming and tedius.

I've been wondering the same thing, thanks for bring the issue up. I'm finding that if the source data(the survey) is setup right then everything works really great but Carlson gets a lot of recommends from the surveyors I talk to. All the frustration with CAD seems to be with the post-processing and Carlson does that pretty well. Also, the draftsmen here don't do much with the 3D part. Seems like a waste to me, even if you almost need a Falcon to run a project like that.

DougW:
thanks for the responses. I sort of want to stick with C3D because we already have it & have put a lot of time into learning & configuring templates & there is a benefit to the design folks getting a native format. But I was really dissapointed when I saw 2012 and they hadn't done anything with survey to speak of. but yes, it's the convoluted work flow that is so time consuming and tedius.

Starting with 2010, we've been pretty pleased with the speed, accuracy, and consistent high quality with which we've been able to use the software.  But it took a fair bit of work to get there...  We had to develop a good template first, and the earlier releases had a lot more problems that we had to fight.  And of course, we use third-party tools, which have also been improving steadily this whole time.  We've now developed quite a reputation in our area for being able to handle just about anything, and create fast, high-quality results.  And unlike many complaints I've heard, we actually use the majority of the program, including things like Corridors (awesome calc tools), the Plan Production stuff (works great for large topos), and more.

In the process, though, I've pretty much decided the Survey Database is a waste of time, and we try to use it as little as possible.  If we didn't need a Survey Database to process F2F linework, we'd probably never create one.  Ironic, eh, how one of the features we like and use the least is one of the few that is targeted directly at Surveyors? 

Sinc... You're everywhere man! You're the man too! Glad to see you on POB.

Well, maybe not everywhere....  I avoid Twitter.  

The SDB is one of those things that probably sounded good in concept.  But the implementation has proven top-heavy.  And in retrospect, I don't think it's particularly necessary at all.  Especially not for Surveyors.  If anything, I'd say that the SDB is really an Engineer's tool (like most of C3D).  My argument goes kind of like this...

True, the SDB can perform traverse adjustments, etc.  But in our experience, C3D is too complex for most of our field surveyors to use.  We have a couple of people who do double-duty, but they're primarily in the office, working with C3D, and only go out in the field when there's a crunch out there.  We have NO regular field surveyors who use C3D.  We've discovered that, unless someone works with C3D a lot, it is impossible to remember all the basic workflows, all the tricks to Styles, all the convoluted "when you want to do this, go open this other dialog and do it over there, not here" stuff, all the "oh yeah, that's a bug in this release" stuff, and so on.  And in order to remember all that stuff, our field guys would need to spend too much time in the office working with C3D, which means they wouldn't be out pulling in their higher "field crew" billing rate, and that's not economically feasible for us as a company.  But when a traverse adjustment needs to be made, it's the field surveyor who knows what was done in the field, and what must be done in the office.  So the last thing we need or want is traverse adjustment software that is built-in to C3D.  We want software that our field surveyors can use, so the people who know what's going on can do the adjustment.

So we don't use the SDB for traverse adjustments, AT ALL.  That means we ignore a whole huge chunk of its functionality.  But it also means we don't need to worry our office staff about details like the Equipment Database.  It makes our lives SO much easier.  But that means we really only create an SDB in order to process field data.  And as many of us have discovered, trying to get all the data into the SDB as intact Survey Figures is incredibly difficult and time-consuming.  Instead, it's much easier for us to use the SDB to get the figures in initially, then perform edits from there graphically, in the drawing.  When we do this, we don't particularly care about making sure every edit we is reflected in the Survey Figures in the SDB.  In many cases, we might simply draw a 3D polyline and add it as a new breakline to the Surface.  By the end, we may have performed many edits in the DWG, and the DWG is right, even though the SDB may not be.

But typically, we don't care that there may be breaklines in the drawing that have no corresponding figure in the SDB, etc.  We'll never use those networks again, and the only further use we might make of the SDB is to create a new Import Event, to pull in more data, should the field surveyor make another site visit.  But that's not a problem.  And usually, our drawing is complete at this point.  As a Survey-only company, we typically ship our surveys off to "others".  Most of the time, "the others" aren't using C3D, and wouldn't want our SDB if they even knew what it was.  And even when delivering files to someone who uses C3D, we've NEVER delivered our SDB.  All we ever give them is the DWG file, complete with a fully-built Surface, active Cogo Points in Point Groups, and all the rest  (in other words, our REAL C3D drawing, and not an "Export to Autocad").  This gives them all the data they need or want, complete with tons of documentation built-in to our Styles.  And because of the way everything is setup with our Point Styles and Description Keys, everything in the drawing as a clear automatic label, it's very obvious what everything is, and so on.

The only people I've ever really seen who want the Survey Figures intact in the SDB are Engineers, and only in shops where the Engineering and Surveying are all done in-house.  Basically, the Engineers in firms like this seem to like to be able to pull Survey data into any newly-created DWG file.  So essentially, the SDB has become a way for Engineers to manage Survey data.  It doesn't particularly help Surveyors at all.  In fact, it's so difficult to work with, it actually HINDERS the Surveyors.  Thus my point that the SDB is really an Engineer's tool.

And I have to wonder if it really gives any value to the Engineers.  Like I said, even when delivering data to other people using C3D, we've NEVER given them our SDB, and nobody's ever requested it.  And the DWG itself can be used to manage the Survey data, by only creating design data in new drawings that reference the Survey DWG(s).  So I seriously question the entire value of the SDB.  ESPECIALLY considering all the headaches involved with it.

At the EBCI we tried Civil 3D and spent a bunch of money to learn to use it, but ended up frustrated at every turn. At 6K+ per seat and maintenance equally ridiculous, we switched to Carlson Civil Suite on Intellicad and are pleased with decision.

Another issue: Autodesk's Civil Business is only about 3% of it's revenue from what I have been told and they do seem to be paying less attention to teh Civil World as well. There is a real danger they will be out of the Civil/Survey business in the near term. Carlson is already beating Autodesk like a drum and can win in head to head competitions if they are stacked. Carlson won the cometition at Dewberry handily as Autodesk was unable to compete on anything like a level playing field. It wasn't even close.

Full disclosure: My department does mostly roadway design, Utilities and Land Surveying in support of the first two. We have gotten more work through Carlson in one year than we were able to get through Civil 3D in 3 years.

We've definitely had issues getting people files they can use.  But we have fewer issues now.

Part of that is because we figured out some ways to setup our C3D Styles so they convert well to other CAD products, via Export to Autocad.  Not ideally - C3D labels get their background masks turned into solid hatches (extremely annoying), items get properties set ByObject, even when the Style is set to ByLayer (also quite annoying), and sundry other issues.  But for the most part, things go well.  However, we designed our template in a verys specific way in order to do this: we use our Point Styles and Layers in very specific ways, we essentially only use one Survey Figure Style that has everything set to ByLayer, Surfaces Styles are set to display contours AND TIN Triangles prior to "Export to AutoCAD 2007", and various other decisions.

We've also gotten in the habit of delivering a "standard package" consisting of:

• Our complete C3D DWG (with all C3D elements intact, and nothing exploded), and a note as to C3D version.
• An Export to Autocad 2007 DWG format.  We also often explode Cogo Points prior to doing this (to fix yet another bug, of course...).
• A LandXML v1.1 export of the Surface (we use v1.1 so that people with Land Desktop and other old releases of software are more likely to be able to use it).
• A CSV dump of the Cogo Points, using Full Description for the dump (this replaces some of our Point Codes with more-understandable "long" descriptions).
• A PDF and a DWF of the final prints.

Sometimes, I have also delivered a DWF made of model space, which the engineer could attach as a DWF underlay.

We also tend to hang back a year - we are just now moving from 2010 to 2011 - so we are less likely to deliver a C3D drawing to people who are using an older version of C3D.

And finally, the most important part:  We've gotten more pro-active in our follow-up with clients.  We make sure to let them know that we have other options for getting them data, so let us know if something is giving them fits.  Depending on what software "the others" are using, and how skillful they are at using it, we've found different things give different people the best results.  Most people can deal with the "standard package" I mentioned above, but not always...  Sometimes, I can use different export options or methods, and give them something they find much more usable.

As for traverse adjustments...   The field guys typically do traverse adjustments either in their data collectors, or in TGO.  At this point, I couldn't imagine using LDD for ANYTHING, and it's been a very long time since I've even tried to use it (probably two years or more).  For the most part, our field guys do not use C3D (they don't use C3D often enough to keep a sufficient skill level to use C3D), yet our field guys are the ones who generally need to do the traverse adjustments (when they are necessary), so we aren't interested in any sort of traverse adjustment that takes place inside of C3D.  We would have no interest in using the C3D Survey Database for traverse adjustments, even if the functionality were dramatically improved to be on par with Star*Net.

But in reality, we rarely need to do traverse adjustments.  We have pretty accurate instruments, and traverses often close to within 0.02'...  For a construction project, there's no need to adjust the traverse when it closes that close.  It's a waste of time.  Or we use GPS to come up with our control.  Or we're just doing construction, and there are already project control points set with published coordinates...  In those cases, we use the published coordinates.  So when we get right down to it, there aren't a whole lot of jobs that we need to do traverse adjustments on.  Someone with different kinds of typical projects might need to do them more, but I'd probably be surprised if we performed traverse adjustments on more than 10% of our jobs.

As for the complexity, I feel your pain.  C3D is also rather unfriendly to Surveyors, as it comes out of the box.  But C3D also happens to be far more customizable than any of its competitors.  When we first started using it, there were lots of basic tasks we wanted to do, and there were no tools to do them.  But I'm actually more-skilled as a software engineer than I am as a surveyor, and C3D had this extensive API, so I was able to create all kinds of tools that we needed on a regular basis.  Now we can do all kinds of things very quickly.  For a while, I was giving away the routines I created, but I started spending so much time on it (40+ hours per week) that I could no longer give it all away for free.  That's when I created Quux Software and started offering the Sincpac-C3D.  I didn't set out to create software, I only set out to get work done.

So the third-party tools help a lot.  We also suffered a lot of pain during our transition at EJ Surveying, and we constantly rail at Autodesk about all the bugs, the tendency to need three releases to get a feature working, the obscure and non-intuitive workflows, the yearly incompatible releases, etc.  But at the same time, we turn out far more work than could have ever dreamed of doing with LDD.  And due to things like the dynamic labeling, the Styles (which encapsulate Standards), the intelligent objects, and so on, our consistency and quality levels have gone up, while error rates have gone down.  It's difficult getting there, I know.  The software itself sure doesn't make it easy.  And it's difficult to find good training...  I've seen a lot of the biggest out there give what I would call very poor training.  But C3D is very possibly the most powerful option out there right now, and it can really do some amazing stuff, if you can tame it.

One of the greatest potentials of C3D is that it has all of these problems right now, yet we can do such insane amounts of high quality work with it.  And each year, Autodesk gets rid of more and more of the problems.  And most of the remaining problems are also fixable, so there's an awful lot of potential here.  Right now, we probably spend over half of our time on less than 10% of our tasks.  As the existing problems get fixed (and the third-party support gets better), more and more of those time-consuming issues go away.  If most of those problems can be eliminated, then we'll really be able to do incredible amounts with very few people in very short timeframes.  The hard part is keeping Autodesk focused on fixing those issues...  They have a really annoying tendency to chase after their next fancy feature before the current fancy feature is fully working.

Sinc, thanks for all your time. You've done a terrific job of summing up my frustrations with Autodesk's problems in general. I can see how you can make the product into a powerful tool. Unfortunately I think I could speak for most of our surveyors in describing them as surveyors and not software engineers, which is what we would expect. They know what they want & it's not there. But your descriptions, suggestions & information has been extremely helpful for what I'm trying to decipher, thanks again. I plan to meet with surveyors and present several options including sincpac. We have to do something different. I’m sure there is room for improvement in my template but from your description of what you’ve done, I think I’ve come up with a relatively decent template that is working as well as can be expected but we obviously lack any 3rd party tools at this point so we’re working with gaps in our workflow where we’re just trying to patch things together with work arounds.  

Present to surveyors also: