Topic: Name That Road Block

[Dinosaur]

Here is one that has been a major pain in my keester all along with Civil 3D and is just as bad with 2007 . . . It bit Mark last week with his points . . .

LAYERS . . . and the management thereof

Civil 3D seems almost to have changed the rules on how to use and manage layers.  It comes out of the box now with templates having a variety of themes to choose from, but even this is little help after you quit playing and start creating objects.  The template layers are OK but within the drawing are a variety of ways to sabotage your scheme.  There are default layers to keep an eye on in the drawing settings tab - some with a layer name and others specifying Layer 0 for various objects.  As you dig deeper, you find styles of objects and their labels with layer names shown in the display properties and if that object is contained within another object, any layer specified for that one may also cause trouble.  The objects also have settings in their creation mode where a default layer may also be  specified.  Finally, within the command settings, there is also a means to assign a default layer on which to create the object.  Another means to complicate this further is to drag and drop a really nifty style from a different drawing along with whatever default layer was tried in the original drawing.  So here is a real witches brew of layering conventions that almost certainly contain conflicts of named layers and "0" layer and an almost certain carpshoot as to what layer your object will carry when it finally displays on screen and the fun really starts when you want to plot or manipulate them in an xref.
I have no idea what the best way to approach the layering.  The old standby ctb system of plotting by color seems to be more of a hurdle than learning how to make stb files work in a style based drawing.

[sinc]

Here is one that has been a major pain in my keester all along with Civil 3D and is just as bad with 2007 . . . It bit Mark last week with his points . . .

LAYERS . . . and the management thereof

I've been thinking for a while that Autodesk needs to completely revamp layers.  It will cause tons of grief, even more than the INSUNITS and CUI things put together, but it seems like things are hitting an "unmanageable" point.

I haven't dug deeply enough into Civil-3D to hit many of the problems (although I've seen a bit of them).  But I've been running into many similar issues in Land Desktop.  We've been implementing standards more and more, and have hit the point where we need to be able to define multiple standards.  Autocad currently does not support multiple standards; it leaves it up to the user to keep track of everything.  The job of administering several concurrent standards also is something of a nightmare.

I've been noticing that much of the issues arise from the way Autocad uses layer names as the "key" for layers.  Since the same layer may have one name in one standard and a different name in another standard, this complicates things.  It especially makes it difficult to administer things like Land Desktop Description Keys.

I've been thinking about what would happen if layers were keyed by something like a "layer role" or "layer purpose".  A bunch of these "roles" would come preconfigured with any vertical like Land Desktop or Civil-3D.  For example, there would be a "role" that would be "Parcel Labels", or the default layer for parcels.  This layer could have different names, for example, in one standard it might be "PARCEL-TXT", in another it might be "V-SURV-ANNO", or whatever.  So, we would have an interface that would let us create "Standards".  Then we would be able to look at all our "layer roles", and key in a "layer name" for each "Standard".

This would fix a whole bunch of issues.  For example, as things are right now, the user may have a base drawing XREF'd into a whole bunch of other drawings.  The Container drawings all have VISRETAIN set to 1, and layer properties have been set in various ways in the various drawings.  For example, imagine a particular boundary layer exists in the base drawing with a CONTINUOUS linetype and a lineweight of .35mm.  This base drawing is XREF'd into three other drawings, all of which have VISRETAIN set to 1.  In one Container drawing, the boundary layer is frozen, and doesn't display; in the second Container drawing, the boundary layer has the linetype set to HIDDEN; and in the third, the lineweight is set to .60mm.  Now imagine that the user needs to change the name of the boudary layer in the base drawing.  Once the layer name changes, the VISRETAIN settings in the Container drawings are useless.  So now the boundary line shows up as a CONTINOUS line with lineweight of .35mm in all three Container drawings, and the user has to fix all three drawings.

Another issue it would fix is the "default look" of layers.  The drawing would have to maintain a link to the template that created the drawing.  But consider the case where the user has purged unused layers from a drawing, then starts adding more objects.  For example, the user creates a new surface and adds contours.  Under the current behavior, Autocad will create the layers for the countours, but they will be created with Default lineweight, CONTINUOUS linetype, and color WHITE.  If Autocad maintained a link to the template, then it could check the template for the layers, and create them with the correct properties, instead of the default CONTINUOUS/Default Lineweight/WHITE.

This would also fix problems with current "Standards".  For example, we currently do work for the US Air Force Academy, and have to use their standards (modified ISO standards).  These standards are extremely weak.  For us (surveyors), it means nearly everything we do is supposed to go on one of a handful of layers, and nearly all the layers are either yellow, red, or magenta.  This make it extremely hard to work in a drawing.  If Autocad had coherent support for multiple standards, we would be able to work in our "company" standards, and then "export" the final drawing to the AFA's standards.

Obviously, there's still things to think about.  It would be imperitive that the new system was not overly complicated, and adding another layer of abstraction (which is basically what this is) increases complexity.  But I think there's an awesome, easy-to-use "system that works" hidden in there somewhere...