I want to get DGN element properties. Using the DgnBaseElement schema I can use class MstnClosedBoundary to obtain the area and perimeter from any DGN element type. That is, MstnClosedBoundary acts as a super-class mixin for any DGN element that is closed and planar.
MstnClosedBoundary
I don't see the equivalent super-class mixin for linear elements. If I want to obtain the length of a line or arc etc. I have to implement a switch statement...
switch (eh.GetElementType ()) { case LINE_ELM: case LINE_STRING_ELM: ecClass = L"MstnLineSegments"; ecProp = L"TotalLength"; break; case CMPLX_STRING_ELM: ecClass = L"MstnComplex"; ecProp = L"TotalLength"; break; case BSPLINE_CURVE_ELM: ecClass = L"MstnBSplineCurve"; ecProp = L"Length"; break; case ARC_ELM: ecClass = L"MstnArc"; ecProp = L"Length"; break; }
Both the class name and the property name vary, depending on the element type. Is there a super-class mixin for linear elements? Is there a super-class mixin for solid elements? What have I missed?
You haven't missed anything. There isn't really a meaningful hierarchy of 'types' of elements (whether in EC, C++, or conceptually). Think of ECClasses like MstnClosedBoundary more like "mixins" than "superclasses" - they describe a set of properties that multiple types of elements may have in common but do not imply an inheritance relationship.
No such mixin ECClass exists for all linear element properties.
In the code above, you already have an ElementHandle. Maybe that's just serving as a simplified example? If not, wouldn't it be easier just to process your ElementHandle's geometry directly using IElementGraphicsProcessor or MeasureGeomCollector?
Either way, switch (eh.GetElementType()) is a bug.
Paul Connelly said:switch (eh.GetElementType()) is a bug
Why?
Paul Connelly said:Wouldn't it be easier just to process your ElementHandle's geometry directly using MeasureGeomCollector?
If I could find MeasureGeomCollector that could be the answer. It's not mentioned in the MicroStationAPI or MstnPlatformNet or BentleyGeometryNet, nor in any header file.
MeasureGeomCollector
I'm looking for a solution using either C++ or C#.
Regards, Jon Summers LA Solutions
A solution to what? Literally finding the length of some linear element?
It looks like someone was confused as to whether or not they wanted MeasureGeomCollector included in the published headers. You are right, it is currently omitted.
MSElementTypes is not an exhaustive enumeration - there are several types which are excluded from the published version - most notably type 106 ("extended element"), which can have any type of geometry. Your switch statement will fail to do anything useful with them.
Paul Connelly said:A solution to what? Literally finding the length of some linear element?
Yes, just as MstnClosedBoundary facilitates literally finding the area and other properties of some closed element. I don't want to write that switch statement, but currently have to switch because different element types have different APIs and different EC classes. With MstnClosedBoundary I don't have to concern my code with a particular element type or EC class.
Jon Summers said:Paul Connelly said:switch (eh.GetElementType()) is a bug Why?
Whereas Paul Connelly provided "technical justification", I see it as bad from slightly different perspective: To use "integer identification" for types is clearly a resignation from OOP principles in my opinion.
Every element type is represented by its class, not by its number: In C++ API it's ElementHandler, in NET it's the class type. It allows to be isolated from the issue mentioned by Paul, when different elements can be stored as opaque common types (like Type 106) and also vice versa, when the element is stored as particular usage of another type (e.g. GrouppedHole class represents the special usage of cells).
I recall several discussions about this topic, I was able to find e.g. this one.
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Jan Šlegr said:I see it as bad
The question is about ways to perform mensuration on DGN elements.
I regret posting a simple example that shows a switch statement. My goal is to eliminate the switch. The most appealing way to perform mensuration is by using a MeasureGeomCollector. Unfortunately that class is not public.
switch
Jon Summers said:The most appealing way to perform mensuration is by using a MeasureGeomCollector. Unfortunately that class is not public.
You did not provide information where did you find the class, even whether it's native or managed one.
My first impression is that it would not be so big problem to implement the required functionality using ElementGraphicsProcessor, because it provides generic way to access all elements geometry. Btut as usually, it would require some coding and testing.
Jan Šlegr said:You did not provide information where did you find the MeasureGeomCollector class
Read Paul Connelly's response above.
Jan Šlegr said: it would not be so big problem to implement the required functionality
The question arose because there is an EC way to mensurate a generic 'area' class (EC MstnClosedBoundary) — what Paul terms a 'mixin'. Unfortunately, as he comments, there is no equivalent mixin for a 'linear' class nor, as far as I can see, for a 'solid' class.
Jan Šlegr said:I see it [switch statement] as bad from slightly different perspective: To use "integer identification" for types is clearly a resignation from OOP principles
Paul Connelly said: switch (eh.GetElementType()) is a bug
You've missed the point of that switch: it's there to choose the right ECClass and property. Do I have an alternative to implementing the switch based on DGN element type?
In the case of linear/curve elements, there is no mixin ECClass that enables measurement of all types of line. Rather, there are individual classes for various element types, and within each class a different property name to get the object's length.
ECClasses are mapped to element type — not by me, but by the DgnElementSchema...
One can't include information about DGN element type 106 because there's no ECClass that can encapsulate it.
That's why linear and volumetric analogs of MstnClosedBoundary would be useful.
Hi Jon,
my feeling from the discussion is you are trying to use EC API for a task that it's not designed for and where using another API (C++ or NET) would be easier and more straightforward.
Jon Summers said:You've missed the point of that switch
I think I did not, I just agree with Paul that whenever in CE code the element type is used, it's probably bug in code design. This old-style elements identification is obsolete and should be avoided as much as possible.
Jon Summers said:Do I have an alternative to implementing the switch based on DGN element type?
Recommended approach is to test element handler type (or class type in NET), it provides much better information about the element type.
Implementattion question is whether to use switch and not e.g. hash table because of performance and also code readability.
Jon Summers said:In the case of linear/curve elements, there is no mixin ECClass that enables measurement of all types of line.
I assume that it's because EC schemas were designed based on different priorities and goals. EC schemas are not software API, but meta language used to describe data structures, nothing else. To measure elements, API is probably much better (even when I agree it would be nice to have e.g. simple EC query that will receive elements volume. ;-)
Jon Summers said:ECClasses are mapped to element type — not by me, but by the DgnElementSchema...
Despite it's not completely wrong, it's not correct and this assumption is pretty missleading in my opinion.
Your table contains several mistakes also.
EC Classes created to describe DGN elements (because other schema e.g. to desctibe plant model and data exist also) are closer to "user elements" (I think there is not standard term available) and often they are not equal how elements are stored in DGN file.
What I can see directly in schemas delivered with MicroStation:
For simple elements your statement is correct: arc element is ArcElement (it's inherited from MstnArc), line string is represented (e.g in i-model) by LineStringElement EC class (inherited from MstnLineSegments), line is LineElement etc.
But it's not because of element type (expressed by an articfical integer id), but because names of element, element handler and equivalent EC class are the same. EC classes / schemas are closer to element handlers, so e.g. for parametric cell, which is stored as type 106, there is ParametricCellHandler and ParametricCellElement EC Class available. Similarly e.g. for Grouped Hole, that is stored as a cell (type 2), there is GroupedHoleHandler and GroupedHoleElement EC class.
For some elements, the mapping is even more complex and have no relation - similarly to ParametricCell - to old element types at all. E.g. what is presented as Parametric Solid to user is stored as Type 106, represented in API by SmartFeatureElement and there is (not published) EC schema SmartFeatureSchema that defines SmartFeatureCollection allowing to describe the solid tree of nodes and leaves using EC relationship classes.
So in summary the mapping is not element types > EC Classes (even not EC schema, because every EC class is inherited from some base classes and modified by several attributes typically), but is completely artifical. In some parts, the mapping looks like equal to element types based, but it's closer to Element Handlers structure (and other handlers for non graphical elements).
Jon Summers said:One can't include information about DGN element type 106 because there's no ECClass that can encapsulate it.
Sure it's not, because type 106 is a place holder for an element handler. And the handler itself is mapped to EC Class.
Jan Šlegr said:You did not provide information where did you find the class, even whether it's native or managed one.
You may be interested in this response by Brien Bastings.
Jon Summers said:You may be interested in this response by Brien Bastings.
Thanks!
Even when it's not what I expected personally, it makes sense :-)