|
Paul Blomerus and Harrison Eiteljorg, II
(See email contacts page for the author's email address.)
Beginning 2 years ago, Dr. Paul Blomerus and Dr. Alexandra Lesk wrote a series of three articles in the CSA Newsletter. They presented an alternate to the CSA Layer-Naming Convention for managing model entities. Both their approach and the CSA approach manage model entities by managing the layers on which those model entities are stored in an AutoCAD model. Their way of doing so, however, is different in important ways. [See "Using AutoCAD to Construct a 4D Block-by-Block Model of the Erechtheion on the Akropolis at Athens, I: Modeling the Erechtheion in Four Dimensions," XX.2 (Fall, 2007); "Using AutoCAD to Construct a 4D Block-by-Block Model of the Erechtheion on the Akropolis of Athens, II: Connecting a Database to an AutoCAD Model," XX.3 (Winter, 2008); and "Using AutoCAD® to Construct a 4D Block-by-Block Model of the Erechtheion on the Akropolis at Athens, III: An interactive virtual-reality database," XXII.1 (April, 2009).]
The CSA Layer-Naming Convention has also been discussed multiple times in the CSA Newsletter, beginning, in fact, with the very first issue ["Using the CSA Layer-Naming Convention on the Propylaea Model," XICV.1 (Spring, 2001); "Layer-Naming Convention -- Again," III.4 (February, 1991); "Layer-Naming," III.1 (May, 1990); "Layer-Naming Conventions Important In CAD," I.1 (May, 1998)]. Thanks to questions raised by Mr. Blomerus in the course of the work on this article, the document setting out the convention has been updated to provide an improved description of the aims of the system.
Both the CSA convention and the Blomerus/Lesk approach seek to accomplish an important end for complex models (in each case a model of a structure). Each is an attempt to apply a database-like approach to the individual items that make up a model; each attempts to identify them as having specific characteristics, e.g., Pentelic marble vs. poros, anta block vs. stylobate, first period of the structure or second, and so on. The point is to permit the model creator or any subsequent user to examine portions of the model according to characteristics of importance to that user or to show the model in one or another specific state of completion.
Each approach was developed in response to the specific needs of a specific project. CSA Director Harrison Eiteljorg, II, developed what became the CSA convention as he worked on the older propylon; Mr. Blomerus and Ms. Lesk developed their approach as they worked on the Erechtheion.
Both approaches are based on a key feature of any CAD program: the ability to separate entities in a model by placing them in different model segments. The segments are called layers in AutoCAD and many other CAD programs, and that is the term used here. (In addition, the term entity is used in AutoCAD to refer to any single item modeled in a CAD file, from a simple line to a very complex 3D object originally composed of many simpler objects that have been combined into one. That term, entity, will also be used here.) CAD programs not only permit entities to be separated from other entities by placing them on different layers, they also permit layers to be "turned on" or "turned off" while working, that is, to be included on screen or not at the whim of the user. Of course, layers can also be included or excluded in a printout. As a result, assuming that all entities with the same set of characteristics have been placed on the same CAD layer, the layers can be used to manipulate the model for analysis and illustration -- and the effect is the same as if the entities themselves were being manipulated. (CAD programs do not permit accessing individual entities at a level the typical user -- even most advanced users -- can manage.)
The careful use of layers permits all entities on a given layer in a model to be turned on or off at any time for the sake of clarity. For instance, Mr. Eiteljorg could and did look at the model of the older propylon with the poros blocks in the parastas wall of the structure on and then off so as to get a better idea of how those blocks came to be in the structure where they were. Similarly, Ms. Lesk and Mr. Blomerus used layer controls to turn on and off entities in the Erechtheion so as to see the building at a variety of times in its history, times when most of the blocks were on the ground instead of the building and times when the building was far more nearly complete.
In archaeological use generally, CAD's layers are not only extremely important, the content of layers can be extremely precise and carefully circumscribed to permit the effective manipulation of individual model elements. For instance, a model of a building that has undergone modification at multiple times must separate the model elements according to date, but entities representing blocks made of different materials must also be placed on different layers, as must entities representing blocks with different functions (columns vs. capitals, for instance). As a consequence, any given layer will ultimately have many important characteristics, with layers being being accessible according to each characteristic alone or in combination with others. All entities on a layer must share all characteristics used to separate one entity or group of entities from another.
CAD programs are generally very flexible. Layers may contain virtually anything, and, at least in AutoCAD, they are not hierarchical. Using them to assist in analysis is therefore a fairly obvious notion as soon as one begins to use CAD in a scholarly setting, especially if there are parts of a model that differ as to chronology so that they should naturally be seen together -- or not. In addition, AutoCAD places no limit on the number of layers; so there may be virtually an infinite number of segments of a model (though, to be sure, too many segments may make dealing with the model unwieldy). As a result, the layers may be sufficiently numerous to include one layer for each set of characteristics, even if only a single model entity shares all those characteristics.
As is obvious, using layers to separate material requires that layers be named in some way that permits identification -- identification of each and every characteristic of every layer.
Mr. Eiteljorg's older propylon project required that he define portions of the building according to a variety of criteria, but the project began so early in the history of the scholarly use of CAD that separating the material by layer was done as much with an eye toward keeping virtually everything separate as a real understanding of the ultimate analytic needs or benefits. (Experience had also shown that using and then remembering "obvious" layer names, e.g., southwall worked very badly. Such terms were almost always too broad, requiring later subdivisions, and rarely managed to be fully descriptive.) Complicating matters, there were some blocks that were used in different places at different times, and the same block might be interpreted differently by Mr. Eiteljorg and William Bell Dinsmoor, Jr., whose ideas were also incorporated in the model (the two-dimensional version only). Finally, Mr. Eiteljorg needed not only to distinguish between the points of view of Mr. Dinsmoor and himself, he also needed to provide for possible third or fourth interpretations and to make it clear if items were defined in the same way by all who had studied the area.
Ms. Lesk and Mr. Blomerus, on the other hand, were most concerned with managing the complexity of the Erechtheion's tortured history. That is, individual blocks were removed from and added back to the Erechtheion in a bewildering and illogical sequence that needed to be understood and expressed in the model. It was a basic aim of the project to be able to show which blocks were present or absent at any point in the history of the structure. While this required the use of layers, it also required that any given block have an unknown number of chronological indicators. That is, a given block might have been in the building any number of times, and there needed to be a way to indicate the moments when each block was in the structure.
In Mr. Eiteljorg's case, the blocks in the model rarely had conflicting data determinations. There were a few blocks that had to be credited to Mr. Eiteljorg and a given set of dates while needing another set of dates according to the views of Mr. Dinsmoor. When that was encountered, the same blocks might be in the model twice, once on a layer assigned to Mr. Dinsmoor during the requisite time period and a second time on a layer assigned to Mr. Eiteljorg and the period he had determined.
In the case of Mr. Blomerus and Ms. Lesk, however, every block of interest -- those being removed from and replaced on the building -- had multiple dates of use and disuse. That is, each might have been on the building for a few years, off again, on again, and so on. As a result, the CSA approach seemed ill-suited. Each block, using Mr. Eiteljorg's approach, might have been modeled multiple times, once per period of use, with each model on a layer associated with a specific time period.
The two approaches to the use of layers to permit analysis represent just that -- two approaches to a similar problem, two ways to assist in the analytic work of the scholar. Mr. Eiteljorg and Mr. Blomerus thought it might be useful to lay out carefully the distinctions between these two approaches here so that potential users could design a system suited to their particular needs.
We begin with a short description of the two approaches, noting that each has a more full and complete description elsewhere.
The CSA Layer-Naming Convention
The idea here is to name each layer according to a scheme that accomplishes two aims. First, the name must be meaningful; it must provide all the required data about the entities of the model included in the layer, albeit via a coding process. Two, the naming system must permit an AutoCAD user to call up layers according to their criteria simply by understanding the naming system and AutoCAD's layer commands. That is, the system must permit relatively easy naming and grouping of layers for changing their status -- turning them on and off and the like.
AutoCAD's command structure aids this process. It permits layer names to be found or specified with a variety of search techniques. For instance, it is possible to specify that the fourth character of a layer name be Z and that there be only four characters in the name. Layer names can also be very long, making the possibilities extensive.
Mr. Eiteljorg therefore created a system that named layers according to specific characteristics, one character/number per characteristic so that the position of any character/number within a name is critical to its meaning. That is, the first character in a layer name specified that a layer contained plan-view information (P) or modeled, 3D information (M) or Text (T), or . . . . Any search for layers with M in the first position would find only layers with 3D model information. Another character indicated whether the material on the layer was Pentelic marble (P) or local limestone (L) or bedrock (B), or . . . . Therefore, specifying layers with the letter P in that spot would access only layers with Pentelic marble blocks. Of course, various characteristics could be combined so that one might call up all 3D models of an anta block, still in situ, made of Pentelic marble, in use during a specific span, and . . . . This can be generalized rather readily, and the key advantage is that it permits someone who understands the names and AutoCAD to manipulate the model in very valuable ways for the sake of analysis or illustration.
It is important that there is no external software required for this system. It operates entirely within AutoCAD. The disadvantage is that this is not really a database, though it provides some of the same possibilities. It could have been expanded to handle the problems of blocks that are treated differently by multiple scholars, for instance, but the kind of open-ended potential of a good database design is simply impossible. In addition, changing layer names in response to changing needs of the system is very time-consuming -- not intellectually difficult but very time-consuming and error-prone.
The linked database approach developed by Mr. Blomerus moves the management of the information about the objects in the CAD model from the coded letters in the layer name to a database external to the CAD model.
This database approach also takes advantage of AutoCAD's layer-management system and also assigns each entity (or group of entities) to a layer that contains only entities that share all recorded attributes. The name of the layer is not a code, however, and will act as the primary key for a database entry. The database entry for each layer will then define fully the characteristics of the objects represented by the model entities on each layer. The layer names are no longer necessarily significant in this system and can simply be a sequentially assigned integers, and the database itself can be created in the user's choice of database or spreadsheet software. Regardless of the software, the layer name is the key, leading to the pertinent data about the object or group of objects represented by the model entities on the layer. The user can then sort, filter, and select objects using the database functionality to determine which layers need to be seen or printed or given a different color. Most important here, having used the database to determine the layers needed, the choices made in the database system can be transmitted to AutoCAD to change the layers in the model more or less automatically -- turning some off or on, changing colors, and so on.
The synchronisation of database and drawing relies on AutoCAD's layer state file as a means of transmission, but, as will be discussed later, a simple cut and paste approach would also suffice.
The benefits of this system are described in more detail in "Using AutoCAD to Construct a 4D Block-by-Block Model of the Erechtheion on the Akropolis of Athens, II: Connecting a Database to an AutoCAD Model," XX.3 (Winter, 2008). The main advantage over the CSA Layer-Naming convention is that searching, sorting, and selecting entities in the model is more flexible and better able to deal with complex, multi-faceted data. The database can also contain far more information than can be embodied by the series of coding letters of the CSA system, including free text comments or hyperlinks to other pertinent information. Changes to data once new evidence emerges are also much easier.
The major drawback is that the system requires two separate files and programs to be maintained for any drawing, the CAD model and the database file, the CAD program and the database program. If the database becomes separated, lost or corrupted, the CAD model can become almost useless. It should also be recognized that the linkage process from database to drawing, even when fully automated, is still not instantaneous, requiring the user to bring the database to the fore, use it to select the layers desired, and activate the update process that will then be reflected in the drawing. While the linkage may be automated with Visual Basic®, the user must still work with the database to begin the process.
The method actually employed by Ms. Lesk and Mr. Blomerus was a hybrid of the CSA Layer-Naming Convention and the linked-database approach described above. Instead of assigning the layer names as meaningless number sequences, an approach similar to the CSA Layer-Naming Convention was employed to assign the layer names.
This hybrid system was created almost by accident. The Erechtheion already had a hierarchical grid system to categorize the blocks; it seemed logical to use it to identify the blocks in the CAD model. This had the extremely desirable effect that the draftsperson could perform the type of filtering and selection permitted by the CSA Layer-Naming convention based on the geometry of the building without needing to employ the linked database. This was particularly useful during the "construction phase" when enquiries such as, "display only the 4th course of the South wall of the building" are commonly required to gain access to a particular part of the model for further construction or validation.
The linked database comes into its own once the model has been created and when more interpretive queries are needed, such as changing the colour of all the blocks that are believed to have moved during a particular time period.
Considering the virtues of the two systems defined here and the hybrid just described, it seems clear that the hybrid provides the best of both worlds. The CSA system may be sufficient if the required distinctions between/among real-world objects in the model do not require the more complex database-style approach -- as was the case with the older propylon. However, if and when those more complex distinctions are required, the linked-database approach adds the necessary additional flexibility.
There are two approaches to linking the linked-database to a model. The first requires the use of a software tool -- Visual Basic used by Mr. Blomerus -- to interpret between the chosen database or spreadsheet and AutoCAD, but that tool lets the user fully automate the linkage. Furthermore, the linkage is two-way linkage, permitting full synchronization between the database and the model. The second constructs AutoCAD commands within the database or spreadsheet and requires the user to copy a command and then paste it into the AutoCAD command line.1 There is no synchronization of the database to the model in this system. For further information about the Visual Basic approach, please contact Mr. Blomerus via email. For further information about the command-line approach, please contact Mr. Eiteljorg via email.
-- Paul Blomerus and Harrison Eiteljorg, II
References
1. Since the AutoCAD command line accepts text -- either typed or pasted -- it is a relatively simple matter to make a command with output from either a database or a spreadsheet. In either case, a simple list of the layers desired can be created, copied, and then pasted into the command line as part of a command. Thus, for example, one might copy a list of all the layers that should be turned on for a specific purpose from either a database table or a spreadsheet. Then one could return to AutoCAD, enter the layer command (the version that retains the command-line interface, not the version that calls up a dialog box), set the current layer to the empty layer (a layer called "Z" if one is following the CSA guidelines), freeze all layers (that process automatically exempts the "Z" layer if it is the current layer), and then issue the thaw sub-command, and finally paste into the command line the list of layers previously copied -- the layers that will be thawed and visible. The only complication might be the presence of carriage returns in the copied list. A text editor might be required to replace all carriage returns with commas. A more sophisticated process might use a formula to generate either the list of layers or even the full command in the database or spreadsheet. Return to text.
An index by subject for all CSA Newsletter issues may be found at csanet.org/newsletter/nlxref.html; included there are listings for articles concerning the use of electronic media in the humanities, and articles concerning Applications of CAD modeling in archaeology and architectural history, and articles concerning The "CSA CAD Layer Naming Convention".
Next Article: Review of the Kindle 2
Table of Contents for the September, 2009, issue of the CSA Newsletter (Vol. XXII, No. 2)
Table of Contents for all CSA Newsletter issues on the Web
| CSA Home Page |