Items & Item Types - What's in it for Mstn?

Lots of confusion about Items v Item Types in the forums. My understanding is that its all based on the shadowy advance of Bentley's EC Frameworks APIs, which I first heard about as Bentley's secret weapon used to consolidate MX, Geopak and Inroads into OpenRoads. Then started making an appearance in OpenPlant and its Class Editor, as a means to manage ISO 15926 schema (object-oriented in relational database friendly format?) info. EC Attributes also described as Bentley's version of AutoCAD's XAttributes. Guess that this needed for direct reading / writing all those dwgs.

Now in Mstn CE, Items seems to be the go-to enabler for data-centric (Hey, Mstn is BIM not just CAD, y'know) workflows like Property based Annotation, reports, parametric variables, business info, property panel display, queries etc. Items since V8i has been able to access Mstn's elements or 'schema' and I suppose some of Bentleys verticals (OpenRoad, Plant) and is providing some plumbing to verticals like OBD to use the same tools like the Properties Panel and Parametric Cell Variables.

All great great stuff. OTOH, this is taking so long and the results drip-fed over so many years, I can't help wondering whether we know what we really really want from Items and small brother Item Types, as users. I am sure that they are great for all kinds of programming reasons 'under the hood'. In fact, I wonder if Bentley high command have a clear idea, given the slow -seemingly tentative- pace of development.

Some of the benefits are already clear. Mstn has always been very good at CAD, but not so great with data-centric BIM working, which would normally need addons. Providing all of that at platform level is welcome. Ditto for the parametrics, smart annotation and business info attachment stuff. Common data and modeling platforms would pave the way for 'open' cross vertical working. Something that doesn't work very well even within the Bentley family of apps. Try printing from a file that has OpenRoads and OBD etc content for example.

Some of the dis-benefits are also becoming clear: extracting, converting all that non-graphic info for display and data-centric 'BIM' manipulation will make your file loading, model switching etc slower. More resource to convert existing app code will mean slower bug fixes, fewer new features etc.

  • From a user's standpoint, I think it is the improvements in the Project Explorer  and Properties Panel, especially, and that are most striking. Being able to modify element properties and parameters from the PP is great, and supports some basic 'data-centric' manipulation that would more difficult using the old CAD-centric tools. Especially now that there is an avalanche of pesky 'business data' that also needs to be managed these days with BIM deliverables.

    The new Expressions functionality is a natural progression. If you need to work with nongraphic data, usually in table format, then it makes sense to have more 'speadsheet' type tools. Edit-in-Excel is also a pretty powerful feature. And the way OpenRoads can add Item Type, Element Template input into their regular tools is pretty impressive. Bravo Bentley!

    Moving forward, it would be good to provide Expression support for the Mstn schema and integrate Named Expressions into the PP. Not sure how the new Expressions Builder will evolve. Will it end up like OpenPlant's Class Editor? I don't think it would hurt to have something that can be extended to handle Items as well as Item Types?

    Question: could the user write a dialog - that hosts a number of fields that report dynamic session info like cursor position etc by using Named Expressions?

    Logical to see Item Types functionality addressing nongraphic info first, including smart annotation and the variables associated with the new Parametric Solids. But this would be a huge opportunity lost, if the data-centric tools stopped at the geometry 'boundary'. It would be great to see the Expressions and more parametric tools link up and write to and manipulate general Mstn geometry / cells. If Mstn is going to be truly data-centric, it needs to reach out to the CAD side as well.

  • What kind of geometric link ups would be good? Bear in mind that a lot of stuff is already supported. Reporting areas, length/perimeters and volumes of elements is a good example. All that tedious math done by the CAD engine built on top of those fancy geometry and solid modeling libraries. Parametric control of Named / Graphic Groups, rendering materials and other symbology attributes. Named Presentations control is another example. Bravo!

    An oft-requested feature is a Dynamic Blocks / R*vit-style Visibility Parameter for elements in a Cell, that would provide control of the 'existence' or visibility of geometry using a parameter. Yes, I can see this being very useful.

    Enhancing the array or any Mstn tool to store the user's dialog inputs would be a great way to lend some parametric power to the established CAD tools. Items would be used to store the user's inputs and settings for later re-use. Why not if all the plumbing is already in place? I suppose that the new Array or Move tool would need to be able to extract and save the current ACS / Accudraw settings, state. If the tool operates on a sub-element of a solid or nested element in Cell, it would be good to intercept and store the ElementID and/or index to the vertex, edge, face, normal etc. More Symbols or functions to be used as part of  Named Expessions? Cool, I can see the Symbols also being put to good use by others in VBA or other scripts.

    Seems like Items already function as containers for expressions. Their info-storing purpose also equips them store parameters and attributes. Put together, shouldn't they also be containers for simple scripts and jigs?

    Looking at the usefulness of having a 'visibility' parameter that would allow the user to use multiple variants of a component or Cell, it would be equally useful if the 'visibility' parameter could call the Replace Cell tool to swap out Cells based on a parameter and some stored paths. There would need to be some 'set' expressions in addition all the 'get' ones in place. Or would it just be a matter of feeding the CADinputqueue with some keyins?

  • confusion about Items v Item Types

    The underlying technology is EC SchemasEC Schemas have been around since about MicroStation V8i.  They define, at their simplest, a set of properties that can be attached to a DGN element, model or file.  Properties such as Line.Length or Arc.Radius are built-in to MicroStation.  The schemas (XML files) are found in folder ..\MicroStation\ECSchemas\DGN.

    EC Schemas are fundamental Bentley Systems technology.  I suggested to the then MicroStation product manager,  (currently User Success Services Manager), years ago that Bentley should publish a white paper promoting EC Schemas as the foundation of Bentley's BIM offering.  He intimated that they were planning to publish that white paper, but it never to my knowledge appeared.

    Additional EC Schemas are used by vertical products to define application-specific business data.  For example, a pipe design app. might define pipe material and pipe contents & temperature.  During the use of that app, a user would place a pipe that would have those data attached.  The EC Schemas data are displayed as Items in MicroStation's element property dialog.  That is, an Item is a particular piece of data that belongs to something (a class property) in an EC Schema.  The developer of a vertical app. based on Bentley's Power Platform will define one or more EC Schemas applicable to their application domain.

    Item Types are a simplified approach to EC Schemas.  They are intended to be simpler to define and use than EC Schemas.  You don't need to be an application developer to define or use Item Types.  Just like any other EC Schema, when data is created and attached to a DGN object it is termed an Item.  That's what you see in the element properties dialog.

     
    Regards, Jon Summers
    LA Solutions

  • Hi Dominc,

    as often in your case, pretty long text, where I am not sure what is its intention: Is it question, complain, blog, a summary of personal ideas? Plus, not always correct, sometimes based on facts, sometimes on incorrect subjective assumptions, merging together different "levels" (persistence technology vs abstraction concepts...).

    So it cannot be answered in an organized structured way, only fragments commented...

    Lots of confusion about Items v Item Types in the forums.

    I do not think "lots of confusion". Please, provide evidence.

    I agree it can be confusing, especially when not enough knowledge is available, but I remember one recent discussion only.

    My understanding is that its all based on the shadowy advance of Bentley's EC Frameworks APIs

    Yes, it is more or less correct. Jon is wrong, because underlying technology is not EC Schema, which is only one part (aspect) of the technology, used for one specific task. Your naming "EC Framework" is better, because it can be split into things like formalized data structure definition (EC Schema), formalized data storage (EC instance), both covered by ECXML specification, and APIs in C++ and NET. Plus, there are topics like persistence, because it can be on-the-fly in memory, in DGN format, serialized to database (like .imodel based on SQLite).

    into OpenRoads. Then started making an appearance in OpenPlant and its Class Editor

    I am pretty sure it was opposite. Idea of engineering objects abstraction and formalization came from plant world (e.g. ECXML format was standardized before 2005!), used years ago in ProjectWise services, and step by step introduced to desktop products. It was  (and still it is) slow process, because it requires to change mindset completely.

    EC Attributes also described as Bentley's version of AutoCAD's XAttributes.

    I do not know AutoCAD XAttributes, but I think it is incorrect and bad statement, maybe a result of misunderstanding what EC objects are. EC world is from very beginning designed to be platform agnostic / neutral, and only fractions (like how data is saved in DGN format) depends on MicroStation and DGN.

    Item Types

    Item Types are nothing else than user-level tool, based on EC Schema. Whereas developers are able (I do it quite often) define own EC Schemas, describing custom data structures, including relationships between objects, Item Types are based on one pre-defined EC Schema "template", that is used to create EC Schema at background for every Item Type library, that is created by user.

    It specifies existing limits: Item Types cannot include anything, not allowed be EC Schema (and because the technology itself is rigid and strict to universal and do not depend on specific platform or program, there are plenty of limitations and rules defined ;-) Also, when application support is required (e.g. Symbol Provider has to be written to offer functions for EC Expressions), it must be done very carefully to maintain backward compatibility (both with MicroStation, as well as other existing tools).

    and I suppose some of Bentleys verticals (OpenRoad, Plant) and is providing some plumbing to verticals like OBD to use the same tools like the Properties Panel

    It is more complicated:

    Internally:

    • Some applications are "EC Schemas" based, like civil products (OpenSite, OpenRoads, OpenRail) and plant (OpenPlant). They use EC data directly, both to save them in DGN, as well as to create data models in memory on the fly (when necessary).
    • Other (like OpenBuilding Desginer) do not use EC data natively. It is just because of the product history, when it was not re-implemented, but only migrated (on civil products can be seen, how complicated such process can be).

    GUI level:

    • When data is natively stored in EC format, they can be displayed automatically by MicroStation. It is good especially when data is "flat" and no dependencies or restrictions exist (like when SHP data is imported).
    • Sometimes EC data is displayed not 1:1, but further modified, both using EC Schema customization and application code.
    • When data is not in EC, EC adapters can be implemented , so proprietary formats are converted to EC representation. It is used by MicroStation also, when DGN format and element data (not based on EC) is available to the rest of MicroStation through unified "EC language".
    I can't help wondering whether we know what we really really want from Items and small brother Item Types, as users.

    You can want only what is defined in EC specifications, created nearly 20 years ago ;-)

    I think you hit one topic, that is often a source of confusion and misunderstanding: EC<whatever> is technology how to describe data structure and how to save data in this structure. Nothing else, nothing more, no exception. Everything is else is not "EC", but just application layers and tools, build around EC world.

    So, what EC technology can do more for you? Nothing else than store data.

    But, how we can use this unified way, how data is described and stored, in new ways? There are no borders, it depends on fantasy (and development skills) only ;-)

    I wonder if Bentley high command have a clear idea, given the slow -seemingly tentative- pace of development.

    I think that EC (and the whole MicroStation) is stabilized, but a bit obsolete, technology, from Bentley perspective.

    The most investments, and the fastest development, is in iTwin.js and iModelHub projects, based on EC successor (BIS schemas were created using 20 years of experience with EC in server and desktop implementations).

    Something that doesn't work very well even within the Bentley family of apps.

    It is not simple task in general, because even when EC allows to read data in standardized way, often it is not clear how they can be interpreted without knowing wider context or to have authoring application. Especially, when plenty of data - typically defining relationships, further conditions and abstract models - are not specific to particular element, but stored in model.

    Regards,

      Jan

  • as often in your case, pretty long text, where I am not sure what is its intention: Is it question, complain, blog, a summary of personal ideas?

    HI Jan, its always good to hear from you... honestly!

    Length: Yes, I know. You should be getting used to it by now; The biggest clue is in the title : Whats in it for Mstn?

    I do not think "lots of confusion". Please, provide evidence.

    You correcting Jon goes a long way to answering your own question. See also Jon's reference to the lack of white paper. Anyways...

    AutoCAD XAttributes

    Yea, I am no expert here either. But looking at this oldish presentation on AutoCAD Plant 3d on spec and cat writing. It does look very similar to what OpenPlant is using for its own spec / catalog / schemas editors. It would make sense to see other CAD vendors having to have something similar. I recall that AutoCAD also introduced Entity Framework at the time. Don't hear much about it these days. Probably already decided to switch their bets onto Revit?

    You can want only what is defined in EC specifications

    No problems wit dat. Ones and zeros still have a lot of mileage left on the clock :-)

    Everything is else is not "EC", but just application layers and tools, build around EC world.

    Absolutely, but what I am interested in is how this can be developed with the best results for the user... not just the developers. As mentioned above, one of the big problems Mstn has is its lack of user-friendly data-centric tools... something that the competition has been able to capitalise on.

    So, what EC technology can do more for you? Nothing else than store data.

    Yea, this is the type of dev think that I am afraid of. You can be the data storing king of kings but it the user doesn't notice... well, then the writing is truly on the wall.

    based on EC successor (BIS schemas

    Ya, another thing that I am afraid of. Old hag Mstn being abandoned in favour of the new sexy girl in town? I guess nothing is forever. I would be interested to hear what BIS does better?

    when plenty of data - typically defining relationships, further conditions and abstract models - are not specific to particular element, but stored in model.

    Yea, its one thing to store the data in a type safe way, its a bigger problem to define and store links etc that propagate between them properly. Limits being  rehearsed by those guys trying to improve IFC and ISO 15926 etc for years. May not work at all.

    In many ways it is another reason to look more seriously at something 'dumber' like Item Types and UI-based automation tricks as described above.

    How about it, Jan? Do you think that something like expressions that are hosted in the Properties Panel that would work on general Mstn geometry will work? It suppose proof of concept has already been provided by OpenPlant. How would you do it, given your knowledge of the EC Framework APIs?