Revit: Placing Elements in Coordinates with Dynamo

As far as I know, at the moment there is no way to put elements in Revit in certain coordinates, and you have to go to AutoCAD as an intermediary. However, with the help of Dynamo you can automate the location of objects in precise coordinates.

The most common example of use is to enter the coordinates of a site from a table provided by the surveying service provider. Usually georeferenced CAD planes are also delivered, however, we have often found precision errors when positioning the coordinates on a linked CAD in Revit. That is why the need arose to enter the points from the coordinate table stored in an Excel file.

In general, the definition of Dynamo follows this simple process:

Reads the data in the .xlsx file
Places family instances (of 2D structural column in this example) at each of the coordinate points.
Draws the property boundaries with model lines.
Optionally, tags the coordinate points.
A previously configured coordinate schedule is filled.

The first thing will be to prepare the coordinate spreadsheet in Excel. The order of the columns will determine the order we’ll give later reading data in Dynamo. The data is in mm in this example.

If we are working with very high coordinate values, beyond the limits of the accurate workspace in Revit, it is highly recommended to first specify the Survey Point values at a point close to the ones we are going to introduce, and preferably one of the points of the plot. I have chosen P1 for this case.

Before going into details, let’s quickly see how it works when executed from Dynamo Player. It is always advisable to access the input data edition before executing the tool. Some field values may be changed, if necessary.

In any case, once executed, thanks to the data | shapes input data form, we will have a new opportunity to confirm or modify the input information. As you can see, all options are intuitive and their default values correspond to the most common ones.

Once OK is pressed, a final dialog with the results is quickly prompted.

Check in Revit if the layout and points are where we expected, as well as the contents of the schedule. We also see that they are tagged, and in a 3D front view we are presented with the elevation of each point giving slope to the property boundary lines.

As you can see, it is really simple to use, and without the need for a great preparatory work.

Now we are going to detail the construction of the Dynamo script in steps.

First of all, we see a group of nodes with which a default selection of the path in which the Excel file should be made, following the company’s standard. I’m not going to delve into it, because obviously it is very customized, but I would like to mention that it is a great help to avoid extra clicks looking for the file in a corporate network with many directories, gaining a lot of time when running the definition. Keeping to the standard has a prize. This group of nodes feeds the default value of the file path of the next group that we will see next.

Before the incorporation in Dynamo Player of the option to edit input data, there was no other way to control different options by the user. With the nodes of data | shapes (by Mostafa el Ayoubi) it was possible to give this interaction to users with different dialog boxes and data entry types. Once this was possible with Dynamo Player, I kept the data | shapes functionalities in my definitions, because I think they are still more flexible and friendly, and allow intermediate steps with user action. In addition, these input data editions are forced, while in Dynamo Player it is hidden and it is common to forget about it. Normally, the default values will be as desired and it will be enough to confirm with OK to continue with the execution.

In the next group of nodes the Excel file is read and the data is split from each column, excluding the headers.

Now we come to an operation of tanslation and rotation of the points with respect to the internal origin point of Revit. This is necessary to ensure that in any circumstance we will have the points correctly located. That is, in cases where for some reason the Survey Point has shifted with respect to the internal origin and / or a rotation of the project angle has already been made. If none of this has been done, there is no problem, because the values with which it operates are 0 and the result is not altered.

The main operation is hidden inside the Point.Translate node, which is shown in the following image.

The next group is responsible for locating the chosen family in the points already moved to the reference of origin, and making sure that they do so at the level of the view chosen in the previous steps.

The View.GetLevel node is open in the following image.

We continue with the copy of the coordinate values to custom parameters of the families we have chosen to represent the coordinate points.

Next, the property lines are drawn by tracing a polygon between the points and these are tagged, if we have decided so before.

And finally, we use data | shapes again to show a last dialog box to confirm the result. In my opinion, it is extremely useful to do this with all the definitions so that the user has a more accurate idea of what has happened and if everything went well before reviewing it in Revit.

I hope this explanation has been sufficiently clear, although without going into many details so that it is not too tiresome either. I encourage you to leave comments to answer questions, and even provide suggestions for improvements.

Notes and acknowledgements:

· The present Dynamo tutorial aims to modestly help the development of automation in the work processes of the AEC world.

· For confidentiality reason and due to its high customization, none of the scripts can be shared.

· Thanks to all package developers for Dynamo, without whose effort, tips and generosity it would not be possible to extend the customization power of Revit, considerably increasing its effectiveness and efficiency. I would like to highlight especially the work of:

· Mostafa El Ayoubi (data | shapes)

· Andreas Dieckmann (Clockwork)

· Konrad K Sobon (archilab & BumbleBee)

· Nate Miller (LunchBox & Rhynamo)

· Dimitar Venkov (SpringNodes)

· John Pierson (Rhythm & Bang)

· Julian Benoit (SteamNodes)

· Thomas Mahon (Bimorph)

· Luke Johnson (Bakery)

· Johnes Hou (Hot Gear)

· Colin McCrone (Ampersand)

· Dieter Vermeulen (BIM4Struc.Rebar)

· Laurenk Schmidt (Landform)

· Tomasz Fudala (Structural Design)

· Modelical

· Marc Tavernier

· For my part, I have developed custom nodes to simplify definitions and reuse them in others. When it is necessary for the understanding of the tutorials, I show the image of the custom node so that it can be recreated.