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

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.

Brian Nickel recently sent through a link to the very Elk package for Dynamo, that essentially opens up web geographical data access to Dynamo and thus through to Revit for topography creation and similar.

It was already an established plugin for Grasshopper, but developer Timothy Logan has released a port for Dynamo which can be accessed through the Package Manager.

Elk_Dynamo.png

Elk HKS site:
Elk Mapping Plugin | HKS LINE

Heads-up from:
The Revit Saver: Dynamo – Elk for DynamoBIM by Timothy Logan

Quote from The Revit Saver:
Thank you to Timothy Logan for making Elk available to Dynamo users!

Here are his two videos for how to use the OSM data and Topographical data.

Elk for Dynamo – OSM from Timothy Logan on Vimeo.

Elk for Dynamo – OSM from Timothy Logan on Vimeo.

Some of the links referenced in the above videos:

https://www.openstreetmap.org/
http://dds.cr.usgs.gov/srtm/version2_1/
http://earthexplorer.usgs.gov/
http://www.opentopography.org/