Layers VS categories

[bouhmidage]

Hi all !
as archicad introduces categories and classification systems, is there a reason to stay with layers and layer combinations ?
showing and hiding Categories will be more BIM and more usefull, we set categories, and then we start working like always

[Jp1138]

I think layers can be more flexible on what you want to show on your plans. With categories only you may be forced to make non construction logic categories just for the sake of representation. At least that´s how I see it right now, maybe I am wrong

[DGSketcher]

I have wondered about this myself, but there are two initial issues 1. Legacy AC projects with layers - There's no easy migration path. 2. Categories are not set up for 2D work - This means you need to develop a display category & control system for the 2D elements. If AC was a new software there's probably a lot that could be changed but the current 10 year legacy requirement limits what can be done with some aspects.

[bouhmidage]

2D elements can't be classified, maybe this is the main reason for that, but, if we establish a link between classifications and 3D elements layers, so we keep both, and filter the model in one single step, i used to filter bu layer combinations and then with classifications to coordinate, so the work is done twice

[Barry Kelly]

Layers are basically just a special classification for elements anyway.

If layers were included as an actual classification, then we would either …
- need multiple classifications (which we can do now) and then we would just be setting the extra classification to the layer (no different to what we do now?).
- or we would need to set a property in a classification that denotes the layer. That would mean we could have different layers in different classifications - could be a good thing or a very bad and confusing thing.

I am happy that the layers and layer combinations are controlled separately.

Barry.

[poco2013]

Barry wrote:

I am happy that the layers and layer combinations are controlled separately.

Barry.

I agree completely, but having the ability to control viability by classification does not negate the necessity for layers. We now control visibility by revision status, MVO and about five + other schemes. Having a classification visibility option would add even more convenience in drafting. Although I would extend classifications and properties to 2D elements also. Just another option to use or not use? Perhaps element viability could be added as a rule to the GOs using classifications and/or properties among the other options?

[Barry Kelly]

poco2013 wrote:
Perhaps element viability could be added as a rule to the GOs using classifications and/or properties among the other options?

Yes I would love to be able to hide elements by GO, rather than just changing there appearance (making them white so they don't print for example).


Barry.

[LucaP]

Barry wrote:

poco2013 wrote:
Perhaps element viability could be added as a rule to the GOs using classifications and/or properties among the other options?

Yes I would love to be able to hide elements by GO, rather than just changing there appearance (making them white so they don't print for example).


Barry.

That actually comes down to a wish that I wanted to add to a wishlist, but wanted to have some feedback first.

What do you guys think about creating Layer Combinations with criteria? Instead of trying to add new functionality to GO we could just change Layers which were created specifically for visibility settings.

Let's say you have a naming convention for your layers (E.g. We use prefixes for specific elements categories ' 1 | 1 | External Walls ') and then you could use a criteria to determine in which Layer Comb you would like to see which layers - By using "Begins with" in that case.

This would save some time and perhaps help to avoid some mistakes when creating new layers and then having to remember to update specific Layer Combinations.

What do you think? Is it worth creating a wish?

[Barry Kelly]

LucaP wrote:
That actually comes down to a wish that I wanted to add to a wishlist, but wanted to have some feedback first.

What do you guys think about creating Layer Combinations with criteria? Instead of trying to add new functionality to GO we could just change Layers which were created specifically for visibility settings.

Let's say you have a naming convention for your layers (E.g. We use prefixes for specific elements categories ' 1 | 1 | External Walls ') and then you could use a criteria to determine in which Layer Comb you would like to see which layers - By using "Begins with" in that case.

This would save some time and perhaps help to avoid some mistakes when creating new layers and then having to remember to update specific Layer Combinations.

What do you think? Is it worth creating a wish?

I don't get it.
So you have 3 layers all with the same prefix and you want to hide those layers that "Begin With... 1|1|".
That is fine and all of those layers will hide.

Now what happens when you want another layer combination that shows just one of those layers but hides the other two?
How would you do this except for creating criteria that looks at the whole layer name?
Or they would all need different prefixes.
So why have the prefixes in the first place?

Maybe I just don't understand what you mean.

Layer combinations are so much easier and it is only one click per layer combination to show or hide a new layer.
In fact you can do it now in the Attribute Manager by selecting multiple layer combinations and turning a layer on of off in all of them at once.

Barry.

[LucaP]

Now what happens when you want another layer combination that shows just one of those layers but hides the other two?
How would you do this except for creating criteria that looks at the whole layer name?

For exceptional situations you could of course use whole name criteria.

However, after giving it a second thought, you might be right - perhaps I'm overthinking this. Thanks for your input.

Yes I would love to be able to hide elements by GO, rather than just changing there appearance (making them white so they don't print for example).

Your idea seems to be better in that case, since you could apply layer criteria in GO for specific objects and then give them correct visibility state (I was trying to find a solution where you could still maintain visibility setting in the layers tool, but maybe it's not necessary since it still is going to be quite a code change for developers).

BTW. Do you know if there is a wish for it?