Revisiting Thoughts on Vault in the Civil Workflow

I mentioned yesterday that I’ve been spending time with our data management team. Part of what we are doing is taking another look at how data moves through a Civil Engineering project.

We’ve been talking about the reports, analysis, plotted sets, excel files, images, correspondence, transmittals, and other glorious bits and pieces that go along with the “real work”. We’ve also been digging into the mechanics of how the “real work” is shared.

Back in Civil 3D 2006, we were faced for the first time with rethinking how we shared data with data shortcuts. When Civil 3D 2007 came along, it brought with it the possibility of using Vault (who can forget the landmark post in July 2006 from James “Why is Vault Better?”).

At that point, we really had to think about how we worked. How we split our projects. If we were going to move forward with model based design, it was going to require more than just a new box of software.

In those early days we didn’t know what we wanted yet. We started with a modified LDT or CAD style workflow- a mix of XREFs, minor data sharing, and tentative breaks from the normal process.

This is an excerpt from an article I wrote in 2008:

Here is how it worked: we’d do most, if not all, of our modeling in one master base plan. We’d set up our styles to match our current forms of layer control and label in this model drawing. Then, we’d XREF this model into sheet drawings, where we would cut viewports and create layouts. While some people can get out of control with layouts, most people keep it around 5-10 layouts per drawing, with drawings broken up into “families” (all of the sanitary sheets in one, all of the grading sheets in another, etc.)

Sometimes it worked. Sometimes it didn’t. Sometimes it was the software, and we learned how to deal with that. But if we are really honest with ourselves, sometimes the problem was between the seat and the keyboard. If we wanted to dig into the real power of the Civil 3D model, we probably had to do more than just swap XREFs for DREFs. We needed to look deeper and change the way we think and the way our teams interact.

I came up with something vague like this:

I remember when the Civil 3D 2008 with Vault whitepaper came out. I remember we took a look at its proposed file structure and immediately freaked out. A single drawing for an individual object? Seriously? Where are my smelling salts!

Three levels of drawings?? Why would I need that when I can just have two base drawings and XREF the whole caboodle together and have forty layout tabs?

Three years later, everything is the same and everything is different. We’ve come a long way as Civil 3D users. We’ve begun to stop resisting the idea of BIM. Our workflows have matured, and while data shortcuts are great, we have the nagging feeling that there might be something more to take us to the next level. Maybe we don’t really need forty giant surfaces in one drawing. Maybe it would be easier to share work with another office. Just maybe….

I was amazed this morning when I sat down to read that Civil 3D 2008 with Vault whitepaper that some of it actually made sense and some of it gave me ideas on how to fill in the gaps in my personal workflow. I suppose after four years (or is it five?) of working in a model based world, I am beginning to get it.

I’ll be spending a lot of my time on this over the next year- so I want to know your thoughts. Please comment on what has worked for you. If you have a documented file organization or data sharing plan for your office, I’d love to see it. Feel free to email me (first.last@autodesk.com) with your documents, visios, pdfs, jpgs, etc. that map out workflow. Tell me what has resonated and what hasn’t been easy for users to digest.

We’ve all come a long way since Civil 3D 2007. Many who took the plunge couldn’t imagine working any other way. Mark Spatz recently posted this on Civil3D.com:

As of today we are up to 303 Civil 3D projects in Vault, company wide, and we just passed our one-year hallmark of our Civil 3D rollout.

Read more of Mark’s thoughts on Vault at: Civil3D.com: Vault Articles and also check out the great technical material at Being Civil: Vault Articles.

Comments

[Mark Spatz]

1. The option that if something is XREFing from outside of Vault it does not try to copy the item to the Vault project on check-in. I understand version integrity but it would be nice if this could be turned off as an option. As a company we would make that choice. We just end up erasing the copied stuff from Vault anyways.

2. Speed up the process of files being checked back into Vault. As it stands, it seems C3D opens each XREF in the background to check a couple of things. Make that process faster...

3. If a person is getting into a project that is already setup and he/she checks out a plan sheet that xrefs some model files, Vault knows what model files it needs to pull down to the working folder to support the plan sheet (XREFs). But if that plan sheet is ONLY Data-Referencing objects from model file, Vault does NOT pull down the model file to the working folder and you get broken Data-Reference warnings. That connection should be made in Vault.

Other than that, the improvement made in 2010 are GREAT and with these improvements Vault would be PERFECT (for us at least)!

[Jason Ellis]

Ahhhhh Vault - the word still makes my eye twitch to this day.

We had to abandon Vault after launching it in four offices and using it for the better part of two years, as it over-complicated the work-flow, played havoc with our project structure, and destabilized Civil 3D.

The difference between Attach DWG and Attach from Vault really confused a lot of folks; people were XREFing DWGs that already lived in the vault via the 'Attached as DWGs' command and then targeting the working copies, which resulted in duplicate DWGs and their respective folders in the vault. So in the end, you had the original vault DWG and then two to three copies of the working folder version as well in various identically named folders and whatever else they contained.

Then there was the issue with sheet set manager didn't play well with Vault - so if you had sheet drawings, which is a huge organizational benefit, they had to live outside the vault if you wanted to publish them all at once.

So now base drawings are in the vault, but sheet drawings are not. Working copies of bases drawing are accidentally copied into the vault. Some XREFs should be established by Attach DWG and some should be established by Attached by Vault. Agonizing.

Don't even get me started on circular dependencies.

Then there was the speed issue. Vault was incredibly slow to check in/check out drawings and synchronize DREFs. A typical check out on a typical DWG file (5-10 MB) would take 2-3 minutes. Unacceptable.
It took 3-5 minutes for many machines to open Civil 3D and auto-log into Vault. Couple that with the instability and frequency of crashes, you have a perfect storm of mass dissatisfaction.

Survey Databases lived in the Vault database. We had to go to one tab to check the database out, and then go to another to open it and use it, then close it, then back to prospector to check it in. Not a fun training session that day,'No, really guys, it's makes sense - it's a separate database that lives inside another database and the points that live in your database are different than the ones in the other database which you have to check out too, but they can have the same numbers if you're not careful. Oh, and DWGs can have their own points too that don't live in either database and - hey - OK who threw that?'. I felt like a stand-up comedian that was bombing.

The ADMS admin tools were anemic at best and the actual error reporting to try and troubleshoot anything was abysmal.

The moment we dropped Vault and went to using a DFS Root and Data Shortcuts, all of these problems went away. Projects structures remain intact, Civil 3D and drawings open fast, fatal error support calls in C3D went from 1 or 2 an hour to a handful of times during the week, no more circular dependencies, no more duplicate DWGs, simply open a survey DB. Serenity now.

Our users are infinitely more happy with Data Shortcuts than they were with Vault.

It's my anecdotal observation that Autodesk never really gave Vault (for Civil) the attention that it needed to be successful. To this day, I wonder why I carried that torch for so long. I was committed almost to the point of fanaticism to getting it to work right and went above and beyond to fix things, but in the end it bore no fruit.

I really can't see what the benefit of Vault is especially now that the Data Shortcut tools are so much more robust and easy to use.

Versioning and restoring? Nightly backups and autosave.

Project Templates? Data Shortcuts do that.

Document sync/control between remote offices? DFS root and Riverbeds.

Document (non-DWG) management? Maybe, but I'd argue SharePoint (et al) is a better solution. I know it costs, but Vault feels 'free'.

In fact, you can DREF objects from other projects into any drawing with Data shortcuts - that's something you couldn't do with Vault; everything had to live in that project.

I know people are using it with success, and I am happy for them, but this was my experience.

(Exhale) OK - I'm done. I must go massage my eyelids now.

[kamagra]

I find it very interesting to hear these kinds of issues
thanks for sharing