New version of GGIFC project

Hi, in the new version of ggIFC Project there isn’t a param for the Root Site/Building, I don’t know which is the new param for this.

Thanks for all your help.

Yes, we made a change here. The IfcProject component can now be wired in as the host of a site.
We are considering for GH2 whether we will pursue a top down hierarchy for the components or a bottom up (ie stories get wired into a building component)

Really thanks Jonm


i work as architect and urban designer, we are looking at Geogym as a tool for our bim process (espacially for large scale projects).

I have dowloaded the trial version but can’t figure properly how georefrencing works.
Is it possible to georeference a project in another crs then wsg84 ?



Unfortunately very few IFC models are georeferenced correctly.
Primarily this is because it was only improved in IFC4, and most IFC files
are still generated to IFC2x3 (although there is a work around using property sets).

Here’s a grasshopper example as I understand it. To my knowledge, the most important aspect is to nominate the EPSG code. If you have different requirements or a different understanding, let me know and we can discuss. It is possible in grasshopper to post process a file authored from another application and inject the georeferencing in.

210925 (19.9 KB)




Jonm, thanks a lot for your grasshoper definition.
Currently at the office we have a few options on the table.

Currently i have a 3d model that si ready to export. Here is a screenshot.

The origin basepoint XY coordinates are : X=1653000.68 and Y=8189178.90
Wich are the georeferencece coordinates of the project (the project’s crs is CC49) here is a screenshot of this selected point:

This point is very important because it also is the revit basepoint.

What we are trying to is to export and ifc file so that the file will be georeferenced base on the basepoint. Is that possible ?
I don’t understand if the grasshoper defition you poster reprojects the whole file georeferencing or not ? Or does it bake the model with a new ifc site ?

Currently we are looking at your software as really good solution for generation IFC files directly from rhino. If we could have a call it would be really nice for us to understand how your software works with georeferencing. (I have already read all your wiki)

Thanks a lot !


After some tweekign i have a few questions:

Does your software save files according to XY object locations ?
The software use to crash a lot when exporting ifc from rhino, do you have any wiki/documentation that showcases the export ifc process from grasshoper ?

Some feedback:
The “export IFC” tab appears to not work is that normal or is it a probleme cming from my computer ?
The rhino IFC layer tab does not update when layers change. to update the ifc layers we have to disbale then enable ifclayer tab.


The emphasis on our work is certainly authoring IFC from Grasshopper (also to a lesser extent import/extraction).
Even if you are modelling in Rhino, you can get higher quality IFC by processing in Grasshopper.
We have enabled the export directly from Rhino. But I don’t believe users want to be “constrained” in how they manage their model, and we don’t believe creating a lot of User Interface in Rhino is the best use of the limited resources we have.

There are a lot of examples for Grasshopper here, IFC Examples - Geometry Gym But if you have problems in getting started, you can either share some representative samples (publicly or privately) and we can arrange an online meeting where I can talk you through it.

Hope this makes sense. If you can provide the input files to replicate a crash, we will certainly review it.

In terms of project base point, then the “typical” implementation of this in IFC2x3 is a transform nominated on a site object (there is a more formal way to nominate this, but it’s not commonly used).

Maybe this is semantics, but Revit doesn’t have what I call “georeferencing” explicitly available, it has shared coordinates. But there is only True North explicitly nominated, which is different from grid north. I suspect a lot of users nominate grid north using true north attribute. We can help you still use local coordinates in Rhino/Grasshopper (remote coordinates lead to poorer performance) and importing relative to shared coordinates in Revit.

This is technical, but should make sense when demonstrated.

1 Like


I am using the example scripts on the linked website thanks a lot.
We need a bit of time at the office to process and test everything.
I will keep you informed, but it seems like eveyrthing should go smoothly with the grasshoper method.

Good day,

In terms of project base point, then the “typical” implementation of this in IFC2x3 is a transform nominated on a site object (there is a more formal way to nominate this, but it’s not commonly used).

How can this be done using GeometryGym in Rhino? I tried to set it in the ggRhinoIFCLayers (IfcSite → Placement → SetPlacementPlane), but this has no effect on the exported IFC.

Any suggestion, what I could do wrong?


1 Like

I guess we are trying to do the same thing.

Model in rhino in local cooordinate with the model being near to the origin.
When exporting an ifc we need it to land at the location then the models in revit using shared colrdinates (revit base point x=1650 y=2300 z=0).

We have been using thirf party software to do this but if it s possible to do it directly in grasshoper it would be great. @jonm


With the Geoemtry Gym tools, it’s much more powerful to generate the IFC from Grasshopper, even if you’re doing all the modelling from Rhino. I’ve concentrated on implementing the features of IFC there, without the resources to build a lot of UI in Rhino (which would overlap a lot with visualArq).

Here’s some samples about how to nominate grid coordinate systems in IFC. You can modify an IFC authored elsewhere (including visualArq), but I haven’t explicitly checked this yet. If you want to post or email a sample, I’ll check the required components are there.

In reality, shared coordinates in Revit typically are relative to a projected coordinate system, although there explicitly nominating the coordinate system (often by EPSG code) isn’t obvious. Also Revit only refers to true north, which is rarely the same as grid north. But I suspect most projects treat it as grid north.

In IFC4, there is the ability to nominate the projected coordinate system. I’ve identified a site, the Sydney Opera House in Civil3d, and identify a project base point in a projected coordinate system.

You can see the latitude and longitude (which can also be nominated in IFC for information but it’s often not accurately nominated in Revit). Here’s how to nominate the projected coordinate system in IFC4.

220621 SOH projected coordinates (19.1 KB)

In IFC2x3, this feature didn’t exist. I’d suggest to nominate the basepoint location using the context world coordinate system. If there is no rotation for project north, then working out the relative plane is trivial, but GG has a component to compute from project base point info if you include rotation.

220621 SOH projected coordinates (14.5 KB)

Let me know if this helps, or if you don’t get the results you need.



1 Like


This looks like what we are looking for.
I m trying to find wich of your grasshoper components i should use to assign ifc tags to geometry and export. i’m using this element (ifc product)

Sorry for this question i can’t find an example on your wiki that shows wich grasshoper compenent is used to get rhino geometry and assign tags and parameters.

Thanks a lot !

Hi Jon,

what a detailed and helpful answer, in particular the explanations regarding IFC4. Great, thanks!
As I’m currently using IFC 2x3, your example “220621 SOH projected coordinates” covers my usecase.

Howevery, when I do it that way, the target CDE (Trimble Connect) displays the data still in a local system. Whereas, if I set an ObjectPlacement to the IfcSite object, it works… I think that is an interpretation problem of Trimble Connect, do you agree?


look at this example, hopefully is what you are looking for. (gh file attached also) (16.0 KB)

Thanks for raising this. I believe many years ago, there was an “Implementers Agreement”
that grid coordinates would be established in the site local placement. Some of the viewers and applications don’t support the context world coordinate system, or must assume that all files involved in the project use a common base point (so can simply display the model in local coordinates).

So yes, establishing the transform on the site object is an appropriate strategy if the software you use doesn’t support the context placement. It might be worth contacting Trimble to seek their advice and see if they might change the strategy. There is a similar issue where often the site elevation is adopted from the attribute on IfcSite (Software such as Revit has a config option to include the elevation on both attribute and placement).