Archives for category: iPad
« Older Entries
Newer Entries »

1:1 Drawings Workflow

By John Wallrodt
July 10, 2011 //
0

This post was written with the help of Greg Tucker of the BSR, who is our new project CAD developer.

The new drawing workflow is working better than expected with TouchDraw’s unlimited paper size and ridiculous zoom levels. The iPad drawings this summer are produced directly on top of the AutoCAD files instead of being traced. This gives us an almost-spatially-correct drawing environment. Almost because we do use a local coordinate system which we have chosen to ignore in TouchDraw. So while the measurements are 1:1, the plan is not in the local grid, and as you will see below, north has changed.

The overview of the process is that the relevant area is exported from AutoCAD in svg format, opened up in TouchDraw, and then cleaned up and made ready for field drawings. Once the drawings are finished, they are again exported to svg, converted from svg to dwf using Inkscape and then back into AutoCAD. There are some minor adjustments to be made in AutoCAD to get the drawing to fit back into the spatial grid.

Here are the details:

Creating SVG files for TouchDraw (And reintegrating them with the CAD model)

This season we’ve decided to draw on the iPads in the field using TouchDraw, which can export in Scalable Vector Graphic (SVG) format. This makes integration of the drawings into the CAD model much quicker, just needing to assign layers to the features and drawing elements as opposed to digitizing either raster images or on a drawing tablet. Our site plan is being made using AutoCAD, which unfortunately does not recognize SVG for either import or export (as of the 2012 version).

The first step to drawing on site was to export a base plan of the trenches so that the excavators could begin planning directly on their iPads. After exploring a few options available we decided on DWG to SVG Converter 2011 MX by DWG Tool Software to create SVGs from the CAD models. Initially all our attempts to generate the baseplans for each of the four trenches resulted in files approaching 10MB, much too large to easily and quickly manipulate. Even when deselecting layers we didn’t want exported, deleting hidden lines, changing the compression, etc, the file sizes remained at this bloated level. The immediate solution we have been implementing is to copy the objects necessary for each of the baseplans (wall bases, architecture, trench extents, baselines, and four target points to ease with scaling and rotation) to a new DWG so as to remove the extraneous data. In the options menu in the DWG to SVG converter we select “Last Saved View” and adjust the output size to match the view dimensions in the CAD model. If we are viewing plan of trench 53000 for instance the dimensions of the view window could be 26.55×11.62m and the image size we would output would be 2655×1162. The resulting SVG has a scale of 1px:1cm and is small enough, <500kb, to be easily manipulated in TouchDraw. Additionally, to aid drawing in the field the CAD model is rotated so that the baselines are aligned vertically before SVG creation. The final output then allows the excavators to use the gridlines within TouchDraw to draw more quickly and efficiently.

After the excavators draw their plans the resulting SVGs are loaded in Inkscape, which is compatible with both SVG and DXF, and saved as a DXF. The DXF can then be opened by AutoCAD, the objects can be rotated and scaled quite quickly using the target points and then copied into the side plan DWG.

There are potentially ways to streamline this process even further and we will be exploring different methodologies throughout the season.

output from CAD for trench 56000

Once the svg file is exported from AutoCAD, it is transferred to TouchDraw via iTunes. In TouchDraw there is an import command to convert the drawing to their native format.

Objects in the drawings were pulled out of the flat svg file into their different layers in TouchDraw and assigned our more standard drawing conventions (orange dashed line for the trench outline and blue dashed line for the baseline, etc.).

Plan with layers in TouchDraw.


The final drawing is given a name to indicate that it is the baseplan. That is, you do not open this one and start drawing. This one is duplicated and the resulting file named “trenchnumber plan x”

When the drawings are finished, they are saved in the native TouchDraw format. Then the Walls, Trench Outline, and Scalebar layers are turned off. The plan is exported into svg format with only the registration points, baseline, and any features or SUs drawn in. The resulting file is given to the architect for importing into the CAD plan.

The native svg output and TouchDraw files can be downloaded from here.

This is also my first post from the iPad. I am testing blogsy.

Advertisement
Categories Drawing, iPad

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

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

Tablets Compared

By John Wallrodt
May 16, 2011 //
0

The New York Times has an interactive comparison chart for the different models of tablets on the market. They promise to keep their page updated as new models come out so you might want to bookmark: http://www.nytimes.com/interactive/technology/personaltech/2010-tablet-computer-comparison.html?ref=technology

Categories Android, iPad

The Future for Databases

By John Wallrodt
February 16, 2011 //
2

The FMTouch software served us well during the 2010 season. In the middle of the season FileMaker came out with their own software: FileMaker Go. FileMaker Go does not rely on the DDR to create the database layout as does FMTouch. Instead the original FileMaker database can be copied to the iPad using the file transfer feature in iTunes. FileMaker Go then opens up the database with fewer limitations than FMTouch. Most script steps, calculations, and layouts just work. FileMaker Go will also let you open a database over a network,  so that multiple people can edit the database at the same time. The JMP project, mentioned in the previous post, used FileMaker Go.

Since our iPads work offline in the trench, we would need to have a copy of the database on all iPads. With three trenches open and all of them running their own local databases, and the ‘live’ hosted database being edited nearby we would have four copies of the same database. This leads us to the downside of FileMaker Go: no automatic syncing. That is the strong suit of FMTouch and one that will be missed. Instead I will have to alter our database to allow audit trails where we track changes to the database on each device (something I have been meaning to do anyway), and create my own scripts for syncing the data to avoid overwriting new data with old.

The audit trail should be fairly easy to do. Essentially I need to create a new table to hold the old and new data and use script triggers in the layouts to force new records to be created in the audit table.

The syncing is a different matter. I have been following how some people handle syncing and how some have had problems doing so. For instance  I use Dropbox heavily and I never have to worry about syncing issues. But my iDisk seems to have issues regularly. And the folks at Cultured Code, the developers of Things (GTD task management software) seem to be taking their own time waxing philosophically about how sync should work. I have also been reading about Zotero’s syncing issues. So I get it, syncing is hard but can be done and I will work on getting something in place soon so I have time to test it before we make our final decision about databases this year.

One of the problems I recently noticed is that the iPad does not sync with a time server. Last week I noticed that my iPad was over 5 minutes off and right now it is 63 seconds slow (thanks Emerald Time!). This means that I have to adjust the sync script to allow for some minor time discrepancies when recognizing the creation and modification times of a record.

Once I get these issues worked out, I will post a new version of the database.

Categories Database, iPad
« Older Entries
Newer Entries »