Ifcopenshell: IfcPropertySingleValue wrappedValue not working anymore?

[yorikvanhavre]

Hi Thomas,
This used to work before in python (with this file: test.ifc.zip), it apparently doesn't work anymore? Can you have a look?
Thanks!
Cheers
Yorik

import ifcopenshell
f=ifcopenshell.open("test.ifc")
t=f[262].NominalValue

gives: #261=IfcText('Draft._Rectangle')
then:

t.wrappedValue

gives:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/dist-packages/ifcopenshell/entity_instance.py", line 49, in __getattr__
    "entity instance of type '%s' has no attribute '%s'" % (self.wrapped_data.is_a(), name))
AttributeError: entity instance of type 'IfcText' has no attribute 'wrappedValue'

[aothms]

Thanks for the report Yorik, another oversight after this refactoring step.

[yorikvanhavre]

Awesome, thanks for the quick fix!!

I'm working on some proof of concept to create an IFC file that is fully parametric (export it out of FreeCAD, reimport it and have all your parametric objects fully restored to the last bit). Not so useful outside of FreeCAD (at least at the moment), but it's a concept widely used out there already, for ex. by Inkscape with SVG. Might give way to something interesting, we'll see...

BTW totally in love with ifcopenshell's serializer. I don't know any other app that has such a powerful mechanism. Too bad almost no other app is able to swallow the advanced breps yet :) That's the bad side of being avant-guarde!

[jf---]

Too bad almost no other app is able to swallow the advanced breps yet :) That's the bad side of being avant-guarde!

So, so true!
IFC4 support is an amazing feat indeed...
love the idea of parametric IFC parts, that's really ingenious

[aothms]

I'm working on some proof of concept to create an IFC file that is fully parametric (export it out of FreeCAD, reimport it and have all your parametric objects fully restored to the last bit). Not so useful outside of FreeCAD (at least at the moment)

I think it would be very interesting to determine the overlap with the definitions that are available in IFC. E.g. for a window the IfcWindowLiningProperties, IfcWindowPanelProperties, ... and see if we can pipe this information back into the standardization process.

BTW totally in love with ifcopenshell's serializer. I don't know any other app that has such a powerful mechanism. Too bad almost no other app is able to swallow the advanced breps yet :) That's the bad side of being avant-guarde!

So, so true!

One thing perhaps we can work on, is to give this automatic serializer more context of the kind of element it is serializing geometry for. For example, for many elements it might look for an extrusion of a footprint and export this accordingly. This results in smaller files, better semantics, but probably also a higher success ratio among other importers, because for example an extrusion of a circle segment is much better supported in tools than an advanced face with cylindrical surface.

[yorikvanhavre]

I found another bug @aothms is it okay to post it here, so we don't loose our momentum? ;) Tell me if you prefer me to open another issue for it.

When writing a new ifc file from python:

import ifcopenshell
f = ifcopenshell.file()
f.write("somefile.ifc")

The 3 lines inside the header lack the ending ";" character (not sure if they are mandatory, but ifcplusplus complains)

ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('ViewDefinition [CoordinationView]'),'2;1')
FILE_NAME('','2017-08-03T12:51:02',(),(),'IfcOpenShell 0.5.0-dev','IfcOpenShell 0.5.0-dev','')
FILE_SCHEMA(('IFC2X3'))
ENDSEC;
DATA;
ENDSEC;
END-ISO-10303-21;

I think it would be very interesting to determine the overlap with the definitions that are available in IFC. E.g. for a window the IfcWindowLiningProperties, IfcWindowPanelProperties, ... and see if we can pipe this information back into the standardization process.

Exactly! All the structure is there in IFC. All we would need is a kind of standardization of what parameter does what. Then it would be the application's job to do the correct thing with the correct parameter.

One thing perhaps we can work on, is to give this automatic serializer more context of the kind of element it is serializing geometry for. For example, for many elements it might look for an extrusion of a footprint and export this accordingly.

Maybe, but, the way it works now, it already makes IFC reach the level of STEP: you can always trust a step file. You can import and export them, your geometry will be there, faithfully. With the serializer, ifcopenshell reach es the same level: anything can be exported, anything can be imported. This is really precious. If that can be refined, it's good, but maybe not so important if IFC files evolve into something more parametric...

BTW just stumbled on this fascinating parametric example: https://github.com/jmirtsch/GeometryGymIFCExamples/blob/3dcae45940dff8cb7b3abdb9b4e549855b67084e/ConsoleParametricFooting/ParametricFooting.ifc

[aothms]

The 3 lines inside the header lack the ending ";" character (not sure if they are mandatory, but ifcplusplus complains)

Way ahead of you ;) https://github.com/IfcOpenShell/IfcOpenShell/commit/b696df0da18ce26776cffac70db58018c889ab75

it's good, but maybe not so important if IFC files evolve into something more parametric ... BTW just stumbled on this fascinating parametric example

Indeed, it's fascinating stuff, but it's also brittle in the way it's currently layed out. For example, #52= IFCREFERENCE($,'Items',$,(1),#51);. The (1) is for an attribute called ListPositions which

Optionally identifies an instance within a collection according to position starting at 1.

But IfcRepresentation.Items referred to here specifies a SET which is an unordered collection, applications may freely shuffle the elements in such a set, but then need to somehow remember to adjust this ListPositions accordingly.

To me this is all a big hack to something that is for example elegantly solved in the Linked Data domain [1] where relationships are first-class citizens and establishing equivalences is an elemantary building block of the language. Anyway, don't mean to evangelize or stand in the way of (obviously impressive) innovation from Jon et al. But I'm a bit sceptical about this introspection using IfcReference as it moves even more validation logic to end-user applications with already so many invalid files out there.

[1] http://www.buildingsmart-tech.org/future/linked-data

[yorikvanhavre]

Way ahead of you ;) b696df0

Should have guessed! :D Thanks for the fix

To me this is all a big hack to something that is for example elegantly solved in the Linked Data domain [1] where relationships are first-class citizens and establishing equivalences is an elemantary building block of the language. Anyway, don't mean to evangelize or stand in the way of (obviously impressive) innovation from Jon et al. But I'm a bit sceptical about this introspection using IfcReference as it moves even more validation logic to end-user applications with already so many invalid files out there.

You have a point there... That example is a complex web of links and references. It takes quite some time to follow all the relationships to finally understand the whole thing. But what I could grab of the linked data stuff seems complex as well.

I'm working on something dead simpler :) https://gist.github.com/yorikvanhavre/1d7072440c855866b2abaa9c38faa372 not very beautiful, but, as a proof of concept, it works... I'm thinking, all that would be actually needed, would be a kind of common agreement to use the same attributes...

[jmirtsch]

Hi Thomas,

Sure, the "parametric" implementation in IFC is far from perfect and can do with improvement. But it is flexible for piloting and testing it and is enabled in the official IFC4 release. Would be interested to learn and discuss how this can be improved.

Cheers,

Jon

[aothms]

Hi Jon, thanks for dropping by here, and again, I think we are all very lucky we have people like you at the forefront of innovation fighting the good fight. In the case of the parametric relationships I have some small concerns.

1. It seems there is a substantial overlap with ISO 10303-108: Parameterization and constraints for explicit geometric product models. But I don't see it referenced in IFC4. It defines similar constructs, such as:
   ~
   ENTITY instance_attribute_reference
   SUBTYPE OF (variable_semantics);
   attribute_name : attribute_identifier;
   owning_instance : representation_item;
   END_ENTITY;
   ~
   It's a slightly different approach (limited to representation_item and therefore no need for these IfcReference paths, but also basically a string reference to an entity attribute) with a whole set of where clauses to provide some checks and balances. A much more elaborate approach with also mathematical
   constructs in 10303-50 to truly create systems of references of arbitrary complexity.

2. In general though this kind of introspection is very hard to do in EXPRESS and sometimes I get the impression we are betting on a dead horse. For example in ifcOWL, basically all attribute values are fully qualified instances that can be further annotated and linked, without introspection hacks.

3. In the case of IfcReference.ListPositions which Optionally identifies an instance within a collection according to position starting at 1.. Only LISTs and ARRAYs have an order, a SET is not an ordered collection and there is therefore no reliable way to index its elements using an INTEGER. That LISTs and SETs have similar representation forms in IFC-SPF is mere coincedence, other representations will not be able to numerically index into a SET.

4. General concerns about complexity, lack of modularization, ...

But yeah, I understand that there are no perfect solutions to this problem probably and I am happy to see things moving forward at this pace.

[arzezniczak]

@yorikvanhavre

I'm working on something dead simpler :) https://gist.github.com/yorikvanhavre/1d7072440c855866b2abaa9c38faa372 not very beautiful, but, as a proof of concept, it works...

I had very similar idea months ago, but after discussion with my co-workers we decided to don't go that way. Yes, It's good to have a full list of "native" parameters in IFC file, but you have to think about this this way: how many times user will export from my app to IFC and then import this IFC again in my app? Why would user do this if he have option to save his work in native format?
In our case there was very small chance to have this scenario happen.

[theoryshaw]

@arzezniczak Unless you're co-creating content with someone that's use a different authoring program.

To date, I think our (AEC) industry hasn't really done that because we really haven't had the option to.

Just imagine if your programming language was shackled to your preferred IDE--must like our content is shackled to our BIM programs.

Although very nascent, @yorikvanhavre and I composed a bunch of construction details by roundtripping between Revit and Freecad, via the IFC format.

https://github.com/OpeningDesign/FreeMVD_WorkFlow/tree/master/Example%20Projects/Restaurant

Although we were forced to simplify everything down to simple extrusions and material names--it was still 'good enough' for a viable workflow.

In a way, it's kinda like 'Markdown' for our industry, that is, although there's a ton of other formats (html, doc, etc.) that give you more bells and whistles, Markdown's popularity springs from it's simplicity and portability.

What excites me about @yorikvanhavre and @jmirtsch's parametric initiatives is that it could be a way to improve the intelligence of this roundtripping workflow.

---

IMHO I think standards should spring out of actual, in the trenches, work. That is, release early and often and refine through actual billable work.

[yorikvanhavre]

I had very similar idea months ago, but after discussion with my co-workers we decided to don't go that way. Yes, It's good to have a full list of "native" parameters in IFC file, but you have to think about this this way: how many times user will export from my app to IFC and then import this IFC again in my app? Why would user do this if he have option to save his work in native format?

Of course, this is just a proof of concept. It would break very easily, for ex, what if another app modifies the IFC content, but not the FreeCAD-specific properties and chooses to restitute them "as is". But the thing is, I believe @jmirtsch will agree because he's fighting on that front, the parameters of parametric objects can be stored in an IFC file, and therefore the "IFC is not parametric" argument that is loudly heard around is invalid. It's much more a question of definition: which parameter does what...

Another question for @jmirtsch if it's ok to continue this discussion here: In your example the relationship between an attribute of an object and a reference property can be anything one's wild imagination dictates. For example, your footing has a length attribute, and then you have a quantity somewhere, that is linked to the length attribute. If you change the value of the quantity, the length changes. All the parametric construction of the object is built into the IFC file like that. Now sooner or later you'll have application X that will say "in our app we don't build footings that way, we don't specify the footing length directly". Doesn't it become really hard for an app to predict what such an IFC file will contain and "match" it with their own system?

[jmirtsch]

Hi Yorik,

I'm not sure if I'm directly answering your questions (perhaps we should move this discussion away from this thread issue), but there is an implementation requirement that an IFC exchange including a parametric definition, should also embed a static definition for software not implementing/requiring parametrics.

Here's a snippet identifying this:

          <IfcFootingType GlobalId="05LFc3yRX2SAW8wvz5h7FY" Name="PadFooting800x800x300">
            <HasAssignments>
              <IfcRelAssignsToProduct GlobalId="0M33Wvw_v8D8VUJ7XbBpGP" id="i93">
                <RelatingProduct GlobalId="3Nlaz12CjCCw_ZR4VWwm$7" Name="PadFootingParametric" xsi:type="IfcFootingType">

The attached image helps explain this. This is taken from https://github.com/BuildingSMART/IFC4-LV by @timchipman

Yes, care would be needed to ensure the parametric definition was not broken in downstream exchange but I primarily see the benefit of this in either object libraries or infrastructure projects.

Cheers,

Jon