Question from BLIS to IAI

Question from BLIS to the IAI

This page contains a log of questions send by BLIS partners to the IAI.

Table of contents

- Geomtery Use Definitions for doors and windows (R1.5.1 implementers agreements)
+ Sharing instances in P21 files (R1.5.1 implementers agreements)
+ R151 agreements on GUID
+ Representation identifiers and context
+ Default domain views
+ Relative placements for IfcWindow
+ IfcElement.WR41
+ Calculated attribute values in IfcSpace
- Use of IfcRelContains
- Virtual space boundaries

Last update:23.11.1999

Questions

Question#1 : Geometry Use Definitions for doors and windows (R1.5.1 Implementers agreements)

Subitted by: Jiri Hietanen Submitted on: 14.08.1999 Submitted to: R1.5.1 implementers (ISG)

Question: The geometry use definition for IfcDoorPanel in R2.0 says
"The standard geometric representation of IfcDoorPanel is defined as agreed for handling the door lining by the implementers agreement for IFC Release 1.5.1. Eventual changes for Release 2.0 still needs to be defined."
The same applys to window geometry.
Could you please tell me where I can find the document with the R1.5.1 implementers agreements, I was not able to find it on the IAI FTP site.

Answered by: Answered on: Answered to:

Answer: It was agreed in the ITM Summit#13 in Munich, that the implementers agreements for R1.5.1 would be documented and published by Robin Drogemuller. $2000 was assigned from the IAI international budget for this purpose.

Discussion:

Question#2 : Sharing instances in P21 files

Subitted by: Jiri Hietanen Submitted on: 06.09.1999 Submitted to: R1.5.1 implementers (ISG)

Question: My question is about sharing instances in IFC exchange files and I would like to learn if the R1.5.1 implementers have come to some agreement on this.
If two or more objects share a instance of e.g. IfcCartesianPoint, does this mean that moving that point should effect all these objects? Or is it just a coinsidence that the objects have a point with the same coordinates and "connections" should be made explicitly using connection objects?

One place where sharing could be considered is the IfcOwnerHistory object. I have seen in R1.5.1 files that there is just one IfcOwnerHistory object which is referenced by everything in the model.

Is the P21 file just a means to transfer data, or does the structure how the data is written to the file tell something to the receiving application? Is a file which has one instance IfcCartesianPoint (0,0,0) different from a file which has 417 instances of IfcCartesianPoint (0,0,0)?

One minor example is IfcPolyline, which needs to be closed if it is used for a profile definition. Would this construct be allowed? (Instance #2 is used twice)

#1 = IFCPOLYLINE ((#2, #3, #4, #5, #2));
#2 = IFCCARTESIANPOINT ((0., 0., 0.));
#3 = IFCCARTESIANPOINT ((5800., 0., 0.));
#4 = IFCCARTESIANPOINT ((5800., 3800., 0.));
#5 = IFCCARTESIANPOINT ((0., 3800., 0.));

I know that the most efficient method for saving file size is to use WinZip, but we should decide if sharing instances is allowed or not.

Answered by: Thomas Liebich Answered on: 06.09.1999 Answered to: Jiri Hietanen

Answer: I recall that we discussed the same question in one of the last implementers meetings (probably in Munich?). The intent was the same, instead of defining e.g., an x/y/z direction

#1=IFCDIRECTION(1.,0.,0.);
#2=IFCDIRECTION(0.,1.,0.);
#3=IFCDIRECTION(0.,0.,1.);

x-times, for each placement, all placements could refer to the same instance

#101=IFCAXIS2PLACEMENT3D(#1001,#3,#1);
#102=IFCAXIS2PLACEMENT3D(#1002,#3,#1);
#103=IFCAXIS2PLACEMENT3D(#1003,#3,#1);
...

The conclusion was, that using the same instance shall not indicate any shared behavior, i.e. that all placements would have to change, if a direction changes. Only for the semantic relationships (objectified relationships 1N) "sharing" an instance (1) by many instances (N) means that a change in (1) affects all (N).

Discussion:

Question#3 : R151 agreements on GUID

Subitted by: Jiri Hietanen Submitted on: 24.09.1999 Submitted to: R1.5.1 implementers (ISG)

Question: Is there an agreement that the GUID for objects is never changed during the project?
What I mean is Application A writes out e.g a IfcWindow with a certain GUID and application B reads in the data. Does application B preserve the GUID from application A and pass it along to application C, or is application B allowed to substitute the GUID from application A with its own GUID?

My understanding is that the original GUID from application A is preserved, but I just wanted to make sure.

This becomes a bit more challenging when we talk about e.g. IfcSpaceBoundary.

The exchange of IfcSpaceBoundary might be supported by application B, BUT there is no consept of space boundary inside application B. This means that the space boundaries comming from Application A are discarded during IFC in and NEW space boundaries are generarted during IFC out. This would mean that the GUID for IfcSpaceBoundary changes.

Answered by: Thomas Liebich Answered on: 25.09.1999 Answered to: Jiri Hietanen

Answer: A GUID is meant to be unique for the life time of an object and shall not be changed by the receiving system. But of cause nobody can prevent the user to delete the wall and to create a new one, since he thought it would be easier than modifying it ...

Discussion: <Jiri Hietanen, 25.09.1999>
What shall be and what really is do not always meet ;-) Let me ask the same question another way - can an application that changes GUIDs pass IFC certification?
This is not a trivial questions and the implementers should UNDERSTAND what supporting this feature means to them.
BTW. I totally agree that the GUIDs should not change.

<Thomas Liebich, 25.09.1999>
yes, it shall be guaranteed, during the last 1.5.1 implementers meeting the agreement was to "guarantee roundtrip for GUID only for leaf node classes", the restriction was, that currently also IfcLocalPlacement has GUID, which provided some problems.

<Kari Karstila, 25.09.1999>
This (GUIDs do not change) should be the principle; AND if the object is deleted, no new object with the same scope (~ project ?) should re-use old GUIDs of the project. Otherwise applications could never tell if an object is the same they have dealt before.

(See JH question about space boundaries above) In my opinion it doesn't mean that GUID changed; according to the principle above this actually means that you replaced the old space boundaries with totally new space boundaries. They might have the same properties, but they are not the same by identity.

<Nikolay Shulga 26.09.1999>
Well, what if I change the type of the object?

<Kari Karstila, 26.09.1999>
This is getting more tricky. As a first quick reaction I would say that, still in principle if we want to say that this object is the same object (by identity), then the earlier rules apply. I guess this could apply to e.g. cases like- the entity type of the object changes over life-cycle because it becomes more specific; let's say we would like change object's type from more generic supertype to more specific subtype.
- in mapping objects between IFC releases there might be cases where we would need to map R2.0 objects to R1.5.1 IfcProxy because there is no corresponding entity type in R1.5.1
In both cases it's difficult to think of any reason why the GUID shouldn't be the same, if there is a requirement to support ability to trace object's life-cycle. In practice, though I can expect that somebody can give us examples where this is more difficult. IFC still lacks more comprehensive support versioning, change and life-cycle support, so we need to study the requirements more. I am wondering that we might found out that in some cases we could relax the requirement for GUID to stay the same over objects life-cycle. E.g. to go back to Jiri's example If space boundaries in some cases are pure logical connectivity elements (without own shape) between building elements and spaces, do we then really need GUID for them ? This could also be the case for some of the relationships IfcRel*, that now inherit .GlobalId IfcGloballyUniqueId from IfcRoot.

Question#4 : Representation identifiers and context

Subitted by: Jiri Hietanen Submitted on: 25.09.1999 Submitted to: MSG

Question:
Issue Description
What is the use of ContextIdentifier and ContextType in GeometricRepresentationContext? How do these relate to RepresentationIdentifier and RepresentationType in IfcShapeRepresentation? What are the allowed values for each of these?

Proposed Solution
Clarify meaning, define allowed values.
Partial answer can be found in GeometricRepresentationContext.WR21 and IfcShapeRepresentation.WR24
ContextIdentifier and RepresentationIdentifier are still unclear.

Answered by: Thomas Liebich Answered on: 09.11.1999 Answered to:

Answer: The ContextIdentifier and RepresentationIdentifier is open for interpretation by the system or user. It had been added for closer consistency with the original definitions rooted in ISO 10303-43 Representation Structures. For R2.x it should be considered to make the attribute optional.

Discussion: <Jiri Hietanen, 10.11.1999>
Could you please give an answer that I can understand? If the attributes are rooted in ISO 10303-43, then what was the purpose of the values in ISO 10303-43?
All I know is that I have 4 identifiers for a given piece of geometry, but I don't know how to use them. Would it be possible to give a set of simple example values for some usual case like

The architect draws a wall in the design stage.

Who is the target of the values? Should a program be able to deal with the values? If this is the case the allowed values have to be defined exactly. If the values are just shown to the end user then they can have a looser format.

<Nikolay Shulga, 10.11.1999>
40 series parts do not necessarily define semantics completely - the final definition is left to an AP using that particular construct. So the attributes mentioned above are indeed open to interpretation by user within IFCs. They may well be interpreted based on a particular application. I am not sure whether it is a desirable situation in IFC context.

Incidentally, it may be a good idea to spend some time reading STEP docs. There are many hundreds man-years worth of data exchange experience behind them. The 10303 series are not all that expensive.

<Jiri Hietanen, 10.11.1999>
It is my humble understanding that things have to be agreed in order to reach interoperability (actually, there is no other way). If the allowed values are not agreed upon they are basically worthless to the receiving application. The receiving end user may have some use of them, but not the application.

Square one: How do I use the 4 identifiers in my implementation?

<NS - it may be a good idea to spend some time reading STEP docs> Maybe I'll get to the STEP documents one of these long winter nights (of which we surely have enough), but I don't think this should be a requirement to IFC implementers.

<Nikolay Shulga, 10.11.1999>
Well, any initiative is be punished appropriately write up an implementor's agreement, see if others agree. Keep in mind that it may well depend on the application context - is it HVAC, FM, etc.

<JH - Knowing the STEP 40 series should not be a requirement for IFC implementation> May be not, but it sometimes helps to know what you are talking about - after all, STEP is THE data exchange technology of the '90, it is in production use around the world, we are borrowing heavily from it.. Seriosly, though, you are right, it hadn't been that way for a long time, and the price we paid is rather substantial.

Question#5 : Default domain views

Subitted by: Jiri Hietanen Submitted on: 25.09.1999 Submitted to: MSG

Question:
Issue Description
What is the list of �default� domain views for IfcRelAssignsProperties?

Proposed Solution
Define default domains

Answered by: Thomas Liebich Answered on: 09.11.1999 Answered to:

Answer: A list should be established as a documented implementers agreement by the R2.0 implementers.

Discussion:

Question#6 : Relative placements for IfcWindow

Subitted by: Jiri Hietanen Submitted on: 25.09.1999 Submitted to: MSG

Question:
Issue Description
What is the relative placement of IfcWindow (IfcOpeningElement), IfcWindowPanel and IfcWindowLining?

Proposed Solution
IfcWall <- IfcOpeningElement <- IfcWindow <- IfcWindowPanel
IfcWall <- IfcOpeningElement <- IfcWindow <- IfcWindowLining

Answered by: Thomas Liebich Answered on: 09.11.1999 Answered to:

Answer: Agreed � it should be documented as an implementers agreement by the R2.0 implementers.

Discussion:

Question#7 : IfcElement.WR41

Subitted by: Jiri Hietanen Submitted on: 25.09.1999 Submitted to: MSG

Question:
Issue Description
What should IfcElement.WR41 accomplish?

Proposed Solution
Please clarify.

Answered by: Thomas Liebich Answered on: 09.11.1999 Answered to:

Answer: It is to ensure that the element is referenced by exactly one project (to be defined in the context of one project). There is a cut&paste error; �IfcBuildingStorey� has to be replaced by �IfcElement�.

Discussion:

Question#8 : Calculated attribute values in IfcSpace

Subitted by: Jiri Hietanen Submitted on: 25.09.1999 Submitted to: MSG

Question:
Issue Description
What does the calcTotalVolume in IfcSpace mean? It uses the calcTotalArea as the area, but which height is used, calcAverageHeight, calcAverageGrossHeight or calcAverageClearHeight? For non prismatic spaces the volume can not be derived from the other calc values and it should be clear which volume is meant.

Proposed Solution
Introduce different calcVolume values like they already exist for calcAreas

Answered by: Thomas Liebich Answered on: 09.11.1999 Answered to:

Answer: The total volume is calculated based on the physical boundaries of the space in 3D (without covering). It is provided by the sending program, if it is able to generate the value from the geometry (otherwise left out). For prismatic spaces the value should be identical with calcTotalArea * calcAverageHeight.

Discussion:

Question#9 : Use of IfcRelContains

Subitted by: Jiri Hietanen Submitted on: 20.11.1999 Submitted to: MSG

Question: Issue Description
The inverse attribute IfcSpace.Contains is SET [02] OF IfcRelContains, should be SET [0?] OF IfcRelContains
Proposed Solution
Change to SET [0?] OF IfcRelContains

Answer
The constraint [02] had been introduced to enforce that only one instance of IfcRelContains (a 1N relationship) is used for all contained and referenced elements within that space.

Proposed resolution
For now it should be left as it is.

Question
The subclasses of IfcProduct that can act as an container in R2.0 are IfcSpace, IfcSite, IfcBuilding, and IfcBuildingStorey. Let us focus on IfcSpace as an example.

I understand from your answer that one IfcSpace can have one IfcRelContains that contains other objects and one IfcRelContains that references other objects. These IfcRelContains objects are identified through the attributes ContainedOrReferenced and RelationshipType

ContainedOrReferenced = Contained / Referenced
RelationshipType = SpaceContainer (in this case)

The motivation for my request was to make it possible for one space to contain or reference more than one logical group of objects. I could imagine that this will be useful when dealing with multiple domains, i.e. it could be better to make two separate groups instead of putting furniture and electrical fixtures into the same group.

It seems that there is a way already in R2.0. One has to first make an IfcGroup of a subset of the objects (i.e. furniture) in the space and then to assign this group to the space as one member in IfcRelContains. This way there would be one IfcRelContains for containment and one for reference, like intended, but it would also be possible to divide the contained objects into logical groups.

Is this idea 'legal', and if it is, is it something that was intended by the modelers?

From the implementation point of view it would be a bit easier if a space could contain multiple groups directly. However, this would require that a 'GroupPurpose' was added to IfcRelContains.

Answered by: Answered on: Answered to:

Answer:

Discussion:

Question#10 : Virtual space boundaries

Subitted by: Jiri Hietanen Submitted on: 20.11.1999 Submitted to: MSG

Question: Issue Description
Why is IfcSpaceBoundary.Bounds limited to one or two spaces? What is the special case for having 2 spaces connected to one space boundary?
Proposed Solution
Limit IfcSpaceBoundary.Bounds to reference only one space.

Answer
The special case is a virtual boundary, which bounds two spaces.

Proposed resolution
reject

Question
Let us think about the following scenario

---------------------
|          |        |
|          | Space2 |
|          |        |
| Space1   |--------|
|          |        |
|          | Space3 |
|          |        |
---------------------

If the boundaries between the spaces are physical (walls + slabs) Space1 would have 6 space boundaries
If the boundaries between the spaces are virtual Space1 would have 7 space boundaries

Although the difference seems to be small it is quite significant from the viewpoint of design applications. In the case of physical boundaries the design applications deal with the perimeter of the space, but they don't care what can be found behind the physical boundary elements. (In the example Space1 would have one space boundary that is aligned with the wall that separates Space 1 from Space2 and Space3. This boundary would not care what can be found behind the wall.)

In the case of virtual boundaries the design application would have to query the spaces that are aligned to another space and DIVIDE the space boundary into corresponding pieces. The additional task is to make this division. (In the example above Space1 would share a space boundary with Space2 and another with Space3)

If the number of spaces referencing a space boundary was limited to one, and there would be a relationship object connecting the space boundaries of two spaces, both virtual and physical boundaries would be dealt with in a uniform way. (IfcRelSeparatesSpaces either referencing a building element or being of type 'Virtual')

Using the virtual space boundary the way it is modeled now would not require huge amounts of effort and I'm sure each and every one of the design applications would be able support it - technically.

The question is how much effort we should put into the implementation AND how much this extra effort really helps the applications receiving the data.

Answered by: Answered on: Answered to:

Answer:

Discussion:

Question#11 :

Subitted by: Jiri Hietanen Submitted on: 25.09.1999 Submitted to: MSG

Question:

Answered by: Answered on: Answered to:

Answer:

Discussion:

Question#1 : Geometry Use Definitions for doors and windows (R1.5.1 Implementers agreements)
Subitted by:	Jiri Hietanen	Submitted on:	14.08.1999	Submitted to:	R1.5.1 implementers (ISG)
Question:	The geometry use definition for IfcDoorPanel in R2.0 says "The standard geometric representation of IfcDoorPanel is defined as agreed for handling the door lining by the implementers agreement for IFC Release 1.5.1. Eventual changes for Release 2.0 still needs to be defined." The same applys to window geometry. Could you please tell me where I can find the document with the R1.5.1 implementers agreements, I was not able to find it on the IAI FTP site.
Answered by:		Answered on:		Answered to:
Answer:	It was agreed in the ITM Summit#13 in Munich, that the implementers agreements for R1.5.1 would be documented and published by Robin Drogemuller. $2000 was assigned from the IAI international budget for this purpose.
Discussion:

Question#2 : Sharing instances in P21 files
Subitted by:	Jiri Hietanen	Submitted on:	06.09.1999	Submitted to:	R1.5.1 implementers (ISG)
Question:	My question is about sharing instances in IFC exchange files and I would like to learn if the R1.5.1 implementers have come to some agreement on this. If two or more objects share a instance of e.g. IfcCartesianPoint, does this mean that moving that point should effect all these objects? Or is it just a coinsidence that the objects have a point with the same coordinates and "connections" should be made explicitly using connection objects? One place where sharing could be considered is the IfcOwnerHistory object. I have seen in R1.5.1 files that there is just one IfcOwnerHistory object which is referenced by everything in the model. Is the P21 file just a means to transfer data, or does the structure how the data is written to the file tell something to the receiving application? Is a file which has one instance IfcCartesianPoint (0,0,0) different from a file which has 417 instances of IfcCartesianPoint (0,0,0)? One minor example is IfcPolyline, which needs to be closed if it is used for a profile definition. Would this construct be allowed? (Instance #2 is used twice) #1 = IFCPOLYLINE ((#2, #3, #4, #5, #2)); #2 = IFCCARTESIANPOINT ((0., 0., 0.)); #3 = IFCCARTESIANPOINT ((5800., 0., 0.)); #4 = IFCCARTESIANPOINT ((5800., 3800., 0.)); #5 = IFCCARTESIANPOINT ((0., 3800., 0.)); I know that the most efficient method for saving file size is to use WinZip, but we should decide if sharing instances is allowed or not.
Answered by:	Thomas Liebich	Answered on:	06.09.1999	Answered to:	Jiri Hietanen
Answer:	I recall that we discussed the same question in one of the last implementers meetings (probably in Munich?). The intent was the same, instead of defining e.g., an x/y/z direction #1=IFCDIRECTION(1.,0.,0.); #2=IFCDIRECTION(0.,1.,0.); #3=IFCDIRECTION(0.,0.,1.); x-times, for each placement, all placements could refer to the same instance #101=IFCAXIS2PLACEMENT3D(#1001,#3,#1); #102=IFCAXIS2PLACEMENT3D(#1002,#3,#1); #103=IFCAXIS2PLACEMENT3D(#1003,#3,#1); ... The conclusion was, that using the same instance shall not indicate any shared behavior, i.e. that all placements would have to change, if a direction changes. Only for the semantic relationships (objectified relationships 1N) "sharing" an instance (1) by many instances (N) means that a change in (1) affects all (N).
Discussion:

Question#3 : R151 agreements on GUID
Subitted by:	Jiri Hietanen	Submitted on:	24.09.1999	Submitted to:	R1.5.1 implementers (ISG)
Question:	Is there an agreement that the GUID for objects is never changed during the project? What I mean is Application A writes out e.g a IfcWindow with a certain GUID and application B reads in the data. Does application B preserve the GUID from application A and pass it along to application C, or is application B allowed to substitute the GUID from application A with its own GUID? My understanding is that the original GUID from application A is preserved, but I just wanted to make sure. This becomes a bit more challenging when we talk about e.g. IfcSpaceBoundary. The exchange of IfcSpaceBoundary might be supported by application B, BUT there is no consept of space boundary inside application B. This means that the space boundaries comming from Application A are discarded during IFC in and NEW space boundaries are generarted during IFC out. This would mean that the GUID for IfcSpaceBoundary changes.
Answered by:	Thomas Liebich	Answered on:	25.09.1999	Answered to:	Jiri Hietanen
Answer:	A GUID is meant to be unique for the life time of an object and shall not be changed by the receiving system. But of cause nobody can prevent the user to delete the wall and to create a new one, since he thought it would be easier than modifying it ...
Discussion:	<Jiri Hietanen, 25.09.1999> What shall be and what really is do not always meet ;-) Let me ask the same question another way - can an application that changes GUIDs pass IFC certification? This is not a trivial questions and the implementers should UNDERSTAND what supporting this feature means to them. BTW. I totally agree that the GUIDs should not change. <Thomas Liebich, 25.09.1999> yes, it shall be guaranteed, during the last 1.5.1 implementers meeting the agreement was to "guarantee roundtrip for GUID only for leaf node classes", the restriction was, that currently also IfcLocalPlacement has GUID, which provided some problems. <Kari Karstila, 25.09.1999> This (GUIDs do not change) should be the principle; AND if the object is deleted, no new object with the same scope (~ project ?) should re-use old GUIDs of the project. Otherwise applications could never tell if an object is the same they have dealt before. (See JH question about space boundaries above) In my opinion it doesn't mean that GUID changed; according to the principle above this actually means that you replaced the old space boundaries with totally new space boundaries. They might have the same properties, but they are not the same by identity. <Nikolay Shulga 26.09.1999> Well, what if I change the type of the object? <Kari Karstila, 26.09.1999> This is getting more tricky. As a first quick reaction I would say that, still in principle if we want to say that this object is the same object (by identity), then the earlier rules apply. I guess this could apply to e.g. cases like- the entity type of the object changes over life-cycle because it becomes more specific; let's say we would like change object's type from more generic supertype to more specific subtype. - in mapping objects between IFC releases there might be cases where we would need to map R2.0 objects to R1.5.1 IfcProxy because there is no corresponding entity type in R1.5.1 In both cases it's difficult to think of any reason why the GUID shouldn't be the same, if there is a requirement to support ability to trace object's life-cycle. In practice, though I can expect that somebody can give us examples where this is more difficult. IFC still lacks more comprehensive support versioning, change and life-cycle support, so we need to study the requirements more. I am wondering that we might found out that in some cases we could relax the requirement for GUID to stay the same over objects life-cycle. E.g. to go back to Jiri's example If space boundaries in some cases are pure logical connectivity elements (without own shape) between building elements and spaces, do we then really need GUID for them ? This could also be the case for some of the relationships IfcRel*, that now inherit .GlobalId IfcGloballyUniqueId from IfcRoot.

Question#4 : Representation identifiers and context
Subitted by:	Jiri Hietanen	Submitted on:	25.09.1999	Submitted to:	MSG
Question:	*Issue Description* What is the use of ContextIdentifier and ContextType in GeometricRepresentationContext? How do these relate to RepresentationIdentifier and RepresentationType in IfcShapeRepresentation? What are the allowed values for each of these? *Proposed Solution* Clarify meaning, define allowed values. Partial answer can be found in GeometricRepresentationContext.WR21 and IfcShapeRepresentation.WR24 ContextIdentifier and RepresentationIdentifier are still unclear.
Answered by:	Thomas Liebich	Answered on:	09.11.1999	Answered to:
Answer:	The ContextIdentifier and RepresentationIdentifier is open for interpretation by the system or user. It had been added for closer consistency with the original definitions rooted in ISO 10303-43 Representation Structures. For R2.x it should be considered to make the attribute optional.
Discussion:	<Jiri Hietanen, 10.11.1999> Could you please give an answer that I can understand? If the attributes are rooted in ISO 10303-43, then what was the purpose of the values in ISO 10303-43? All I know is that I have 4 identifiers for a given piece of geometry, but I don't know how to use them. Would it be possible to give a set of simple example values for some usual case like The architect draws a wall in the design stage. Who is the target of the values? Should a program be able to deal with the values? If this is the case the allowed values have to be defined exactly. If the values are just shown to the end user then they can have a looser format. <Nikolay Shulga, 10.11.1999> 40 series parts do not necessarily define semantics completely - the final definition is left to an AP using that particular construct. So the attributes mentioned above are indeed open to interpretation by user within IFCs. They may well be interpreted based on a particular application. I am not sure whether it is a desirable situation in IFC context. Incidentally, it may be a good idea to spend some time reading STEP docs. There are many hundreds man-years worth of data exchange experience behind them. The 10303 series are not all that expensive. <Jiri Hietanen, 10.11.1999> It is my humble understanding that things have to be agreed in order to reach interoperability (actually, there is no other way). If the allowed values are not agreed upon they are basically worthless to the receiving application. The receiving end user may have some use of them, but not the application. Square one: How do I use the 4 identifiers in my implementation? <NS - it may be a good idea to spend some time reading STEP docs> Maybe I'll get to the STEP documents one of these long winter nights (of which we surely have enough), but I don't think this should be a requirement to IFC implementers. <Nikolay Shulga, 10.11.1999> Well, any initiative is be punished appropriately write up an implementor's agreement, see if others agree. Keep in mind that it may well depend on the application context - is it HVAC, FM, etc. <JH - Knowing the STEP 40 series should not be a requirement for IFC implementation> May be not, but it sometimes helps to know what you are talking about - after all, STEP is THE data exchange technology of the '90, it is in production use around the world, we are borrowing heavily from it.. Seriosly, though, you are right, it hadn't been that way for a long time, and the price we paid is rather substantial.

Question#5 : Default domain views
Subitted by:	Jiri Hietanen	Submitted on:	25.09.1999	Submitted to:	MSG
Question:	*Issue Description* What is the list of �default� domain views for IfcRelAssignsProperties? *Proposed Solution* Define default domains
Answered by:	Thomas Liebich	Answered on:	09.11.1999	Answered to:
Answer:	A list should be established as a documented implementers agreement by the R2.0 implementers.
Discussion:

Question#6 : Relative placements for IfcWindow
Subitted by:	Jiri Hietanen	Submitted on:	25.09.1999	Submitted to:	MSG
Question:	*Issue Description* What is the relative placement of IfcWindow (IfcOpeningElement), IfcWindowPanel and IfcWindowLining? *Proposed Solution* IfcWall <- IfcOpeningElement <- IfcWindow <- IfcWindowPanel IfcWall <- IfcOpeningElement <- IfcWindow <- IfcWindowLining
Answered by:	Thomas Liebich	Answered on:	09.11.1999	Answered to:
Answer:	Agreed � it should be documented as an implementers agreement by the R2.0 implementers.
Discussion:

Question#7 : IfcElement.WR41
Subitted by:	Jiri Hietanen	Submitted on:	25.09.1999	Submitted to:	MSG
Question:	*Issue Description* What should IfcElement.WR41 accomplish? *Proposed Solution* Please clarify.
Answered by:	Thomas Liebich	Answered on:	09.11.1999	Answered to:
Answer:	It is to ensure that the element is referenced by exactly one project (to be defined in the context of one project). There is a cut&paste error; �IfcBuildingStorey� has to be replaced by �IfcElement�.
Discussion:

Question#8 : Calculated attribute values in IfcSpace
Subitted by:	Jiri Hietanen	Submitted on:	25.09.1999	Submitted to:	MSG
Question:	*Issue Description* What does the calcTotalVolume in IfcSpace mean? It uses the calcTotalArea as the area, but which height is used, calcAverageHeight, calcAverageGrossHeight or calcAverageClearHeight? For non prismatic spaces the volume can not be derived from the other calc values and it should be clear which volume is meant. Proposed Solution Introduce different calcVolume values like they already exist for calcAreas
Answered by:	Thomas Liebich	Answered on:	09.11.1999	Answered to:
Answer:	The total volume is calculated based on the physical boundaries of the space in 3D (without covering). It is provided by the sending program, if it is able to generate the value from the geometry (otherwise left out). For prismatic spaces the value should be identical with calcTotalArea * calcAverageHeight.
Discussion:

Question#9 : Use of IfcRelContains
Subitted by:	Jiri Hietanen	Submitted on:	20.11.1999	Submitted to:	MSG
Question:	Issue Description The inverse attribute IfcSpace.Contains is SET [02] OF IfcRelContains, should be SET [0?] OF IfcRelContains Proposed Solution Change to SET [0?] OF IfcRelContains Answer The constraint [02] had been introduced to enforce that only one instance of IfcRelContains (a 1N relationship) is used for all contained and referenced elements within that space. Proposed resolution For now it should be left as it is. Question The subclasses of IfcProduct that can act as an container in R2.0 are IfcSpace, IfcSite, IfcBuilding, and IfcBuildingStorey. Let us focus on IfcSpace as an example. I understand from your answer that one IfcSpace can have one IfcRelContains that contains other objects and one IfcRelContains that references other objects. These IfcRelContains objects are identified through the attributes ContainedOrReferenced and RelationshipType ContainedOrReferenced = Contained / Referenced RelationshipType = SpaceContainer (in this case) The motivation for my request was to make it possible for one space to contain or reference more than one logical group of objects. I could imagine that this will be useful when dealing with multiple domains, i.e. it could be better to make two separate groups instead of putting furniture and electrical fixtures into the same group. It seems that there is a way already in R2.0. One has to first make an IfcGroup of a subset of the objects (i.e. furniture) in the space and then to assign this group to the space as one member in IfcRelContains. This way there would be one IfcRelContains for containment and one for reference, like intended, but it would also be possible to divide the contained objects into logical groups. Is this idea 'legal', and if it is, is it something that was intended by the modelers? From the implementation point of view it would be a bit easier if a space could contain multiple groups directly. However, this would require that a 'GroupPurpose' was added to IfcRelContains.
Answered by:		Answered on:		Answered to:
Answer:
Discussion:

Question#10 : Virtual space boundaries
Subitted by:	Jiri Hietanen	Submitted on:	20.11.1999	Submitted to:	MSG
Question:	Issue Description Why is IfcSpaceBoundary.Bounds limited to one or two spaces? What is the special case for having 2 spaces connected to one space boundary? Proposed Solution Limit IfcSpaceBoundary.Bounds to reference only one space. Answer The special case is a virtual boundary, which bounds two spaces. Proposed resolution reject Question Let us think about the following scenario --------------------- \| \| \| \| \| Space2 \| \| \| \| \| Space1 \|--------\| \| \| \| \| \| Space3 \| \| \| \| --------------------- If the boundaries between the spaces are physical (walls + slabs) Space1 would have 6 space boundaries If the boundaries between the spaces are virtual Space1 would have 7 space boundaries Although the difference seems to be small it is quite significant from the viewpoint of design applications. In the case of physical boundaries the design applications deal with the perimeter of the space, but they don't care what can be found behind the physical boundary elements. (In the example Space1 would have one space boundary that is aligned with the wall that separates Space 1 from Space2 and Space3. This boundary would not care what can be found behind the wall.) In the case of virtual boundaries the design application would have to query the spaces that are aligned to another space and DIVIDE the space boundary into corresponding pieces. The additional task is to make this division. (In the example above Space1 would share a space boundary with Space2 and another with Space3) If the number of spaces referencing a space boundary was limited to one, and there would be a relationship object connecting the space boundaries of two spaces, both virtual and physical boundaries would be dealt with in a uniform way. (IfcRelSeparatesSpaces either referencing a building element or being of type 'Virtual') Using the virtual space boundary the way it is modeled now would not require huge amounts of effort and I'm sure each and every one of the design applications would be able support it - technically. The question is how much effort we should put into the implementation AND how much this extra effort really helps the applications receiving the data.
Answered by:		Answered on:		Answered to:
Answer:
Discussion:

Question#11 :
Subitted by:	Jiri Hietanen	Submitted on:	25.09.1999	Submitted to:	MSG
Question:
Answered by:		Answered on:		Answered to:
Answer:
Discussion: