a (confusing) rant about relative xref pathing

[Anonymous]

ok, here's the scoop...

I had this relavation:
I was setting up my directory structure to be used for CAD dwgs.
And I thought to myself
"Always make the xref (design, Work, etc. whatever you call it) directory
a sub directory of the plotted dwgs. So that relative pathing could be used,
and the nested xrefs will always resolve, wherever the project directory
"tree" is moved to (another drive, archived to cd, another parent directory,
etc.)"

so I set it up like this:
(there are WAY more subdirectories under the project folder, but this
illustrates my point)

\\Drawings
this is where the plotted dwgs go that xref design files
These dwgs are opened to plot only, no CAD data here other than xrefs
relative path: Work\.dwg

\\Drawings\Work
this is where the design dwgs go that xref consultant files
These dwgs are opened to edit CAD data,
may xref consultant CAD data
relative path: xref\.dwg

\\Drawings\Work\xref\
this is where the consultant CAD files go (read only)
These dwgs are for coordination, no editing here.

It all sounded so nice.

But my system was flawed:
I made the assumption that an "attached" (vs. "overlayed") xref (A.dwg)
that resolves with a relative path, will also resolve when it's parent
drawing (B.dwg) is xreffed into another dwg. (C.dwg).

not so.

A.dwg lists as "unresolved" in C.dwg
because A.dwg's relative path saved in B.dwg
won't resolve from C.dwg.

if A is attached to B and B to C,
shouldn't A resolve in C?

are you as confused as I am?
(this is completely hard to explain,
if you're not Matt S.)


--
http://www.searchbeforeyoupost.com
"it's been asked before."

[Anonymous]

xRef paths will not be retained if you uncheck "Retain Paths" when
attaching. Always save your path information, then edit it as necessary.

--
Regards,

Paul Monsef
-----------------------------
TSA | architects, pllc
Production/CAD Manager
425.401.6828 x105
paulm@tsaarchitects.com

"Corey A. Layton" wrote in message
news:67581303C597E41270F1ED9284DC7A0E@in.WebX.maYIadrTaRb...
> ok, here's the scoop...
>
> I had this relavation:
> I was setting up my directory structure to be used for CAD dwgs.
> And I thought to myself
> "Always make the xref (design, Work, etc. whatever you call it) directory
> a sub directory of the plotted dwgs. So that relative pathing could be
used,
> and the nested xrefs will always resolve, wherever the project directory
> "tree" is moved to (another drive, archived to cd, another parent
directory,
> etc.)"
>
> so I set it up like this:
> (there are WAY more subdirectories under the project folder, but this
> illustrates my point)
>
> \\Drawings
> this is where the plotted dwgs go that xref design files
> These dwgs are opened to plot only, no CAD data here other than xrefs
> relative path: Work\.dwg
>
> \\Drawings\Work
> this is where the design dwgs go that xref consultant files
> These dwgs are opened to edit CAD data,
> may xref consultant CAD data
> relative path: xref\.dwg
>
> \\Drawings\Work\xref\
> this is where the consultant CAD files go (read only)
> These dwgs are for coordination, no editing here.
>
> It all sounded so nice.
>
> But my system was flawed:
> I made the assumption that an "attached" (vs. "overlayed") xref (A.dwg)
> that resolves with a relative path, will also resolve when it's parent
> drawing (B.dwg) is xreffed into another dwg. (C.dwg).
>
> not so.
>
> A.dwg lists as "unresolved" in C.dwg
> because A.dwg's relative path saved in B.dwg
> won't resolve from C.dwg.
>
> if A is attached to B and B to C,
> shouldn't A resolve in C?
>
> are you as confused as I am?
> (this is completely hard to explain,
> if you're not Matt S.)
>
>
> --
> http://www.searchbeforeyoupost.com
> "it's been asked before."
>
>

[Anonymous]

>are you as confused as I am?
>(this is completely hard to explain,
>if you're not Matt S.)

You're in luck! I _am_ Matt S., so I may be of assistance 🙂

I'll first explain that yes, your original idea about plot-only "sheet" drawings
referencing the design files as xrefs is perfectly valid - we've been using the
technique for some time. I think by now it's pretty much industry standard
practice.

However, relative pathing, in your configuration, has some problems in the
manner you've described. This is because you are both referencing from the same
directory (design xrefs into design xrefs) and across nested folder boundaries
(design xrefs into CD sheet files). Specifically, your problem with referential
pathing is that the sheet files cannot find the nested design Xref file(s) -
simply because the relative pathing cannot take folder nesting into account.

In other words, let's say in the \Project\Drawings\xref\ folder, you have PLAN
and RCP. RCP references PLAN. Without full hard coded paths, the Xref path is
simply "PLAN.DWG". With relative pathing, it is ".\PLAN.DWG" because it's in the
same folder as the parent file. It could also be referenced as
"..\Xrefs\PLAN.DWG" - the "..\" evaluates to the parent folder of the "." which
is the current folder.

However, this saved path falls apart when you reference RCP into the Sheet file
(e.g., A1-2.DWG) that is one folder above, in \Project\Drawings\, because while
the RCP path is relative at "xref\RCP.DWG" it cannot find ".\PLAN.DWG" because
it's not in the same folder as the A1-2.DWG file. Using the double-dot method
does not work either, because the saved path is "..\Xrefs\PLAN" which doesn't
exist at the \Drawings level.

Solutions?

(1) put everything in one folder. I found this to be unacceptable for most
projects of any size.


(2) Use hard coded paths, always. Problematic because of inflexibility with
moving folders around, but it IS bulletproof. Especially if you have a
standardized file naming system that reuses the same file names across projects.

(3) Break out your folders into a parallel structure so that relative pathing is
one level deeper from the same root, using "..\" to reference the root folder
one step above.

To wit:

Use \Project\Drawings\Xrefs for Design files
Use \Project\Drawings\CDs for Sheet files

Under the Working files, relative path from \Drawings, not from .\ (the current
directory) via "..\"

E.g.,

\Project\Drawings\Xrefs\RCP.DWG references "..\Xrefs\PLAN.DWG" - the two dots
evaluate to "\Project\Drawings\". Now you have the base from which all future
pathing can relate to this parent folder, instead of the current folder and
folders below.

So now, when you reference RCP into "\Project\Drawings\CDs\A1-2.dwg", the file
references "..\Xrefs\RCP.DWG" which ALSO references "..\Xrefs\PLAN.DWG" and it
all comes together. Xrefs is under the Root (\Drawings) as is CDs.

This only works when we're using a parallel structure for both CDs and Xrefs,
pathing off the root of \Drawings\. If you don't use parallel folders, and
instead use a nested structure (e.g., \Drawings\ for CDs and \Drawings\Xrefs for
design) the system falls apart because at the \Drawings\ level, children design
files (RCP.DWG) would be referencing "..\Xrefs\PLAN.DWG", which won't resolve
because the path that would _work_ would be "..\Drawings\Xrefs\PLAN.DWG".

So, maintaining a parallel structure works with relative pathing, and has a few
advantages besides:

1) You can have subfolders under CDs and Xrefs which pertain to those types of
files only. For example, I always maintain a \Bakups folder in each for BAK
files, which gets them out of the main folder and reduces clutter. Under CDs you
could have \Plots, and under Xrefs you could have \Trash. It keeps the folder
structure neater and doesn't interfere with cross-referencing files.

2) You can move the whole \Drawings root, and all references below this work as
well, if they are relative pathed in this manner.

Problems with relative pathing:

We use standard file names for design (xref) files to reduce the learning curve
going from project to project. It also makes file management easier at the
server level. However, with relative pathing, you will find yourself in a
situation where references will pull in the wrong drawing from a different
project. This happens when you switch projects without quitting AutoCAD, because
AutoCAD's working directory is the same one used when you launch the app by
dbl-clicking on a drawing icon.

So, for example, if you open up \CDs\A1-2.dwg in ONE project, it may actually
pull in ..\Drawings\Xrefs\PLAN.DWG from a completely different project folder,
because the root "\ProjectA\Drawings" will be referenced, not
"\ProjectB\Drawings\". Which is why I abandonded relative pathing and stuck
w/hard coded xrefs. I like standard names, and I can repath a whole lot of Xrefs
in no time.

Matt
mstachoni@comcast.net
mstachoni@beyerdesign.com













Matt
mstachoni@comcast.net
mstachoni@beyerdesign.com






On Fri, 12 Jul 2002 14:15:25 -0700, "Corey A. Layton"
wrote:

>ok, here's the scoop...
>
>I had this relavation:
>I was setting up my directory structure to be used for CAD dwgs.
>And I thought to myself
>"Always make the xref (design, Work, etc. whatever you call it) directory
>a sub directory of the plotted dwgs. So that relative pathing could be used,
>and the nested xrefs will always resolve, wherever the project directory
>"tree" is moved to (another drive, archived to cd, another parent directory,
>etc.)"
>
>so I set it up like this:
>(there are WAY more subdirectories under the project folder, but this
>illustrates my point)
>
>\\Drawings
>this is where the plotted dwgs go that xref design files
>These dwgs are opened to plot only, no CAD data here other than xrefs
>relative path: Work\.dwg
>
>\\Drawings\Work
>this is where the design dwgs go that xref consultant files
>These dwgs are opened to edit CAD data,
>may xref consultant CAD data
>relative path: xref\.dwg
>
>\\Drawings\Work\xref\
>this is where the consultant CAD files go (read only)
>These dwgs are for coordination, no editing here.
>
>It all sounded so nice.
>
>But my system was flawed:
>I made the assumption that an "attached" (vs. "overlayed") xref (A.dwg)
>that resolves with a relative path, will also resolve when it's parent
>drawing (B.dwg) is xreffed into another dwg. (C.dwg).
>
>not so.
>
>A.dwg lists as "unresolved" in C.dwg
>because A.dwg's relative path saved in B.dwg
>won't resolve from C.dwg.
>
>if A is attached to B and B to C,
>shouldn't A resolve in C?
>

[Anonymous]

Hey Matt,
Thanks for undertaking this totally confusing issue with me.
(and when I say "totally confusing", I mean to *describe*;
not that difficult a concept to comprehend, though.)

The way I do it now, I typically use the "dot,dot" method
to revert back to the "lowest common denominator" directory
as you've described.
I was just searching for a way to revise this,
because my design team just can't wrap their brains around this concept.
I was trying to simplify it by eliminating the need for the "dot,dot";
and just have them strip the path from the current dwg down.
I made the mistake of assuming that if an xref (A.dwg)
is "attached" and resolves in B.dwg via a relative path;
if B.dwg is xreffed somewhere else (C.dwg),
A.dwg is attached baggage that comes along with it.
I didn't understand that A.dwg *has* to resolve from C.dwg to work.
(I wish that it was the other way around)
The only way for my philosophy to work
is to "dot,dot" all paths back to the \Project\Drawings\ directory
and hard code from that point down; which is what I'm currently doing....

>..Solutions?

>(1) put everything in one folder. I found this to be unacceptable for most
>projects of any size.

This would solve it, but I just don't like it.
Separating design files from plotted sheets by directory
makes the Work process clear. Implementing file naming differences
could work, but ,again, I don't like it.

>(2) Use hard coded paths, always. Problematic because of inflexibility with
>moving folders around, but it IS bulletproof. Especially if you have a
>standardized file naming system that reuses the same file names across
projects.

too inflexible.

>(3) Break out your folders into a parallel structure so that relative
pathing is
>one level deeper from the same root, using "..\" to reference the root
folder
>one step above.

This is what I do now.
It works, but is confusing.

>Problems with relative pathing:

>We use standard file names for design (xref) files to reduce the learning
curve
>going from project to project.

I circumvent this problem by add adding the project # to the design (xref)
files.
02.001plan1.dwg vs 02.002plan1.dwg.
Works well for us.

>Under CDs you
>could have \Plots, and under Xrefs you could have \Trash.

This is completely unrelated, but the word "Trash" with respect to computers
makes me chuckle.
I have a friend (not a cow orker) that I built a home PC for
back when I lived in Austin.
I got a call from her the evening that I dropped it off and set it up.
She said that nothing works.
When I got back to her place, I discovered, to my disbelief,
that she moved everything under c:\ that wasn't one of her own directories
into a folder that she named "c:\Trash". Including c:\Windows.
My reaction was similar to the AFLAC duck in the commercial with Yogi Berra.

Later,
Corey




"Matt Stachoni" wrote in message
news:904viug9pvm8d4e163l9ngistqedlmvf4s@4ax.com...
> >are you as confused as I am?
> >(this is completely hard to explain,
> >if you're not Matt S.)
>
> You're in luck! I _am_ Matt S., so I may be of assistance 🙂
>
> I'll first explain that yes, your original idea about plot-only "sheet"
drawings
> referencing the design files as xrefs is perfectly valid - we've been
using the
> technique for some time. I think by now it's pretty much industry standard
> practice.
>
> However, relative pathing, in your configuration, has some problems in the
> manner you've described. This is because you are both referencing from the
same
> directory (design xrefs into design xrefs) and across nested folder
boundaries
> (design xrefs into CD sheet files). Specifically, your problem with
referential
> pathing is that the sheet files cannot find the nested design Xref
file(s) -
> simply because the relative pathing cannot take folder nesting into
account.
>
> In other words, let's say in the \Project\Drawings\xref\ folder, you have
PLAN
> and RCP. RCP references PLAN. Without full hard coded paths, the Xref path
is
> simply "PLAN.DWG". With relative pathing, it is ".\PLAN.DWG" because it's
in the
> same folder as the parent file. It could also be referenced as
> "..\Xrefs\PLAN.DWG" - the "..\" evaluates to the parent folder of the "."
which
> is the current folder.
>
> However, this saved path falls apart when you reference RCP into the Sheet
file
> (e.g., A1-2.DWG) that is one folder above, in \Project\Drawings\, because
while
> the RCP path is relative at "xref\RCP.DWG" it cannot find ".\PLAN.DWG"
because
> it's not in the same folder as the A1-2.DWG file. Using the double-dot
method
> does not work either, because the saved path is "..\Xrefs\PLAN" which
doesn't
> exist at the \Drawings level.
>
> Solutions?
>
> (1) put everything in one folder. I found this to be unacceptable for most
> projects of any size.
>
>
> (2) Use hard coded paths, always. Problematic because of inflexibility
with
> moving folders around, but it IS bulletproof. Especially if you have a
> standardized file naming system that reuses the same file names across
projects.
>
> (3) Break out your folders into a parallel structure so that relative
pathing is
> one level deeper from the same root, using "..\" to reference the root
folder
> one step above.
>
> To wit:
>
> Use \Project\Drawings\Xrefs for Design files
> Use \Project\Drawings\CDs for Sheet files
>
> Under the Working files, relative path from \Drawings, not from .\ (the
current
> directory) via "..\"
>
> E.g.,
>
> \Project\Drawings\Xrefs\RCP.DWG references "..\Xrefs\PLAN.DWG" - the two
dots
> evaluate to "\Project\Drawings\". Now you have the base from which all
future
> pathing can relate to this parent folder, instead of the current folder
and
> folders below.
>
> So now, when you reference RCP into "\Project\Drawings\CDs\A1-2.dwg", the
file
> references "..\Xrefs\RCP.DWG" which ALSO references "..\Xrefs\PLAN.DWG"
and it
> all comes together. Xrefs is under the Root (\Drawings) as is CDs.
>
> This only works when we're using a parallel structure for both CDs and
Xrefs,
> pathing off the root of \Drawings\. If you don't use parallel folders, and
> instead use a nested structure (e.g., \Drawings\ for CDs and
\Drawings\Xrefs for
> design) the system falls apart because at the \Drawings\ level, children
design
> files (RCP.DWG) would be referencing "..\Xrefs\PLAN.DWG", which won't
resolve
> because the path that would _work_ would be "..\Drawings\Xrefs\PLAN.DWG".
>
> So, maintaining a parallel structure works with relative pathing, and has
a few
> advantages besides:
>
> 1) You can have subfolders under CDs and Xrefs which pertain to those
types of
> files only. For example, I always maintain a \Bakups folder in each for
BAK
> files, which gets them out of the main folder and reduces clutter. Under
CDs you
> could have \Plots, and under Xrefs you could have \Trash. It keeps the
folder
> structure neater and doesn't interfere with cross-referencing files.
>
> 2) You can move the whole \Drawings root, and all references below this
work as
> well, if they are relative pathed in this manner.
>
> Problems with relative pathing:
>
> We use standard file names for design (xref) files to reduce the learning
curve
> going from project to project. It also makes file management easier at the
> server level. However, with relative pathing, you will find yourself in a
> situation where references will pull in the wrong drawing from a different
> project. This happens when you switch projects without quitting AutoCAD,
because
> AutoCAD's working directory is the same one used when you launch the app
by
> dbl-clicking on a drawing icon.
>
> So, for example, if you open up \CDs\A1-2.dwg in ONE project, it may
actually
> pull in ..\Drawings\Xrefs\PLAN.DWG from a completely different project
folder,
> because the root "\ProjectA\Drawings" will be referenced, not
> "\ProjectB\Drawings\". Which is why I abandonded relative pathing and
stuck
> w/hard coded xrefs. I like standard names, and I can repath a whole lot of
Xrefs
> in no time.
>
> Matt
> mstachoni@comcast.net
> mstachoni@beyerdesign.com
>
>
>
>
>
>
>
>
>
>
>
>
>
> Matt
> mstachoni@comcast.net
> mstachoni@beyerdesign.com
>
>
>
>
>
>
> On Fri, 12 Jul 2002 14:15:25 -0700, "Corey A. Layton"
> wrote:
>
> >ok, here's the scoop...
> >
> >I had this relavation:
> >I was setting up my directory structure to be used for CAD dwgs.
> >And I thought to myself
> >"Always make the xref (design, Work, etc. whatever you call it) directory
> >a sub directory of the plotted dwgs. So that relative pathing could be
used,
> >and the nested xrefs will always resolve, wherever the project directory
> >"tree" is moved to (another drive, archived to cd, another parent
directory,
> >etc.)"
> >
> >so I set it up like this:
> >(there are WAY more subdirectories under the project folder, but this
> >illustrates my point)
> >
> >\\Drawings
> >this is where the plotted dwgs go that xref design files
> >These dwgs are opened to plot only, no CAD data here other than xrefs
> >relative path: Work\.dwg
> >
> >\\Drawings\Work
> >this is where the design dwgs go that xref consultant files
> >These dwgs are opened to edit CAD data,
> >may xref consultant CAD data
> >relative path: xref\.dwg
> >
> >\\Drawings\Work\xref\
> >this is where the consultant CAD files go (read only)
> >These dwgs are for coordination, no editing here.
> >
> >It all sounded so nice.
> >
> >But my system was flawed:
> >I made the assumption that an "attached" (vs. "overlayed") xref (A.dwg)
> >that resolves with a relative path, will also resolve when it's parent
> >drawing (B.dwg) is xreffed into another dwg. (C.dwg).
> >
> >not so.
> >
> >A.dwg lists as "unresolved" in C.dwg
> >because A.dwg's relative path saved in B.dwg
> >won't resolve from C.dwg.
> >
> >if A is attached to B and B to C,
> >shouldn't A resolve in C?
> >
>

[Anonymous]

On Mon, 15 Jul 2002 08:17:44 -0700, "Corey A. Layton"
wrote:

>I made the mistake of assuming that if an xref (A.dwg)
>is "attached" and resolves in B.dwg via a relative path;
>if B.dwg is xreffed somewhere else (C.dwg),
>A.dwg is attached baggage that comes along with it.

No, because the Path information (relative or otherwise) is the only data
dragged along with the Xref - C doesn't care that B knew where A was. All it
wants is where A is now. And that's fromthe path property of the nested Xref.

>The only way for my philosophy to work
>is to "dot,dot" all paths back to the \Project\Drawings\ directory
>and hard code from that point down; which is what I'm currently doing....

>>(2) Use hard coded paths, always.

>too inflexible.

Well, maybe for your office, but in mine we've been working with HCP for years
pretty well. Although for use we have custom tools to repath stuff on the fly,
so for other offices relative pathing would work.

>This is what I do now.
>It works, but is confusing.

If you can write some customization macro, you can "wrap" the Xref command up
into something that does relative pathing. Or write something that scans the
drawing and automatically changes the path to the "..\<>" notation.

>>Under CDs you
>>could have \Plots, and under Xrefs you could have \Trash.

>This is completely unrelated, but the word "Trash" with respect to computers
>makes me chuckle.

Heh, funny story. We've adopted a naming system by using a "z_" prefix before
all trash (non Xref, non CD) files. This habit worked out very well, because I
can go to my servers and look for all Z_* files that areover two months old, and
delete them. This keeps the number of old dumb files which don't contribute to
the project in check.

Matt
mstachoni@comcast.net
mstachoni@beyerdesign.com

[Anonymous]

We've taken a little further (in theory not always in practice) and all temp
files are to be names zDA_* with the DA or MS or whatever as your initials.
This groups your temp files together for easier housekeeping.

"Matt Stachoni" wrote in message
news:c286jugbjp3naenj1t1lf7u4d42n9vopf5@4ax.com...
>
> Heh, funny story. We've adopted a naming system by using a "z_" prefix
before
> all trash (non Xref, non CD) files. This habit worked out very well,
because I
> can go to my servers and look for all Z_* files that areover two months
old, and
> delete them. This keeps the number of old dumb files which don't
contribute to
> the project in check.
>

[Anonymous]

Hey, great minds think alike - our users are trained to "reuse" the file name
"z_" which allows multiple people inside the same project to keep
their own temp stuff. I have a couple of automated Import and Export utilities
that autonames temp stuff to these names as well.

Matt
mstachoni@comcast.net
mstachoni@beyerdesign.com

On Mon, 15 Jul 2002 12:37:05 -0700, "Dan Allen"
wrote:

>We've taken a little further (in theory not always in practice) and all temp
>files are to be names zDA_* with the DA or MS or whatever as your initials.
>This groups your temp files together for easier housekeeping.

[Anonymous]

Matt,

Great minds and little minds aren't that far apart, so whatch your
tongue cause I've used "z" drive for a long time as "THE"
drive for projects and drawings not for TRASH .

And, oh yeah... tried softshell crab sandwhich once and found it
pretty disssgusssting!

Tom

Thomas E. Momeyer, AIA, CCS

[Anonymous]

yes my firm also has user temp files that are reused per project located
thus:

/xref/_(initials)-*.dwg

"Dan Allen" wrote in message
news:4217D82CEBFC79AB6FF850CC6899E403@in.WebX.maYIadrTaRb...
> We've taken a little further (in theory not always in practice) and all
temp
> files are to be names zDA_* with the DA or MS or whatever as your
initials.
> This groups your temp files together for easier housekeeping.
>
> "Matt Stachoni" wrote in message
> news:c286jugbjp3naenj1t1lf7u4d42n9vopf5@4ax.com...
> >
> > Heh, funny story. We've adopted a naming system by using a "z_" prefix
> before
> > all trash (non Xref, non CD) files. This habit worked out very well,
> because I
> > can go to my servers and look for all Z_* files that areover two months
> old, and
> > delete them. This keeps the number of old dumb files which don't
> contribute to
> > the project in check.
> >
>
>
>