Topic: CAD Standards and C3D

[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...?