topic Re: Scheduling Labels in Collaboration with other software

Scheduling Labels

Anonymous — Fri, 13 Jun 2008 15:59:48 GMT

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

Re: Scheduling Labels

Karl Ottenstein — Fri, 13 Jun 2008 23:55:34 GMT

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

Re: Scheduling Labels

TomWaltz — Sat, 14 Jun 2008 11:31:07 GMT

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)

Re: Scheduling Labels

Richard Swann — Sun, 15 Jun 2008 23:30:14 GMT

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!

Re: Scheduling Labels

Dukatas — Thu, 19 Jun 2008 23:48:54 GMT

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.

Re: Scheduling Labels

Rob — Sat, 21 Jun 2008 08:31:15 GMT

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

Re: Scheduling Labels

Richard Swann — Sat, 21 Jun 2008 17:20:01 GMT

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.

Re: Scheduling Labels

Rob — Sun, 22 Jun 2008 00:47:25 GMT

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.

Re: Scheduling Labels

vfrontiers — Sun, 22 Jun 2008 16:41:16 GMT

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.

Re: Scheduling Labels

TomWaltz — Sun, 22 Jun 2008 16:58:33 GMT

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.

Re: Scheduling Labels

Richard Swann — Sun, 22 Jun 2008 21:26:15 GMT

TomWaltz wrote:
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.

But the advantage with labels is that they can be made to AUTOMATICALLY get the elements data and perform operations on them globally.
I suppose it comes down to this: How do you integrate external databases into the CAD model and extract useful data such as cost, thermal performance etc? Somehow that information needs to be attached to elements and iinteract with parameters and general contextual information. I dont know if it is desirable to try to get this data 'into' the object, when all you want to do is extract the infromation?

Re: Scheduling Labels

Richard Swann — Sun, 22 Jun 2008 21:37:14 GMT

vfrontiers wrote:
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.
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.

Yes Yes Yes, you got my vote Duane, I absolutely agree!

Re: Scheduling Labels

TomWaltz — Tue, 24 Jun 2008 12:49:53 GMT

Richard wrote:
But the advantage with labels is that they can be made to AUTOMATICALLY get the elements data and perform operations on them globally.
I suppose it comes down to this: How do you integrate external databases into the CAD model and extract useful data such as cost, thermal performance etc? Somehow that information needs to be attached to elements and iinteract with parameters and general contextual information. I dont know if it is desirable to try to get this data 'into' the object, when all you want to do is extract the infromation?

If you are going to add information to Archicad, it makes a lot more sense to place them into 3D "real" elements, than it does to place them in arbitrary labels that could be added or deleted separately from the elements they are labeling.

If you schedule labels, you are relying one someone labeling every single element in Archicad, that you may not even want to print, and could easily accidentally remove one with no way of knowing it. It's a pretty thin solution that could cause more problems than it solves.

You forget that labels are meant to LABEL things. A label is intended to call out information already present, not create new information.

Not to mention, the labels don't do ANYTHING automatically. They only do what they are programmed to do. If you are going to program something, it should be something more useful than just an annotation object. It's like asking for data calculation in the Text Tool. While is may be useful in the short term, it falls short of the real goal of integrating a database with a 3D (or 4D or 5D) model.

I'd rather see a long-term solution (like being able to add user-defined intelligence to Archicad elements, which can then be labeled) than a short term one (like scheduling labels). This user-defined intelligence would have to be pretty robust, being able to assign the same information to several elements as well as being easily edited rapidly.

What we really need is a more robust database in Archicad. Not new workarounds.

Re: Scheduling Labels

Richard Swann — Tue, 24 Jun 2008 13:51:41 GMT

TomWaltz wrote:
If you are going to add information to Archicad, it makes a lot more sense to place them into 3D "real" elements, than it does to place them in arbitrary labels that could be added or deleted separately from the elements they are labeling.

I have great respect for your desire to include all data within the 'real' world of ArchiCAD, but if you take a step back and look at the amount of information needed to develop a scheme to construction and beyond, it becomes obvious that much of it has little to do with '3D' or CAD modelling at all, hence GS developed property objects. They don't exist within objects, they are tags and ADD information which can be read by schedules and lists, not the object itself! The idea that labels are arbitrary or could be accidentally removed (as any object?) is not relevant. The fact that they can be "added or deleted separately from the elements they are labeling" is one of their major benefits! Its called filtering.

TomWaltz wrote:
If you schedule labels, you are relying one someone labeling every single element in Archicad, that you may not even want to print,

No, just what you want to filter. I'm not talking here about text labels but custom labels. ie it would be good to be able to select the type of label to schedule otherwise it wouldn't work at all, it would be like only being able to schedule every element in ArchiCAD. The filtering could work like the ID does, no ID= no show.

TomWaltz wrote:
You forget that labels are meant to LABEL things. A label is intended to call out information already present, not create new information.

As I said before, that may have been the original intention, but labels are much more powerful. Just to call out information that is what the Markers are for!!

TomWaltz wrote:
I'd rather see a long-term solution (like being able to add user-defined intelligence to Archicad elements,

Thats what labels can already do. While there may some better long-term strategy for connecting informtion in the AC database to external databases, it would be a whole new approach and would still come back to the fundamental idea of TAGGING elements in ArchiCAD, FILTERING the data and ASSIGNING external data to them. What better way than labelling? Interactive Scheduling is the obvious way to visually check and collect the data.

Re: Scheduling Labels

vfrontiers — Tue, 24 Jun 2008 14:17:45 GMT

Looks like we needed to start this discussion about 10years ago!

Here's what I see...

Tom... I think your right, it's NOT a label... but it is very similar to a cross between a label and a property object.

Property object = "bad" because you have to not only define a format and parameter names for all the data you want to extract, but you have to give it the VALUE. Then you have to [potentially] copy all this to the next type of thing you want data from then change all the values. Then next week, when another iterance comes along you have to create a new type of thing and so on and so on.

In addition, it becomes difficult to "Cross-Breed" your schedules with data from OBJECTS, Walls, Roofs, etc. Keep in mind we're still creating a different property object for each time the data values change.

So, with my vision of this new-fangled "property element" [ok, someone else can name it].... I would be creating essentially a property object without having to infill the data. I'd like to see it attached the same way property objects are now, only once selected in the little window in the LISTING / LABELING tab, a new user interface pops up and I can now fill in the information for EACH INDIVIDUAL ELEMENT in the plan.

OBJECT TEMPLATES have got us a long way toward this goal. Bugger is that they can't be applied to native elements (Wall, roof, slab, mesh, etc.).

I am very interested in pursuing this discussion.... I am hoping AC15 or so can list this as something to look at.

Re: Scheduling Labels

Richard Swann — Tue, 24 Jun 2008 17:32:55 GMT

vfrontiers wrote:
Tom... I think your right, it's NOT a label... but it is very similar to a cross between a label and a property object.

Ok guys have it your way, 'label' is just a name for an object, but you can pretty much do what you are saying now with a thing called a label!
I agree that property objects never worked because they are way too labour intensive. and open to human error.
But lets get back to schedules..
The way I use labels is : associate the label with an object/ wall etc. depending on the type of object the label calls out to a list of files or external data in a text or data file, which can be selected as parameters in the label or selected automatically (depending on the object and context), this interacts with the data in the object and shazam, produces something useful.

The problem at the moment is that you can't schedule this information. If it were possible to call these parameters into a schedule, other fields in the external spreadsheet or textfile could be accessed as lookup tables within the IS. This could be manufacturers data, or other properties of materials, environmental, mechanical data, whatever.
The next step (AC 14) would be to call the xml from a website so you could have live web 2.0 data in schedules..I don't think it would be at difficult to add these facilities but would allow third parties to develop some really interesting links via customized schedules. We just need a few more tools to do the job.

vfrontiers wrote:
I am very interested in pursuing this discussion.... I am hoping AC15 or so can list this as something to look at.

The interaction with external data is so critical that if GS don't do it soon some other BIM will !