Noel Hidalgo Tan from the Australian National University has recently presented a paper at the Australian Archaeological Association on his use of tablets to record the location and motif details of rock art in Thailand. He uses the full range of the hardware including the camera, GPS, and audio recordings for lengthy descriptions. He has blogged about the paper and has uploaded the slides from his presentation.
He uses slightly different software than we do at Pompeii, and I will have to check out Tap Forms, his preferred database app.
You can download the current version of the PARP:PS database here.
I blogged about the database I used at the start of the 2011 field season. This post references the database that I used at the end the field season. The earlier database syncing was working well for about a week and a half. That is when I discovered a couple of problems.
Read the rest of this entry »
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.
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 »
The good news is that I have syncing working with FileMaker. Creating a syncing strategy turned out to be a bit trickier than I thought. Most of the difficulty involved the overall workflow if the data and the iPads. For instance: we will have two iPads per trench this year and I needed to work with the trench supervisors to figure out just how they intended to use the two together. Since we will have four trenches open this year, I needed to know if I was going to have to sync eight iPads or just four, or if the two for each trench had to be in sync with each other. I think we have worked out a strategy for the two iPad use, but I will write about that separately. Right now I want to write about the rationale behind the syncing strategy that I chose and how this was implemented. The files will be uploaded soon. Read the rest of this entry »
While other universities are already thinking about their finals, here at UC we go to the second week of June (blame the quarter system for one more year). We also just now got our new iPads for this year. So I have been getting busy trying to figure out how the workflow will change if we have more than one iPad per trench and how we can best accommodate the needs of the trench supervisors who are in charge of the recording.
I have been working on the evaluation of the GIS space for iOS and hope to have something to say about that as well.
I have also been trying some replacements for iDraw and will post those observations soon.
While all that is going on I am still working on syncing the offline databases to a central database without errors. I have a skeleton plan in place and am looking forward to testing it next week. In the meanwhile, it is nice to see that others are thinking of this too, and I might look forward to a time in the not so distant future when syncing will be much easier. See this post called Why go Local? for an overview of the problem and a tech preview from SeedCode for their solution.