MVDs are irrelevant to IfcOpenShell?

edited October 2022 in General

So far i understood:

IDS is for end-user <- information requirement

MVD is for software-vendor
Each MVD does only describe a subset of the ifc schema -> that's interesting for sofware-vendor, who do not want to implement to whole ifc schema.

However IfcOpenShell tries to implement the whole ifc schema, so for IfcOpenShell the MVDs are irrelevant? Is that correct?

Comments

  • Since the IFC spec is large, MVDs were invented as a way to break it down to only the features necessary for certain exchange usecases, and to allow vendors to be certified against those usecases. Then users would pick the MVD relevant to their usecase.

    In reality, MVDs are practically irrelevant for all software libraries, not just IfcOpenShell, but also XBim, and others. This is because most of the schema parsing is auto generated from the IFC EXPRESS definition, so supporting 10% is equally hard as supporting 100%. In theory, the part where MVDs are relevant are geometry: the easiest "coordination / reference MVD" only requires basic meshes and extrusions. In practice, it seems as though everybody is ignoring this and implementing support for all geometry (or more realistically, 99%). So MVDs from the perspective of a generic library are pretty useless, and there's really no need to create your own mini library since there are so many open source and proprietary libraries already out there for you to choose from unless you really love Perl.

    The only place where MVDs still have a bit of an impact is artificially within proprietary software import and export settings. Here, the developers building the export feature only need to care about a smaller subset of IFC. But even then, this loses a lot of meaning because these are usecase-based and despite the complexity of the world, I can count the number of MVDs for each IFC version on one hand. Try using IFCs in IES for energy analysis, for example. Or IFCs for scheduling in Synchro. MVDs don't apply at all. Revit's reference view MVD is a completely artificial limitation, Revit will happily process random IFC data regardless of MVD, and that's the same in reality for every vendor.

    MVDs have a bit of meaning left in software certification, but apart from the big boys nobody can afford it and it's so super long process of years so people are starting to realise that doesn't work either and the process is being reinvented now.

    In Native IFC, MVDs completely lose meaning.

    brunopostleCoenJanFMartin156131CadGiruArv
Sign In or Register to comment.