Inconsistent Data in Schedules

[BeachHouse1]

There is a Field (Column) available to the Schedules that report the "Type" and the "Sub Type" of Objects in the Plan file.

The Data these Fields contain is inconsistent across different Object Types

 

In this example, out of 221 Unique objects, 79 of them have a default "Type" field with data created by Chief. 142 of them do not have data in the "Type" Column.

 

Admittedly, some of the null records have more than one Type of object. 

 

Obvious omissions are: Appliances, Electrical and Plumbing Fixtures, and Lighting. There are some more.

 

The questions are

1. Why is this a partial list?

2. Is there a way to open up the data in a Global way so hundreds could be updated simultaneously?

 

These Object "Types" should be modeled after the Tree Structure in the Library. Obviously Chief knows what type of objects these are.

In this Schedule the Field "Object Type" is Custom and Populated Manually.

 

 

 

[Renerabbitt]

3 hours ago, BeachHouse1 said:

These Object "Types" should be modeled after the Tree Structure in the Library

I'm going to make some educated guesses here.
Type is used to report value in specific ways in terms of programming. It informs other functions. So it is used in programming language.

It's useful to know the type of a window or the type of a tree.

Type is simply not a reported value for some symbols, as in a recessed light is a class of symbol that does not have the option to report to type. It simply isnt written in.
You could write a "Type" into the OIP but some items such as ridge caps don't have that access.

For those reading this, this has been an ongoing discussion with Joe. I have a personal frustration with this discussion because he does not wish to state the end goal, the "thing" he is trying to produce, which makes it really difficult to guess at what he is ultimately trying to accomplish so that we, as a group can give him some viable solutions.
 

[DBCooper]

1. Why is this a partial list?

 

Because chief coded it that way?  My guess is that if you want more objects to report a type or subtype info in the schedule (and you don't want to do this manually), you will need to ask chief to do this.

 

2. Is there a way to open up the data in a Global way so hundreds could be updated simultaneously?

 

I'm sorry but I am not sure what you are asking for here.  If you have similar objects, you can group select them and open up the spec dialog to make changes to all of them at once (but I assume you already know this).  You can also open all of the objects that are in a row in a schedule which might be handy for changing schedule related stuff.  As far as I know, there is no way to make "global" changes to all objects.  The match properties tool might help, but again, not really understanding what you are trying to change for what objects means that this might not help.

 

[Alaskan_Son]

On 9/11/2022 at 6:27 AM, BeachHouse1 said:

There is a Field (Column) available to the Schedules that report the "Type" and the "Sub Type" of Objects in the Plan file.

The Data these Fields contain is inconsistent across different Object Types

 

In this example, out of 221 Unique objects, 79 of them have a default "Type" field with data created by Chief. 142 of them do not have data in the "Type" Column.

 

Admittedly, some of the null records have more than one Type of object. 

 

Obvious omissions are: Appliances, Electrical and Plumbing Fixtures, and Lighting. There are some more.

 

The questions are

1. Why is this a partial list?

2. Is there a way to open up the data in a Global way so hundreds could be updated simultaneously?

 

These Object "Types" should be modeled after the Tree Structure in the Library. Obviously Chief knows what type of objects these are.

In this Schedule the Field "Object Type" is Custom and Populated Manually.

 

 

 

 

It seems to me like there's a big disconnect here between what you want and what Chief is actually doing; and that you want something completely different from what Chief ever intended to provide with type and sub-type. 

 

It sounds to me like you're really looking for information about what object type you're working with (window vs door vs lighting vs furniture, etc.).  What Chief is providing however is what type the object is as it relates to its own category (right sliding vs left sliding, hinged vs. bifold, etc.).  Sub-type on the other hand is completely for Plants which have checkboxes for various types and sub-types. 

 

I think where some of the confusion arises is that Chief for whatever reason reports the object type for certain objects (roof planes, polylines, etc.).  Those are items that don't actually have a type as it pertains to their own category though so those would otherwise be blank.

 

My 2 suggestions for you:

1. Suggest tp Chief that they create an object_type attribute for all objects and make sure they know what you expect to see for some of the various objects.  For example, there are all sorts of Interior Fixture objects.  Would interior_fixture be sufficient, or should there be some additional information that you would need.  Its imperative that you communicate exactly what you need the information for or Chief may well provide a solution that doesn't do what you need.
2. For now, I would suggest that your best bet for speeding up the process would be using a Custom Object Information Field with a macro that parses from the object's description, layer, and/or any other object attribute(s) that can be used to help verify what type of object you're working with. 

[Renerabbitt]

43 minutes ago, Alaskan_Son said:

For now, I would suggest that your best bet for speeding up the process would be using a Custom Object Information Field with a macro that parses from the object's description, layer, and/or any other object attribute(s) that can be used to help verify what type of object you're working with. 

cept for several of the things he wants to categorize don't have an OIP. I think they all have editable components though