Reporting from Item Types in Cells

Hi Jovan,

I know I am jmping into old discussion, but I was not in office for a few days ;-)

Jovan Djukanovic said:

My aim is to produce a report that contains all the Item Type values along with the X,Y,Z coordinates of the cell origin.

Something similar to this report?

Jovan Djukanovic said:

When I run the report though my table only populates results related to cell property values & not Item Types.

It is expected result, because the reported object are cells, whereas you attached Items somewhere inside cells, so they are hidden for the report engine.

Jovan Djukanovic said:

I suspect that I can get it to work if ‘Add related Item’ the correct way.

I think not, because when you attach Item to an element, there is no simple (direct) relation between cell (represented by cell header) and Item, attached to an element inside cell.

Jovan Djukanovic said:

But I want all this to work with an Item Type already attached within a cell.

You cannot solve your request with Item, attached to "some element" inside cell. In fact, you can, as demonstrated by Jon, using Expressions, but it has some consequences and limitations.

Jovan Djukanovic said:

& will not work for me anyway as I am also displaying the Item Types in text field built into the cells.

This assumption is incorrect: To use Items in Text element does not require the data must exist (be attached) inside cell.

Jovan Djukanovic said:

Hoping for some feedback on how to get this to work.

When you want to report cell properties and Item(s) properties, they must be "on the same level", because there is no way, how to specify relationship "from cell to specific element, with particular Item attached". To be precise, in EC representation such relation exists for sure, it is: cell header > one-to-many relationship to child elements > Item is attached particular child element. But it cannot be queried without code, analyzing to what element the specific Item data is attached.

The solution is to attach Item not to element inside cell, but to the cell itself. It is similar to what you tried manually: To attach Item to cell header. In terms of a cell in cell library, it requires to attach Item to cell (model), not to an element. When such cell, with Item(s) attached to model, is placed, the definition is converted automatically from "attached to model" to "attached to cell header". It's mentioned also in MicroStation help too. When there is any text, using Item as Field, inside such cell, it works fine too: Filed definition is taken from model, and maintained properly after the cell definition is placed to DGN model.

At the end, because Item data exist "at cell level", they can be included in report simply.

With regards,

   Jan

Thanks Jan, I realised that I can only achieve what I want with Item Types & Reports by attaching Item Types after the cells have been placed. Being green on Item Types it just wasn't something occurred to me as some sort of limitation. The workflow I would want to achieve would be helped immensely with something like New Idea – MS-I-409.

I think this touches on something I am struggling with in creating feedback from parametric (2D) geometry in side cells.

Item Types can drive Constraint variables - great..,
and these are exposed as inputs when placed as a cell - wonderful
However there is no convenient way to report out "measurements" derived from the geometry held within the cell. - Not unless I pre-calculate those same measurements as expression equations (not always easy)

When placing text fields to report info on the cell the text editor can only see the header, and no the sub elements/item types within the cell.

Perhaps there needs to be a Item type that can be attached to the header and passes through a cells inner geometry/item type values. ie number, date, boolean, elementproperty

Hi Rob,

Good to see someone still wrestling with getting info out of Parametric Cells after they are placed. Hopefully, Marco and the devs are listening. One thing that would be good is to be able to display the parametric sketches etc on demand after placement. May when the PC is 'activated'? I think that the decision to permanently strip the underlying parametrics from the PC on placement needs to be re-visited.

This blurb from Arcol "We had a thought: rather than having to edit a family in another window in some other editor, what if you could simply make changes to a sketch of the window to add the curve? In Arcol you can do just that." I think illustrates the usefulness of pulling in the underlying sketch and parametrics into the active model.

I think that Bentley should build in some head room for 'post production' work on Items. The old thinking where everything is authored at source is unworkable. The first step is to support nested elements and attaching Items to them.

Reminds me of this recent statement by Graebert: "So, I think that’s the main point, we want to take the non-geometric (BIM) data, and inform the drawings, to enable automation." who see a market for annotating exported BIM models (imported rvt or ifc) using a dwg editor. I think that this something Mstn can do already (with a bit of help from various verticals).

The idea is that annotated drawings are still a big expensive task and automated annotation will need to read business info from the BIM elements. Since these BIM elements also have GUIDs there should be way to link other info to the elements for annotation purposes etc. Persistently even maybe?

I can see a cost consultant Ref attaching a geometry model and attaching his own Items to the architects or engineer's elements in the Ref. The cost consultants Items would have his own info, and also lookup the Items / schema info in the model like areas, volumes etc. Maybe even have special geometric elements like volumes to help select and assign/update Items info the way OBD's Spaces can already do.

Annotation? Once the Items info is assigned it should be straight forward to use Display Rules and the usual Property based Annotation tools to get the desired drawing outputs.

To reiterate: Mstn needs to allow for 'post production' of business info...  ie working on federated models using Ref attachments.

Well it is probably a different discussion thread - but I wish one of the inputs to a parametric cell was an (associated) element.
Perhaps this is a thing already I just dont see any documentation for it eg. - what does the "Point" item type property type do?

You might not need to edit the parametric cell if you can feed it dimensional AND geometric input.
eg. parametric cell that is based on a fundamental profile, could ask for and swap out that profile with a copy of a host/associated profile during placement. - much like Generative Components can promote an existing element to include its properties into the script.

My immediate problem is getting useful geometric properties out of the cell...

Jan Šlegr said:

attached to cells (models) in cell library before they

But only to an an element within (?)... they are not attached to the cell header. Thus they are not directly visible in the properies right away. Only after unfolding the elements in the cell WITH SEVERAL CLICKS

Cell built with Items 

When I place a similar cell with tags and then upgrade the tagset on the other hand, the converted tags are available for editing directly in the properties UPON THE FIRST CLICK

Cell build with tags and then upgraded to objects(items)

I am not able to build a cell with items that behave the same way (?Again: What am I missing?)

Why must it be so complicated (?). 

It is great to be able to report on objects(items) but this has been totally gone astray since years. (All the time and effort of all the guys here to get their head around.)

From the end users point of view it is a nightmare to fill the items. (too many clicks and many more handling issues)

KNX-Daten.dgn

Hi Gerd,

That's the easy bit. Touched on earlier in the thread.

What would be much more useful is if you can attach Items to the nested elements after they are placed (as part of a parent Cell).

You will never be able to predict what Item properties / fields will be required. There will always be more.

Hi Gerd,

That's the easy bit. Touched on earlier in the thread.

What would be much more useful is if you can attach Items to the nested elements after they are placed (as part of a parent Cell).

You will never be able to predict what Item properties / fields will be required. There will always be more.

dominic SEAH said:

That's the easy bit. Touched on earlier in the thread.

Yes, I thought to add my two cents from my perspective. Jovan said it right: This just wasn't intuitive for me. The logging of Idea-I-409 suggests to me that it probably isn't for a lot of other people as well.

I confess guilty that I am not digging into the documentation for something like this. It should be implemented differently.

dominic SEAH said:

attach Items to the nested elements

Is the term "nested" right here? Elements may be contained in a cell. Yet a nesting for me is when it comes to cells in cells.

dominic SEAH said:

never be able to predict what Item properties / fields will be required

Right, for me that may be a task for replacing cell. With tags that was possible (if I recall correctly) Better would be if you could "update" the Item  when some properties have been added in the item definition (that sounds not so hard, does it? Rather should be something that would be a basic requirement. Why do we as users have to.

The development of items (aka. objects soon as Magesh wrote) should have been to
1. deliver enhancements to tags (meaning that wherever possible it should be as easy)
2. enhance the end user handling. (meaning: make it easy to fill out the properties)
Discussions since the upcoming of items often try to convey the message. 

The development of physical products often "reingeneers" good ideas from competiors. Not even the handling of the functionality-to-be-replaced (tags) has been implemented. Nor seems anybody have thought about items handling in real world (hundreds of cells with properties). It rather appears that sb. deliberately made it worse. (Copying cells loosing anchoring of labels, no incrementing of numbered properies,...)

And yes, I am repeating myself and others. The issue in the meantime gives me the impression of screaming in a padded cell. I guess I will stop try riding this dead horse.

Thank you, back to work

Hi Gerd,

Sounds like we are both not very happy about the current functionality. You seem to have more concerns about usability, which I do not want to devalue.

mlm said:

Yet a nesting for me is when it comes to cells in cells.

By nesting I mean any element that is contained in another... typically this is an element grouped in a Cell, and where a Cell is part of another Cell. A Cell could also have nested elements and Cells. Mstn should allow Items to attach to any one of them. Especially since it is so difficult to tunnel into the nested elements/Cells without dropping and losing info.

mlm said:

Right, for me that may be a task for replacing cell. With tags that was possible (if I recall correctly)

Sure, but this is only one use case. At the moment, Mstn can not replace any Cells nested in another Cell. I don't think that this is a sustainable situation. BIM models like MCAD models will be based on assemblies of components. Having everything in a 'flat' hierarchy is unrealistic.

mlm said:

Better would be if you could "update" the Item  when some properties have been added in the item definition

Sure, updating the values in the Properties I think you can already do if the Items were attached to the nested elements/Cells. The problem is when the Item needs to be updated with other properties or when you need to add additonal Items to the nested elements/Cells.

mlm said:

Not even the handling of the functionality-to-be-replaced (tags) has been implemented.

What tag functionality is still missing? It would be good to have a list in Ideas? Ideally, Bentley would provide a roadmap for delivery but I suspect they have a lot of underlying tasks priorities. Items are much more powerful and pervasive compared to tags.

dominic SEAH said:

BIM models like MCAD models

Hierarchical objects are on the wishlist since decades (also Level Hierarchies) I have written that off.

dominic SEAH said:

What tag functionality is still missing?

I have posted this several times. Also as ideas. While I see the potential they are not implemented in a way that the end user can easily work with them (if you know tags) Tags always had shortcomings. 

But items are available since what 8 years (?) And were announced to replace tags. Still ppl. ask to keep them. 

I have not been able to follow ProjectWise Integration.(Has titleblock syncronization been implemented to work with items?)

dominic SEAH said:

but I suspect they have a lot of underlying tasks priorities

I will not go down this rabbit hole.

mlm said:

Hierarchical objects are on the wishlist since decades (also Level Hierarchies) I have written that off.

Not sure what you mean here. I am just looking for the basic Cell functionality in Mstn to be honoured when working with Items. Mstn has been quite good at 'heirarchial objects' at file model level if you look at its Ref file functionality. I think that all BIM processes will require federating 'hierarchial objects'. These days this also means dealing with 'hierarchial objects' authored by other apps.

The industry has been moving away from loose elements to smart objects for decades. These objects need to be aggregated up in assemblies. Even the basic Parametric Cell will be made from component objects constrained together MCAD style. Monolithic objects are problematic like their software equivalents. Loose unstructured elements will be stuck in the low productivity everything needs to be manually edited past.

I can understand why you may have written this off. After all, after eight years... better to lobby for the basics or recover the old level of functionality first, right? I share your frustration. The slide below is from 2006.