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.

Thanks Jan. I also tested & verified this. This was the solution I needed from the start!

An Item Type can be attached to a cell header from a cell library by attaching the Item Type to the Model that the cell resides in. To clarify a little more, I used Microstation Explorer to access the Models in the cell library. Right clicking on the cell model allowed me to attach an Item Type to the Model. The Item Type attached to the model shifts to the cell header when the cell is placed. 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.

Hi Mangesh,

I presume that the Item Type will be passed to the Cell header when the Model is inserted as Cell. Can multiple Items Types be attached to the Model?

Please note that most users would not only be attaching Item Types to the Model before it is inserted as a Cell. I expect that most users will also be attaching Item Types to the the nested Cells (and other geometric elements) after they are inserted. Reasons include:

1. The original Models will often not be available to attach Item Types to.
2. The Cell will be used for different disciplines / users who will have different Item Types to attach. Forcing all of them to go back to the 'source' model or Cell library will not be practical.

Doing a quick test, it looks like you can only attach new Item Types to Cell header, not the component Cells. The Component Cells are available via the Properties panel, and right-clicking a selected nested Cell offers up the Attach Item Type tool... but the Item Type seems to get attached to the Cell header not the nested Cell. Is this because the nested Cells have no headers? It would be good to enable the Attach Item Type tool to recognise the nested Cells (and other nested geometry), so that the user does not always have to use the Properties panel to reach the nested elements.

I note that you can attach Items to a Ref attachment via the Project Explorer, but not to the Cells in the Ref attachment. This would be a really really good functionality to have!

Link via ElementID?

dominic SEAH said:

I presume that the Item Type will be passed to the Cell header when the Model is inserted as Cell. Can multiple Items Types be attached to the Model?

Yes. If this is not user friendly, file an idea for a better user experience to attach itemtype/s to the model.

dominic SEAH said:

most users will also be attaching Item Types to the the nested Cells

We cannot attach item types to child elements of the cell once it's placed. We need to break the cell for it. And, this will complicate things for parametric and shared cells.

dominic SEAH said:

you can attach Items to a Ref attachment via the Project Explorer, but not to the Cells in the Ref attachment

Attaching items to the cell in the reference file from active dgn is also not possible. Reference files are read-only. 

Thanks,

Mangesh

Mangesh.Shelar said:

We need to break the cell for it.

Hi Mangesh, could you explain a bit what you mean by 'break', please? Do you mean:-

1. Break the Cell itself, presumably to tunnel into the nested Cells to attach something that links to the Items. I understand that the Items info is always separate and is not stored within the Cell. If so, will using the Replace Cell tool be the way to go? Replace Parametric Cells also seem to be able to replace Variables and other Items. OBD and OpenPlant also have schema update tools.

The Replace Cell tool would need to iterate to the nested Cell, do its work, then Replace the top level Cell using the usual code? Replacing nested Cells has been mentioned in the past. Not sure if this is on the roadmap / Ideas section. I will check. Hopefully, this will not be too compute intenstive as the geometry is not changing. This would mean waiting on others, which is always problem? I note that the Replace Parametric Cell tool is still in beta?

2. Break the Mstn defintion or data format for Cells. Mstn 16 has introducted Placement Points for Cells. I suppose this would 'break' the Cell data format. Not sure how backwards compatibility was handled. Are the new PPs an extension of some sort that is just ignored by older versions of Mstn?

Mangesh.Shelar said:

And, this will complicate things for parametric and shared cells.

Again, what do you mean here?

3. Parametric Cells: A lot ot the Variables and Items will change as the Cell is developed. There were some very naive assumptions that PCs would be developed 'once' by designated 'power users' and never really change after that like the simple static symbolic Cells of old. The parametrics will evolve and with it the Variables and Items. The Replace Parametric Cell tools seems to recognise this. Being able to tunnel in and replace/update Nested Cells is going to be common place as most Cells are going to be part of assemblies and you do not want to be forcing the user to replace the whole parent assembly just to update one child. Basic stuff in the MCAD world.

4. Shared Cells: like Parametric Cells are based on a single definition stored in the dgn, but I assume that Items info is stored separately linked as each SC can have different Item values. I would have thought that this would make things easier as the 'offset' between the header Cell and its nested Cell children would be consistent.

Mangesh.Shelar said:

Reference files are read-only. 

Reference files tend to be read only, but verticals like OBD do write to them. OBD's Edit-in-Excel mode for example. And within Mstn, Dynamic Views can push settings changes Ref attachments. I am sure that there are other examples.

Even without writing to the attachment, it should be possible to fake this by enabling a database 'join' in the Active model by using the ElementIDs are a key. We can already extract the information in the Ref attachment and populate a Table. We can also generate Item Types in the Active model and add the Items for the nested Cells.

Extract the two Tables side by side and use the Element IDs to insert the nested Cell Item Info into rows under each 'header cell'. Repeat for each nesting level. Probably best  done in Excel or Access?

I would have thought that this kind of ETL, database type 'transforms' would be quite common in the imodel world. Bentley imodel Transformer stuff?

I understand iTwins.js 3.0 is starting on its editing APIs. imodels were mainly read only but are also getting write enabled. Bentleys iTwin strategy is also largely based on ContextCapture classification of existing scans. The whole workflow is based on adding info post 'creation'. This should be replicated in Mstn so that you don't have to round trip to iTwins just add info. Maybe that's the sneaky plan all along is replace Mstn with an cloud based Mstn based on iTwins.js?

"If I made you, how would you do it?" 

Hi dominic,

dominic SEAH said:

We need to break the cell for it.

I mean we need to "Drop" cell here.

Looks like your explanation is not related to https://microstation.ideas.aha.io/ideas/MS-I-409. Please file a new idea.

Thanks,

Mangesh

Hi dominic,

dominic SEAH said:

We need to break the cell for it.

I mean we need to "Drop" cell here.

Looks like your explanation is not related to https://microstation.ideas.aha.io/ideas/MS-I-409. Please file a new idea.

Thanks,

Mangesh

MSR-I-893

MSR-I-894

Please vote !

dominic SEAH said:

MSR-I-893

The facts, mentioned in this idea, are incorrect!

It is currently only possible to attach Item Types to the top level Cell header, after the Cell is placed.

Not true: It is possible, and was tested and confirmed in this discussion, that it's standard MicroStation feature that Items can be attached to cells (models) in cell library before they are placed to active model.

Regards,

  Jan

Hi Jan,

Not sure this correct.

I did try this and as noted in the previous post, the Item Type was attached was moved to the Cell header and not attached to the nested Cell.

Regards

dominic SEAH said:

Doing a quick test, it looks like you can only attach new Item Types to Cell header, not the component Cells. The Component Cells are available via the Properties panel, and right-clicking a selected nested Cell offers up the Attach Item Type tool... but the Item Type seems to get attached to the Cell header not the nested Cell.

Mangesh.Shelar said:

We cannot attach item types to child elements of the cell once it's placed. We need to break the cell for it

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.