Drafting Views have an Origin Too

Drafting views look like a blank sheet of paper we can drop your pen and start sketching in. We can but it might help to know that they do have an origin and you can end up quite from from the origin if we use an external file to sketch over (which happens a lot). I routinely encounter projects that have very large drafting views, when you know where the origin is.

The old trick to find the origin in Revit was to import/link a DWG with a crosshair at the world coordinate system origin. Linked via Origin to Origin places that DWG at the origin of the view. The PyRevit application has a handy function to place a pair of intersecting lines at the origin of a view. I find I just use that now instead. It's about the same number of "clicks" either way.

Now, the natural question to ask is, "Does it matter?" I don't know but if large extents are bad in model views I can reasonably infer that it might also be bad in drafting views. I don't have any evidence that this model was bad because drafting views were huge. I do know that some bad models I've encountered also had drafting views with very large extents. When I deal with a such a model it is one of the things I consider (of the many things, so many things).

Good housekeeping isn't just for the model.

Revit 2020.2 - Internal Origin

A quick post to mention this since I've already run into this issue with users several times. The latest update for Revit introduces a new icon to mark the location of the file's Internal Origin. This is what it looks like in the 3D view.

It's off in all views initially, in the stock templates. Reveal Elements will display it quickly in a view without having to use Visibility/Graphics to show it. It can't be selected, it's just visible to help understand where it is.

Edit: It seems existing projects that are opened in 2020.2 have this Internal Origin turned on in all views (many). That's a bug in my opinion. They should not be turning this on. Though, in my own testing it is not getting turned on with upgraded files. It seems to be existing 2020 files that get this turned after opening it with the 2020.2.

Project Base Point - You won't see the clip when you select it. Move it away from the internal origin and it is automatically behaving as if it isn't clipped. In other words, it isn't clipped anymore. We couldn't really move the project origin, only the Project Coordinate System could be adjusted to provide a local coordinate reference for the Spot Coordinate tool, for example.

The Survey Point remains much the same.

When dealing with linked files you'll find that the icons for each of these is also visible but halftone (gray) to differentiate from the host file's own icons. You can snap to the links icon's to help align the files, using the Move tool for example.

I'll have to return to the subject once we've gotten fully acquainted.

Edit: 11/24/2019

I traded a couple emails with Autodesk staff on this. My understanding (not a developer) is this is not merely something they overlooked. Consider when a 2020 file is opened in 2020.2 it is not going through an upgrade because the file format is compatible. This creates a scenario where they are not activating upgrade code to resolve the existing file's structure with a new version's structure.

Unfortunately this new subcategory gets enabled and its visible status is "on" at the outset. It's my understanding that "off" isn't an option...in this scenario...without also creating an upgrade scenario...which is conceptually a no-go...within a release year.

Upgraded files go through an upgrade process which imposes rules on that process...which includes a task that deliberately "turns off" this new subcategory. It's a quirk of the file open sequence/process.

I think they didn't expect it to be a significant issue. It doesn't print after all. It can negatively affect zooming behavior in many views though. User perceptions can't be ignored either. An unexpected "thing" encroaching on views is "bad"...similar to seeing a view's crop boundary when not intended.

To their credit, they asked if I agreed they should create a Dynamo solution to turn it off in all views. Naturally I encouraged them to DO IT! Hopefully we'll be able to say that such a solution exists soon.

Drafting Views have an Origin

When we create a new drafting view we are presented with an empty view. We are free to begin our drafting exercise anywhere we see fit. It's not obvious but there IS an origin in the view. If we import a simple CAD file that has some lines that define where the 0,0,0 origin is we'll find out exactly where the origin is in the drafting view (use Auto-Origin to Origin).

What does it matter? It may not matter at all. I've often wondered about it since Revit cares about keeping us near the origin of the file for our model views and complains when we import external files that are very far from origin or very very large.

As such I can't help but wonder if we ought to be careful to keep our details near the origin of drafting views too. I have encountered drafting views that have their contents very very far from the origin. It's easy to do, just zoom out a bit and start detailing. It just seems inconsistent with the best practice expectations for model views.

I'm inclined to create a "template" drafting view in a project template to begin drafting views with (duplicate them) with the origin clearly marked, like shown above. I'd welcome someone from the factory chiming in to say this is a good idea or unnecessary.

View Reference Origin Location

I observed this the other day which remind me that it bothered me in the past but failed to bring it up before. The View Reference family that we can use in conjunction with Matchlines and now with Revit 2013 to create more general reference to views on sheets has an unpleasant effect on views that they are in.

They are assigned to the View Reference category but fundamentally began as a generic annotation family. When you create one from scratch or just edit the one the comes with Revit templates you'll find something like this.

The Move icon ends up very far away from the symbol itself when it is in view that are using finer scales. In a view that is assigned to something like 1/8"=1'-0" it is closer to the symbol. The downer about this offset is that it increases the "size" of the viewport when the view is added to a sheet. It just creates some unnecessary busy work to adjust views when this happens. If you find a viewport becoming "larger" than it should it might be related to this kind of situation.