buildingSMART Forums

Mvdxml improvements

After some discussion with various interested people @mweise, @TLiebich, @jonm, @andreas.geiger I would like to invite others to join this discussion on potential improvements to mvdxml. Let me provide an example of the issues I have encountered when modelling/configuring MVDs on the mvdxml level. The more complex a concept is the more important the need of being able to define ERs on its components becomes. This is especially visible on concepts that reference partial concept templates. If I am more specific, properties in the Property Sets For Objects concept template that refer to the partial templates for different kinds of properties. As mvdxml allows ERs to be defined on Concepts only, there is no way of defining ERs on individual properties unless every property gets its own concept defined. The latter option is only partially successful as concepts cannot have logical operators applied between themselves.

That being said, I would encourage anyone with hands on approach and ideas for improvements to share their interests so that we can start a working group. We would not be starting from scratch as there were already some informal discussions in the last year.

@mweise could you post your presentation and the list of currently considered improvements that you presented in Düsseldorf?

Sergej, personally don’t want talk about this more, and this is my last post about IFD/IFC, MVD, IDM, BCF, ect

I just say, think about IFD/IFC structure/architecture BEFORE starting MVD and even IDM improvements

I think @TLiebich worked (or has worked) with an international Building Performance project and understands what am I saying

I have already mailed @mweise with some suggestions for one of the next minor versions of mvdxml (for example 1.2). But they all mostly boils down to different parts of the specification that needs to be much better specified. There are too many undocumented agreements in the format today, and there are also ambiguous things.

Product Geometry Colour in Reference View is one example of ambiguity. I think RV here describes that applying colours with StyledItem and SurfaceStyle is allowed only for SolidModels. So if you have tessellated geometry, colours should be applied with IndexedColourMap instead. But so far, the answer on the b-cert forum has been that it is probably allowed to use SurfaceStyle also for tessellated geometry because SurfaceStyle is part of the RV schema subset. My argument is that since no concept in RV describes that an IfcTessellatedItem (or any of its parent classes) can be styled by a SurfaceStyle, I think it should be considered disallowed. But I guess that wasn’t the intention of the RV authors.

For the next major version of MvdXML, I hope we can focus a little bit more on how MvdXML can be used in IFC authoring tools. So far, I think MvdXML has been designed with mostly documentation and validation in mind, and it is quite good and powerful for those purposes, I have to say! Especially with the additions you’ve proposed for MvdXML 1.2. But to efficiently use this information in an IFC export, I think some fundamental changes are needed.

I have the impression that one expects MvdXML to replace the need for manual user configuration in an IFC export. Today, the user often has a lot of technical options, like for example:

  • Should building elements be exported as extruded solids (convenient for some kind of analysis and simulations) or as breps/tessellations (more precise geometry)?
  • Should space boundaries be exported?
  • Should space have geometry?
  • Are boolean operations allowed?
  • Are IfcOpeningElement allowed to have body geometry (for boolean clipping)?

And an MvdXML can probably answer most of these questions. But I think it is impossible to automatically detect all these things by programmatically parsing an MvdXML document. MvdXML is way too flexible and generic. To find out what kind of geometry is allowed for IfcWall, you have to parse and understand all the concepts on IfcWall. And how are you supposed to know by the MvdXML that in Reference View, IfcOpeningElement shall not have body geometry for clipping? You will need to manually interpret the human-readable documentation in the mvd to find out that, so there is no way the computer could automatically come to that conclusion.

One solution could perhaps be to split MvdXML into one/some official MvdXML base documents, which defines all needed concept templates. IFC authoring applications can then know about and specialize for these concept templates (by guid for example). So it is easy to recognize that if IfcOpeningElement uses concept template X, then you are not allowed to export body geometry for clipping.

Users and other third party companies should not be allowed to freely define new concepts (based on their custom concept templates). They should only have the possibility to use the official ones and set rules with parameters, thus they can create ER and validate data, but not come up with fundamentally new concepts.

Today’s approach, where we theoretically can get any new and fancy Concept Template from anyone, makes it impossible to automatically adapt the export so it produces files according to the given MvdXML. It is almost like giving the computer a grammar for a programming language and expect it (the computer) to produce a useful program with that grammar. That is not what grammar is made for, and this is the same feeling I get with MvdXML: it is made for (and works well for) defining (documenting) and validating (IFC) structures, but is very difficult to use in an IFC export situation.

1 Like

Hi Sergej, Knut and everybody who is interested in mvdXML,

for further discussion please find attached the presentation given at the buildingSMART summit in Düsseldorf (in Spring 2019). The presentation includes a list of topics to be improved in mvdXML 1.2 or beyond.

The goal of mvdXML 1.2 was to work on a list of updates to fix most urgent demands and to be as close as possible to mvdXML 1.1 (so, no substantial changes that would break with current structure).
Beside documentation, most urgent demands are related to model checking. Interest in model filtering was low so far, but seems to increase as well.

Having said that, it would propose to settle down the list of requirements as soon as possible and then to agree on the proposed changes in the mvdXML schema or maybe as a kind of implementer agreement. A lot of people have contributed with proposals already (thanks to them and sorry for the delays on my side).

I would propose the following next steps:

  • Fix the list of new features for mvdXML 1.2 (less urgent extensions could be discussed for mvdXML 2) -> @all: please check the list if urgent change requests are missing
  • Decide about proposed schema changes to finalize the XSD and documentation.

There is a detailed response from Knut to current proposals. @Knut: maybe we use that document to collect further feedback. What is your opinion?

Best regards,
Matthias

2 Likes