I’m sure you are aware that intellectually Revit shared coordinates take minutes to explain, but emotionally they take years to master 🙂

I’ve been looking for a way to check and validate coordinates using the Revit API. One method I implemented in VirtualBuiltApp is to gather Grid Intersection coordinates and compare those, but obviously you need a federated model with links to achieve that comparison.

One interesting fact to note is this:

  • two Revit models can Report functionally identical shared coordinates (same translation and true north rotation), and you can still receive “The host model and the link do not share the same coordinate system. Default center-to-center positioning will be used”. hashtag sadface, hashtag why-revit-why

If we put this another way:

  • if two models don’t have some related history (created from the same file), or
  • if Acquire or Publish Coordinates has not occurred between those models, then
  • the Shared Coordinate error will appear — even if they report identical Spot Coordinates and True North Rotation

If you are wondering what the Revit API actually does support in terms of Shared Coordinate setup and validation, here is the best bit of Revit API Shared Coordinates information I can share:

A GUID-based relationship is set up between the files. Setting up the same relationship has been possible via the API via Document.AcquireCoordinates() for a few releases.

With 2018’s SiteLocation.IsCompatibleWith() it is also possible to identify if two coordinate systems are the same.

This is part of a long thread between Dale Bartlett, Jeremy Tammik, and the Revit development team.

Also, keep in mind that BIM 360 Design (Revit Cloud Worksharing) does not support Publish Coordinates. Only Acquire Coordinates can be used in that environment.

Revit doesn’t like big numbers. There, I said it.

So when dealing with ‘world’ coordinates in a point cloud, sometimes things just don’t work too well. I thought I had this all solved recently by using the DXF, Center-to-Center, Acquire Coordinates workflow. However, I discovered that somewhere along the line, Revit still does break down with the large coordinates. I think this is happening in between Recap and the Revit point cloud rendering engine. I was getting something that looked like this:

As you can see, the shared coordinate system is very large. In this situation, you can’t even move the point cloud into the correct location in Revit, it jumps in large increments when moving. Interestingly, Navisworks and AutoCAD both handle these large coordinates ok – appending the same data does not have the error shown above. So…

How do we fix this and make Revit happy?

Basically, we do a temporary truncation of the source data, get it into Revit, and then reinstate the appropriate coordinate system.

To truncate the data, have a look at your source point cloud information. In my case, I could identify 4 leading digits for the X and Y coordinates that were not significant:

Using EmEditor (which handles large text files very well), and its Vertical Selection feature, I was able to delete the 2781 and 6181 digits from my source data.

In effect, this transformed everything by 278100m and 6121000m. Keep these numbers in mind for future reference…

simplified.png

Ok, with the simplified source data in hand, I followed these steps:

  1. Index a new RCP in Recap using the simplified data
  2. Open surveyor DXF file in AutoCAD and manually Move all the geometry. Move the objects by the values above (278100, 6121000) towards the origin. Save As – a new DWG file with modified coordinates.
  3. Link this modified DWG into Revit, Center-to-Center
  4. Acquire Coordinates from it
  5. Link the Point Cloud RCP By Shared Coordinates
  6. Everything lines up now that the large coordinate shift error has been avoided!
  7. Link in the original DXF and align it with the modified temporary DWG we were using
  8. You may need to temporarily neutralize coordinates (here or here), and…
  9. Now you can Acquire Coordinates from the original DXF and you will have reinstated the ‘world coordinates’, but the Revit point cloud rendering engine is now much happier.

Hope this helps you if you face a similar problem 🙂

Previous post:
What Revit Wants: Using a DXF to Locate a Point Cloud in Revit with Very Large Coordinates

When Revit exports to IFC, it typically uses the current Location (Survey Point) Shared Coordinates as Origin. You can observe this in the IFC file:

2%2Bifc.png

But what if you want to Export to IFC with Project coordinates (Revit origin), not Shared?

We want to do this because we have set up the import process from Tekla using this same Revit origin, here and particularly this:

tekla.png

1) Firstly, make a container RVT file with one Site Location, no shared coordinates. In other words, Project Base Point, Survey Point, and Revit Origin are all in one place.

1%2Bproject.png

2) Then, open the project you want to export, and link this ‘container’ file Origin-to-Origin

3) Transfer Project Standards:

3.png

4) Choose the Link you made, and Project Info (only):

4.png

5) Choose New Only (this will just bring in the uniquely named project location from the link):

5.png

6) Open Location dialog in Revit, under Site you will notice a new “Site“. Set it current with the Make Current button:

6.png

7) Now that the Project Origin (neutral coordinates) are set, you can export to IFC:

7.png

8) After Exporting, reset the coordinates back to what it was before with Make Current:

8.png

9) Optional: delete the IFC Export site definition if you don’t need it anymore…

I previously posted about a similar method, but it was a bit ‘destructive’, whereas the above process can be implemented into a live project more easily:
What Revit Wants: When and how to neutralize Survey coordinates for IFC export from Revit

Further reading:

I thought that most of this was ‘easy’ and solved now, but it was more of a challenge than I expected. I received a ASC file from a survey in XYZRGB format, which looks like this:

asc.png

Those XYZ values are Metres (or Meters if you are in US) in the MGA 94 coordinate system. I also received a DXF file with the same World coordinates, and project related gridlines so I could relate the point cloud to our Revit models.

I tried getting the MGA Shared Coordinates right in Revit, and then linking an RCP or RCS from Recap ‘by Shared Coordinates‘, but I didn’t have much joy.

Here is the workflow that worked for me…

Getting the right Shared Coordinates in Revit

  1. Start a new, blank Revit model
  2. Link the DXF Centre-to-Centre (this is best way to deal with huge coordinates)
  3. Acquire Coordinates from it
  4. Save your Revit file. You now have the right World coordinates, and a project grid relationship.

Importing the Point Cloud by Shared Coordinates 

  1. Open Recap and import the data. For the ASC data above, on the import settings I used ‘Advanced’, and chose the text columns XYZRGB. I also set the coordinate system.
  2. Export to PCG. Sounds weird, I know. But PCG is a nice reliable container that supports colours.
  3. In Revit, Link Point Cloud, by Shared Coordinates, and choose the unIndexed raw PCG:
     
  4. Revit will now open another dialog, and you can index the PCG file (again) to an RCP+RCS
  5. Link this RCP file by Shared Coordinates
  6. It should be in the right location and related to the DXF coordinate system.

Let’s face it, sometimes Shared Coordinates can be a pain. Issues may arise when trying to make small adjustments to very large numbers, and that comes up in other places in Revit too. In some cases, using “Specify Coordinates at a Point” has almost no effect, and you need to resort to workarounds like these.

In Revit, if we follow certain steps in a certain way we can solve these issues. It may seem a fiddly, but if you want to fix coordinates on an existing model, perhaps one of these methods will work for you.

Method 1 – Transfer Project Standards, Project Info
This transfers the ‘location’ data of a Shared Site…

On a real project, you will probably have a control model you can use in the workflow below. The control model needs to have some lines showing at the desired Project Base Point position, probably in a Linked View, as well as a SITE fixed named site that has the ‘correct’ shared coordinates.

  1. Open one of your models to fix
  2. Go to a Plan view
  3. Link in the COORDINATES file Origin-To-Origin
  4. Set Linked view – COORDINATES
  5. Turn on Site – Project Base Point
  6. Select it and ‘unclip’
  7. Transfer Project Standards (from the link) – Project Info
  8. Choose ‘New Only’
  9. Go to the Location – Site dialog box
  10. Set the SITE fixed to ‘Make Current’
  11. Delete your old SITE, and rename SITE fixed to SITE (we have now replaced the shared site coordinate info with that from the control model). Now, to get a moved PBP in the right spot for the project
  12. Back in Floor Plan view, slightly drag the unclipped PBP away from the two green lines (the pbp position in the control file), then move it back to exactly that point
  13. PBP should now be fixed

tps.png

If this doesn’t work, you may try
Method 2 – neutralizing coordinates and re-Acquiring

  1. Select your PBP, unclip it, rightclick and “Move to Startup Location”
  2. Link in a new, blank RVT such as a NEUTRAL_COORDINATES.rvt and Acquire Coordinates from it (this resets coordinates)
  3. Save your file (your PBP should report 0,0 coordinates)
  4. Link in the control model PBP RVT
  5. Acquire coordinates from it
  6. Delete it (yes)
  7. Re-link it again (this is to get around a Revit bug, that sometimes ‘shifts’ the linked model after acquiring coordinates)
  8. Save your host file (shared coordinates are now set correctly, and the PBP can be moved into place as below)
  9. Select your PBP, unclip it, and move it to the location from the control model. You may need to set up a plan view that has PBP switched on, and view range all the way down to AHD 0.00.

Both of these methods are somewhat involved, but they may be useful to you in those situations where “nothing else works”.

Video: Matthew Miller recently gave high praise to this class, when he posted that David Baldacchino’s class AB412 Navigating Through the Storm Using Coordinate Systems in Revit “has been the best explanation of shared coordinates, that has helped me understand them.”

Matthew also provides these useful links:
Blogs Talking about Survey point in Revit
Understanding Shared Positioning in Revit

Shared Coordinates

Project Base Point Manipulation

Revit 2013 – Project Points, Survey Points, Revit Coordinates

via

Revittize: Set the Revit Survey Point

When exporting to IFC, you may find that Revit feeds the Survey Coordinates (or shared coordinates) to the resulting IFC file, when in fact you want it to be based on Project Coordinates.

If your project team is using origin-to-origin linking, it will be almost vital that you neutralize the Revit survey coordinates immediately prior to exporting to IFC.

This is quite easy:

  1. Make a new file based on a blank template
  2. Insert a origin locator dwg and draw a couple of model lines over the top (this is purely to give you something to “pick”)
  3. Save and close this blank RVT file (and keep it for future use)
  4. Link it into your live Revit project
  5. Use Acquire Coordinates and select the new, fresh, blank RVT file
  6. Save As this temporary RVT with neutralized survey coordinates to somewhere
  7. Now Export your IFC

Your resulting IFC file won’t be confused about which coordinate system to use – it should now Append to Navisworks and other software using the same origin-to-origin coordinate system as that in the originating Revit project.

Often, it is.  But if Project Base Point has ever moved in the life of the Revit project, then it probably won’t be.  Revit Zero (sometimes called the Internal Origin) affects things like FBX and NWC export (IFC too) when using Project Coordinates.

One way to find it is to make a DWG file with a couple of lines at 0,0,0 and link in Auto – Origin to Origin.  Another way is to make a Spot Coordinate that reports based on the “Relative” option.

You can theoretically  have 3 different coordinate records for a single geometric point, as this image shows:

You can read a bit about this at Revit Landscape.