Autodesk Technology Managers Forum
Share your knowledge, ask questions, and engage with fellow CAD/BIM Managers.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Reply
Message 1 of 18
Anonymous
547 Views, 17 Replies

Nested Xrefs?

My office has a history of NEVER attaching an Xrefs, it is all overlays.
Because of this, you get into a situation of Xref the structural grid into
the plan, then xref the grid and the plan into the ceiling plan, then xref
the grid, the plan & the ceiling plan into the ceiling plan sheet. It seems
to me this is just a bunch of wasted effort, and nesting Xrefs would
eliminiate a LOT of redundancy. As far as I can tell, the Never Overlay rule
is a hold over from when there really was issues with doing it (what,
release 12 or something?).
So, from a CAD Management standpoint, and given an office of 30 people,
doing relatively large public projects, are there any reasons to stick with
the 'No Nested Xrefs' rule, or potential pitfalls to be aware of?

Thanks,
Gordon
17 REPLIES 17
Message 2 of 18
Anonymous
in reply to: Anonymous

Nesting Xrefs just makes it harder for people to understand the data flow.
Set up the sheet/model the one time, xref the needed files, and go about
your business. If you are consistent with file naming, you can do it with a
simple script or lisp routine.

I abhor nested xrefs just because of the mental gymnastics of keeping
multiple levels of xrefs straight for most users.

--
James Wedding, P.E.
IT Manager
Jones & Boyd, Inc.
Dallas, TX
jwedding@*NOSPAM*jones-boyd.com

Search before you ask, it's been asked before.
Message 3 of 18
Anonymous
in reply to: Anonymous

We do only Overlays also. I like it that way because it is just easier
conceptually. Personally, I have no problem with nested Xref's but I have
seen it confuse more than one person, more than one time. It also avoids
circular references which can confuse AutoCAD, you know, Xreffing A into B
into C into A type of stuff. Is A the parent drawing or the nested xref
now? AutoCAD isn't sure either.


--
matthew g.
Message 4 of 18
Anonymous
in reply to: Anonymous

Nesting xref's is like any other feature of AutoCAD, it has it's role and
effectiveness. Every argument against can be offset by a few minutes
training and an understanding of how they should be used. If you're
spending time referencing the same group of files over and over to create
different "sheets" it's time to think about nested references....one place I
can think makes sense to me: base architectural plans and column grids, why
force all the trades to reference them in themselves?? (If you're like us
with separate column grid plans (G))

Steve


"Gordon Price" wrote in message
news:BED760C4DACAF0BDEF7D42DEFA28E9F8@in.WebX.maYIadrTaRb...
> My office has a history of NEVER attaching an Xrefs, it is all overlays.
> Because of this, you get into a situation of Xref the structural grid into
> the plan, then xref the grid and the plan into the ceiling plan, then xref
> the grid, the plan & the ceiling plan into the ceiling plan sheet. It
seems
> to me this is just a bunch of wasted effort, and nesting Xrefs would
> eliminiate a LOT of redundancy. As far as I can tell, the Never Overlay
rule
> is a hold over from when there really was issues with doing it (what,
> release 12 or something?).
> So, from a CAD Management standpoint, and given an office of 30 people,
> doing relatively large public projects, are there any reasons to stick
with
> the 'No Nested Xrefs' rule, or potential pitfalls to be aware of?
>
> Thanks,
> Gordon
>
>
Message 5 of 18
Anonymous
in reply to: Anonymous

I almost never use "OVERLAY" with xrefs. The only reason it was added in
the first place was to deal with circular references. It just makes you
have to re-xref everything you've already referenced in. With "Edit Block
In-place," creating circular references is no longer an issue, because you
don't need to do it.
--
David W. Claflin
Associate/Architect

TSP

Architecture Engineering Construction

8751 E Hampden Ave, Suite A-1
Denver, CO 80231-4928
phone (303) 695-1997
fax (303) 695-1938
cell phone (303) 378-3414
www.teamtsp.com <>

--

This email may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this email in error) please
notify the sender immediately and destroy this email. Any unauthorized
copying, disclosure or distribution of the material in this email is
strictly forbidden.
Remove .ns from reply address.

"Steve Stafford" wrote in message
news:1185B0A7D10DFA42658A8D597BD51012@in.WebX.maYIadrTaRb...
> Nesting xref's is like any other feature of AutoCAD, it has it's role and
> effectiveness. Every argument against can be offset by a few minutes
> training and an understanding of how they should be used. If you're
> spending time referencing the same group of files over and over to create
> different "sheets" it's time to think about nested references....one place
I
> can think makes sense to me: base architectural plans and column grids,
why
> force all the trades to reference them in themselves?? (If you're like us
> with separate column grid plans (G))
>
> Steve
>
>
> "Gordon Price" wrote in message
> news:BED760C4DACAF0BDEF7D42DEFA28E9F8@in.WebX.maYIadrTaRb...
> > My office has a history of NEVER attaching an Xrefs, it is all overlays.
> > Because of this, you get into a situation of Xref the structural grid
into
> > the plan, then xref the grid and the plan into the ceiling plan, then
xref
> > the grid, the plan & the ceiling plan into the ceiling plan sheet. It
> seems
> > to me this is just a bunch of wasted effort, and nesting Xrefs would
> > eliminiate a LOT of redundancy. As far as I can tell, the Never Overlay
> rule
> > is a hold over from when there really was issues with doing it (what,
> > release 12 or something?).
> > So, from a CAD Management standpoint, and given an office of 30 people,
> > doing relatively large public projects, are there any reasons to stick
> with
> > the 'No Nested Xrefs' rule, or potential pitfalls to be aware of?
> >
> > Thanks,
> > Gordon
> >
> >
>
>
Message 6 of 18
Anonymous
in reply to: Anonymous

do you have a lisper that allows offset from a gridline contained within an
xref?

Just curious - always wanted to xref columns/grids etrc but hated not being
able to use offset

--
Jamie Duncan

"Maybe the Hokey Pokey is REALLY what's it all about"
"Steve Stafford" wrote in message
news:1185B0A7D10DFA42658A8D597BD51012@in.WebX.maYIadrTaRb...
> Nesting xref's is like any other feature of AutoCAD, it has it's role and
> effectiveness. Every argument against can be offset by a few minutes
> training and an understanding of how they should be used. If you're
> spending time referencing the same group of files over and over to create
> different "sheets" it's time to think about nested references....one place
I
> can think makes sense to me: base architectural plans and column grids,
why
> force all the trades to reference them in themselves?? (If you're like us
> with separate column grid plans (G))
>
> Steve
>
>
> "Gordon Price" wrote in message
> news:BED760C4DACAF0BDEF7D42DEFA28E9F8@in.WebX.maYIadrTaRb...
> > My office has a history of NEVER attaching an Xrefs, it is all overlays.
> > Because of this, you get into a situation of Xref the structural grid
into
> > the plan, then xref the grid and the plan into the ceiling plan, then
xref
> > the grid, the plan & the ceiling plan into the ceiling plan sheet. It
> seems
> > to me this is just a bunch of wasted effort, and nesting Xrefs would
> > eliminiate a LOT of redundancy. As far as I can tell, the Never Overlay
> rule
> > is a hold over from when there really was issues with doing it (what,
> > release 12 or something?).
> > So, from a CAD Management standpoint, and given an office of 30 people,
> > doing relatively large public projects, are there any reasons to stick
> with
> > the 'No Nested Xrefs' rule, or potential pitfalls to be aware of?
> >
> > Thanks,
> > Gordon
> >
> >
>
>
Message 7 of 18
Anonymous
in reply to: Anonymous

Are you refering to placing walls offset from a grid line? If so that's a
value you can set when placing walls, the wall command doesn't care what you
are using just what your start and end points are.

Steve
Message 8 of 18
Anonymous
in reply to: Anonymous

We use nested Xrefs extensively.

We use Attach about 95% of the time, because we split our drawings
into smaller units which makes output easier to deal with. IMO you
need to carefully analyze your particular needs, and see where nesting
Xrefs makes sense.

In our case, we usually start with an Existing Architectural (AE)
plan, which is referenced as an Attached Xref into a Demo plan (AD)
and a new Architectural (A) plan. This allows the A/AE combo to be
referenced via Attach into ceiling (AC), furniture (AFE), finish (AF)
and power and communications (APC) files. These files are in turn
referenced into a final plot "CD" sheet files. By using Attach all the
Xref info we need comes along.

We also Xref Overlay plans into elevations and building sections for
design work to progress and still be tied to the plans. However, in
those drawings we do not want the plan info to progress to the CD
sheets, so we use Overlay to limit where the references go.

We use Overlay for referencing the Project Title Block into floor plan
files, where we use layouts for shooting off space plans for sign off.
This is just a tad simpler than creating dedicated CD sheets for
basically transitive purposes.

I would say that both Attach and Overlay perform essential functions
and need to be considered.

Matt
mstachoni@comcast.net
mstachoni@bhhtait.com

On Mon, 20 Jan 2003 12:51:13 -0800, "Gordon Price" this)@attbi.com> wrote:

>My office has a history of NEVER attaching an Xrefs, it is all overlays.
>Because of this, you get into a situation of Xref the structural grid into
>the plan, then xref the grid and the plan into the ceiling plan, then xref
>the grid, the plan & the ceiling plan into the ceiling plan sheet. It seems
>to me this is just a bunch of wasted effort, and nesting Xrefs would
>eliminiate a LOT of redundancy. As far as I can tell, the Never Overlay rule
>is a hold over from when there really was issues with doing it (what,
>release 12 or something?).
>So, from a CAD Management standpoint, and given an office of 30 people,
>doing relatively large public projects, are there any reasons to stick with
>the 'No Nested Xrefs' rule, or potential pitfalls to be aware of?
>
>Thanks,
>Gordon
>
Message 9 of 18
cprettyman
in reply to: Anonymous

Gordon: In my last office, which was fairly small, and where I had been exerting my influence for some time, we allowed nested X-refs, and only one of 12 people ever used overlays. But, the projects were quite small, and the majority fo them didn't have any nesting of xrefs because we didn't have to deal with a lot of issues that are common to larger, more complex projects. In my current office, I wish that there had been an "Overlay Only" rule, except that my predecessor would never have enforcced it. The x-refing here is a nightmare. I think, having seen what may be the worst case scenario, that nested x-refs would still be OK, if everyone worked in some logical manner. But the "overlays only" rule is simple to define, and relatively simple to audit. If you are trying to make CAD work better in your office, you need to choose your battles. If everyone already accepts that rule, I would accept it, and pick another issue as the focus of my attention. - CP
Message 10 of 18
Anonymous
in reply to: Anonymous

Gordon,

We use attached X-refs only. No overlays. Even though I experimented for some time
with overlays, I finally realized that we can do everything with X-ref-Attach with no
problems. In our office, we produce drawings that are related to different
disciplines: Architectural, Electrical, Mechanical and Technology. The floor plans of
each discipline are organized by putting each discipline's design elements in their
own "master" files; then, these "masters" are borrowed by other departments to create
their own design elements in their "masters"; then, these combined "masters" are
x-ref'd into sheet files. The sheet files are drawing files that might contain 3 or 4
layouts, in order to group the sheets that share the same master file or design. The
relationship between these master files is represented in our CAD manual in a chart
with bubbles and arrows, that shows the relationship betweens all these files.

The setup for the master or design files is something like this:

architectural design = "A"
reflected ceiling design = "B" (includes A as background)
lighting & fire alarm design = "C" (includes A+B as background)

The setup for sheet or plot files is something like this:

architectural floor plans = X-ref "A"
reflected ceiling plans = X-ref "B"
lighting plan = X-ref "C"
fire alarm plans = X-ref "C"

The maximum depth of nesting is the one represented by a+b+c , which occurs precisely
when we do the lighting sheets, because we x-ref "C" in order to show the
architectural background(A), plus the r.c.p.(B) plus the lighting design itself (C) In
most other situations, only two levels of nesting are required.

Alfredo Medina

"Gordon Price" wrote in message
news:BED760C4DACAF0BDEF7D42DEFA28E9F8@in.WebX.maYIadrTaRb...
> My office has a history of NEVER attaching an Xrefs, it is all overlays.
> Because of this, you get into a situation of Xref the structural grid into
> the plan, then xref the grid and the plan into the ceiling plan, then xref
> the grid, the plan & the ceiling plan into the ceiling plan sheet. It seems
> to me this is just a bunch of wasted effort, and nesting Xrefs would
> eliminiate a LOT of redundancy. As far as I can tell, the Never Overlay rule
> is a hold over from when there really was issues with doing it (what,
> release 12 or something?).
> So, from a CAD Management standpoint, and given an office of 30 people,
> doing relatively large public projects, are there any reasons to stick with
> the 'No Nested Xrefs' rule, or potential pitfalls to be aware of?
>
> Thanks,
> Gordon
>
>
Message 11 of 18
Anonymous
in reply to: Anonymous

It depends on how the xrefs are being used, IMO.

For my industry since ACAD 2000 came out with the new layouts as miltiple
paperspace layouts. We no longer need it to attach the architectural
backgrounds to our drawings so that we would not have to reattach everything
in every plot layouts in paperspace.


"Gordon Price" wrote in message
news:BED760C4DACAF0BDEF7D42DEFA28E9F8@in.WebX.maYIadrTaRb...
> My office has a history of NEVER attaching an Xrefs, it is all overlays.
> Because of this, you get into a situation of Xref the structural grid into
> the plan, then xref the grid and the plan into the ceiling plan, then xref
> the grid, the plan & the ceiling plan into the ceiling plan sheet. It
seems
> to me this is just a bunch of wasted effort, and nesting Xrefs would
> eliminiate a LOT of redundancy. As far as I can tell, the Never Overlay
rule
> is a hold over from when there really was issues with doing it (what,
> release 12 or something?).
> So, from a CAD Management standpoint, and given an office of 30 people,
> doing relatively large public projects, are there any reasons to stick
with
> the 'No Nested Xrefs' rule, or potential pitfalls to be aware of?
>
> Thanks,
> Gordon
>
>
Message 12 of 18
Anonymous
in reply to: Anonymous

"Gordon Price" wrote in message:
>[...]
>are there any reasons to stick with
> the 'No Nested Xrefs' rule, or potential pitfalls to be aware of?
>[...]

I had the same realization that you are having a while back:
"Why re-attach xrefs to the plotted sheet files,
when I could just attach all necessary xrefs to the design files;
and they would *all* insert into the plotted sheet files; albeit nested?"

Well, this sounds good on paper, but there certainly are some drawbacks.
Here are two that come to mind:

1. Relative Pathing
If you are using relative paths for your xrefs, and the design files and
plotted sheet files do not reside in the same directory, the nested paths
will be broken/not found. When I setup our system here, I mistakenly made
the assumption that if a relative path resolves for an un-nested xref in its
parent file, then it will just be carried along as "baggage" with the
parent file; wherever you xref the parent file. Not so.
See a lengthy, confusing post on this (in the archives) that I authored a
few months back...

2. ADT Scheduling
If you use nested xrefs, then just be aware that when you schedule an xref,
the schedule will scan the parent and all nested xrefs. This can be dealt
with, with layer filtering; but it certainly is a lot more cumbersome to
setup.

--
http://www.searchbeforeyoupost.com
"it's been asked before."
Message 13 of 18
Anonymous
in reply to: Anonymous

No I mean when you are in the planning stage - setting out rough areas and
trhings like that - we always keep in mind the final working drawing product
righty from the start of concepty desighn - offsetting from grids would be
nice.

--
Jamie Duncan

"Maybe the Hokey Pokey is REALLY what's it all about"
"Steve Stafford" wrote in message
news:DC4A94579F4649F5C473988E8F856D3A@in.WebX.maYIadrTaRb...
> Are you refering to placing walls offset from a grid line? If so that's a
> value you can set when placing walls, the wall command doesn't care what
you
> are using just what your start and end points are.
>
> Steve
>
>
Message 14 of 18
Anonymous
in reply to: Anonymous

"Corey A. Layton" wrote in message
news:B72426FFD19A2FCCA3F4D224F7543CDF@in.WebX.maYIadrTaRb...
> 1. Relative Pathing
> If you are using relative paths for your xrefs, and the design files and
> plotted sheet files do not reside in the same directory, the nested paths
> will be broken/not found. When I setup our system here, I mistakenly made
> the assumption that if a relative path resolves for an un-nested xref in
its
> parent file, then it will just be carried along as "baggage" with the
> parent file; wherever you xref the parent file. Not so.
> See a lengthy, confusing post on this (in the archives) that I authored a
> few months back...

Corey,
great heads up. We are actually looking at going to relative pathing as
well, so things could have really blown up there. Luckily, from any drawing,
the relative paths will always be the same, ie we have a folder for the
project, and then a bunch of single folders there, but every file is exactly
one level deep, So for every xref in the project, ..\folder\file will work,
no matter what folder the refrncing file is in.
Now I just need to document the change so people get it 😉

Gordon
Message 15 of 18
Anonymous
in reply to: Anonymous

another thing to consider when you choose to use the more complicated method
of nested xrefs is to re-evaluate your folder structure. maybe you can
compensate by making this simpler.

it is a lot easier to manage nested xrefs for instance of all the files for
a project live in only one folder with no subfolders. then you only have to
manage file naming.

of course this is rarely possible and a combination of solutions will
prevail.

for me i choose to overlay anything that requires an absolute path to be
saved. examples would be project notes, titleblocks, and details. these all
live in a central network location.

on the other hand anything that can have a relative path almost always
should be attached. examples here would be exterior shell, core, interior
partitions, annotations, and discipline specific drawings.

matthew



"Gordon Price" wrote in message
news:BED760C4DACAF0BDEF7D42DEFA28E9F8@in.WebX.maYIadrTaRb...
> My office has a history of NEVER attaching an Xrefs, it is all overlays.
> Because of this, you get into a situation of Xref the structural grid into
> the plan, then xref the grid and the plan into the ceiling plan, then xref
> the grid, the plan & the ceiling plan into the ceiling plan sheet. It
seems
> to me this is just a bunch of wasted effort, and nesting Xrefs would
> eliminiate a LOT of redundancy. As far as I can tell, the Never Overlay
rule
> is a hold over from when there really was issues with doing it (what,
> release 12 or something?).
> So, from a CAD Management standpoint, and given an office of 30 people,
> doing relatively large public projects, are there any reasons to stick
with
> the 'No Nested Xrefs' rule, or potential pitfalls to be aware of?
>
> Thanks,
> Gordon
>
>
Message 16 of 18
Anonymous
in reply to: Anonymous

also if you are planning on embracing the single model file concept then
nested xrefs are crucial.

plan, section, elevation, and structure DWGs can be xref attached into a new
intermediate model file. then this model file is what should be xref
attached into the sheet file. this has an added benefit of simplifying reuse
of templates. however this unfortunately also creates some layer management
difficulties that usually require custom lisp routines.

matthew



"Gordon Price" wrote in message
news:BED760C4DACAF0BDEF7D42DEFA28E9F8@in.WebX.maYIadrTaRb...
> My office has a history of NEVER attaching an Xrefs, it is all overlays.
> Because of this, you get into a situation of Xref the structural grid into
> the plan, then xref the grid and the plan into the ceiling plan, then xref
> the grid, the plan & the ceiling plan into the ceiling plan sheet. It
seems
> to me this is just a bunch of wasted effort, and nesting Xrefs would
> eliminiate a LOT of redundancy. As far as I can tell, the Never Overlay
rule
> is a hold over from when there really was issues with doing it (what,
> release 12 or something?).
> So, from a CAD Management standpoint, and given an office of 30 people,
> doing relatively large public projects, are there any reasons to stick
with
> the 'No Nested Xrefs' rule, or potential pitfalls to be aware of?
>
> Thanks,
> Gordon
>
>
Message 17 of 18
Anonymous
in reply to: Anonymous

Gordon,

I came from an office that worked similarly as Alfredo, the rule was "attach
only". It's important to note that when using attach, there should be
strict standards concerning *where* you attach xrefs. We also had a three
level system such that base files, such as grids, referenced only into
master files, such as floors, which only referenced to sheet files. Never
attach at the same level (of the three). When there's a clear hierarchy,
circular references are not really a problem.

I now work for an office that's "overlay only". It took some time to get
used to, but overall I think it causes less headaches, and allows a looser
file structure. Granted we have to use the xref attach command a little
more, but really, once a file it set up, you don't ever have to go back to
it. I don't think that the "I have to xref SO much more when overlaying"
argument really flies. With 100 drawings over 6 months to a year for a
project, you're still attaching files only 100 times (once for each sheet).

IMHO, from my experience, the real problems come when you MIX attach and
overlay on the same project. It gets really hairy, and requires a lot of
coordination for the team. Only with clear guidelines about how the project
is organized will this ever work. There's a project here that the team
tried to do that on without any organization, and it's been a nightmare for
them. I say "I hate to say I told you so, but..."

So as others have suggested, a clear organization will enable either system
to work. However, if one is in place already, you're asking for more
trouble by changing it.

Good luck,
Danny Polkinhorn
Perkins & Will
Atlanta


"Alfredo Medina" wrote in message
news:47AA124F5A8AD993EBEA1D0682526878@in.WebX.maYIadrTaRb...
> Gordon,
>
> We use attached X-refs only. No overlays. Even though I experimented for
some time
> with overlays, I finally realized that we can do everything with
X-ref-Attach with no
> problems. In our office, we produce drawings that are related to different
> disciplines: Architectural, Electrical, Mechanical and Technology. The
floor plans of
> each discipline are organized by putting each discipline's design elements
in their
> own "master" files; then, these "masters" are borrowed by other
departments to create
> their own design elements in their "masters"; then, these combined
"masters" are
> x-ref'd into sheet files. The sheet files are drawing files that might
contain 3 or 4
> layouts, in order to group the sheets that share the same master file or
design. The
> relationship between these master files is represented in our CAD manual
in a chart
> with bubbles and arrows, that shows the relationship betweens all these
files.
>
> The setup for the master or design files is something like this:
>
> architectural design = "A"
> reflected ceiling design = "B" (includes A as background)
> lighting & fire alarm design = "C" (includes A+B as background)
>
> The setup for sheet or plot files is something like this:
>
> architectural floor plans = X-ref "A"
> reflected ceiling plans = X-ref "B"
> lighting plan = X-ref "C"
> fire alarm plans = X-ref "C"
>
> The maximum depth of nesting is the one represented by a+b+c , which
occurs precisely
> when we do the lighting sheets, because we x-ref "C" in order to show the
> architectural background(A), plus the r.c.p.(B) plus the lighting design
itself (C) In
> most other situations, only two levels of nesting are required.
>
> Alfredo Medina
>
> "Gordon Price" wrote in message
> news:BED760C4DACAF0BDEF7D42DEFA28E9F8@in.WebX.maYIadrTaRb...
> > My office has a history of NEVER attaching an Xrefs, it is all overlays.
> > Because of this, you get into a situation of Xref the structural grid
into
> > the plan, then xref the grid and the plan into the ceiling plan, then
xref
> > the grid, the plan & the ceiling plan into the ceiling plan sheet. It
seems
> > to me this is just a bunch of wasted effort, and nesting Xrefs would
> > eliminiate a LOT of redundancy. As far as I can tell, the Never Overlay
rule
> > is a hold over from when there really was issues with doing it (what,
> > release 12 or something?).
> > So, from a CAD Management standpoint, and given an office of 30 people,
> > doing relatively large public projects, are there any reasons to stick
with
> > the 'No Nested Xrefs' rule, or potential pitfalls to be aware of?
> >
> > Thanks,
> > Gordon
> >
> >
>
>
Message 18 of 18
Anonymous
in reply to: Anonymous

One trick I used (when I worked with numerous xrefs in a dwg)
was to change the colors of the predominant layer (walls, for example)

The strategy was to set that layer similar to the following:
Xref 1-- color 11 Xref 2-- color 21 Xref 3-- color 31 Xref 4--
color 41
Now, when you need ot turn one off (or remove it) it was obviuous to the
opereator which was which

As for my preference - do not nest them.... and its in my manual that way...
with the further explanation NOT to try to eliminate nested setups...
sometimes it IS the best.

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Administrator Productivity


Autodesk Design & Make Report