Property Boundary and Coordinate Data - Dynamo

Alternate title: Mr. Revit OpEd finally does something (tho basic) with Dynamo!

I used this problem as an excuse to dig into Dynamo a bit. I created the attached graph to read a text file with coordinate values, one line per X,Y,Z values.

The text file format is very basic, it looks like this:

I created a 3D cylinder and model lines to form a target symbol family, 3D and fairly large so I could see it anywhere in the model. The graph places a target family at each coordinate location. Before running the graph, I assigned the Project Units for Length to Meter. Then I ran (manual) the Dynamo graph to place the target families. The last step was to start the Property Line tool and sketch the property boundary segments from target to target, which looks like this.

It was necessary to move the points closer to Revit's origin so they were not so far away, since Revit hates that. After doing that, I moved the Survey Point (not clipped) to one corner of the property (target family location) and then used Specify Coordinates at Point at that location using the coordinate values for that corner. This will allow me to export the result to DWG, if necessary. I also created a specific Spot Coordinate family type so I could identify some or every target location and make sure each reports the correct coordinates, double checking my work so to speak.

I probably spent a couple hours on this, mostly trying to get my head wrapped around which nodes in Dynamo to use. The next time I'll be twice as fast!

Project Units Matter - Specify Coordinates at Point

When we use the Specify Coordinates at Point (SPaC) it is possible that the units in use will affect your results. For example, this project is using Feet and Fractional Inches (FaFI) but for SPaC to match the available survey info it was changed to Decimal Inches (DI) with six decimal places. After using SPaC the units were returned to FaFI.

Some time later the elevation needed to be changed thus causing us to revisit using SPaC. The following image shows the original values used for SPaC.

Leaving the Project Units assigned to FaFI resulted is this subtle change to the coordinate values.

When the units were revised to match the earlier DI settings the SPaC coordinates are not altered.

Shorter story, be careful with your unit settings when using SPaC.

Revit Coordinate Systems Video

A lengthy exchange at Autodesk's User Forums about this subject reminded me that I've meant to create a short video to describe how they relate to each other for quite awhile. This morning I saw our cutting boards drying next to the sink and realized they could serve as metaphorical coordinate system planes (Project and Survey) work in Revit. I am curious if readers find it helpful.



The original post at the forum dealt with a few projects that had been modelled very far from Revit's Internal Origin/Startup Location. I looked at one of the project files and found the Survey Point and Project Base Point had been moved very far away while unclipped. The modelling started there, really far far away. They started to experience some of the negative symptoms that can occur and started looking for solutions...thus the original post. The short answer is they needed to move their model closer to the origin. No other way around it.

Clipped or Un-clipped - That is the Question

The question asked: "Steve, should we leave our coordinate system icons clipped or un-clipped?"

My Answer: As we know, the Project Base Point (PBP) and Survey Point (SP) can be un-clipped. If they are untouched we'll find them clipped.

When these are clipped the symbols for each of these are attached to the coordinate systems they belong to. That means moving either while clipped will alter the coordinate system. If this is done unintentionally, or by someone who does not realize they have been adjusted intentionally already, the coordinate system(s) will be changed.

Therefore I'd say it is not unreasonable to leave these in their NOT clipped or un-clipped state at all times, especially after they have been adjusted intentionally to align models or survey data. If they are not clipped then accidental movement of these icons do not alter their related coordinate systems. It merely changes the symbol's position relative to their coordinate systems.

I regard these symbols as markers or annotation when they are not clipped. In this state they are harmless to our coordinate machinations. Clipped they pose a danger to our careful adjustments to align models and site information.

My opinion: Keep them Not clipped, un-clipped.

Shared Coordinates - Autodesk Reference Information

It's September already...no posts in August...time flies.

This post is brief, merely a referral. If you struggle with understanding Revit's coordinate system then THIS LINK, at Autodesk's Knowledge Base (KB) site for this subject might be helpful. I like the images and some of explanations or interpretations it offers.

Check it out, it may help!

Edit: I wrote this on Sept. 7th originally, received an unflattering comment about it, returned it to draft, revised it, and restored it to published on Sept. 14th.

I was lazy. I thought the information was an addition to their formal help documentation. When I saw the comment I read through the KB article again and realized that it was written by an Autodesk User Group member and submitted to their Knowledge Base system, which happens to be curated by different people than the product documentation group. I might quibble with some subtlety of it here or there but its approach may help someone get a grasp on the bigger picture. Just keep in mind that its claims are not gospel, nor written by Autodesk's own people.

Revit 2018 - GEO Reference and Shared Coordinates

I replied to a thread at RFO that asked about Revit 2018 touting support for AutoCAD's GEO Reference feature.

On the surface, there is no obvious difference between how things worked in 2017 (or older versions) compared with 2018. Over the years you may have noticed that the Location Dialog, the one that allows you use a map to locate your project did not do anything at all related to the Shared Coordinate system. All that action did was provide a way for Revit to; originally calculate sun position (and therefore shadows) more believably and more recently to allow for energy analysis estimation to be done.

Now...in Revit 2018, assuming the source DWG file is using AutoCAD's GEO Referencing feature, it is possible for Revit to inherit this data to affect not only the Location (Sun and Energy Analysis) but also the coordinate location of the project (Shared Coordinates).

The thread at RFO also asks about the 20 mile threshold Revit has regarding model size and warning us about model accuracy. The following is a restatement of things I've written in the past. Specifically they asked if there was any change to this in 2018. There isn't that I know of. I included the following to superficially explain the reason it exists.

The 20 mile threshold is a math and computer science problem that Revit developers choose not to lie to us about. They want us to keep the model as close to the file's mathematical origin as possible. External files (and internal modelling) that have data whose extents are larger than 20 miles begin to influence the accuracy of the calculations required to generate and display the model faithfully.

More often than not a civil file is not really larger than 20 miles. It just has elements that are farther away from the origin than that. Revit doesn't mind that issue and it doesn't mind assigning very large coordinates values to the shared coordinate origin (Survey Point).

It only cares when there are elements that are beyond the threshold. For example a file that only has two short line segments that are 30 miles apart will cause a warning. A file with an entire set of contour lines 40 miles away from the origin won't cause an error IF all the contours themselves and other annotation don't cause the extent of elements to also be larger than the 20 mile threshold. Distance from the origin is one aspect and the total extent (X,Y AND Z) of the elements in the file is the other.

Ultimately, the error appears because they want us to know that this external data could negatively affect the accuracy of what we work with inside Revit.

I wrote THIS POST to discuss how I deal with survey files that violate the threshold. It starts out with one issue (transparent elevations/sections) that occurs when the threshold is crossed.

Transparent Elevations and Large Coordinates

Back in December 2011 The Revit Clinic shared a post called Interior Elevations and Large Coordinates in the Project. It's worth echoing it again four years later.

It boils down to this. If you link a DWG file that has geometry that extends beyond Revit's 20 mile threshold then you may find elevation views (or section views) look transparent. In 2016 I find that some views just stop responding to Visual/Graphic Style settings at all. If you remove the offending file the problem goes with it.

It is necessary to clean up and reduce the size of the offending file so that the threshold is not crossed. I shared this list in the past, in particular consider using the WBLOCK technique.

• Import multiple Survey files individually (don't nest them as xref's)
• Purge everything you don't need, purge again
• Use Wblock if you can't get Zoom Extents to focus on just the relevant portion of the site
• Remove Named UCS (Revit only wants the World Coordinate System)
• Set UCS (User Coordinate System) to WCS and Plan to WCS
• If the survey isn't oriented to WCS, North is "up", have the civil engineer/surveyor change their file first
• Identify a specific location within the relevant part of the survey, put a marker, identify its coordinates, better still make those coordinates easy to use, even clean numbers.
• Make sure everything actually aligns correctly in AutoCAD first, no point setting it up in Revit if it doesn't work there
• Once you get a working first survey file, pass it back to the surveyor so they know what you need in the future

That might be a lot of work...so fortunately there IS an easier fix. Just make sure the offending DWG file is NOT visible via Visibility/Graphics in views that are acting up. It should restore normal behavior.

I prefer elevations that aren't see thru. Watch out for those surveys folks.

In-Place Massing and Project Orientation Inequity

In-Place families are necessary for some geometry, in particular the massing environment. I've always stressed that people should start a project without being concerned about site alignment immediately. Revit was (is) designed to allow us to adjust True North easily after the fact. As I've written before, just make it easy to "draw on paper".

A recent post at RevitForum.org underscores that bias when it asked if the two project orientation tools seem to work differently? Actually it was just focused on Rotate Project North (RPN) and that in-place massing didn't play along when it was applied. Rotate True North (RTN) on the other hand does work.

In this image the massing has been created aligned with the "site" but we've realized that it would be easier to document if Project North were aligned along one building edge.

In this image I've used the Rotate Project North and picked the reference plane I sketched to mark the East/West bearing I wanted. I had to rotate the text but the tool rotated the reference plane correctly but the massing is unchanged.

As I wrote in my reply there, RTN is sleight of hand while RPN is really altering the entire model and related views to change orientation. In other words RTN rotates the world under the building and RPN rotates the building on the world. Rotating the world is actually "easier" (less work) for Revit than grabbing every element and everything in every view and rotating it (the building).

If you heed my Two Pieces of Advice, you'll start a project off better...