I stumbled upon the following, in the Ifc spec:
"Only the core or constructional part of this construction is considered to be a slab. The upper finish (flooring, roofing) and the lower finish (ceiling, suspended ceiling) are considered to be coverings. A special type of slab is the landing, described as a floor section to which one or more stair flights or ramp flights connect."
In other Words, all architectural flooring belongs in IfcCovering, and not as they by default not, export to IfcSlab. Obvious and would help me organice my IFC files a great deal.
The only problem is, that I can't get the exporter to do it, when adding Ifccovering in the export table, or when adding the IfcExportAs parameter in Revit and filling in the type. In the same model, I can get a mass to export to IfcCovering by using IfcExportAs, without any problems.
Am I missing the obvious?
(Seperated Family Types for Flooring and Slab, not just "Floor", would help a great deal in Revit, but that's kinda' of topic here ;)
regards, troels
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This has been something I have been nagging about for a long time... Same goes for Wall Sidings and some other stuff.
Basically most Revit System Families cannot be overridden upon exported (or import). They're hardcoded into a certain mapping. Problem is, it's not really consequently executed.
In Place families will override. Created as a System Family they won't.
You can define overrides in the Export table, but they won't work.
However, try finding IfcSlab in the Import table. It's not there. However, IfcWall is and this can't be overridden either.
It's sort of a mess really...
I vote for complete freedom in mapping options. If I want to map a Floor to something else (e.g. an IfcRamp because Revit Ramps SUCK), I should be able to do that. Both on export and import.
But a nice first step would be to have the ability to override Finish layers into IfcCovering...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes! This is something that has been bugging me for a long time too, particularly the inability to map To/From various IFC Entities PredefinedTypes which can in many instances mean very different things. IfcCovering is a good example:
oh and IfcCurtainWall = Curtain Wall (not Generic Model!!)
I understand that Import is outside the scope of this forum .. but at least here we know the right eyeballs are on it, so as Martin says, complete freedom in mapping options for both Import and Export.
Last edit: Owen Sharp 2014-01-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the interesting discussion. I'd say there are a couple of issues here.
Ability to export (or import) anything to anything. I lean toward that direction, but (of course) it isn't as trivial as it seems.
Ability to assign different assignments to different layers of an object - say, IfcSlab for the structural layers of the floor and IfcCovering for the finish layers. That could be done automatically, but then that would conflict with #1 above. So there will have to be some thought about proper UI for that.
It seems like a hardwired #2 would be a useful first step: IfcCovering for the finish layer, IfcSlab (or IfcFooting) for the rest. We can tackle #1 later.
Does that make sense?
Thanks,
Angel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We can all agree, that free mapping is what we need. But I also understand that there is some internal wirings that makes this complicated. Option 2 is kinda already in the product and supported in scheduling. I don't have a need for different layers, going into either slab or covering, as our floors are devided between top layer(s)architect model and bearing floors in the structural model. But others might, and it would be nice, if/when the floors havn't been devided.
I would assume:
1. Ifcslab. If the Floor is bearing (drawn as strc.floor).
2. Ifccovering.flooring. If it's non bearing (drawn as arch. floor).
3. IfcFooting. If it's a Foundation Slab or Wall Foundation (they already do this)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, so it looks like a short-tem solution may be even simpler, as stated above, that non-bearing floors go to IfcCovering.Flooring instead of IfcSlab, no user intervention required. Would that meet the 80% case?
Thanks,
Angel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe Foundation Slab / baseslab should be exported as IfcSlab with enumeration BASESLAB.
If we look into the IFC spec (both 2x3 and 4) for IfcSlab it has an Enumeration BASESLAB:
"BASESLAB: The slab is used to represent a floor slab against the ground (and thereby being a part of the foundation). Another name is mat foundation."
IFC 4 spec for IfcFooting have this note (not included in IFC 2x3):
"NOTE Slab foundations, also called slab-on-grade, are not instantiated as IfcFooting but as IfcSlab or as its subtype IfcSlabStandardCase, IfcSlabElementedCase with a predefined type of IfcSlabTypeEnum.BASESLAB. Deep foundations, which transfer the loads to subsurface layers, are represented by IfcPile."
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure that differ the export on structural/non structural floors will work for all projects. If the floor is divided between structural floor and top floor/ceilings, as mentioned in earlier post, it will do the work, but if the floor is one element, as I believe it is in several projects, all layers will be exported as IfcSlab. In this case dividing the export by layers or core/not core could be a solution...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And I would think that it doesn't matter for projects that model
bearing/non-bearing as one combined element, either walls or floors. If
that's a problem in IFC, it's going to be a problem in Revit too (think
structural views)
I'm not sure that differ the export on structural/non structural floors
will work for all projects. If the floor is divided between structural
floor and top floor/ceilings, as mentioned in earlier post, it will do the
work, but if the floor is one element, as I believe it is in several
projects, all layers will be exported as IfcSlab. In this case dividing the
export by layers or core/not core could be a solution...
To make a consistent IFC export I believe the exporter should have the same solution for floors and walls.
I've found nothing in IFC specs regarding dividing walls into IfcWall and IfcCovering (as you should expect reading IfcSlab requirements), so I guess there must be an UI where the user decide if the wall should be divided into IfcWall/IfcCovering or be exported as IfcWall only.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually there is a IfcCovering.SIDING for wooden panelling of the exterior
of walls. Not quite sure why there's only that and not others but still...
If I had to choose I'd probably would place other specific finish layers
(e.g. stucco or metal panelling) in Covering too.
There is IfcCovering.CLADDING which could be used for interior/exterior wall finish layers.
What I meant earlier was that for floors it's required to divide into IfcSlab/IfcCovering, but for walls there are no requirements.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well.. there is the division of IfcWallType into IfcWall, IfcWallStandardCase and IfcWallElementedCase (IFC4). Elementet is then divided further.
Does this cover what your thinking about?
Last edit: Troels Olsen 2014-01-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just want to follow up on this one, and ask if any progress is being made? Or a possible timeframe?
We are entering a collaboration with a FM supplier, to get .IFC up and running as a possible deliverable directly into their system (yay!).
The situation is, that they only need a part of the data, for FM. One thing they tell us, is that only covering is interesting for their clients, not slabs. On top of that, slabs are very heavy for them to handle. So it would be of a very big advantage, if we could filter the floors onto covering and slabs already at export and then only import coverings onto the FM. Othervise they would have to import everything and set up a extra cycle, to filter through non-bearing/bearing properties.
regards, Troels
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I started looking at this a while ago, and realized that a very minor change would result in a lot of very different IFC files. So I am now thinking about a 2-stage approach: (1) continue exporting all floors as IfcSlab, but allow IfcExportAs to override, and then (2) switch the default to IfcCovering.FLOOR. I'll see about expediting part (1) of that.
Thanks,
Angel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sounds like just implementing part 1 is the best option to me. Simply
because a Revit Floor could also be representing other things such as a
Foundation (not supposed to, but not always something you can prevent
others from doing), a Ramp (not every shape is doable with the Ramp tool)
and so on.
Also, while you're at it: could you also expedite this for Walls, Roofs,
Curtain Systems, and so on? Basically other, currently sealed off, System
categories?
I'd agree that (1) is really all that is necessary - as Martijn points out they may be used for more than just 'Floors' as is so if you change the default mapping its going to require overrides in many instances either way
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your reply. Just having option (1), would alone bring us really close to the goal! And yes I agree, option (2) is a more involved step, that would change existing behavior, and inherently needing more caution and time to solve.
thanks,
Troels
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I ran into a similar situation today. I have a bunch of wall fenders, modelled as sub categories of wall sweeps, that I want to export to types of IfcCovering or IfcRailing. In the export options, I specify the sub category of sweep and export. But this to no effect, other than that Revit exports them to IfcBuildingelementproxy.
So.. I'd like full support for exporting walls to covering/railing types, as this would allow me to seperate sweeps out into appropriate enums.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Following Arjan's post, has there been any follow up? I'm currently trying this out for Revit 2017 however it still won't let me override a wall to be an IfcCovering and a ceiling is always a Suspended Ceiling when opened in Solibri. Strangely floors in Revit can be overriden to be IfcCovering so just wondering why walls and ceilings can't be.
Any assistance greatly appreciated.
Attach the Revit files and Ifc files for your information.
I stumbled upon the following, in the Ifc spec:
"Only the core or constructional part of this construction is considered to be a slab. The upper finish (flooring, roofing) and the lower finish (ceiling, suspended ceiling) are considered to be coverings. A special type of slab is the landing, described as a floor section to which one or more stair flights or ramp flights connect."
In other Words, all architectural flooring belongs in IfcCovering, and not as they by default not, export to IfcSlab. Obvious and would help me organice my IFC files a great deal.
The only problem is, that I can't get the exporter to do it, when adding Ifccovering in the export table, or when adding the IfcExportAs parameter in Revit and filling in the type. In the same model, I can get a mass to export to IfcCovering by using IfcExportAs, without any problems.
Am I missing the obvious?
(Seperated Family Types for Flooring and Slab, not just "Floor", would help a great deal in Revit, but that's kinda' of topic here ;)
regards, troels
This has been something I have been nagging about for a long time... Same goes for Wall Sidings and some other stuff.
Basically most Revit System Families cannot be overridden upon exported (or import). They're hardcoded into a certain mapping. Problem is, it's not really consequently executed.
In Place families will override. Created as a System Family they won't.
You can define overrides in the Export table, but they won't work.
However, try finding IfcSlab in the Import table. It's not there. However, IfcWall is and this can't be overridden either.
It's sort of a mess really...
I vote for complete freedom in mapping options. If I want to map a Floor to something else (e.g. an IfcRamp because Revit Ramps SUCK), I should be able to do that. Both on export and import.
But a nice first step would be to have the ability to override Finish layers into IfcCovering...
Yes! This is something that has been bugging me for a long time too, particularly the inability to map To/From various IFC Entities PredefinedTypes which can in many instances mean very different things. IfcCovering is a good example:
IfcCovering.CEILING = Ceilings
IfcCovering.FLOORING = Floors (Architectural)
IfcCovering.CLADDING = Walls or Generic Models
etc
oh and IfcCurtainWall = Curtain Wall (not Generic Model!!)
I understand that Import is outside the scope of this forum .. but at least here we know the right eyeballs are on it, so as Martin says, complete freedom in mapping options for both Import and Export.
Last edit: Owen Sharp 2014-01-15
Hi All,
Thanks for the interesting discussion. I'd say there are a couple of issues here.
It seems like a hardwired #2 would be a useful first step: IfcCovering for the finish layer, IfcSlab (or IfcFooting) for the rest. We can tackle #1 later.
Does that make sense?
Thanks,
Angel
It does.
We can all agree, that free mapping is what we need. But I also understand that there is some internal wirings that makes this complicated. Option 2 is kinda already in the product and supported in scheduling. I don't have a need for different layers, going into either slab or covering, as our floors are devided between top layer(s)architect model and bearing floors in the structural model. But others might, and it would be nice, if/when the floors havn't been devided.
I would assume:
1. Ifcslab. If the Floor is bearing (drawn as strc.floor).
2. Ifccovering.flooring. If it's non bearing (drawn as arch. floor).
3. IfcFooting. If it's a Foundation Slab or Wall Foundation (they already do this)
OK, so it looks like a short-tem solution may be even simpler, as stated above, that non-bearing floors go to IfcCovering.Flooring instead of IfcSlab, no user intervention required. Would that meet the 80% case?
Thanks,
Angel
I believe Foundation Slab / baseslab should be exported as IfcSlab with enumeration BASESLAB.
If we look into the IFC spec (both 2x3 and 4) for IfcSlab it has an Enumeration BASESLAB:
"BASESLAB: The slab is used to represent a floor slab against the ground (and thereby being a part of the foundation). Another name is mat foundation."
IFC 4 spec for IfcFooting have this note (not included in IFC 2x3):
"NOTE Slab foundations, also called slab-on-grade, are not instantiated as IfcFooting but as IfcSlab or as its subtype IfcSlabStandardCase, IfcSlabElementedCase with a predefined type of IfcSlabTypeEnum.BASESLAB. Deep foundations, which transfer the loads to subsurface layers, are represented by IfcPile."
I'm not sure that differ the export on structural/non structural floors will work for all projects. If the floor is divided between structural floor and top floor/ceilings, as mentioned in earlier post, it will do the work, but if the floor is one element, as I believe it is in several projects, all layers will be exported as IfcSlab. In this case dividing the export by layers or core/not core could be a solution...
Would work for me...
And I would think that it doesn't matter for projects that model
bearing/non-bearing as one combined element, either walls or floors. If
that's a problem in IFC, it's going to be a problem in Revit too (think
structural views)
Met vriendelijke groet,
Martijn de Riet
MdR Advies
De Papiermaker 22
5283 ZS Boxtel
martijnderiet@mdr-advies.nl
www.mdr-advies.nl
Tel: +31411 67 11 51
Mob: +316 24 28 31 75
T @mdradvies
2014/1/16 Reidar Ristesund reidarjr@users.sf.net
To make a consistent IFC export I believe the exporter should have the same solution for floors and walls.
I've found nothing in IFC specs regarding dividing walls into IfcWall and IfcCovering (as you should expect reading IfcSlab requirements), so I guess there must be an UI where the user decide if the wall should be divided into IfcWall/IfcCovering or be exported as IfcWall only.
Actually there is a IfcCovering.SIDING for wooden panelling of the exterior
of walls. Not quite sure why there's only that and not others but still...
If I had to choose I'd probably would place other specific finish layers
(e.g. stucco or metal panelling) in Covering too.
There is IfcCovering.CLADDING which could be used for interior/exterior wall finish layers.
What I meant earlier was that for floors it's required to divide into IfcSlab/IfcCovering, but for walls there are no requirements.
Well.. there is the division of IfcWallType into IfcWall, IfcWallStandardCase and IfcWallElementedCase (IFC4). Elementet is then divided further.
Does this cover what your thinking about?
Last edit: Troels Olsen 2014-01-17
Hi,
I just want to follow up on this one, and ask if any progress is being made? Or a possible timeframe?
We are entering a collaboration with a FM supplier, to get .IFC up and running as a possible deliverable directly into their system (yay!).
The situation is, that they only need a part of the data, for FM. One thing they tell us, is that only covering is interesting for their clients, not slabs. On top of that, slabs are very heavy for them to handle. So it would be of a very big advantage, if we could filter the floors onto covering and slabs already at export and then only import coverings onto the FM. Othervise they would have to import everything and set up a extra cycle, to filter through non-bearing/bearing properties.
regards, Troels
Hi Troels,
I started looking at this a while ago, and realized that a very minor change would result in a lot of very different IFC files. So I am now thinking about a 2-stage approach: (1) continue exporting all floors as IfcSlab, but allow IfcExportAs to override, and then (2) switch the default to IfcCovering.FLOOR. I'll see about expediting part (1) of that.
Thanks,
Angel
Hi Angel,
Sounds like just implementing part 1 is the best option to me. Simply
because a Revit Floor could also be representing other things such as a
Foundation (not supposed to, but not always something you can prevent
others from doing), a Ramp (not every shape is doable with the Ramp tool)
and so on.
Also, while you're at it: could you also expedite this for Walls, Roofs,
Curtain Systems, and so on? Basically other, currently sealed off, System
categories?
Kind regards,
Martijn de Riet
MdR Advies
martijnderiet@mdr-advies.nl
www.mdr-advies.nl
I'd agree that (1) is really all that is necessary - as Martijn points out they may be used for more than just 'Floors' as is so if you change the default mapping its going to require overrides in many instances either way
Hi Angel,
Thank you for your reply. Just having option (1), would alone bring us really close to the goal! And yes I agree, option (2) is a more involved step, that would change existing behavior, and inherently needing more caution and time to solve.
thanks,
Troels
I ran into a similar situation today. I have a bunch of wall fenders, modelled as sub categories of wall sweeps, that I want to export to types of IfcCovering or IfcRailing. In the export options, I specify the sub category of sweep and export. But this to no effect, other than that Revit exports them to IfcBuildingelementproxy.
So.. I'd like full support for exporting walls to covering/railing types, as this would allow me to seperate sweeps out into appropriate enums.
Hi all,
Any feedback on this toppic yet?
Greetings,
Arjan
Hi all,
Following Arjan's post, has there been any follow up? I'm currently trying this out for Revit 2017 however it still won't let me override a wall to be an IfcCovering and a ceiling is always a Suspended Ceiling when opened in Solibri. Strangely floors in Revit can be overriden to be IfcCovering so just wondering why walls and ceilings can't be.
Any assistance greatly appreciated.
Attach the Revit files and Ifc files for your information.
Cheers
Mark
HI Mark, all,
Unfortunately there hasn't been progress on this yet, Right now we are concentrating on IFC4 certification.
Regards,
Angel
Angel,
Thanks for your response. Would be great if you could advise if/when this has been developed further.
Many thanks
Mark