Graphical Editing Standalone iModels

[Ellord207]

Context

We are currently experimenting with storing Standalone iModels in component center for users to use as "templates" when creating sheets by harnessing transformations.

We are currently having trouble with the editing workflow for users to make updates to these standalone iModels. The intent is to download the standalone iModel, edit it, then upload it as a new version of the template. The problem is that when editing the standalone, the tiles are not getting updated with the new geometric elements.

I understand it to be a tile update issues because, the geometry is not visible when inserted. If I zoom into the view more than I have previous, the tiles have the inserted geometry. If the iModel is closed, the tiles cache delete, and the iModel is opened again, the new geometry is visible.

We are using similar logic to open and edit iModels from the hub and that works, but not with standalones. To review what we are doing:

1. Open iMode in ReadWrite mode: iModel = await BriefcaseConnection.openStandalone(path1, OpenMode.ReadWrite); (obviously not using openStandalone iModels that are not standalone)
2. Enter Graphical editing scope: await iModelConnection.enterEditingScope();
3. Make changes: await basicManipulationIpc.insertGeometricElement(props);

It's been awhile since I set this up so it's possible I'm missing a step. If so, I apologizes

Questions

• Is graphically editing standalone iModels supported?
• If so, is there a step I am missing?
• If not, would you consider adding such a feature?

CC: @ashish-srivastava-dev

[Ellord207]

On a side not, I attempted test the above workflow by adding a geometric element to a standalone iModel using DTA, and had the following issue:

1. Set environment variable IMJS_READ_WRITE=1
2. Start DTA
3. Open standalone iModel.
4. keyin dta edit
5. keyin dta place line string
6. Complete tool with a few line segments.
7. Observe error failed to insert element [10040] which confused me.

Is this workflow currently bugged in DTA?

[pmconne]

1. Set environment variable IMJS_READ_WRITE=1
2. Start DTA

In between these two steps, cd test-apps/display-test-app and npm run build.
After step 3, confirm that display-test-app's title bar includes the phrase R/W.
After step 4, confirm R/W is replaced by EDIT.

1. Open iMode in ReadWrite mode: iModel = await BriefcaseConnection.openStandalone(path1, OpenMode.ReadWrite);

display-test-app uses BriefcaseConnection.openFile. See if that makes a difference in your app.

Whenever I test editing operations in display-test-app, I use standalone iModels. It has been a while since I did that, so perhaps something has since broken. But please test the display-test-app workflow first to help narrow down the potential problem space.

[bbastings]

display-test-app uses BriefcaseConnection.openFile.

This is what I use for testing with standalone imodels in a studio test app as well. This plus enterEditingScope should be all you need.

dta place linestring currently works as well, I used it yesterday.

[ashish-srivastava1]

One workaround that we tried, add a new property StandaloneEdit with the value {"txns": true} in the be_local table for the standalone bim. This works but doesn't seem to be a parmanent solution.

[pmconne]

One workaround that we tried, add a new property StandaloneEdit with the value {"txns": true} in the be_local table for the standalone bim. This works but doesn't seem to be a parmanent solution.

That is what StandaloneDb.convertToStandalone does for you, among other things. Prefer to use that function instead of modifying be_local yourself.

There was some debate back in the day about whether we should permit people to edit standalone iModels, hence this "secret" be_local property. IMO it's their iModel, so yes, they should be able to do whatever they want with it; I think we've all come around to that perspective since.

[kabentley]

Using Component Center for template iModels is definitely the wrong approach for many reasons, as I've explained numerous times. That's the whole reason I created the CatalogIModel api. Why not use that?

[ashish-srivastava1]

Using Component Center for template iModels is definitely the wrong approach for many reasons, as I've explained numerous times. That's the whole reason I created the CatalogIModel api. Why not use that?

This has been an old discussion thread and currently we have moved away from Components Center (for storing template iModels) and now using Catalog Dbs.

[kabentley]

Wonderful, I'm very glad to hear that. Standalone iModels (un-versioned files with no timeline) are just not appropriate for large scale multiuser production workflows. Adding "document management" to them doesn't help.