1:1 Drawings

By John Wallrodt
June 14, 2011 //
1

While playing with TouchDraw the other day I realized that the unlimited page size would help us get rid of another piece of complexity in our field drawings. Our drawings are usually done at 1:20 scale since this is the largest scale that will fit on an A3 sized sheet of paper. The standard method of drawing is to have something static, like the sides of the trench or a baseline, and measure an object from those static lines. Measure from two sides, find out where they collide, and you have a point that you place on your paper. Measure enough of those points and you can connect them with a freehand line that represents your object.

The problem is transferring the ruler measurement to the paper. You could use an architect’s scale to handle the math; or after enough time, you can do the math in your head. Whichever you do, you have to convert the measurements on the ruler to the measurements on the grid paper. Last year we worked in pixels, not centimeters, so things were slightly odd, but this year we can use the unlimited paper size and units capabilities of TouchDraw to help us even further.

The test drawing below is a 1:1 drawing of a trench with an SU in TouchDraw.

There is still a little bit of math to do. The numbers on the rulers are centimeters, not meters. But almost everything we measure ends up in cm.

Drawing at this scale is a little tricky. The lines, for instance, are anywhere between 15 and 30 (I assume pixels) wide. The text is 300 (again, I don’t know the unit, but I assume pixels or points). But dropping the necessity for scaling makes converting the ruler measurements so much easier.

Note the blue lines above. Those are my ruler lines. If I make the strictly horizontal or vertical (by using the function lock, the little fx on the lower left that acts as a shift-constraint), I can type the length of the line in the overlay (the gray HUD on the right). Where the two lines join, I can make my feature. When I don’t need the lines, I just delete them.

I was able to add the elevation symbol and the SU name to the library easily enough so they can be used over and over. The elevation symbols are a group of three lines and a text box, but if I lay one on the page and double tap it, I can edit the number on top very easily.

I worry some about the line thickness. This is something that you don’t get in CAD environments, but you have to deal with in straight vector or paper drawings. As you can see from the second screenshot above, the lines are roughly .5cm thick. This is roughly the equivalent as the thickness of a line on pencil paper, which is why archaeologists tend to aim for centimeter accuracy. But that might not always be desired. If you take a look at the top image again you can see that we can remove yet another leftover from the old pencil drawings and that is our dependency on pencil lines altogether. The SU shape has no line, just a semi-opaque shape.

The original TouchDraw document can be downloaded from here for experiments.

We leave for the field in a couple of weeks. In the meantime I am gathering some comments from the field supervisors and getting ready to make and test the last additions to the database before we go.

Categories Drawing

Second best unused feature

By John Wallrodt
June 7, 2011 //
2

Archaeological notebooks are sloppy. They just are. Take elevations, for instance. You need to use the level or total station when it is ready not when you are ready. This makes for some creative record keeping to store the elevations: the corner of your SU sheet, inside cover of your notebook, your hand, whatever is nearby. The data will often get transferred to its proper place later. This happens with a surprising amount of archaeological data. Ideas can creep up on you at any time: while walking home, just before you fall asleep, while having dinner with your trenchmates. These thoughts can get recorded in a bunch of odd places and sometimes they lie forgotten there, with no place to call home.

Most of the trench supervisors that I know compensate for this by spending a large amount of outside-the-trench-time working on their notebooks and forms. They have to gather these pieces of odd information and put them into the database, a drawing, or in a place in their notebook where they will have a context and can be useful for someone else later on.

But where to store these odd snippets until then? My best suggestion is to use a task manager on the iPads. There are hundreds of them to choose from. I am an early adopter of Things and I like some aspects of the program but lately I have been trying to get people to adopt some of the free software: Sorted, Wunderlist, or even Epic Win. You don’t have to use all of the features of any of these programs, but simply using it as a list of action items that can be checked off when completed can save an enormous amount of time when you have some time to focus and get some things done.

I have a hard time getting people to adopt to-do lists. I use them extensively, as does Steven Ellis, our director. But the trench supervisors are hesitant. I attribute this to the graduate student lifestyle. Grad students are notoriously bad at time management and almost all trench supervisors on excavations are grad students. So, in addition to any other changes we make to this year’s workflow, I am going to push for the adoption of any task manager for everyone on the project. I hope to wipe the task manager from the list of most unused features.

Categories General, iPad

Let’s call this a beta [updated]

By John Wallrodt
June 7, 2011 //
1

I have uploaded the latest version of the PARP:PS database. The major difference between this one and previous versions is the syncing. I have syncing working on the following tables: AuditTrail, Trenches, SU, Finds, Finds Attributes, Media, MediaLink, Ceramics, QuantifiedPottery, ReportPhases, SoilSamples, Measurements, and SUCompType (which I would like to get rid of but not right now).

Most of the details involving the syncing mechanism are described in an earlier post. In summary: the parent database is the one that lives on the ‘server’ computer. It is the master database. While it is opened, multiple other computers can connect to it from our limited wi-fi network and add/edit records. The parent database is then closed and copied onto each of the iPads (or other computers that are working outside of our network). Those databases are renamed PS_11_child. The child databases are then edited, copied back to the main laptop, and the scripts are run from the Parent database. Currently, I run the script 1_1 Import Audit Trail from the Scripts->Sync menu. That starts the ball rolling and the last step of each scripts is to run the next script. You can disconnect that process by removing that last script step from each section. The scripts also provide some feedback concerning the number of records that are being updated with each step.

The scripts themselves are written in pieces to make it easier to edit them. You might find that you have to do this if you change the name of the parent database. Script steps x_2 and x_3 import data from one table in the parent database to another table in the database. Those steps will have to be edited if you change the file name. If there is no file named PS_11_child when the script steps ask for one, you will be prompted to find it, so changing the name of the child databases shouldn’t be a problem.

An important point to make with this process is that the syncing steps are wholly dependent upon accurate timestamps in fields. Those timestamps are automatically entered when a record is created or modified but I ran into some problems late last week that were related to the iPad recording the wrong time. It was set properly in Settings-General-Date & Time. That is, my time zone was right, but when I tell the iPad to set the time automatically it sets it for four hours earlier. I haven’t figured out why this is the case, but I have to make sure that all iPads are set to the correct time in the field.

This database syncs by having a shadow table for each main table. So there is an SU table and an SU Shadow table. The child records go into the shadow table and are compared with the main SU table. For this to work properly, if you make a change to the SU table on the parent, you must make the same change to the SU Shadow table, or the fields will not import correctly.

We are currently still in the process of testing the scripts and syncing mechanism. We also have a couple of internal questions to settle on matrices and elevation recording, so this isn’t quite the database that we will use this year, but it is close.

Update– I added the full DDR report and reposted the archive. A DDR report is a full description of the database in (this case) html format. Open the DDR folder and double-click on Summary.html to see how detailed. I am in the process of updating the documentation for the use of the database as well.

Categories General

Two iPads per Trench

By John Wallrodt
June 7, 2011 //
0

One of the first things we realized in 2010 at Pompeii was that while the iPads were working for our data recording, too many people wanted to use them at the same time. One person needed to record some elevations at the same time someone wanted to write down a description of the soil of the fill. Our immediate answer to that was: put two in each trench. It wasn’t until this spring that I began to wonder just how that would work. Even if I had a full network going at the site, which I don’t, I couldn’t keep the two iPads totally in sync with their various documents. So you couldn’t pick up iPad 53000-1 (I named them after their trench) for twenty minutes, add some data, put it down, and then pick up 53000-2 and expect to pick up where you left off. And if you couldn’t do that, how do you separate the duties that the iPads need to perform?

While speaking to the trench supervisors this spring about it, we seem to have come to the conclusion that we can separate the software and duties that each iPad will handle.

iPad 1 will usually be at the trench supervisor’s side. That will be the primary tablet for the notebook and matrix information. iPad 2 will be the database and drawing tablet. My concern is that the drawing and data recording will need to be done at the same time but I have been assured that this isn’t the case.

The two iPads will have access to the other’s data, but it will be up to four hours old. I can copy the database and the drawings from the first iPad to the second and copy the documents from the second iPad to the first, but the team members need to know what is editable on each iPad.

We will see how that works soon.

Categories General, iPad

Syncing Sample

By John Wallrodt
May 27, 2011 //
1

I still haven’t finished getting syncing working with the entire PARP:PS database. The testing and troubleshooting phase of this is taking longer than I thought. But since I have worked out the basics, I decided to upload a demo file that explains the technique.

Sync_Trenches.zip

This file contains only a Trench table, not the full suite of tables used in the field. But by doing so, I was able to cut everything down to the basics to explain the parts of the database that are necessary for creating the audit trail and for syncing. In order to get everything to work there is a new table, changes to two fields, and the addition of a few fields. This file also uses Script Triggers and Conditional formatting to help create the audit trail and resolve sync issues.

There is a readme in the file. That text is reproduced below.

Special thanks to Chris Motz at Tufts for helping me with the scripting.

Read the rest of this entry »

Categories Database
« Older Entries
Newer Entries »