What should be the format of the OMF V2 file.

[m-sb]

My question is regarding the format of the OMF V2 file.

Should we write all elements to the project handle? or should we create a tree structure format. Consider I have a composite element which contains multiple composite or leaf elements. So in that case is it ok to create well structured file format.

[Tim-Evans-Seequent]

You're right, we don't yet have any guidelines at this stage for how to store common composites of elements. The code that's in beta now does support nested structures, so we can probably start working this out.

Anyone reading this, please post some of the things you would store in composite elements.

[m-sb]

@Tim-Evans-Seequent is this same for the omf block model?

[Tim-Evans-Seequent]

Not to the same degree IMO. With surfaces it's common for a collection of them to form something else, like a geological model for example. Block models are largely self-contained; they're less often part of a larger object.

There are some types of larger collections that might be interesting to represent for all types of elements, like changes over time.

[m-sb]

Hi,
@Tim-Evans-Seequent , my query is regarding again the format of file, as we don't have specific structure for non-block model file. Is this similar to blockmodel files?
Mean we don't have specific format of the nodes or data. Use has to decide its own encoding , decoding logic for reading writing OMF files.
Right?

Let me know if you have any query.
Thanks,

[Tim-Evans-Seequent]

To avoid confusion, there is no "block model file" as such. A file can contain any number of elements, which could be a mixture of block models, surfaces, points, lines, and 2D grids. The OMF2 specification defines those elements and their attributes, but not their "meaning" or how they relate to each other. This is mostly unchanged since OMF1. It has always been up to the application and user to choose what to do with the data they import.

OMF2 does provide some new features that may help applications convey that meaning. First is free-form meta-data on the elements and attributes. Second is the "composite" geometry that creates an element that contains other elements. Your application could, for example, store a geological model by putting all of the lithology volume elements into a composite element, and adding a meta-data item to that composite to tell people importing the file what the composite is. What we don't have here is a definition of what that meta-data item would be.

Getting a product owner from every relevant company into a room together to work this all out would be a large effort, and unfortunately it's beyond the scope of what I have been asked to do. For now, I recommend using meta-data fields and comments to make everything as obvious as possible for the person importing the file.

[m-sb]

Thanks @Tim-Evans-Seequent , for in detail description.