Trimble Business Center

There are quite a few "Smart" entities in TBC that default to layer zero. I want to put in a #featurerequest for a spot in project settings to select the layer that these entities would go to and avoid dumping these on layer zero:

Entities that default to the zero layer:

• Plan Sets
  • All new layers in plan sets default to zero 
  • Profiles
  • Cross Sections
• Corridors
  
  • Templates

Entities that do not default to zero but would be nice to set default layer:

• intersection

If I think of anymore I will add them to the list. 

You really hate Layer Zero don't you ....

At least with Layer 0 you only have one place to look for things and only one layer to turn off when you don't want to plot those objects.

I am not sure what you mean about the Plan Sets - while when you create a Plan Set the start point is Layer 0, however the expectation is that you will create a layer for all those items and place them on Layers of your choice - of course if you don't assign those things a layer then they may default to Layer 0 but they have to go somewhere - so why is Layer 0 a problem?

Please keep adding to this list Pat - I will get back to this in due course after I have thought through this - the challenge that I see with spraying things onto different layers is that they get harder and harder to find as a user unless you intimately know your own processes (this is ultimately why CAD files are so hard to understand - maybe we need to stop thinking Layers for some of these things and make them "Objects" that dont have Layer Properties but have an On / Off property as a Group or Individually that roll up in Project Explorer rather than on Layers (Like Surfaces or Images or ....etc.) - put some thought into this

Originally TBC was going to be more Object Based than CAD based. The Objects would be Grouped and Managed and Layers were to be used to manage Imported CAD Data only. However over time that vision has got a little lost I guess and we now put everything on Layers - then we Group Layers to make them more manageable, but now we have a lot of layers in a lot of groups and so we need to go another level and allow Groups to be controlled by View Filters so that we can minimize the lists we are working with etc. So I think if we are going to rework this type of thing we need to take a step back further and rethink how all this works to get us back to increased productivity - I am not convinced that Layers are the answer to all of this - Thoughts ..../ Ideas ..... / Please comment and brainstorm here

Of course adding more groups to PE may also make that less usable etc. So we need to think this out some more

Alan

Not as much as I did prior to the prefix fix for blocks and the zero layer.  Thank you 5.0. That has been a huuuuuuge improvement!

Alan, you wrote - 

Originally TBC was going to be more Object Based than CAD based. The Objects would be Grouped and Managed and Layers were to be used to manage Imported CAD Data only. However over time that vision has got a little lost I guess and we now put everything on Layers - then we Group Layers to make them more manageable, but now we have a lot of layers in a lot of groups and so we need to go another level and allow Groups to be controlled by View Filters so that we can minimize the lists we are working with etc. So I think if we are going to rework this type of thing we need to take a step back further and rethink how all this works to get us back to increased productivity - I am not convinced that Layers are the answer to all of this - Thoughts ..../ Ideas ..... / Please comment and brainstorm here

When you have a moment could you expand on how Objects being Grouped and Managed would be different than Objects being in Layers and the Layers grouped and managed? I'm guessing there is more than just nomenclature involved here but maybe not.

I find myself using multiple layers to assist in my build process. However when I send it out to the field for use I'm told by some that they want fewer layers. For example rather than WW-Main Line, WW-Laterals, WW-MH and WW-CO they want it all in Waste Water.

Objects like Surfaces today do not have a Layer and can be organized and

accessed through eg the Project Explorer or the View Filter Manager and

visibility controlled independently of Layers. Other similar objects

include Point Cloud Regions, Point Cloud Scans, Georeferenced Imagery and

PDF Pages etc.  The benefit of Object Based Visibility Controls is that you

can then keep CAD Layers and Layer Groups for CAD Data and not have to

assign everything to a Layer. Where we have likely gone astray is that many

things like Alignments are both an Object (Alignment Object with an

Alignments Group in the Project Explorer) as well as an Alignment Object

drawn on a Layer - so it is treated from a visibility perspectve like a CAD

object when it could and should be treated exclusively as an Alignment

Object.

Layers are well understood, however when you have several hundred in a

Project they become unwieldy - that is why we created Layer Groups -

however when you get dozens of Layer Groups they too become unwieldy, we

can improve that with View Filters that could control the Visibility of a

Group - so while working you could have eg a Utility View Filter and an

Earthworks View Filter that reduce the Layers and Layer Groups down to just

what you want for a Task that you have to execute. Objects can be included

in View Filters but would still have Visibility controls and Object

Property Controls that allow you to define how they are seen / viewed -

like Surface Colors, Surface Color by Elevation or Surface color by

Material etc. (these are more like the Object Specific Visibility Controls

- and some should be relational - ie if I have an Alignment and the

alignment is labeled, if the Alignment is Off the Alignment Labels should

also be off - but because we put these things on different CAD Layers it is

possible to have Alignment Labels On with no alignment visible etc. For me

the Alignment is an object and the ALignment Labels should be visible only

when the alignment is ON and only when the user wants the alignment labels

displayed - while you can do all of this with Layers - it is pretty clumsy

and needs good management skills to organize the data.

Alan

The intersection segments are good examples of entities that it would be nice to be able to set predefined values. 

These don't default to zero but ti would be nice to be able to set what the user whats this entities to go to. Currently they get scattered through the layer list. The ability to apply a prefix to these layers would be nice such as: Road- or Road-INT-. Something to group these together better.