Wednesday, November 26, 2014

Roads Category and Spot Elevation

This is too weird not to write about it. I was asked to take a look at a file that would not let us apply a spot elevation. I did the usual things, check for the floor category visibility, no overrides to the linked floor(s), no filters, no underlay weirdness... no joy.

I compared it against a new view with no view template. The new view worked but the one with a view template assigned didn't. I tried turning back on all the model categories that were off in the view template. The Spot Elevation tool worked again. Hmmm...

I reset the View Template and then I turned back on each category that was off in the template, one at a time. When I turned on the Roads category the spot elevation started working again. WHAT??

That's more than a little bizarre since we've never been able to use the Roads category for anything. They don't even let us create an In-Place family using the Roads category. I imagine that it is something gone awry in this particular project file since this is the only one behaving this way but still...turning on the Roads category fixed it??

Thursday, November 20, 2014

Username and Local Files

Revit knows who we are based on a simple piece of data, the Username entry here (Application Menu (Big R) > Options). That is usually defined by who logs on the computer. If we log on our computer, then open Revit AND change the Username...Revit preserves this alternate username until we change it again. If we never change this value then Revit just uses the computer's log on username identity. When we change it Revit captures and preserves it for this particular person's log on credentials on the computer.


Using Worksets (Worksharing) this username provides our unique identity to Revit, the Librarian (not to be confused with the TV show or movies). We can't just arbitrarily change our username while we are working in our Local File. If we do that we'll be greeted with an unpleasant message when we attempt to use Synchronize with Central.


We can become convinced that changing the username is permissible because Revit doesn't complain until we attempt to use Synchronize with Central. It's also easy to think it is reasonable because when the file contains changes that have not been synchronized yet we see this message when we attempt to change the username. When Revit complains and offers the reason that changing the name isn't going to work it implies that there might be an acceptable circumstance.


Fwiw, we CAN change our username freely if we are working in a central file (discouraged). However we won't find that very fulfilling if other users are also working on the project via their own local files. We'll be advised by Revit that it is necessary to use Save As to create a our own Local File first, when we use Synchronize with Central.

We CAN assume any username identity, we just have to change the Username parameter before creating a new Local File.

Damn Revit's Worksets and Worksharing features are fussy!

Wednesday, November 19, 2014

Importing CAD Files and By Shared Coordinates

When we link/import DWG files with survey data Revit often encounters file extents that are quite large. The developers have always encouraged us to use the Auto - Center to Center positioning option with those files. Revit will forcefully use that option when the extents of the file violate the current 20 mile tolerance it has.

I wish I could write that linking/importing survey files was very simple and error free. The reality couldn't be further from that. I recommend these steps to improve the odds for success:
  • 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
Once we've used Acquire Coordinates on our first survey file and verified the resulting coordinates are correct we can import the rest of the site related files. If Acquire Coordinates didn't work then we need revisit the items above, especially Named UCS. I find that Revit will acquire very large coordinates accurately IF the file is pristine.

In contrast I also like to use Specify Coordinates at Point (SCaP), using the marker I created earlier. Keeping in mind that doing so doesn't establish a shared coordinate relationship between the CAD file and the project. By relationship I mean that Revit records the identity of the linked file in the project when/if Acquire Coordinates is used to align the project with the linked file's WCS origin. SCaP does not.

Now regarding the title of this post, importing the rest of the files. Once shared coordinates are defined based on our first file we can import other site files using the positioning option: by Shared Coordinates. This assumes that each of the site related files are already aligned with each other using the same WCS origin. When we link a file this way a warning will appear while it is loading.


Revit is being precise, warning us that this project doesn't have a shared coordinate relationship with the incoming file. That's true, it is just another CAD file as far as this project is concerned. The only shared coordinate relationship that is established is between the first file and this project.

The last part of the warning is the significant part, The link's World coordinates will be aligned with this project's Shared coordinates". That means it will line up correctly because our project is aligned with the same WCS and both cad files already use the same WCS origin between themselves. Clicking Close accepts the warning and the link should land in the correct location. We can repeat this as many times as we have site related files to use.

When we save our project we may receive this warning. In this circumstance choose the bottom option Disable shared positioning...


We really don't want to create a named UCS in the CAD file the dialog references. It's linked and lined up correctly, its WCS is already correct, there is nothing to be gained by letting Revit store a named UCS in the file. This is what happens if you click Save instead, we end up with the named UCS in the image below.


I don't recall Revit bringing up this dialog in the past, unless I moved the link later, and I don't think it should be doing it in this circumstance. Fwiw, it doesn't in Revit 2015, at least not with the files I've been experimenting with for this post. It may be related to having a Named UCS. In some further testing I was able to link and save without generating the dialog. The inconsistency seems to consistently fall back on the condition of the DWG file though.

If we are careful to link each file and Disable the shared positioning Revit seems to think needs to be established all our linked file should line up very nicely. When they don't I find it necessary to revisit the list above. Skipping over them is very likely to bring on heartache later.

Tuesday, November 18, 2014

Adding Callout to Quick Access Toolbar in 2014

If you're using Revit 2014 and have tried to add the Callout tool to your Quick Access Toolbar (QAT) you've been turned away, rejected, sorry no you can't do that here... Sorry, applying Web Update 3 doesn't fix it either.

Subtle and minor it may be but stuff like this frustrates users. ...and I was sure it was possible. Oh right, it's working in Revit 2015. One more subtle reason to upgrade.

Friday, November 14, 2014

Enable 2D Setting for Multiple Grid Lines

There are times when we'd like to alter the 2D (view specific) position of Grids. When you select a Grid you can click the 3D icon to toggle it to 2D. That's a one-at-a-time affair though. If you have many grids you won't look forward to doing that.

When a Grid crosses a crop boundary in a view (when the crop boundary is enabled) it switches from 3D to 2D automatically. If you want to enable the 2D setting for all the vertical grids at once turn on the view's crop boundary and make sure it crosses your grids.


Now you can adjust all the Grids end point position together just like they do automatically for the 3D setting. It will work for levels too. If you don't want the crop region long term you can just disable it afterward. The Grids or Levels will retain their alteration until (if) you elect to use the Reset to 3D Extents (right click context menu option).

Thursday, November 13, 2014

Relocate Project is Sleight of Hand

Try these steps:
  • Create a new empty project
  • Open the Site plan View
  • Make sure the PBP (Project Base Point-circle) and the SP (Survey Point-triangle) are visible
  • Use Relocate Project, "move" the PBP 1 meter to the left
  • We'll find the SP is now 1 meter to the right, left behind marking where the origin was
  • The SP identifies the origin of an alternate coordinate system, roughly equivalent to AutoCAD's WCS (World Coordinate System) origin, consider that using Acquire Coordinates aligns Revit with the WCS of the source DWG file.
  • The previous steps are essentially the same as moving the SP (clipped) to the right 1 meter instead (use Undo and try it)
  • Using Relocate Project you see the PBP move but its really the SP that's changed, it just doesn't look like it because the PBP is reporting a different 0,0 coordinate offset now (more on that below).
In a sense Revit just shifted the world over, underneath our building, and the origin never really changed. If we try the steps above and make sure we can see elevation symbols it becomes more apparent when they don't change their relationship to the PBP after using Relocate Project.

The PBP and SP start out at the same location in stock templates, but they are NOT marking the same information.

The Project Base Point always (when clipped) identifies where the project's origin is. The Survey Point identifies one alternate coordinate system's origin location, when it reports 0,0.

I believe it causes confusion when we examine the PBP coordinate values (when selected) because it displays values that are relative to where the SP defines the WCS origin, NOT the project origin. Since the project origin is never really changing it would be more accurate or consistent to continue displaying 0,0 and only begin showing different coordinates when it is moved un-clipped.

The following image shows a SP that has been moved by Acquire Coordinates to mark the WCS origin of a source survey DWG. The PBP now shows coordinates that match the offset from this alternate coordinate system's origin. To be fair it does say Shared Site: just above the values but it isn't as meaningful to most users as we'd hope.


The following image shows both PBP and SP moved while un-clipped. It is tempting to think of them as points when they are moved like this but they are really annotation referencing coordinates that are only meaningful when compared with where the origins they are referencing are, which I believe contributes to the confusion about what they display when selected.


General Comments and Advice
  • The Project Base Point never displays coordinates that reference anything but the Shared Coordinate origin location.
  • The Survey Point initially identifies an alternate coordinate origin but it can be un-clipped and moved to show coordinates that reference its origin location.
  • The Project Base Point and Survey Point start by marking their own origins, at same location in stock templates but they are NOT the same coordinate systems.
  • Don't use Relocate Project for X/Y axis project changes, it's really just establishing an offset relative to the Survey Point, not changing the project origin.
  • Don't move the Project Base Point clipped
  • Relocate Project can be useful in the Z axis when you need to show an arbitrary elevation value without placing the building at the actual elevations, see True Elevation and Position, it is still sleight of hand though, using Shared Coordinates to achieve the difference.
  • Moving the PBP un-clipped can be used with the Spot Coordinate annotation. It can reference the Project Base Point location when it is desirable to mark locations, using the Spot Coordinate tool, that all reference where we've placed the un-clipped PBP.

Monday, November 03, 2014

Dynamo Tip and Forum

If you open a Dynamo project that is based on a language that is not the same language as the Revit project you are in it can cause Revit/Dynamo to crash. We can avoid the crash if we open a project that shares the same language first. That's how it was described to me at RTC in Dublin this past week. Perhaps it is just a build incompatibility? It seems to me that will make it difficult to mix and match up Dynamo work that is done in various languages?

The best place to stay in the loop about Dynamo info is DynamoBim.org. Better check in with the forum there to be sure.

BTW, regarding forums, AUGI recently created a new forum for Dynamo, to expand their Revit forums to include a place for this rapidly emerging tool. You can VISIT it HERE.