Scheduling Labels

[Anonymous]

It would be nice to be able to create an interactive schedule of every label note used across a project so that you could change them from a schedule rather than from the model - just an idea

[Karl Ottenstein]

There is an existing wishlist item from Duane on this and various discussions. Pretty sure if you search using the terms 'schedule labels' you'll find it...

[TomWaltz]

I think the idea of scheduling labels is a little work-around-ish.

We'd be better off if we could have:
1) better ability to assign new information/parameters to elements
2) better ability to label those new parameters.

A label was intended to show information about what it's calling out, not assign new information to them (even though right now that's just about our only option short of writing add-ons)

[Richard Swann]

TomWaltz wrote:
I think the idea of scheduling labels is a little work-around-ish.

We'd be better off if we could have:
1) better ability to assign new information/parameters to elements
2) better ability to label those new parameters.

A label was intended to show information about what it's calling out, not assign new information to them (even though right now that's just about our only option short of writing add-ons)

That may have been the original intention, and for simple labelling there may be some benefits, but there are some very powerful reasons why labels should be used as a way of tagging additional data to an object/ element:
1. A label can automatically filter any object/ element to calculate additional contextual data. (eg identify certain wall types in relation to certain zones)
2. Because labels have their own scripts, any object/ element can be tagged with more intelligent data than assigning additional parameters within the object.
3. Different types of labels can be applied to objects at the users discretion whereas additional parameters within an object would have to be assigned manually and individually.

I have many label tools for thermal analysis and energy calculation which would not be practical if every new wall, window or object needed its own new parameter(s).
Scriptable labels are not well recognized for their advantages, at least judging by their current implementation, and I agree that the anomily of lack of support for labels in scheduling should be removed so that 'tagged' elements can have additional non-graphic data listed, preferably with the ability to perform more complex mathematical calculations than can be achieved at present. But then perhaps schedules should be scriptable labels themselves given that they have better access to the database!

[Dukatas]

For the purposes of creating schedules of plumbing fittings, plumbing fixtures, and equipment, simple 2d markers can be saved as their respective object subtype then added to schedules. Giving the makers a subtype gives you all the standard listing variables you need for your schedules. This is the same principle as using labels just simpler. Use the object ID as the schedule number (can be used for incremental labeling). Using a object vs label due to a situation like labeling a faucet and a sink would be difficult as they are likely in the same object.

[Rob]

For the purposes of creating schedules of plumbing fittings, plumbing fixtures, and equipment, simple 2d markers can be saved as their respective object subtype then added to schedules. Giving the makers a subtype gives you all the standard listing variables you need for your schedules. This is the same principle as using labels just simpler. Use the object ID as the schedule number (can be used for incremental labeling). Using a object vs label due to a situation like labeling a faucet and a sink would be difficult as they are likely in the same object

this is nice but whole system has the Achilles' heel - objects placed on plans only will be listed. so anything you have placed in IE or details is ignored. I like the idea of label scheduling.

That may have been the original intention, and for simple labelling there may be some benefits, but there are some very powerful reasons why labels should be used as a way of tagging additional data to an object/ element:

Bingo!!! mate. it sounds to me like a deja vu, more here:

http://archicad-talk.graphisoft.com/viewtopic.php?p=116100&highlight=tags#116100

http://archicad-talk.graphisoft.com/viewtopic.php?p=119356&highlight=tags#119356

[Richard Swann]

Rob wrote:
Bingo!!! mate. it sounds to me like a deja vu, more here:

Hey Rob thanks for the links, a corner of the forum I have missed, you have another vote!
The issue of tagging is critical to the usability of CAD for BIM. While it would be great to add custom text to schedules or composites, there also needs to be a way of creating rule based tags, so, for example, a material can be synced with an external cost or thermal conductivity database automatically.
My work around is to bypass the scheduling and to script labels which do this. It works ok if you can cope with the imperfections of the text and data in/out addons, but it would be much easier if a schedule could automatically add a field from an external spreadsheet or database which obey user defined rules.. The advantage with schedules is they have a much better connection to the internal database than the text in/out addon. If you could combine them easily this would be an extremely powerful way of tagging ArchiCAD stuff with live external data.

[Rob]

My work around is to bypass the scheduling and to script labels which do this

same here. I am quite glad to see that someone else has the same line of thinking which reassures me it is a good way to go perhaps. What I can say is that GS knows about this possibility, however the implementation timing or even decision to implement it in AC is big unknown at the moment, unfortunately.

[vfrontiers]

Just to clarify... My original goal was to create something like MINICAD (yes, this wish is from 1997) whereby you can attach essentially a PROPERTY SCRIPT to any ELEMENT (not just objects, but walls, roofs, slabs, ets.)

Property ELEMENT would have the following attributes...
1. Script ONE Property element and be able to ATTACH it to any element
2. It could dig into HOST element and extract things like length or surface area.
3. It can also just have FILL IN THE BLANK type parameters so we can just associate little bits of text to any element we like.

The intent is two fold...
A. Avoid having to script EVERY STINKING OBJECT we use to match parameter naming. Especially critical when using a bunch of 3rd party objects

B. To allow information stuffing into other ELEMENTS like walls and roofs, etc. again, without having to script a PROPERTY OBJECT for each wall type, etc.

BTW.... MiniCAD was doing this forever ago. It is a good system.

Back this up with the ability to perform basic MATH FUNCTIONS inside a SCHEDULE itself (Can you find the lot coverage in a schedule?[Site Area / Building Footprint]) This stuff is basic and needs to be accessible to all users.

[TomWaltz]

Richard wrote:
1. A label can automatically filter any object/ element to calculate additional contextual data. (eg identify certain wall types in relation to certain zones)
2. Because labels have their own scripts, any object/ element can be tagged with more intelligent data than assigning additional parameters within the object.
3. Different types of labels can be applied to objects at the users discretion whereas additional parameters within an object would have to be assigned manually and individually.

Again, why not give the elements themselves these abilities and just have the labels display the information?

There's nothing here that would benefit more from being separated from the elements than it would from being integrated into them. Now, maybe that looks like scripting labels to the user, but the key is getting the data back into the original elements so that if you change the element, you don't have to go through all the labels and edit them as well.

The ideal here is to make more intelligent elements, not give us more workarounds for them not being intelligent enough.