Shared Coordinate System

It looks like you would need to transform your Incoming Revit to Rhino geometry, similar to this recent example by Scott.

For instance, i added this box into revit from the world revit location and it comes into the oriented view correctly. If you exported the revit from the true north orientation to Revitzo, the Rhino geometry would need to be oriented to that direction as well.

Hi Japhy, thanks for the response! After more investigation, I believe it’s not an issue between Rhino and Revit - the location node helps with locating and orienting the geometry. The real problem is when Rhino is exported to Revizto, the default setting is from (0,0,0) regardless. The next question is how you move the Rhino geometry in Revizto space (turned out to be the only way as far as I know) using the data extracted from Project Location? It’s easy to get the degrees right but I have no idea what to do with the other two numbers derived from EWO and NSO.



Is revitzo transforming the Revit as well? You can use the revit info to transform the Rhino Geometry, but depends on the workflow. Another option is to create a file with the Rhino geometry as a linked block thats rotated/moved. Binding the geometry before sending to Revitzo.

Revizto is able to take Revit in three different coordinate systems (screenshot below), and most likely shared coordinates will be used. I saw a tutorial on Revizto on creating a “cone” to identify reference point( so that the model can be moved later in Revizto space. This sample project was using millimeters, which really explained why I had no clue what those EWO and NSO numbers were. But thanks for the help!!


Hi everyone

Knowing that this is an old conversation I still find it relevant.

I’m trying to work from rhino(drawing and modelling), and wants to work in the world x,y,z in revit and in world 0,0,0 in rhino, and still make sure the two files are relate to each other in some sort of coordinate system.

My revit file has a linked dwg (survey) which I acquired coordinates from, so the survey point and the project base point is now in “world”. so my model is located in (1.2077e+9, 1.8426e+8, 0)

In rhino.inside i’m using the “project location”-component, but this is where its tricks me a bit.

The shared site (SS): is now moved to negative value of where the model is acutally positioned in world (-1.8426e+8, -1.2077e+9,0)
The project base point (PBP) and the survey point (SP) are somewhere I don’t even know (at least in the numbers): (2.8155e-11, 4.6996e-10, 0)
The Internal Origin (IO) is in (0,0,0)

But as you can see in rhinoVP the PBP and SP are located the same place as the IO inside rhino. But the PBP and SP are not located in the same numbers as in revit.
The SS is the one with the right coordinates but in negative.

I know I could work from this, but it confuses me, why the different points are not the same in revit and rhino.
Has this something to do with using acquire coordinates or what is messing up the PBP, SP and IO?

I hope this makes sense, even though its an old topic, as well as my explanation might be a bit tricky. :slight_smile:

Kind regards

A cleaned out example would make it easier to discuss this.

If you have acquired coordinates from the survey point you can transform (Orient3D component) your geometry. You will want to use Plane instead of Points to get the rotation.

Hi Japhy

Good point. I tmade a zip file with all the files: revit file, two dwg as links, a rhino file, The gh file.

Hope this makes it easier to understand my issue, (6.3 MB)

I’m not quite sure if I understand your proposal. I linked the “survey-test.dwg” into revit and acquired coordinates from this file, and then linked the other dwg containing the basic objects from my rhino file (The same obejcts are in the rhino drawing, and i’m just using this as a reference file between the two.)

The objects inside the rhino file is positioned in world (0,0,0) and the GH makes the translation. And this is where I found that the PBP, SP and IO are all located / referenced to the rhino ( 0,0,0). and the SS are now located far away.
Eventhough PBP and SP are showing different values inside gh.

In my mind the PBP and SP should be located with the same coordinates as in revit (1.8426e+8, 1.2077e+9,0) and the SS should be in rhino (0,0,0). It was showing like this before I acquired coordinates, so I have an idea that this somehow is messing up something.
…or perhaps I don’t understand it :slight_smile:

I hope this explains it a bit better

Hi again

Here’s another, and maybe a lot more simple setup with two scenarios.

  1. Acquired coordinates - where the coordinates are still numbers I don’t understand.

  2. Not acquired - where the numbers bwteween revit and rhino seems to be working fine. (just not the right coordinates)

So the issue is happening when acquiring in revit, and then finding the right coordinates,

Simpelt (18.4 MB)

I think i’m starting to understand the “project location”-component.

It seems like the coordinates getting from this is always relative to IO (0,0,0)

This is the SP coordinates in revit:

This is the same location for the SP, but relative to the internal origin:

So I guess I finally understand it :slight_smile:

As I understand it the acqured coordinates in revit:
the SP creates its own “new” (0,0,0) which in the project-location-component is called “share site”, and this one is moved away in the negative direction from the IO, which stays in the same position.

This is why the value is becoming negative, instead of positive inside the “project location”-component, as these values are related to the IO (0,0,0). In my screenshot I let the SP stay in IO(0,0,0) with the clips off, so it get the new acquired coordinates inside revit.

But it would be nice if the values were the same in revit and rhino for the SP. So the SP uses the IO (0,0,0). Maybe this is a revit thing…

Bjut if you could have a rhino file located in the same location e.g. (12000,12000,0) as the revit SP showing (12000,12000,0) …Right now these are opposite from each other. +/-

Hope this makes sense. :slight_smile:

Great that you are getting a grasp of it, its a bit slippery. Kike explains it well here.

1 Like

Hi Japhy

I did not find this thread in my search.
But super nice, thank you so much!

Very smart with the “Cplane” option.

I was trying to counter check the exact coordinate of a point from an element in rhino but i couldn’t the same coordinate using the method above. is it possible to get the exact same coordinate number in rhino ?


Hi @olivia8,

could this work for you? I am exporting the geometry to Rhino in this case with the True North orientation and exporting the Survey Point in Revit so that it matches with the internal origin in Rhino.

But you could also do it with the Project North.

Hi Olivia

I understand what you want to do, and it should be.

At least that what I wanted to do as well, but if you work with shared coordinates in revit then it gets a bit tricky.

If you have a revit file WITHOUT using shared coordinates, rhino will translate all coordinates of your revit model according to the internal origin in revit, as you can only move the survey point and the project base point:

But when you start using shared coordinates in does not work the way you think. Now the “shared site” is being moved. The “shared site” is now the negative value of the real world coordinates. Somehow its moved the wrong way inside rhino.

So in order to get the use negative in front of the numbers

The project base and the survey points is still just relative to the internal origin of revit, but in revit the coordinates is showing the real world-coordinatess. This is a bit confusing.

Does this make sense?

thanks thomas,

I tried another work around that allow me to check elements’ coordinates.
by export the share site point, translating it to a plane in grasshopper and made a named cplane. then i can get the exact xyz coordinates number the same as in revit while using that cplane