Custom Classes - What is your system?

[Taproot]

@Kennedyme  just recently asked me how we set up our classes.

 

This spring I decided to rebuild our office standard around a new system of custom classes.  So it's a timely question.  I'll offer what I learned in the process, but I encourage others to share their take on this topic to better give new users  a range of successful strategies in setting up their office standards.

 

Old Setup

Initially I used the 'User 2' standard for class names.  It mapped VW's standard class names to a slightly more simplified and user friendly list.  The challenge I found was that many of the names were both vague and hard-coded into the tool structure.  For example, what is 'Style-1' ?  But 'Style-1' was built in to the door and window tool and couldn't be renamed.  That put a lot of burden on us to remember OK,  'Style-1' = Exterior Trim.  Repeat that scenario throughout the whole class list and it got pretty challenging to keep it all straight.

 

VW has matured and now allows custom naming of classes without creating a new (redundant) class with the original name.  It is much easier to work with now.

 

Standard vs. Custom System

If you are comfortable using an already existing class organization system, do so ... it will save you a lot of work.  Specifically, one of the ones built into VW - as there are enough hidden glitches that you will have to spend some time maintaining a custom system.

 

A custom system allows you to tune the class environment to your way of thinking. 

Done well, It allows you to preconfigure all of the class attributes in your file so that they are automatically applied and consistent throughout your drawing set.

 

Custom System Tips

 

Create a standardized system that can easily be added to over time.

As your drawings develop you'll evolve how you use the software, so leave room for adaptability.

 

I built our system around the CSI Division numbering system. In my way of thinking, classes represent materials. 

1. CSI's MasterFormat is the industry standard for material classification, so it fits nicely with material specifications, etc.
2. Most people are already familiar with the material divisions, so it's intuitive for our staff to use
3. Classes can become more specific and detailed over time.
4. The numbering system makes for a concise naming system
5. Attribute mapping makes sense when all objects within the class are the same type of material

 

Rather than include every division, I've just used the divisions that we need.  If a specific project requires a unique material, we can add that to the system easily.

 

Make the system easy and intuitive to understand

 

I tried to keep my class naming structure to just 3 layers deep.  i.e. ## - ClassName - SubClass Name.  Two layers works even better for me.

Some firms prefer to abbreviate everything.  I prefer names that are ordered, but easy to understand

 

Here's a list of the divisions that I use for my template.

Division 0 & 1 are general conditions in MasterFormat. I've used some creative license to re-assign them:

Division 00 = Annotations

Division 01 = Site

Division 02 = Existing Conditions

Division 03 -> are conventional categories

 

 

 

At the end of the division list, I've assigned an arbitrary Division 50 to be 'Model Specific' items like lights and cameras...

The only class that remains unchanged is "NONE".  I've capitalized it to make it stand out more.

Placement at the end of the list makes it easy to find - rather than somewhere in the middle.

 

Rename Existing Classes

 

I found that the best way to make this class standard work was to start from an already complete template file and rename the existing classes to my new naming standard.

 

For example, I wanted the class "Dimensions" to be '00-Notes-Dimensions'

VW allowed me to rename the class and from that point forward objects created with the dimension tool correctly associated with the newly named class.

However, If I just created a dimension in an empty file it would automatically create a class named 'Dimension' for it.  This applies to things like plug-in objects as well.  I found it easier to rename 'Style-1' to what I actually wanted it to be rather than to delete it and reset all of my door and window symbols to a new class.

 

Setup Standard Attributes

Under Tools>Organization, you can setup all of the standard attributes for your classes. 

 

 

 

 

Class Name Maintenance

We have a lot of legacy material (libraries, details, etc) that we need to pull into our current standard from time to time.

Since everything is currently organized with a ##-Name structure, the legacy classes all pile up at the bottom of the list.  That helps us easily find them and reassign them.

We delete the offending class and then in the pop-up re-assign the objects to the correct class.

 

In the meantime, we're going through our old libraries and upgrading them to the new class structure.  It's certainly an investment of time up front, but I can already see the benefit in consistency and time savings.

 

 

 

 

 

 

[E|FA]

@Taproot Thanks for the post and starting the conversation.  How do you deal with viewport annotations?  Are line weights/types set individually, by class, other?

[Taproot]

@E|FA  We use classes throughout the entire set including viewport annotations.  Notes, dimensions, and even masks and fills (like a soil hatch for sections) are all given attributes by classes.

 

There are some tricks to this.  For instance:

Class:  03-Soil ... We use an earthen hatch that in the hatch settings is set to "page" instead of "world."  That lets us use the same class for soil in a 1:48 scale section as a 1:12 detail and have both results look good.

 

Class: 00-Outline ... is a container for manual perimeter outlines of details, sections, elevations, etc.  We have it set to a 0.50 line weight by default, but will manually override the line weight for say an elevation that has multiple layers of depth.  That way we can turn the visibility on and off with one class and don't have to manage 3 or more subclasses for this singular function.

 

[E|FA]

1 hour ago, Taproot said:

Class: 00-Outline ... is a container for manual perimeter outlines of details, sections, elevations, etc.

If I understand correctly, you're using division-00 for any linework added in viewports.  I'm still working through how to deal with classes for items I'm modeling vs details I'm drawing in 2D, and then how to deal with SLVP annotations in each case.  It's still a work in progress.

 

Once I have things resolved a little better I'll post my class structure as well.

[Taproot]

@E|FA Not quite.  I use the same classes inside and outside of viewports.  The example I gave for the Outline class was just for perimeter emboldening of drawings.

I use many other classes in viewport annotation as well.

 

For Example - Here's a very simple section.

 

 

Classes and attributes follow materials.

The grade line = 00-2D-Outline

The elevation markers = 00-Notes-General

The soil hatch = 03-Soil

The insulation = 07-Insul Batt

and so on...

 

Incidentally, I really like using keynotes rather than callouts on my plans, elevations and sections.

I've classed  all of the material behind the section cut to 00-2D-Section Beyond

 

The same classes are applied to a detail.

 

 

One of the main advantages to classing by material rather than individual circumstance is that attribute control can be consolidated in one place, rather than scattered about.

For instance, elements assigned to 03-Concrete like the footings in the detail above have a concrete hatch in 2D, and also have a concrete texture in 3D.  So objects whether 2D or 3D will display correctly.

 

This makes even more sense when you start building off of classes into things like wall styles.  I set the components of my walls to use attributes 'by class.' 

 

We're discovering as we go, but the further we advance, I can see that the software was intended to be used this way. 

That said, It does take some persistence to get it all to work.

 

 

 

 

[gester]

we now use the sfb system from the design express localisation versions (dutch, french and polish have the same classing setup).

 

as soon as the polish classification system is ready (currently we work in the polish chapter of the buildingsmart int'l on it - the priority is the emerging cci system based on the danish ccs and swedish coclass) it'll replace the sfb in the pl vectorworks version. we give it some 2 years...

 

the integration of the building classification system in the bim authoring app is essential - otherwise the digital supply chain is not possible.

 

the digital supply chain integration is a 3-step procedure:

 

1. the objects in the 3d model are placed in the classification codes. the ifc export drags the classification codes with into the ifc models.

2. the ifc guids are being mapped to the bsdd guids (bsdd = buildingsmart data dictionary - a martix to map all classifications between them, and with the ifc)

3. the gtins (gs1 product codes) are being mapped to the bsdd guids via digital link.

 

thus the delvered products and materials know where they are to be built-in into the physical asset, based on the model information. this connection remains for the management stage of the asset (at best as the digital twin). remember: the uk initiated the process of building a digital twin of the whole country...

 

as for the digital supply chain: check out the dscibe (digital supply chain in the built environment) and digiplace, both started last year.

rob

Edited July 11, 2020 by gester

[Boh]

On 6/12/2020 at 12:36 PM, Taproot said:

One of the main advantages to classing by material rather than individual circumstance is that attribute control can be consolidated in one place, rather than scattered about.

Do you mainly used page based hatches or how do you accomodate different scale viewports of the same material?

 

I like how you work @taproot. Your section and detail examples look v similar to my own drawings! 

[Taproot]

@Boh Yes, I've come around to using page based hatches for different scaled viewports.  That most commonly applies to sections and details.  Formerly, I had two copies of each hatch, so that details displayed an enlarged version.  Now that we're using class attributes for everything, I've found a single (compromise) hatch works pretty well.  It's not quite as good (aesthetically) as it was, but it's fast, consistent and still reads well.

 

Have you found a better method?

 

I've been enjoying your posts as it seems we're at similar places in our skill development and you're often tackling the same issues I am.  Your solutions are often excellent and save me loads of time in the process.

 

[Donald G. Martin]

Thought I'd give my penny's worth on the subject.

 

As my work is based in South America, specifically Chile, we do not have such standardized measures in our local industry, nonetheless I do agree that as BIM kicks in worldwide, this tendency will no doubt change.

 

We do have a system for class definition which is based both on, the actual building procedure (from the ground up)and construction type ... defined by the materials that are specific to each part of this process. (Wall, slab, divisions, ceiling, roofing MEP, etc..)

 

We've found that as clients have become more involved in design decisions, due to a myriad of softwares, that allows them to 'navigate' our designs ...materials and how they are applied, often suffer many changes in the design process and have become the essential discussion points in any conversation

 

 This has made for class organization to become based on texture denominations in first place ...( rather than have a technical appendix as its prime definition, which sometimes becomes hard to find when navigating the endless list of possibilities).

 

We've defined a basic scheme where we congregate Graphic type classes (annotation and measures), and building based definitions starting from, contextual classes assigned to the environment the project will be set in, site classes based on the actual plot the project is embedded (mainly landscape orientated) and then the construction set, such as; foundation, structural and finally  .... visual (material) based component classes.

 

These last ones, are basically always applied through the components of each structural shape used in the model. Generally applied through wall, roof, slab styles aswell.

 

This allows for easy change of the appearance of a given part of the project just modifying the model style in question.

 

This allows us to present the clients with options easily (and quickly), which allows for the project to advance in a expedited manner.

 

We've found that numeric definitions are hard to understand or foresee (by new comers to the office), have a steep learning curve, whilst material based denominations are easier to find.

 

It also allows for new materials in the industry to be integrated quickly to the work process.

 

(Well maybe that's my  ... two cents worth ...)

 

Great discussion and food for thought, though, well done.

 

 

 

Edited July 14, 2020 by Donald G. Martin

[Taproot]

@Donald G. Martin @gester  

 

Would you be willing to post a sampling of some of the classes that you use so that we can get a sense of your naming strategy?

I think the more tangible examples folks have of a system that works, the easier it will be to make one of their own.

 

For us, the main obstacle to developing a new set of office class standards was the fear that we didn't know enough and were just going to create a messy confused result.

Quite the opposite has proven to be true.  We have a few legacy projects in our old class standard and drafting in them feels like molasses compared to our new files.

 

That's not to say that we got it perfect the first time.  We are adding a few classes as we go, but the standards are accommodating it well.

 

Now that we've converted our legacy libraries to our new standard ... I've definitely learned the value of keeping most symbol geometry in the NONE class and then applying a container class to the whole.  Otherwise, you end up with a whole host of legacy classes with each symbol import. 

 

 

[Rossford]

As a golf course architect, I need all custom classes, LOL.  While not familiar with all the classes you mention, I find that my "proposed" layers and classes ought to be first and existing layers and classes (which don't get changed as often after you set up the base map) ought to show up near the bottom of the list.  It saves some scrolling for me, anyway.  Visually, the construction items (drainage, contouring) show up on top of contours, existing features, etc. naturally, as well, which works for my kind of work. 

 

I use letters first, not numbers and find names that allow me to be alliterative, i.e.,  while being in the correct (for me) order.  Then,  drainage classes always start with 'D".  A 10" drain pipe is D-10, for example, and go in the appropriate layers, rather than putting everything in "Design Layer 1".  A bit more work, but easier to avoid mistakes and get quantities, control the drawing look, etc.

 

A- Activate Project (including prelim staking, etc)

B- Brushing and Clearing

C- Contouring (Grading)

D- Drainage

E - Engineering and Environmental

F - Features

G - Grassing

H - Hardscape

I - Irrigation

K - 3d Contours/polys

M - Site Model

X - Existing (XS for ex site, XG for ex golf, etc)

Z - Aerials and imports.

 

Call be crazy, but we debate putting all those separate layers as well.  It's a little complicated, but does allow working in "Show Other" layers, without worry that I am picking up a clearing line when I am working on drainage, etc.  To simplify and reduce file size, we actually have templates for concept drawings only, and only use the full template once we get to construction drawings, importing classes as we need to.

 

Probably not for everyone, but thought I would share.

[Donald G. Martin]

Hi there! ... sorry to take so long to reply... 

 

I´ll try and summarise and translate from spanish accordingly ...

 

As I mentioned earlier we tend to generate classes based on graphic and text requirements, contextual (location) graphical requirements, site specific and construction processes, building materials and finishes ... (this last one has become the largest 'mother' class of all...) basically used in components through wall styles ... for example...

 

and subgroups, using the score sign or minus (-) to create subsequent derived class specs ... all with the according texture (when applicable)

 

note: When bold letters are used ... it means a subsequent (-) subcategory of a class ... BTW.

 

i.e.

GRAPH-LINES-0,1/0,2/0,3/0,4/ ...etc.. for graphic enhancement (viewports annotations and such)

GRAPH-AXES-primary/secondary/referencial etc..

GRAPH-LINES-Revision/Land Line (topographic for viewports annotations and such) etc...

 

CNTX (contextual)-ROADS-Asphalt/Gravel/Dirt/etc..

CNTX -SIDEWALK-Concrete/Gravel/Dirt/etc..

CNTX -LANDSCAPE-Grass/Gravel/Dirt/etc..

CNTX -BUILDINGS-Highrise/Housing/Industry/etc.. for instance ... then

 

SITE-PLOT-Grass/Gravel/Sand/Earth/Water/Hardscape-walkways/Terrace/etc..

SITE-CONST-Sheds/Misc Buildings/etc.. and so forth..

or

TOPOG-Main/Secondary/etc.. (levels)

 

Then we have some construction based class definitions (load bearing) ...

 

STRCT-PILARS-Concrete/Steel/Wood-Oak/Pine/etc.. 

STRCT-WALLS-Concrete/Brick-Industrial/Handmade/Wood-Oak/Pine/etc.. etc

STRCT-SLAB-Concrete/Steel/Wood/Pine/etc

 

FOUND(ation)-CONCRETE-Continuous-simple/reinforced/etc..

FOUND-CONCRETE-Isolated-Simple/reinforced/etc..

FOUND-STONE-Continuous-simple/reinforced/etc..

as examples ...

 

Then we have FINISHING classes... generally used in wall, slab or roof components...

 

FINISH-WALL-Plaster-Polished/rough/etc..

FINISH-WALL-Stucco-Grain/plain/etc..

FINISH-GLASS-Plain/Mirror/etc..

FINISH-FLOOR-Wood-Plank/Laminated/etc..

FINISH-FLOOR-Linoleum-Forbo/Tarkett/etc..

FINISH-WOOD-Beech/Oak/Maple/etc..and so forth ---

 

FURNIT-HOUSE-Chairs/Tables/etc...

FURNIT-OFFICE-Chairs/Tables/etc...

 

MEP-ELECTR-Fixtures...

MEP-SANIT-Fixtures- Lavatory/WC etc

and on and on...

 

Some classes are specific to trademarks (forbo) or materials etc..

 

This is a brief explanation but as you can see this helps any newcomer understand where and what class to apply ... to a given item.

 

This DOES mean we have a LOT of classes ( as is obvious ... but ... they're all incorporated to our company templates ...) and not all are used in a given project, just what is necessary ..

 

We've found that using this type of organisation makes for standardised workflows and simple comprehension  ... line type, thickness and fills along with textures ... are all managed and defined by a couple of people and that makes for a corporate identity to be established thought our endeavour.

 

It also allows us to quickly activate or 'hide' a given mother class or category... in viewports and presentations.

 

In general the 'MOTHER' class ... gives the user an insight to the derived subsequent class structure from the 'get go'... making class navigation simple... (NO numbers ...)

 

Straight to the 'meat' as they say here ...

 

"no playing about with the garnishing"  ... LOL

 

Hope this helps...

 

Cheers!

 

 

Edited July 24, 2020 by Donald G. Martin

[Boh]

In essence we have developed a very similar custom class system as yours @Donald G. Martin and all for much the same reasons. We apply class attributes to as much as possible in our work and as well as having lots of classses we also have a lot of custom hatches, textures that are used for class attributes.

 

The main difference between your system and ours is how we have defined our mother classes.
 

We are Architects and interior designers and so we treat site work as it’s own sub universe of classes. We also try to keep all the 3D work classes together and we just use class name suffixes to distinguish ‘_Extg’ & ‘_New’ items.

 

in summary our Mother sets are:

 

COMPONENT-

All wall, slab, roof style component classes

 

DEMO-

All demo dawgs are 2d and we just need a couple of classes here.

 

DETAIL-

For 2d construction details. Sorted into materials with appropriate line weights &  hatches for 1:5 details eg:

DETAIL-Plywood

 

ELEVATION-

Al. 2d, For tidying up elevation viewports in annotations. Also used by IInterior designers for showing wall finishes. Eg

ELEVATION-Brick_New

 

FINISH-

All 2d, typ polygons to show finishes in floor, ceiling and Roof plans. Eg 

FINISH-FOOR-Carpet 1_New.

 

LIGHTING-

For switching on or off heliodons or light objects.

 

MODEL-

All 3D work is here (except site work)

This has a bunch of ‘sub-Mother‘ classes all with intuitive names:

-BEAMS-

-COLUMNS-

-FITTINGS--

-FLOORS-

-WALLS-

etc

 

NONE

Capitalised so more prominent

 

NONPLOT-

guides lines and anything else you don’t want printed

 

SECTION-

Al. 2d, For tidying up section viewports in annotations. Eg:

SECTION-Framing

 

SERVICES-

All 2d for plumbing and drainage, electrical schematics etc. Eg

SERVICES-P&D-SW-Drain

(P&D.and SW are not code. in NZ they are commonly used abbreviations for plumbing & drainage and stormwater)

 

SITE-

As mentioned site is a sub universe. This will have its own 3D, finishes and services classes. Eg

SITE-DTM (for the terrain model)

SITE-FINISH-Garden

SITE-SERVICES-Watermain

etc...

 

WD-

We use the WinDoor plug in for windows and doors which has its own set of classes.

 

Thats about it. A typical project can have up to about 300 classes but with hierarchical view the classes all collapse down to a dozen or so mother classes which keeps scrolling to a min. 
 

The system is always being reviewed and updated. @Taproot ‘s idea of using page based hatches might be good for us. Also as we move more and more into a 3D workflow some of the 2d classes should become redundant.

 

Cheers

[PLENZEN]

With the CSI Masterspec Division approach, I like the grouping. How do you handle phases? Existing, demo, new?

 

One of my biggest struggles is to have items auto-class. I am a TOTAL NEWBIE to VW. Coming from Revit, which has it's pros and cons like any software, the one thing I really enjoyed was to not have to worry so much about classes. Those few seconds to define classes for things you are working on and inevitably miss classing appropriately and using lots of time (in small amounts of seconds, but over time that adds up to a lot of lost productivity) to manually class is killing me. Is there something I am missing?

 

I like this thread of sharing types of office class standards to make projects consistent.

 

Thanks!

[Boh]

I’ve never got auto classing to work but hear are Some of my tricks for classing:

Symbols can be set to automatically insert straight into a class each time.

Using the eye dropper tool to quickly pick up the class of one object and apply it to another.
Class objects via the nav palette instead of the oip. Right click on a class and select  “assign to selection “

For items you draw a lot you can set up custom scripts with the custom visibility tool. Dble click the script it selects the correct tool and places the object you draw straight into the correct class. Great for detailing.

 

Keen to hear any other time saving suggestions.

cheers

 

[Taproot]

6 hours ago, PLENZEN said:

With the CSI Masterspec Division approach, I like the grouping. How do you handle phases? Existing, demo, new?

 

 

We have the Existing, Demo, etc. classed within Div. 02 - which coincides with the "Existing Conditions" section of CSI.

 

@Boh 's tips are great. 

 

One more that I would add is to set up a custom magic wand selection (add your own parameters as makes sense).

Then when you add a bunch of say Room Names and realize that they are in the NOTES class instead of the ROOM NAME class, you can just grab them all and move them over.

[PLENZEN]

On 9/8/2020 at 3:04 PM, Boh said:

Keen to hear any other time saving suggestions.

Any wisdom on time saving suggestions are greatly appreciated. Not only with classes, but in general. Managing classes seems cumbersome and I lose a lot of time keeping objects in the correct class and would honestly like to have auto-classing take care of this, but auto-classing is too limited.

[gester]

On 7/14/2020 at 8:31 PM, Taproot said:

@Donald G. Martin @gester  

 

Would you be willing to post a sampling of some of the classes that you use so that we can get a sense of your naming strategy?

(..)

 

we use sfb system in our polish vectorworks localization (this is a 1959 swedish system which is widely used in the benelux countries, especially in the netherlands). 

the codes base on numbers, and the exterior walls are like '21 exterior wall some description', or '22 interior wall ssome description', or '31 opening in the exterior wall some description', '27 roof some description', a.s.o., according to the table below (sorry, i haven't found it in english, and it's the part of the whole).

 

the system is pretty straightforward, it bases on the overall building structure, but has been examined and abandoned by the uk subjects while working on their classification, which became uniclass 2015.

 

 

of course, you can use any classification system (including your own), but the presence of this option alone gives vectorworks an edge, when it comes to the mapping of the codes and guids.

rob

Edited October 6, 2020 by gester

[gester]

...here's the other part (attachment)

 

general rule is:

27 roof (as the overall class for the roofs)

27-some roof  1 (which makes an indent)

27-some roof  2

 

the roof components are in the 47 group.

 

Edited October 6, 2020 by gester

[line-weight]

I keep my classes in 3 basic categories:

 

2d-xxx-xxx

Materials-xxx-xxx

Objects-xxx-xxx

 

2d is mainly line types (elevation lines, cut plane lines, overhead lines, etc etc) sometimes with fill defined. They are used mainly for annotation, any 2d detailing, and also as attributes for section viewports and so on (so, my cut plane line is the same whether it's a manually drawn 2d section or one generated from the model

 

Materials are for what the name suggests. Set up with textures, hatches etc so that things appear as I want them whether I'm looking at the 3d model or a section.

 

The objects classes tend to be applied to container objects (which contain elements that are placed in the appropriate material classes).

 

In practice I find the objects classes are mainly used to control visibility, for example when I want only to see structural elements, or don't want to show any furniture, and so on. I'm considering ceasing to bother defining things as "walls", "cladding", etc, but just have a tiered system that's based on construction sequence (substructure>superstructure>insulation>services>finishes>fittings or something like that) because almost all the time, that's how I want to control visibility.

 

I think that sometimes there can be "over-classification" at the object level - but realise that it may be useful for those producing reports etc from the model.

 

I have the luxury that most of my projects are relatively small scale and only me working on the drawings.

[gester]

here's my take on the connections between ifc structure, bsdd, classification, product identification and digital supply chain...

rob

[blimey]

Hi,

We've also just reorganized our class system and decided to base it on the Uniclass2015. If you are interrested. This is a very interesting link : https://toolkit.thenbs.com/Definitions

[unearthed]

I run my classes in a hierarchy associated with my layer names. I design landscapes, mainly for farms, industrial and commercial as well as some residential so each site highly custom (like Rossford ^)

Layers

1 Legal svcs trees and top 
2 Topo exist_features  

3 Water
4 Arch  
5 Hardscape  
6 Plants  
7 Traces Guides Underlays 
8 Aerials  
9 Sheet

 

Classes are like;

1 legal-boundaries_Surveyor [and usually a surveyor code and file date]

2 topo-proposed

3 streams, drains, wells, springs...

3 arch-build footprint

4 arch-footprint

6-plants_-typeA [often have 10-15 types with worksheet doing plant mix calcs for each]

9 sheet-viewport

 

I find having to only remember 9 numbers as basis for classing is quick and simple. I don't stick to it like a religion - but it's a useful framework.

I try and limit classing to 2 levels, and for some items like trees use an empty class that owns all classes in hierarchy so I can toggle individual elements off - or turn all trees off;

 

1 trees-00 SymHolder  
1 trees-00 SymHolder_Exist_trees 
1 trees-02 CODE  
1 trees-03 graphical  
1 trees-04 circle.planting  
1 trees—05 10yr dripline  
1 treesfls mature dripline  
1 trees-baseGraphical

1 trees-3D [for interworking with sketchup]

 

When you have hundreds of trees, many with different type of protection orders, and other variables this saves a lot of time, and helps remove map clutter.

[Rossford]

I like the idea of only 9 classes, at least per class.  And, I also dislike Drainage-Basin-12" if I can get by with CB-12 instead.  Long scrolling is a bear.  May have to reconsider a few of mine, LOL.

 

I also do what you do, making the number 1, "01" and so forth so that they show up in the numeric order I want them, otherwise, classes might show up as 0, 1, 10, 11, 12, 2.....or something similar. I do the same thing dating my drawings and revisions as in 2020 11 17 15 (3PM)  

 

Also see you came to similar conclusions on the layer hierarchy on what is most likely to show info you want.  As in, yes, topo should be above even features since you usually want it to show through, at least in my plans.

 

Thanks for sharing!

[hollister design Studio]

On 6/11/2020 at 12:04 PM, Taproot said:

....I found that the best way to make this class standard work was to start from an already complete template file and rename the existing classes to my new naming standard.

For example, I wanted the class "Dimensions" to be '00-Notes-Dimensions'

VW allowed me to rename the class and from that point forward objects created with the dimension tool correctly associated with the newly named class.

However, If I just created a dimension in an empty file it would automatically create a class named 'Dimension' for it.  This applies to things like plug-in objects as well.  I found it easier to rename 'Style-1' to what I actually wanted it to be rather than to delete it and reset all of my door and window symbols to a new class....

 

I'm finding that VW keeps creating 'Site-DTM-Modifier' even though I renamed that class M-Site-Mod...

 

Do you think this is just a bug in my system?