Link IFC does not create Room/Space from IfcSpace

[torgeirfadnes]

We need IfcSpace to create a Room or a Space in Revit when linking in IFC.

[LostinBIM]

Yes the ifcSpace objects should be converted to Rooms (when it's the architectural model being linked) or to Spaces (when it's the MEP model being linked). I don't see how ifcSpaces as generic models help anyone. ifcSpaces as generic models only obstruct the views in Revit.

So far we have used Open IFC to get the ifcSpaces to convert to Rooms so we as MEP engineers can create spaces according to architect's model. But Open IFC seems to be inferior in other things when compared to Link IFC like creating in-place objects for identical geometry etc.

And it seems that Revit really struggles to keep the room boundaries intact so usually we end up with a garbage model where some of the Rooms are missing anyway. Though maybe that is something to improve in Revit itself so that when using linked files Rooms wouldn't need to require intact room boundaries or something.

[AngelVelezSosa]

How do you know if it should be a room or a space? Is that a UI option?

[LostinBIM]

Thanks for the quick reply and question.

Well I suppose the default should be that ifcSpace is converted to a room. Since that is an actual workflow: MEP engineer creates and updates Revit Spaces according to architect's model.

If there will be a way to differentiate between rooms and spaces in IFC in the future (I don't know if there already is) then the option to create spaces instead of rooms could be a nice bonus. But right now we as MEP engineers don't actually export spaces to our normal IFCs used for coordination (at least here in my country). We do export them to IFCs that are used in different simulation programs inside our company and then import that simulated data back from an updated IFC. But that particular workflow is handled by a tool in MagiCAD add-in for Revit so it doesn't exactly concern your project.

Basically I was just continuing what the original poster wished for so maybe he/she has a use for importing ifcSpaces as Revit Spaces. But in all honesty our company doesn't require that, we just need ifcSpaces as Rooms.

The deluxe option would of course be that we could have a similar IFC mapping option dialog for Link IFC as there is for Open IFC.

[AngelVelezSosa]

Actually, that does seem like a good request for IFC 5, to be able to identify the type of IfcSpace (architectural vs. MEP) since that does affect what should be created. This should be entered as a user request in forums.buildingsmart.org if you do feel like it is a good idea. Indeed, there are people that need rooms, and others that need spaces.

[tsolsen]

I might be misunderstanding the spec. But isn't the MEP use cases covered by the IFC4 IfcSpatialZone entity?

[kristoffer-tungland]

Currently we use a hybrid workaround to this issue. We strip down an IFC file to IFCSpace only and use open IFC on this file to generate an Revit file with Room bounding lines and Revit Rooms. This file is then link to MEP model with room bounding.

Then we remove all IFC space from the IFC and link it directly through Link IFC.

This is a time consuming task where we need to manipulate ifc files, and need to update two links every time we get a new IFC fil.

The link IFC function must create at least Room Separation lines and Rooms elements. The we can easily place space on the same place I MEP model and copy space and room number. I don’t think we need the possibility to choose this in first release, we need all IFCSpace Obects to be converted to room boundary lines and create room elements instead of DirectShape elements. They don’t help us at all

26. nov. 2019 kl. 18:24 skrev AngelVelezSosa notifications@github.com:



Actually, that does seem like a good request for IFC 5, to be able to identify the type of IfcSpace (architectural vs. MEP) since that does affect what should be created. This should be entered as a user request in forums.buildingsmart.org if you do feel like it is a good idea. Indeed, there are people that need rooms, and others that need spaces.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAutodesk%2Frevit-ifc%2Fissues%2F15%3Femail_source%3Dnotifications%26email_token%3DAFITOTQMEGR5TLQL3GP3CWDQVVLVJA5CNFSM4FOPVYMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFGZX3Q%23issuecomment-558734318&data=02%7C01%7C%7C3f08ee02b7b8495b3e0e08d772958382%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637103858788243052&sdata=cfrHYrC4ATAO%2BnPm6E2UKty%2FIaAZ0nA1X8sLIPePakg%3D&reserved=0, or unsubscribehttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFITOTQSFJU7TCHCMLCO77LQVVLVJANCNFSM4FOPVYMA&data=02%7C01%7C%7C3f08ee02b7b8495b3e0e08d772958382%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637103858788263068&sdata=nzlFtm%2FrjFdBo5loxjX1H5%2BFqEelHFRM3K9z%2BeGw%2FGM%3D&reserved=0.

COWI handles personal data as stated in our Privacy Noticehttps://www.cowi.com/privacy.

[LostinBIM]

tsolsen: Well that seems like something that could be used for zones that don't necessarily adhere to rooms/spaces and zones (pasted from the IFC spec):

NOTE The IfcSpatialZone is different to the IfcZone entity by allowing an own placement and shape representation, whereas IfcZone is only a grouping of IfcSpace's.

I guess the new MEP systems analysis tools in Revit 2020.1 update could be used to create something native representing that. Since it sounds like Revit couldn't do the converting in previous versions if that IfcSpatialZone doesn't adhere to the spaces/zones. Haven't had the chance to test Revit 2020 or 2020.1 yet though.

And those free form zones or zones defined by rooms/spaces are only there to help in certain things in MEP. We still need to use spaces created from architect's rooms at least in some point of a given project. Currently we don't have a need to make any export functions better since we are using MagiCAD IFC Export function. And like I said in the previous post we don't need to export or import spaces anyway except again with MagiCAD. Though I'm definitely not saying that me or our company represents all the users.

The pain is that import process that kristoffer-tungland also explained. We do need the ifcSpaces in architect models as rooms in Revit. So we can maybe all agree that ifcSpaces should be converted to rooms instead of generic models at least?

And if there are any ideas to help the conversion to keep the room boundaries intact, then those are also very welcome. kristoffer-tunglands idea about creating Room Separation lines on the boundaries of ifcSpaces if the surrounding walls aren't connected after conversion could be one solution worth investigating.

[Moult]

Time for a 2021 bump :)

IfcSpaces should come in as Revit rooms :)

[Moult]

@lejla-adsk not sure what the hooray is for ... as this is still broken 3 years later.

[lejla-adsk]

@Moult I saw the smileys in your message and misinterpreted it.

[Moult]

Just for the record that there is another workaround that:

1. Does not involve creating a separate IFC file just for spaces
2. You can keep your file as IFC4 so you don't lose data

However:

1. It still relies on File->Open, not Link IFC, since no progress has been made on this bug.
2. It requires modifying the lower elevation of your IFC spaces.

If you're doing an IFC4 project, the first thing to fix is to convert any tessellations which File->Open does not support into faceted brep. This is quite typical for IFC4s provided by ArchiCAD. You can fix this by using the free and open source BlenderBIM Add-on. Just import your IFC, select your spaces, enable the "Force Faceted BREPs" vendor workaround, and update the representations so that you get BREPs:

This will get you rooms in Revit, but no room bounding lines. To do this, you have to ensure that the bottom vertices of all rooms are exactly the same Z value as the containing building storey. You can again do this in Blender by selecting all rooms on a storey, going into edit mode, scale Z to 0, and snap to the building storey elevation.

The side effect is that you will lose the data about how some rooms might be lower or higher than the storey. Unfortunately Revit seems unforgiving on this requirement.

Once you've done these two, you will get bounded rooms. You will notice in the screenshot above the room on the left purposely is extra low whereas the room on the right has its bottom aligned to 0. Here is the result in Revit:

[iyurrr]

I was trying to figure out what defines the behavior of spaces and absolutely gave up.

At first I was trying this library, even on a simple zones it shows a negative result – all spaces are dropped into the Base Point and have incorrect shape.

Then I've switched to IFC Import via Graphisoft addon for Revit – the result was better, but I still had some issues with space placement.

After a dozens of test, I've found a strange relation – those spaces which have no openings (doors, windows) were imported incorrectly. Digging into the details showed my this:

So it seems the import reacts somehow to this nuances, but I don't really know hot to avoid it and prepare a stable workflow/workaround.

[iyurrr]

https://github.com/archimatika/archicad-template/blob/master/temp/exp_021.ifc

[Moult]

3 year anniversary bump!

[Moult]

The BlenderBIM Add-on now offers a patch for IFC space exports from ArchiCAD to Revit: https://github.com/IfcOpenShell/IfcOpenShell/commit/52e8ac386e97f633f63588aff75e63c870750cc0

[LostinBIM]

Hi,

returning to this subject after a couple of years. As it's still broken in Link IFC and the other functions Open IFC / Graphisoft's Improved IFC Import in their add-in are starting to fall apart. Not that the conversion of rooms are flawless in those either as has been mentioned in previous comments and in that IfcOpenShell link that Moult provided.

And there is indeed interesting commentary in the IfcOpenShell project that I hadn't run across before. Like the requirement that the rooms should have a lower bound with a Z value matching the Z value of the storey it is on. Which can't be a limitation going forward as plenty of buildings have differentiating floor surface heights on the same level of the building.

We have found further workarounds for projects where we don't need the ifcSpaces to be converted to rooms. At first I thought that Link IFC doesn't follow the "Import IFC Class Mapping" configuration file in Revit's IFC Options at all. Because even though if you change ifcSpaces to be converted to Rooms in the configuration file, Link IFC still converts those to Generic Models. But apparently that is just not a supported category for Link IFC and you can make Link IFC to convert ifcSpaces to e.g. "Planting" category with that configuration file.

And since "Planting" category is usually useless anyway for MEP we are considering to start converting ifcSpaces and ifcOpeningElement categories to Planting and just turn off this category in all of the necessary views in Revit.

(A bit related discussion about ifcOpeningElement category can be found here: https://sourceforge.net/p/ifcexporter/discussion/general/thread/c6959066/ )

But this is still just a workaround and doesn't solve the problem that MEP needs those ifcSpaces as rooms inside Revit if we want to make use of the Revit Spaces. And since Link IFC does indeed seem to follow the Import IFC Class Mapping configuration file at least nowadays I suppose the point that I raised earlier about detecting if ifcSpace objects in an IFC file are to be converted to Rooms or Spaces in Revit are moot. Since the end user could define this in the configuration file if Link IFC would just support the conversion in the first place?

[Moult]

Happy 4th birthday!

[AngelVelezSosa]

While this isn't yet explicitly on our public roadmap : https://trello.com/b/ldRXK9Gw/revit-public-roadmap, this is on our extended roadmap (which is still "things we intend to do" vs "things we'd like to do someday, maybe"). For all the reasons listed above, mapping a 3D shape with relations to objects/virtual boundarues (IFC) to an element that's defined by a level, a couple of offsets and a point is tricky. I'd like to get some feedback on this: my current thought is that link IFC would still continue to create what it does, but that there would be the option to "promote" or "associate" the space with a real Revit room (or MEP space), similar to a copy/monitor concept. Alternatively, we could teach these IFC spaces to be more room-y, but that seems like not the right direction.

[LostinBIM]

Thanks for the quick reply.

Well if I understood correctly what you meant then sure that could work. If by "associating" or automatically creating our MEP Spaces in Revit could be done according to whatever the fitting Revit category for the conversion of ifcSpaces would be.

And if that was what you meant then what comes to mind next are a couple of other possible issues:

1. The first problem is that as ifcSpaces get converted to Generic Models atm. these obstruct the (3D-)views of Revit. So the Revit category that ifcSpaces would be converted to should be something that wouldn't obstruct 3D views by default or could be turned off without loss of other visual information. Plenty of other things in an (architectural) IFC get converted to Generic Models so this is a particularly bad category. 1b. This could also be a lot worse problem if there are any other objects being converted to the same category. Though if the "new" tool/workflow could also differentiate between objects created from ifcSpaces and other IFC categories (e.g. by reading the IfcExportAs -property that is created in the .rvt during the conversion) then this could be avoided. 1c. And if ifcSpaces would still be converted to Generic Models then these could be handled in the same way as ifcOpeningElement objects in the coversion when looking at subcategories? As IfcOpeningElement gets its own subcategory under Generic Models and if you create a subcategory with a same name in your Revit template you can turn that subcategory off from all the necessary view templates in your Revit environment and in so doing prevent that "useless" subcategory from ever showing up in views. But for some reason ifcSpaces don't get their own subcategory or aren't associated with one.
2. This "new" workflow would have to work even when updating the linked and room bounded model (or whatever would be equivalent to room bounding with this "new" workflow). As a MEP company we get a new architectural IFC maybe as often as once a week in a given project. So if the ifcSpace hasn't changed the space that we have created according to it should still work even with an updated linked model. Of course creating new Spaces for any possible new ifcSpaces has to be done. And as a deluxe option whatever this "new" workflow/tool in Revit could be it also could tell us if any existing ifcSpaces have changed (e.g. area or volume) or been removed since the last update.

I can't talk with confidence about how this would work if you'd want to create Rooms from the ifcSpaces as we are not an architectural company. So are there even any use cases where creating Rooms from ifcSpaces in Revit is necessary? Perhaps if you get some old IFC model and you are asked to start creating a whole new Revit model from scratch of that particular building? Are there any use cases on the architectural side that would need Rooms to be updated according to a new updated IFC?

And what I gathered from your response is that the major problem between the ifcSpace and Revit Room/Space conversion is the way Rooms and Spaces are defined in Revit. Thanks for opening up this topic a bit more as I'm starting to understand the underlying problems more clearly. Converting between two objects that are defined in totally different principles is understandably difficult even if I'm not proficient in coding but understand concepts around it.

[tsolsen]

So are there even any use cases where creating Rooms from ifcSpaces in Revit is necessary?

Sure.

• Any time we receive a existing building, or take over a design proposal, as an IFC
• Opens up the ability to receive the room-program from the client, and load it into Revit as a native area, room or space

If anything, I'd rather have the IFC load, create the rooms in Revit but not place them, rather than the current behavior where the IfcSpace is placed as geometry, not spacial geometry.

[AngelVelezSosa]

There's a lot to parse there, but to your first issue, IfcSpaces should be mapped to a subcategory of Generic models, so you should be able to turn them off independent of the rest of the Generic Models. We are actually looking to make that even more useful by having nothing in IFC map to Generic Models, but instead to a sub-category of the same name. Right direction for that?

[lejla-adsk]

Just wanted to give you a heads up about this free add-in which might be useful for certain workflows as it pulls all room data from an IFC file and imports it to the current Revit project (there is a detailed video on this page): https://apps.autodesk.com/RVT/en/Detail/Index?id=5175665021513349789&appLang=en&os=Win64

[Moult]

Happy 5th birthday! This bug is now old enough to attend school :)

[AngelVelezSosa]

Not a bug, but an unimplemented feature. It is on the roadmap and it isn't trivial, since an IfcSpace and a Revit space (room/area/MEP space) are very different things. We are doing some foundational work that will make it easier to do this, although there are a lot of possibilities for what "this" is.

[thumDer]

@AngelVelezSosa with all due respect I think you are overthinking the problem, and therefore no improvement has been made for years. What I would suggest, is to simplify the issue to the following scenario:

• if IfcSpace has a geometry, then take its section at its container level (or somewhere above it, where it makes sense, could be customizable) -> closed polyline(s)
• upon linking create room separation lines from the outline that is the result of the previous operation
• create room on the target level, at a calculated point that is inside the outline
• adjust the base offset and unconnected height parameters to match the extreme extents of the opriginal IfcSpace geometry

The resulting Room/Space won't be exactly the same geometry wise as the IfcSpace, but still produces an endresult that is better than the current solution by orders of magnitude. This behaviour should be documented though.

[HL-code]

@AngelVelezSosa

Do you remember when we had a very informal meeting at The Venezian in Las Vegas 7-8 years ago. Round table on one of the lower floors there. You, me, my manager and one of your guys. That was right before you started working on the Link IFC functionality. We talked about Rooms and i specifically brought this up. I was fairly adamant about it :-) Create Rooms not static geometry.

To make it reliable it would have to create the separation lines as well. Which you previously did very well if the IFC-file did not contain 2. Level space boundaries.

As for UI option you already have it in the Import IFC Options. Write "Room" or "Space" instead of "Generic Model".

Just a trip down memory lane :-)