[ORD CE 10.10 C#] LinearElement to MicroStation element (id)?

Actually LinearElement is NOT an Element, it is just a geometry. Its naming brings misunderstanding. Perhaps calling it LinearGeometry is better.

If your LinearElement came from an Alignment, then you can get an Element from an Alignment directly by using myAlignment.Element.

Hi Yongan,

thanks for your answer :-)

Yongan.Fu said:

Actually LinearElement is NOT an Element, it is just a geometry.

Yes and no :-) I know the civil geometry is more like abstract model, represented by EC data. On the other hand, it is persisted as MicroStation element(s). And when some manipulations must be done (e.g. to copy a part of alignment, existing between two identified curves), it is necessary to jump the gap between civil model and MicroStation DGN format reality.

Yongan.Fu said:

If your LinearElement came from an Alignment, then you can get an Element from an Alignment directly by using myAlignment.Element.

Yes, I know, but it is the whole alignment (I guess it is typically ComplexChain), not its part (e.g. CircularArc, represented by ArcElement).

I though about this way, but I have had not enough time yet to check what is the best way to access elements in the chain, as it is not "indexed container", and graphic processor returns (again) geometry only.

Yongan.Fu said:

LinearElement.GetCurveVector() can return us a MicroStation CurveVector object which we can extract any geometry information from it.

Yes, I found this way already. But it looks like geometry position is lost: I have an alignment in some coordinates, but when converted to curve and new element is created from the curve, it is placed around 0,0. I plan to allocated some time to test when it happens: Whether geometry itself lost original coordinates, or when element is created, or maybe defined GCS plays some role here.

With regards,

  Jan

Hi Yongan,

Yongan.Fu said:

Can you provide a very simple test case?

I wrote a few tests and I think I found bug in API (ORD 10.10 was used), that can be demonstrated:

I used a file from my customer: Metric, using meters, in Czech JTSK GCS (so coordinates are quite big and negative).

In MicroStation API (or in ORD, accessing MicroStation NET API, not ORD one):

private void ExtractCurveVectorMicroStation(Alignment alignment)
{
    ComplexStringElement cse = alignment.Element as ComplexStringElement;
    CurveVector curveFromElement = cse.GetCurveVector();
    
    DPoint3d start;
    bool result = curveFromElement.GetStartPoint(out start);
}

I received DPoint3d xyz="-721542014,508014,-1016705669,76981,0"

They are expected values in UORs, equal to the element start points -721542.015 m,-1016705.670 m.

In ORD API the code is similar but CurveVector is obtained from Alignment, not from Element:

private void ExtractCurveVectorORD(Alignment alignment)
{
    CurveVector curveFromAlignment = alignment.Geometry;

    DPoint3d start;
    bool result = curveFromAlignment.GetStartPoint(out start);
}

I received DPoint3d xyz="-721542,014508014,-1016705,66976981,0"

These values are not in UORs, but in master units, so when I use

Element element = DraftingElementSchema.ToElement(dgnModel, curve, null);

in later manipulation (add to model, display in view...), it's in wrong size and wrong position.

I did not find any information in what units ORD NET API works, but because all APIs work in UORs by default (user oriented VBA is an exception), I treat it as API bug. Would you be so kind and to discuss it with ORD team?

With regards,

  Jan

I asked my ORD team colleague. He told me ORD SDK is using Meter as its default unit. It isn't a bug.

Thanks for the information!

Yongan.Fu said:

He told me ORD SDK is using Meter as its default unit.

It explains a lot. I take it as the fact, but it sounds weird and it would be interesting to know why such decision was made. For ages everything in MicroStation is expressed in UORs, so to work in meters adds extra complexity and places for bugs.

I would assume, when used API units are different than standard, standardized way how to cross borders exists and is explained somewhere? ORD API is limited and MicroStation API must be used for plenty of tasks.

Unfortunately, ORD team do not care about any documentation. When I tried to check and understand API directly, analyzing what classes are available in NET Cif assemblies, I do not recall any e.g. extension, allowing quickly transform standard objects (CurveVector, CurvePrimitive, elements, points...) from one API to another.

Regards,

  Jan

You and I are veterans of MicroStation and think UOR as a natural concept. But when I tried to explain UOR to a new developer, it is really difficult. I personally think using Meter as a default unit in ORD is a better choice.

BTW, Have you tried Tekla Structure API? It is similar -- always think Millimeter as its default unit(programming perspective) even your model is set in English unit.

Yongan.Fu said:

But when I tried to explain UOR to a new developer, it is really difficult.

I agree, the same experience here :-)

Yongan.Fu said:

I personally think using Meter as a default unit in ORD is a better choice.

Probably it is, because meters are the most general unified length metric.

The problem is not in meters itself, I can't object here, but in the lack of documentation and explanation, plus no standard too how to cross gaps between APIs. Even though it's simple (just to scale in the right way), when it is common to all API, I would expect it is part of the API (but it is not as far as I know).

Yongan.Fu said:

BTW, Have you tried Tekla Structure API? It is similar

I have no experience with Tekla, but I remember my friend told me some Autodesk product is in inches internally, regardless what units are used by a user ;-)

With regards,

  Jan

Yongan.Fu said:

But when I tried to explain UOR to a new developer, it is really difficult.

I agree, the same experience here :-)

Yongan.Fu said:

I personally think using Meter as a default unit in ORD is a better choice.

Probably it is, because meters are the most general unified length metric.

The problem is not in meters itself, I can't object here, but in the lack of documentation and explanation, plus no standard too how to cross gaps between APIs. Even though it's simple (just to scale in the right way), when it is common to all API, I would expect it is part of the API (but it is not as far as I know).

Yongan.Fu said:

BTW, Have you tried Tekla Structure API? It is similar

I have no experience with Tekla, but I remember my friend told me some Autodesk product is in inches internally, regardless what units are used by a user ;-)

With regards,

  Jan