Drawing Orientation in Land Desktop
The diagram at the right illustrates an example of a situation that arises frequently
in Civil projects. We desire to create an exhibit of a parcel of land at a
certain scale, but the parcel will not fit on the page. However, if we rotate
the parcel slightly so that North is no longer to the top of the page, the drawing
will fit. In the diagram on the right, North is at a 45°-angle clockwise from
the top of the page.
But how exactly should we go about creating a drawing like this in Land Desktop?
There are a lot of features in AutoCAD - paperspace, viewports, views, UCS's, etc.
But we are also working with a parcel of land. So however we choose to proceed,
we must make sure that we do not affect the Northing/Easting of any points, and
all Land Desktop functionality must continue to work correctly. When we label
a line with a distance and bearing, the label should have the correct values, and
it should appear correctly in the drawing. Surfaces should display correctly.
Station Labels on Alignments should look correct. Basically, we want EVERYTHING
to still work. So we must utilize some care in how we proceed. And unfortunately,
as we shall see, our task is made even more difficult by a series of bugs and questionable
design choices in AutoCAD and Land Desktop, which we must work around. But
there is a way.
Problems with Views and UCSs
Some initial aspects of our design are basically dictated to us by the design of
Land Desktop. For example, the Land Desktop line labeling commands do not
work correctly in paperspace. There are also a number of problems with placing
dimensions in paperspace in Land Desktop, as detailed in
this article. For those reasons, among others,
we will do the bulk of our labeling in modelspace. Similarly, we will use
QLeaders instead of old-style Text Leaders, because the arrow automatically moves
with the text for QLeaders. (Note: The 2008 release introduces
MLEADERS, which have a number of significant improvements over QLEADERS.
As such, if you are using 2008 or later, we recommend you consider using
MLEADERS, although you may not be able to use them if compatibility with earlier
versions of Autocad is important to you.) And paperspace has a variety of useful features
that we'll want to take advantage of, so we will be using paperspace viewports and
plotting from paperspace. But to create our drawing, we still have a number
of options in how to proceed.
The first idea for creating the drawing might be to just use the DView TWist command
to change the orientation of the paperspace viewport. And since we're primarily
working in modelspace, we'll also want to DView TWist modelspace to match the paperspace
viewport. For this particular drawing, we would want to start the DV command,
then specify a TWist of -45°. However, if we then try to use the default Land
Desktop Line Labels and QLeaders and place text and labels in our drawing, we get
results that look like this (click for a larger view):
Note that the bearings and distances for the lines are correct, but some of them
appeared on the wrong side of the line. And the QLeader and Dimension text
does not go in the correct direction. This does not seem to be a bug, but
more like a poor design choice in AutoCAD. AutoCAD places the text in what
it determines to be a "readable direction", and it determines the "readable
direction" by assuming that the y-axis of the current coordinate system points
to the top of the page. But the result of this behavior is seen on the left.
If AutoCAD worked differently, and assumed the top of the current view was
the top of the page, then all labels would be placed correctly. And this would
be a nice intuitive system, much like rotating a piece of paper to make it easier
to write on. But instead, AutoCAD uses the current coordinate system
to determine the top of the page.
"OK, fine," you may be thinking, "why not just create a custom
UCS, rotated as needed?" Unfortunately, if we try to use a rotated UCS,
we begin to hit a whole series of bugs in AutoCAD and Land Desktop.
The first bug involves QLeaders. The inset on the right shows what a QLeader
looks like when created in the WCS. It also shows a QLeader created in a UCS
that is rotated by only 45°.
Notice
that the distance between the leader line and text is not the same. If the
UCS is rotated a full 90°, the result is even worse, and may even have overtyping
between the leader and the text. The gap may also appear bigger than it should
be, instead of smaller, depending on the rotation of the UCS, and also depending
on which side of the text the leader is attached on. Basically, the QLEADER
command uses the Text Offset specified in the DIMSTYLE to calculate the distance
between the leader and the text. It then uses this distance to determine the
location of the end of the leader. In a rotated UCS, this calculation is performed
incorrectly, and the end of the leader is placed in the wrong spot. The exact
spot varies depending on the rotation of the UCS. And if you drag the text
to a different location, causing the leader line to flip sides and attach to the
other side of the text, the gap size will change. This problem can be fixed
by manually dragging the end of the leader to the desired spot, but it gets rather
annoying.
There are a number of other problems, as well. For example, in AutoCAD 2007,
the MTEXT editor will sometimes rotate the text incorrectly in a rotated UCS.
The text is place correctly in the drawing, it is just rotated incorrectly while
the user tries to edit the text. This can make it somewhat challenging to
type, almost like trying to use a Bizzarro version of the 2006 MTEXT editor.
There are numerous other little bugs, too, like the "horizontal" and "vertical"
options of the QLEADER angle constraints don't function correctly, etc.
But the worst bugs arise from Land Desktop commands. Basically, many Land
Desktop commands do not work correctly unless the user is in the WCS. Changing
to a custom UCS confuses Land Desktop commands, and many of them no longer return
the correct values for Northings and Eastings or bearings. In addition to
using incorrect values, many Land Desktop labeling commands will also place the
text in the incorrect location, resulting in text flying to some apparently-random
point in your drawing (usually in a completely different quadrant of modelspace).
It is worse than that, though. If you try to create any Land Desktop elements
such as Points, Alignments, Parcels, etc., in a rotated UCS, Land Desktop may get
confused, and create the items using the wrong coordinates. This can actively
trash your project. Therefore, it is strongly recommended that you avoid using
a UCS in Land Desktop as much as possible. There are times when you
may want to temporarily switch to a custom UCS to draw something, but it is critical
that you remember to switch your drawing back to the WCS as soon as you are done.
If you should forget and leave the drawing in the UCS, the potential damage that
can result is immeasurable. Luckily, enough Land Desktop commands function
incorrectly in a UCS that it usually becomes clear pretty quickly what's going on.
But the safest bet is to just try to avoid using a UCS.
This is not an exhaustive list of all the problems with Views and UCSs in Land Desktop
- there are more. This is mainly designed to illustrate the types of problems
that occur. But at least in Land Desktop, there is a feature called "Drawing
Orientation" that we can use to work around all these issues.
(Unfortunately, some of these problems can crop up again in Civil 3D, and Civil 3D
has no "Drawing Orientation" feature that we can use to get around them.
But the new MLEADERS fix the "gap" problem that the old QLEADERS had, and Civil 3D
has other features that make this problem less of an issue than it has been in the
past.)
The "Drawing Orientation" Band-Aid
AutoCAD was originally conceived as a sort of "word processor for draftsmen".
Using a word-processor on a computer, formal (and even informal) written documents
could be produced much more quickly and easily than with hand-written drafts and
typewriters, and the end result looked better. It was only natural for people
to want to use computers to gain the same advantages for the slow, laborious process
of drafting plans. Thus AutoCAD was born. And since it was designed
largely to function as a tool for "computer-aided drafting", it seemed
natural to use a standard X, Y, and Z Cartesian coordinate system as the basis.
However, when it comes to Civil projects, the most-common Project Coordinate systems
are based on Northing, Easting, and Elevation. Since this is basically the
same thing as AutoCAD's XYZ coordinate system, it seems simple enough to just use
X-coordinates for Eastings, Y-coordinates for Northings, and Z-coordinates for Elevations.
And in fact, many people think that's the way things are in Land Desktop, and there
is no difference between an Easting and an X-coordinate, or a Northing and a Y-coordinate.
But that is not really the case. Land Desktop has two different grids, an XYZ
grid, and a Northing/Easting/Elevation (NEZ) grid, and they are two completely separate
grids.
In Land Desktop, Civil information is stored in a separate data store called a "Project".
This is a set of files outside of the DWG file, where items such as Alignments,
Surfaces, and Cogo Points are stored. Items in this Project data store are
defined using Northings, Eastings, and Elevations.
The DWG file, on the other hand, uses X, Y, and Z coordinates, because that's the
way AutoCAD works. When we Insert a Civil entity like a Cogo Point into a
Drawing, or Import an Alignment, or Generate Contours for a Surface, Land Desktop
converts the Northings, Eastings, and Elevations from the Project data into X, Y,
and Z coordinates. It then uses the X, Y, and Z coordinates to draw AutoCAD
entities in the drawing.
For example, when we add a new point to our project, Land Desktop creates a CogoPoint
entity in the Project database. This CogoPoint has a Northing, Easting, and
Elevation. When we insert the point into a drawing, Land Desktop converts
the Northing, Easting, and Elevation into X, Y, and Z values. It then creates
an AECC_POINT entity, and inserts the AECC_POINT into the drawing at the calculated
X, Y, and Z values.
The Z-value of a Land Desktop entity may or may not have anything to do with the
Elevation of the corresponding entity in the Project database. For
example, depending on various settings in Land Desktop, the AECC_POINT may have
a Z-coordinate that is the same as the Elevation of the CogoPoint, or it may be
inserted at some other Z value, such as Z=0. (This behavior is specified in
the Point Settings, on the "Insert" tab.) When Surface breaklines
and 3D-Lines are imported into a drawing, the resulting polylines are always created
with Z-values that are the same as the Surface Elevation at that point. Contours
and other Surface Display items are similar, but their Z-values are equal to the
Surface Elevation multiplied by an optional scaling factor. Alignments, Parcels,
and Surface Boundaries that are imported into a drawing are always created with
Z=0, as are most other objects created by Land Desktop commands. You can easily
see the Z-values of various items by starting up the 3DORBIT command and looking
around in a drawing (warning: this command is rather unstable in some versions of
AutoCAD, so you may want to save your drawing before using it).
On the other hand, the relationship between the NE grid in the project and the XY
grid in the drawing is specified in the Drawing Setup. In the Projects
menu, select "Drawing Setup...", and go to the "Orientation"
tab. On this screen, you can pick an XY point in the drawing to use as the
Base Point for the NE grid, and also specify the NE for that point. Then you
can specify a North Rotation for the NE grid. Unlike the AutoCAD ROTATE command,
which uses an angle-left from the X-Axis, the North Rotation is measured as an angle-right
from the Y-axis, similar to a North Azimuth. For example, a North Rotation
of 0 means North is in the same direction of the positive Y-Axis; a North Rotation
of 90 means North is in the same direction as the positive X-Axis; a North Rotation
of 180 means north is in the same direction as the negative Y-axis; etc. (Note:
the value in the North Rotation field is specified in HH.MMSS format, even though
it looks like decimal degrees. So if we wanted a North Rotation of 12 and
one-half degrees, we would have to type in 12.3 for 12°30'00". A value
of 12.5 would indicate 12°50'00", or 12.8333°.)
Using the "Drawing Orientation"
From our experience, we have determined that it is wise to try to avoid using an
offset for the Base Point of the NE. In other words, try to always use (0,0)
as the Base Point for the NE grid, so that (0,0) in XY coordinates is also (0,0)
in NE coordinates. We have discovered from experience that using any
other Base Point creates huge levels of confusion, and should be avoided if at all
possible.
Let's take a look at our earlier example, and see how we would set it up using the
Drawing Orientation. Let's assume we already have our basic linework created
in modelspace. It would look much like the image in Figure 1 below (again,
click for a larger image). The drawing is set to the WCS, and there is no
DView TWist applied. Notice that North is pointed in the same direction as
the positive Y-axis. If we use Land Desktop's "Identify Northing/Easting"
command (found in the Inquiry menu), we see the XY and NE coordinates for the indicated
point are as shown in the Figure 1. Note that the X-Coordinate of the indicated
corner is the same as the Easting, and the Y-Coordinate is the same as the Northing.
In the drawing we want to create, we actually want North to point 45° clockwise
from the Y-Axis. To configure this in Land Desktop, we go to our Drawing Settings,
and change the North Rotation to 45°. When you do this, you will get a warning
dialog box pop open, warning you that you may also have to move objects in your
drawing. We'll get back to this in a second; click OK in the dialog box for
right now to go on. This rotates the Northing/Easting grid, so that North
is now rotated 45° clockwise. The NE grid and the XY grid still share the
same base point, and (0,0) is still the same point in both grids. But the
NE grid is now rotated at a 45°-angle to the XY grid. So now if we run the
Identify Northing/Easting command and identify the same point as before, we get
the values shown in Figure 2 above. Notice that the XY coordinates did not
change. But now our NE coordinates are different. This is what that
dialog box was warning about when we changed the North Rotation. Essentially,
we rotated our NE grid under our linework, but we left the linework in the old location.
Our linework and the NE grid are "out of sync". To fix things, we
must also rotate our linework 45° clockwise, so that it matches the NE grid.
To do this, we first must make sure all
objects in the drawing are turned on and thawed, then select ALL objects and rotate
them 45° clockwise, using (0,0) as the basepoint. When we ID the Northing/Easting
of the property corner after rotating the linework, we get the results found in
Figure 3. Note that the Northing and Easting are back to the same values as
in Figure 1, although the X and Y values are different.
At this point, we have a drawing with all linework oriented the way we want it.
If we ID any point, we will get the correct Northing and Easting. If we inverse
between any points or label any bearings, we will get correct bearings. But
we haven't changed our XY grid at all - it's still oriented with Y pointed to the
top of the page. We are still using the WCS, and we are not using DView Twist.
This means that every Autodesk and Land Desktop labeling command will still work
correctly. In other words, we have achieved our goal.
We can now go around and label items normally, without worry, and without needing
to constantly "correct" things and "clean up after Land Desktop".
The results are as shown in the figure at the right. I have placed the same
labels as I did earlier, using the exact same commands, but this time everything
shows up correctly. I did not have to tweak or modify any text or dimensions
after they were created; every item was created exactly as it should look.