Jump to content

Custom Classes - What is your system?


Recommended Posts

@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.


  • Like 2
Link to comment
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.

Link to comment

@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.





  • Like 2
Link to comment
  • 5 weeks later...

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.


Edited by gester
Link to comment
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! 

Link to comment

@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.


Link to comment

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 by Donald G. Martin
Link to comment

@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. 



  • Like 2
Link to comment

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.

  • Like 1
Link to comment

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.



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-CONST-Sheds/Misc Buildings/etc.. and so forth..


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


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



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






as examples ...


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







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






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





Edited by Donald G. Martin
  • Like 2
Link to comment
  • 1 month later...

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.



Link to comment

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.



  • Like 2
Link to comment
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.

  • Like 1
Link to comment
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.

Link to comment
  • 4 weeks later...
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.


Edited by gester
Link to comment

I keep my classes in 3 basic categories:






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.

  • Like 2
Link to comment
  • 1 month later...

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 ^)


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.

  • Like 1
Link to comment

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!

  • Like 2
Link to comment
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?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...