Get the unit of measure associated with an iModel (dgn)

[rhaines57]

I believe a Bentley Open Roads .dgn has a unit of measure associated with it.
When that dgn is sync'd to an iTwin/iModel does the unit of measure get saved with the iModel?
If so, is there a way (API call or ECSQL query) to get the units associated with an iModel?

We are using the PresentationManager and I do understand how I can specific the activeUnitSystem to get my display values in a specific units.
My task is to retrieve the actual UOM so I can properly run calculations on the data (which is always in metric) and display the result in the proper UOM.

I see the following paragraph in the Quantity Formatter docs, but I'm not sure where the ui-test-app can be found:

It is possible to retrieve Units from schemas stored in IModels. The new SchemaUnitProvider can now be created and used by the QuantityFormatter or any method in the core-quantity package that requires a UnitsProvider. Below is an example, extracted from ui-test-app, that demonstrates how to register the IModel-specific UnitsProvider as the IModelConnection is created. This new provider will provide access to a wide variety of Units that were not available in the standalone BasicUnitsProvider.

// Provide the QuantityFormatter with the iModelConnection so it can find the unit definitions defined in the iModel
const schemaLocater = new ECSchemaRpcLocater(iModelConnection);
await IModelApp.quantityFormatter.setUnitsProvider (new SchemaUnitProvider(schemaLocater));

Thanks!

[grigasp]

... so I can properly run calculations on the data (which is always in metric) and display the result in the proper UOM.

Just to confirm, you're retrieving values in persistence units (metric) and want to:

1. Convert them to different units
2. Do calculations with the above result
3. Format the calculation result for display

Is that right?

Any reason not do do calculations in persistence units and do the units conversion and formatting at the end?

@ColinKerr

[rhaines57]

Hi Colin/Grigas. Thanks for the response.

Running calculations on the persistence units and converting to the proper UOM is the plan.

To know what UOM (units) to convert to I would like to read the UOM that the model was saved/designed in when pulling model data from the briefcase.

Thanks,
Randy

[grigasp]

If you use Presentation APIs to get the properties and their values, part of the metadata associated with the property is KindOfQuantityInfo. You can get it through (from top to bottom):

• Content
• .descriptor (Descriptor)
• .fields / .getFieldByName / .getFieldByDescriptor (PropertiesField)
• .properties (Property)
• .property (PropertyInfo)
• .kindOfQuantity (KindOfQuantityInfo).

If you use a content visitor to traverse content, you get the Field as a prop there, so getting property's KindOfQuantityInfo is straighforward.

KindOfQuantityInfo should provide all you need to do the conversion from persistence to presentation unit. You can use our KoqPropertyValueFormatter to do that (example).

[rhaines57]

We are using the Presentation APIs to get elements and properties, but we use the getElementProperties API (with a custom contentParser). I believe we can still get to the Field prop and therefore KindOfQuantityInfo per property.

When pulling 14M properties storing a unit identifier with each property will take up some space.

Isn't there a unit (UOM) applied at the model level? This would be a single value we can pull and store with the model metadata that could be used to format any calculated values.

Thanks.

[ColinKerr]

Each property definition (unique PropertyInfo) defines a KindOfQuantity and that KindOfQuantity defines the persistence unit and the active format. The format defines the presentation unit and attributes to control how the converted value should be converted to string.

If you are pulling 14 million individual property values there are likely only a few unique property definitions that describe those 14 million values. The ratio will depend on the data you are selecting.

You can identify unique property infos by combining the PropertyInfo.name and PropertyInfo.classInfo.name. Within one iModel the combination of PropertyInfo.classInfo.name and PropertyInfo.name will be unique.

That said you should not need to do all that work. If you use the KoqPropertyValueFormatter as @grigasp suggested you can just pass in the KindOfQuantity full name and the value from your calculations into the format function and it will return a string with the value converted into default/active format for that KOQ.

In most cases the default/active format for a KOQ uses the unit from the source file.
That may not be true if

• Multiple source files with different UOMs were brought into the same iModel
  • If there are multiple source files with different UOMs then I believe the first UOM in will win.
• The connector used to bring in the data uses a default KOQ instead of generating one based on the source file's units.
  • If the connector is not bringing that information across in the KOQ it is possible that the data is being stored in some non-standard way but we'd have to look at that based on the connectors you are using.

[rhaines57]

Thank you @grigasp and @ColinKerr for your responses to my question. I marked the last response as the answer, but the last 2 answers were very helpful. I'll do some testing based on the information you both provided. If I have any questions I'll reach back out. Thanks again!