Author Topic: Project Navigator  (Read 5745 times)

0 Members and 1 Guest are viewing this topic.


  • Guest
Project Navigator
« on: January 16, 2005, 09:56:03 PM »
I just wanted to grab some thoughts on the Project Navigator that can be used in the ADT 2005.

From my reading, and very little actual use, the Project Navigator seems to be dragging the user back into the old ways of doing things. Years ago, a single project, in my case, a residential house, would have 10 different drawings in one folder. Today, we draw all of our stuff in one file and use the tabs to sort them out. Instead of having a drawing for the electrical plan, you now have just a tab for it.

From looking at the Project Navigator, it appears that this sets up multiple drawings for one project. Each level gets its own drawing file. Reflected ceiling plans, electrical plans, floor plans, etc... all are now individual files if you use the Navigator. I assume this is done now because of the importance of keeping things together so ADT can reference the drawings with setting up sections, schedules and other inter-plan connections. But my question is this really better? If someone if the firm were to modify, delete or change just one file, the whole setup becomes problematic. It just seems like it is taking us back to the older ways of file management.

I just wanted to see if anyone else here is using the Navigator and how you may or may not like it. For residential projects, would it be better to stick with simple one file projects then to try and figure and work with the Navigator? This software is new to me, so I am looking for some help and advice on the matter.


  • Guest
Project Navigator
« Reply #1 on: January 20, 2005, 06:46:41 PM »
not to familiar with it myself, but I did some research on the NCS forum and found this thread:
We have been using ADT for about a year and have implemented the project
navigator folder structure for all of our work, even for non-ADT based
projects. This is primarily for project flow consistency. Overall, the
initial concept of the Project Navigator has been difficult for some
user to understand. However, as they become familiar with how
information is combined and shared with others outside our firm and they
become familiar with the file naming concepts outlined in the UDS, the
concept is much easier to understand.
 We have been using the sheet naming and view naming as outlined in the
UDS for sheet and model naming (as indicated by others). As far as
constructs and elements are concerned we have taken to naming those
files more descriptively, as if they were block files (which they are
 Drawing elements such as key-plans, titleblock, A-seals, A-FP-Notes, are
fairly descriptive enough and distinct during the working process of the
project. Building elements such as "OR-type-I", "Queen-Suite", "Toilet
Core", "Elevator Core", "Large Cubical", etc. are also fairly easy to
 Constructs tend to be unique arrangements that represent physical
objects such as building floor levels. These can be further dissected
into "Shell", "Partitions", "Ceilings" (although I don't agree with
separating ceiling information from the space object as it looses some
of the efficiencies gained by combining them), etc. Repetitive building
elements are then either referenced or inserted into the construct files
(if you have repetitive elements).
 I think it is also important to address the "4D" aspects of these files.
Most of our current work (which is largely healthcare) is renovation
work. So there is also a time element associated with this work (which
is also typical of most civil engineering work). There is always an
"existing", "demolition", and "new" phase of the work. This is another
way of looking at the "Division" categories for the ADT method of
configuring projects. We use divisions not to differentiate between
"Wing A" and "Wing B", rather we use it for "demolition" and "new" work.
This is also an area that needs to be addressed.
 In general, the UDS file naming conventions are great at designating
views and sheets, but I would recommend that is where it should be
limited (for the ADT Project Navigator). ADT is a specific tool, not all
of the CAD tools out there use the same concepts so to develop the NCS
specific to one tool neglects other systems. The project navigator is
Autodesk's attempt at further organizing CAD information specific to
their CAD file system. Reference files for AutoCAD are not exactly the
same as how MicroStation uses reference files. Ultimately, CAD systems
will need to standardize if the exchange of information is to flow
easier than it currently does. (This is really a discussion that is
about Interoperability... not CAD Standardization.) That being said,
some general guidelines for naming other file types like reference files
would be helpful. I would recommend, for building related files, that
there be enough information to give relational information about the
constructs. At this time I believe some general guidelines would be
helpful for exchanging information, but think that falls to the
individual design professionals.
 We precede our file naming with the project number (a default setting
for ADT) so that the files are unique and there is limited chance of
corrupting other projects with these files. We then use the concept of
giving the level assignment as part of the file name "01" for the first
floor, "02" for the second, "03" for the roof, "B1" for first level
below grade, etc. this helps organize the files in a very easy fashion.
Most people organize buildings by floor levels. Next we us a descriptor
for what we are including in the construct "shell", "partitions", this
could further be sub-divided into areas of the building (where large or
complex) "OR suite", "Concourse", etc. The last designation we include
is related to either phasing or plan options. We find that seldom does
one pass at an arrangement satisfy the client. This is usually a date in
a "YYMMDD" format or a phase as identified in Module 01 for Supplemental
Drawings. The same is used for the view name if multiple options are
presented to the client for the same general view. For example
"A-FP02-050118" would be Architectural Floor Plan level 2 options for
January 18, 2005: (Simple enough).
 The reason I think the construct and element naming falls to the
professional is because that information generally does not get
forwarded to the end users. At the conclusion of the project,
information that is passed onto the owner is valuable for the life of
the project. The electronic files tend to be an intermediate step
between the physical sheets used by the contractor to build the project
and the owner's physical entity when complete (whether it is a bridge, a
heating system, a water treatment facility, a building, a campus, or an
airplane). At the conclusion of the project, the owner generally wants
an electronic version of what the contractor used to build the entity,
not all of the working files used by the team during the process of
completing the design. Therefore, the files are usually combined to
emulate the final instrument (drawings and specifications) used by the
designer to convey the concept to the contractor to execute the
contract. If this is the extent of sharing or conveying information,
does the UDS really need to drill that deep into file naming of
constructs and elements?
 Also, there seems to be some legacy of the"8.3" DOS format for naming.
Since most computer system recognize more than 8 characters for file
names, should the UDS still hold true to this legacy file naming
practice? It seems there is some room for expansion. The example file
above would actually be "P0501-A-FP02-050118.DWG". As you can see this
exceeds the 8.3 format.
Chris Nesbit     RA, NCARB, CSI
Process Director

We have just implemented Project Navigator in our office, but only after
I learned it at AutoCAD University. There are some issues with renaming
files and sheets, but the value added through ease of use, coordination,
elimination of mundane tasks, and convenience are well worth this minor
 I mentioned in an earlier post that the NCS needs to address the issues
with the PN. NCS needs to be the leader in this area, not the hindrance.
 As suggested, the sheet files are no-brainers for NCS compliance. The
view files are pretty much on target with the old "model" files, even
though there are still some categories that NCS has omitted, such as
reflected ceiling plans. If we leave those categories without names,
people will develop their own and dilute the effectiveness of a
 Constructs and elements are new features for which NCS has no solution.
One of the ADT gurus, Paul Aubin, has suggested that constructs and
elements be used in a fashion similar to layers. It would follow, then,
that constructs and elements be named similar to layers. There are still
discipline differentiators, so the first character is good. There are
still constructs, such as walls, roof, and floor, so those names are
still good. The status/phasing categories are still good. Autodesk has
two additional features that require identification, and those are level
and division.
 Level is obvious, in that it represents a horizontal slice of the
building. A division is a vertical slice in the same context as a level,
not to be confused with a sectional view. The division works well with
large buildings, where more than one person can work on a single level
of the plan. These are also natural locations for match lines. Wall
cleanups from host to Xref make this most feasible.
 These new features in AutoCAD emphasize the point that we cannot let the NCS become stagnant, or become a hindrance to users of new technology.
Charles A. Graham, Jr., AIA, NCARB