Topic: CAD Standards and C3D

[Guest]

I see there's a CAD Standards toolbar which has the four basic plug-ins that've been around since, what, 2000i?  And then there's the Style Manger dialog box (note the Architecture icon).  And while a DWS can be attached to the drawing, can it be used to sync the various styles within Civil 3D to another file (or am I asking too much?!?)

[mjfarrell]

You speak of an autocad tool, and an ADT tool that has no real analog in C3D that I have discovered in my experiments.

The closest you might get would require that ALL new styles have the same name as all the old styles, and then dragging those styles into the working file in the settings tab would serve to over write the same named styles with the new.

However I do not see this working for ALL C3D objects because of the defects in Pipes. So even IF it does work, you would most likely need to manually update your pipes.

[Guest]

'Nuf said!

Thanks!!

[mjfarrell]

Might be time to log a ticket through your subscription asking for such functionality.

[Guest]

Might be time to log a ticket through your subscription asking for such functionality.

Might be an actual feature by the time we implement C3D here!      

[mjfarrell]

Might be time to log a ticket through your subscription asking for such functionality.

Might be an actual feature by the time we implement C3D here!      

I can help change all that for you.....

[scout]

Might be time to log a ticket through your subscription asking for such functionality.

The keeper of the Civil 3D wishlist actively monitors both the AUGI Civil 3D Wishlist and the Autodesk Civil 3D Wishlist forum. While he may see subscription tickets eventually, the surest way to catch his attention is here:
http://discussion.autodesk.com/forum.jspa?forumID=185

I think the OP request is a heck of a nice suggestion and would be extremely handy!

[mjfarrell]

From my experience the wish lists are mostly a waste of time and energy. As very little of the items users actually want are incorporate into the products.  And often when they are, they do not work as desired.
Not to say that some form of standards tool as discussed would not have some use, at present I would venture that as they can not get pipes or parcels functioning corerectly this item would be at the end of an already long list of repairs that need to be affected prior to it's implementation.

[sinc]

The list isn't THAT long, is it?

Let's see...  Off the top of my head:

• Parcels are seriously mis-designed; need to be redone from the ground up.
• Labels and Styles are seriously mis-designed, leading to a giant mess that is very difficult to manage.  Ideally, all labels and styles would be completely redesigned from the ground up.  As a stop-gap measure and "hack fix", we need a "Style Manager" that lets us manage styles more-easily.
• Civil-3D does not support grid-based projects.  This is a serious issue that has ramifications throughout the structure of Civil-3D, and it will become an incredibly serious issue as more people start to use C3D for more giant projects that must be done in grid-based systems.
• Civil-3D has no project management.  The hackneyed attempt at Project Management in the Vault is misguided and flows against all good software engineering principles - PM *must* be in the core product, not hacked on in the Vault.
• Model Data Management is hackneyed and roundabout - again, something that should NOT be done in the Vault.  Users have no need or desire to deal with the constant check in/check out process, no desire to worry about which DWG file a project element is designed in, etc.  All of this makes the product more-difficult to use.  This problem should have been solved using industry-accepted methods of multi-user access to data, and not an ill-conceived plan that uses a Data Management System to implement a feature it was never designed to handle.
• Lack of interoperability between versions is a major issue.  Again, a better design of Model Data Management would have allowed easy import/export of model information between versions, without needing to use LandXML (which loses too much information).  This still won't be entirely seamless, as newer versions can introduce features that can get "lost" in a round-trip to the older version and back, but with a good design, it should be possible to get nearly everything working in a roundtrip, especially when going back only one version.  Again, this is a well-known software engineering problem that was solved long ago, Autodesk simply needs to learn about the available solutions and implement one.  Unfortunately, at this point, they would probably have to redo the entire DWG concept (and probably more) in order to achieve a robust solution, which would involve a major rewrite of the core product.
• The Survey Database is largely mis-implemented, and does not support many required, basic survey tasks.  It really needs a complete rewrite.
• US Survey Feet are largely mis-implemented.  But again, this is mainly because "US Survey Feet" is not one of the core Autocad units, and the concept of a "US Survey Foot" is 'pasted on' in Civil-3D, rather than integrated the way it should have been.
• Other survey support is virtually nonexistent.  There is no "stakeout" object, that could be used to create dynamic stakeout points from featurelines.  There is no GPS support.  Points are a major pain to deal with, unless the Vault is introduced, and even then there are still problems (besides which, we don't want Vault in any case).  There is no support in Parcels for measured vs. ground vs. deed, there is no integration between Parcels and Points, point manipulation features are weak, point group features are weak, the stock subassemblies are missing many required link and point codes that MUST be there in order for the subassemblies to be useful for surveyors, the Slope Stake report is pathetic, FBK files are old, outdated technology that should never have been incorporated into Civil-3D (except maybe for backward-compatibility with Land Desktop, in order to ease the transition between products), and much more.
• Grading is unreliable and difficult to use - it could use a substantial revamp.
• Corridors are implemented in an inefficient manner.  Currently, every subassembly must resolve every target at every station.  There is no reason for this.  It should only be necessary to resolve a target once for each subassembly in each region - it should not need to be done at EVERY station.  Fixing this could result in a significant boost to processing time.
• C3D chokes with large data sets (witness the thread in the Autodesk newsgroups, where a third-party solution can create a TIN from 15 million points in 1.5 minutes, without weeding the data set).
• General C3D performance is poor for many tasks, especially when a Windows network is involved.  (Even an Export to XML that takes less than a second to a local file, can take 30 seconds or longer when exported to a file on the server.)
• The issues with Pipes.
• The incompatibility with MAP.
• And all the CRASHES....

That's just off the top of my head.  I'm sure more things that I forgot will pop into my head later, but as you can see from the list, there's not too much to do before they get to things like Standards...   

[sinc]

Oh, and in case you missed this list last year, it was identical.  It was also identical the year before that, with C3D 2007.   

[scout]

From my experience the wish lists are mostly a waste of time and energy. As very little of the items users actually want are incorporate into the products. 

In broad terms, probably true. However, if you want your wishes having a shot at being seen, that is where to put them.

While certainly flawed in many ways, two recent wishes that did make it to the core product were the Lines/Curves Menu in 2008 and Lines.Curves tags/tables in 2009.

I won't comment on how well they have been integrated, but sigh, at least they made it in

[mjfarrell]

From my experience the wish lists are mostly a waste of time and energy. As very little of the items users actually want are incorporate into the products. 

In broad terms, probably true. However, if you want your wishes having a shot at being seen, that is where to put them.

While certainly flawed in many ways, two recent wishes that did make it to the core product were the Lines/Curves Menu in 2008 and Lines.Curves tags/tables in 2009.

I won't comment on how well they have been integrated, but sigh, at least they made it in

All stuff that has or was in the product (land desktop); autodesk has forced users to abandon, and thus should have been available from day one, not 5 version later. And as you admit, now that they are there they work pretty poorly. Should we thank them for that, or grab the pitchforks and torches and storm the castle after Dr. Frankenstein, the Monster, or both?

And please do comment on it, or will you be punished for doing so?

[jpostlewait]

I lobbied long and hard for the ability to archive and restore by project functionality to vault and that has been incorporated.
( I along with many others, I hardly own this one.)
And vault BTW is not that bad a feature particularly in the early going. My users, for the most part, have not struggled with Vault and have found it an aid in fixing troublesome drawings.
An argument can be made that the stakeout features belong with the data collector folks rather than the design software people.
And as the Design model delivery to contractor to upload directly into equipment scenario gains momentum the need for construction staking will diminish.
I agree that the styles organization could stand some consistency but a from the ground up rewrite Not sure it needs that.

And as to the large data set functionality, it's a long standing short coming for a memory based application. The file based Bentley line works much more efficiently with large data sets and that's been true for a long time. It will be interesting to monitor the Wisco DOT switch to C3D to see how that works out.

[scout]

And please do comment on it, or will you be punished for doing so?

I won't comment on it, because at this precise moment in time, I have not beat on the Lines and Curves tables in a production setting.

I wasn't really a fan of adding them in the first place because I felt that if parcels were 100% where we want them to be, Line and Curve tables would be unnecessary.

[sinc]

An argument can be made that the stakeout features belong with the data collector folks rather than the design software people.

Not really.  The whole point of having office support for field crews is that certain things are easier to do in the office, and when the office provides the correct support for the field crew, the field crew can work more-efficiently.  Net result is that we can serve our client faster and more-efficiently than if all this stuff was done by the field guy, using his data collector.

Not to mention, there are reasons why we have developed processes that involve both an office person and a field person.  The fact that things get looked at by more than one person provides redundancy, and helps eliminate errors.

But in order for all this to happen, the office personnel must be able to do their necessary calcs.

And as the Design model delivery to contractor to upload directly into equipment scenario gains momentum the need for construction staking will diminish.

Maybe eventually.  But that won't happen for quite some time to come.  And I would be very surprised if we hit a point in the foreseeable future - let's say the next thirty years - where ALL construction is done with data uploaded directly to equipment.  If you're saying that we foresee a time 30 years from now where this technology will not be needed, so therefore it is not worth Autodesk's time, well then...  maybe you have been around Autodesk long enough that you understand how they think?

I agree that the styles organization could stand some consistency but a from the ground up rewrite Not sure it needs that.

There are many fundamental errors in the design of most of the styles.  With a better design, it would take far less time to setup the styles.  When they needed to be changed, it would be much easier to change them.  And it would be easy to work with multiple standards, as some shops must (i.e., some work is done for the DOD and must follow the DOD A/E/C CADD Standards, some work is done for another large company and must follow the NCS standards, etc.).

Right now, in my opinion, the single largest waste of time in C3D is the style creation and management.  And this is largely because of the design.  A better design would dramatically reduce the number of styles needed for normal work, without impacting flexibility or power, and make them nowhere near as bad to setup and modify, and waste nowhere near as much time on something that really should not demand much time.

[mjfarrell]

As to styles, methinks that simply allow the units setting to be truly hierarchical MUST control the units of all Styles >>>>>>>unless the user wanted to manually override a style or a child with ALT units.   Problem Solved


Now go have a beer......but I don't see this happening because this idea is too simple to implement.
Whatever piece of code they use to allow the parent object layer to override the object label layer is probably easily applied to units, just by pointing it to a units class item, note a layer class or some nonsense.

Hello JP, uh there is no tooth fairy.  If you were to shake the world upside down, and put engineering firms, and construction practices through a sieve far fewer are as far up that evolutionary tree.

The process of allowing independent review of ones data is one of many that sinc and his team employ.

C'mon say it Vault Sucks you'll feel better.

[sinc]

And vault BTW is not that bad a feature particularly in the early going. My users, for the most part, have not struggled with Vault and have found it an aid in fixing troublesome drawings.

I note that you say your users have not struggled with the Vault...

The number of levels that the Vault is misguided are so numerous that it takes quite some time to list them all.  I've done it all before, so I don't particularly care to do it again now.  But to hit some of the high points:

• C3D without project management is crippled software.  Unfortunately, Autodesk has decided to implement NO PM FEATURES AT ALL in the core product, and has pasted them on in Vault.  This means that, in order to get any PM at all, the user MUST use Vault.
• Autodesk glosses over the difficulty involved in implementing and mainaining Vault.  When pressed, they finally admit that yes, it should be installed on its own server, and that means getting, configuring, and maintaining an additional computer.  Not so bad for big companies, but a real pain for small shops that really just want decent PM.  They also leave it to you to discover what happens when you want to upgrade to next year's version of the software, which can end up being a real nightmare for smaller shops with no real dedicated IT person.
• The constant check-in/check-out may not bother YOU too much, but I have heard a lot of complaints about it.  And I find it annoying myself, especially since I know that, with a better software design, it would be completely unnecessary.
• While it is true that there is value to Document Management Software, I object to having Document Management Software forced on those who do not want it, and merely want other, unrelated features (such as PM).  I also object to the way that C3D and Vault were designed with a high degree of cohesion, so that if you want DMS in C3D, you must use Vault.  If you have other, better, DMS software, you cannot use it with C3D, and you must maintain two separate DMS systems.
• The high degree of cohesion between C3D and Vault is a breeding ground for development problems and bugs.  The most-likely result is that we will never get good PM or Model Data Management, because it would be too difficult to do using the Vault.  So we will be stuck with things like the current approximation of PM (which is hardly any PM at all).
• There's more, I'm just tired of talking about it yet again...

[sinc]

Oh, and I forgot the point that makes me most saddened by Autodesk's approach to Vault...

If used differently (and more in-keeping with it's original design), the Vault could have provided a solution to that multi-office problem that plagues so many of us, and it would not require an expensive solution like Riverbeds.  But oh well, yet one more thing that "could have been"...   

[sinc]

I wasn't really a fan of adding them in the first place because I felt that if parcels were 100% where we want them to be, Line and Curve tables would be unnecessary.

How does the design of Parcels have anything to do with this?

The reason for using Line/Curve tables is generally because there are overriding reasons for having a small page size and large scale, and any other sort of labeling would be unreadable or unsightly.  Or because one area of an overall site has a series of small segments that cannot be easily-labeled at the overall scale, and it is undesirable to create a detail or second page at a second scale.  Things like that.

All of these reasons are valid reasons, having to do with the desired presentation, and have nothing to do with the design of Parcels or the features in the software.  I do not understand your assertion that Line/Curve tables are somehow unnecessary - in my experience, they have a very valid raison d'etre, and in fact, the software MUST be capable of them in order to call itself a serious piece of Civil graphic software.

[mjfarrell]

I wasn't really a fan of adding them in the first place because I felt that if parcels were 100% where we want them to be, Line and Curve tables would be unnecessary.

How does the design of Parcels have anything to do with this?

The reason for using Line/Curve tables is generally because there are overriding reasons for having a small page size and large scale, and any other sort of labeling would be unreadable, unsightly, or unmanageable.  Or because one area of an overall site has a series of small segments that cannot be easily-labeled at the overall scale, and it is undesirable to create a detail or second page at a second scale.  Things like that.

All of these reasons are valid reasons, having to do with the desired presentation, and have nothing to do with the design of Parcels or the features in the software.  I do not understand your assertion that Line/Curve tables are somehow unnecessary - in my experience, they have a very valid raison d'etre, and in fact, the software MUST be capable of them in order to call itself a serious piece of Civil graphic software.

[Dinosaur]

Aye, Michael . . . sinc pretty much said it all but I think you might have meant to add SOMETHING. 

I am going to hijack this thread back to its original question about CAD standards and then let it go back to its new tangent if you wish.
From what I was able to observe, once a proper template is established CAD standards take care of themselves for the most part, even at the level of object and label style names.  New object and style name creation would be the only real benefit for Civil 3D but I think the naming templates were provided to assist with these.  Rogue style names imported from different drawings might benefit from a standards checker but I would think it more useful to have these outside style remain easily identifiable as of foreign origin.

[sinc]

I agree that the styles organization could stand some consistency but a from the ground up rewrite Not sure it needs that.

The release of C3D 2009 has given us another good example of the terrible design of Styles and Labels.

Finally, after years, we have the ability to put a leading zero in our bearings.  As a de-facto industry standard, this should have been possible from Day 1, but at least we got it eventually.

Unfortunately, enabling this feature is no simple task.  Sure, there's a setting in Drawing Settings->Ambient Settings, but it does not propagate to the existing label styles.  And because of the general design of label styles, we have probably a hundred different styles that use bearings, if you consider General Segment styles, Parcel styles, and all reference components that include a bearing.

So now, I have the joyful task of going through that mess of styles, converting all of them to use that leading zero.  It's a feature we've wanted for years, sure, but now I find myself wondering "Is it worth it....?"

[dfarris75]

Well sure it is!!!

[sinc]

Yeah, I know.  It takes a bit of time to get through them all, but it's a pretty fast change.

It's nowhere near as bad as this (hopefully) hypothetical situation:



Dude 1:  Hey, you know how we've been stuck on C3D 2007, because 2/3 of our work is done for Companies A and B, and they're both staying on 2007?  Well, Company A's company headquarters decided they're moving to C3D 2009, so now all drawings we exchange with them need to be done in C3D 2009.

Dude 2:  What about Company B?

Dude 1:  They still expect everything in C3D 2007...  Their company headquarters has announced no plans for upgrading, and it sounds like they won't upgrade until at least the 2010 version.  So I guess we'll have to keep doing all their work in C3D 2007...

Dude 2:  You mean we need we need to install and use C3D 2009 for Company A, but we have to keep using C3D 2007 for Company B???!!!

Dude 1:  Do you have any better ideas?  Those companies are too big to do what WE tell them, and we really don't want to lose their business....

Dude 3:  Hey, guess what I just heard!  You know Company C, the company we do the other third of our work for?  Well, they just switched from Land Desktop to C3D 2008!  Now they want everything in C3D 2008 files...

All together:  AAAAAAAAGGGGGGGHHHHHHHH!!!!!!!!

[Guest]

You can't just give them the XMLs and a "dumb" linework file?

[dfarris75]

Maybe it's time to send an Autodesk lobbyist their way.

[sinc]

You can't just give them the XMLs and a "dumb" linework file?

Was that a serious question?  Or was it an ironic regurgitation of the Autodesk company line?

When it comes to C3D, I often can't tell the difference...  :ugly:

[Guest]

You can't just give them the XMLs and a "dumb" linework file?

Was that a serious question?  Or was it an ironic regurgitation of the Autodesk company line?

When it comes to C3D, I often can't tell the difference...  :ugly:

It was serious... I don't know what kind of companies they are or their extent of work in relation to what you do so....

Hey, look!  A quarter!!

[dfarris75]

Too funny.

[sinc]

Note that I stated that was a hypothetical situation.  But it illustrates some of the issues we've already been seeing on a smaller scale, and projects them.  For example, we've already had to consider the effect of switching software on some of the companies we work with.  We now have three companies all upgrading from C3D 2008 to C3D 2009 in loose synchronization, just to minimize the trouble.  Luckily, we can manage that; not all companies are so lucky.  (And no one else we regularly work with is using C3D yet, so that's the extent of the trouble for us.)

But when it comes to the compatibility issue, there are a number of problems.  First, we're modeling systems because of all the advantages of a model.  So cutting a dynamic, intelligent model down into a bunch of flat linework eliminates all the benefits of having the model in the first place.

Second, LandXML does not contain a complete model.  If we could export a complete model to LandXML, then import that LandXML into an empty DWG file and get an exact replica of when we started, then it would be a different story.  But we don't get that.  We get pieces of the model, which must be "reconstructed" on the other end, and all the information that got lost in the LandXML export must be "recreated" somehow in order to get back to the model.  This is arduous at best, and it definitely kills any attempt at a collaborative effort.  It can work OK when Company A does a complete task then sends it on to Company B, who does a complete task and sends it on to Company C.  But when Company A and Company B must constantly exchange files in a dynamic, developing project being designed jointly, it doesn't work.

Third, doing an Export to Autocad on a C3D drawing creates something that is little better than a DWF.  All the C3D labels lose their dynamic abilities, and cannot even be dragged to a different location.  Simply dealing with the hatches-that-used-to-be-background-masks can be annoying.  Then, if the person using C3D tended to control everything from C3D styles with little regard for layers, removing all style information can create a nightmarish drawing that is barely usable for anything.  If different viewport scales have been used, the resulting file(s) cannot even be printed anymore, because all the dynamic labels are dead, and C3D labels do not have an equivalent of "Maintain Visual Fidelity".  So for some purposes, a DWF can be even better than an C3D file Exported to Autocad.

As an example of something the Export to Autocad kills, C3D makes it very easy (for example) to model a parking lot with feature lines.  If we get a 3D model of a parking lot with the curb created from feature lines, we can use the STAKEFEATURES command from the Sincpac-C3D to create offset stakes at the click of a button, and go out and stake it immediately.  If we get a C3D file that's been Exported to Autocad, we have to clean up the mess of nested blocks so we can work in the drawing, then recreate all the 3D aspects.  All of this is wasted effort, introduced by the Export to Autocad, and it results in nothing but additional opportunity for error and increased cost to the client.

And that doesn't even get into the problems on the horizon.  For example, what happens in a couple of years, when we need to go back and open those C3D 2008 files for some important reason, and discover that C3D 2011 can't open the files, and we can't seem to find the old C3D 2008 install disks anywhere...

Maybe the important thing is to just remember to never throw away the install disks for old versions of C3D, and just deal with things as they happen...?   

[dfarris75]

That does sound like a mess and I'd agree. For us we use several different surveyors and for the most part none of them seem up to date with software and/or how to use the software efficiently. I request anything from points to breaklines to a full surface and seemingly get that "deer in the headlights stare" if that is so possible via email communications. Some of them deny my requests. Others give me data, but usually the data is not complete, or is vague in nature at times, enough to be a hindrance so I end up piece mealing things together to compose an eg surface. Then most of the time I don't even get to utilize C3D for what it is anyway due to the fact that I'm the only one in the office that knows how to use it to any degree. If my boss weren't so good to me in terms of time off (I take lots of time off due to religious days) I would likely seek employment elsewhere and have considered even still.

Then of course there is dealing with architectural files. I won't go there.

[Guest]

Others give me data, but usually the data is not complete, or is vague in nature at times, enough to be a hindrance so I end up piece mealing things together to compose an eg surface.

We go through the same thing.  I just don't get it.  What's the big deal?  Just send us the info we need in order to our job.  We're both working for the same client (most of the times).  The only thing I'm afraid of is getting the DTM file and then having the surveyor "tweak" the survey manually because of a blown shot or something.  Then, the DTM that we receieved from them and are using as the existing grade is no longer accurate because of some manual changes on their end.  *sigh*   I'm just going to bend over and "assume the position" because now I'm screwed.   

[dfarris75]

Yeah. I think around here most of them don't know how to use the software fully and/or don't know how to do the field work to make the office work easier, better quality, etc. I've seen a couple who do a fairly good job, but no more than two. That's not to say they don't give us good surveys in terms of a nice drawing because we do get that (usually), but when it comes to modeling using the data they collect... ugh. I wish they would learn it better so folks like me wouldn't have to sit around building an inaccurate eg model that really should already be done by the surveyor since they know better what's going on what with them having surveyed it and all.

Sorry. Getting a bit off on a tangent from the thread.

[sinc]

We've heard similar tales.  Some of the people we work with regularly have told us that we're the only ones who give them exactly what they need.

Unfortunately, there's nothing we can do about those other surveyors...  If you're in Colorado, though, we'd be glad to help you out...

[dfarris75]

Hehe. Unfortunately I've never even been to Colorado. Love to visit sometime though. The photo's are beautiful.

[Dinosaur]

a great place to visit, but try to stay out of the Denver sprawl.  Sinc is lucky to be on the south end of it - all the way north to Loveland / Ft. Collins is becoming one big urban corridor.

[mjfarrell]

Can we get back on topic here?

 


The interoperability of all of autodesk products is such a jacked up mess it isn't even news.
Why they do not ensure that their various products do not function together is beyond me.
I know the 'why' of not keeping the various versions working together is to force the upgrade issue.
They cleverly have most everyone convinced that being a brain eating zombie on subscription diet is a good thing.
The brain eating zombies upgrade at their masters bidding, and simply because the products do not work well together
and the 'upgrade' typically has no tools to convert your work forward or backwards, it's worse than a Chinese Finger Trap.

And if you want to be 'good' associates that are able to give them exactly what they are asking for, I'll be happy to help you reach that goal.