A lovely walk around the harbour

A walk around the harbour

A walk around the harbour

During the most recent sprint, Intersect gave us a tracklog feature. We save GPS data, either every unit time (the second half of the walk) or by distance away from the prior point (the first part of the walk) as an Archaeological Entity, along with associated accuracy and heading.

With a (mostly) simple query, we pulled this from the produced database, turned it into CSV, and then imported that CSV into arcGIS. Et voila we have the map above. Airplanes were cuter than normal arrows.

 

Can I have your data?

Sure, it’s on a USB drive….

I could not resist but post this hysterical video about what shouldn’t happen when a researcher makes a data sharing request!

Data Sharing and Management Snafu in 3 Short Acts

“Where is your USB drive? It is in a box. It is in a box at home…

Want to be an armchair archaeologist?

The FAIMS project appears in the media again, this time in the Fox News. Here is the considerably imaginative article with an –  interesting – spin …

New archaeology apps may make you an armchair Indiana Jones

A new app for tablets and smartphones will soon transport you to actual dig sites and ancient civilizations around the world, from China to Egypt to Peru, without getting you down into the mud, muck and malaria that often characterizes an archeological site ….

In my opinion, we are not quit there. While I share Gene Koprowski’s  enthusiasm for virtual reality and understand the sensational aura of archaeology in the media, the FAIMS project is aiming in a more utilitarian direction (not that our developers would not love a 3D fancy requirement…).

To play a bit on Koprowski’s title, the FAIMS ecosystem of federated web applications and services will, in fact, make it possible for you to be an armchair archaeologist –  if comparative research and analysis is what you are after.

As for the mobile application, I hope archaeologists will do exactly the opposite –  namely hurry into the field to collect more, higher quality data, because the recording will be so much easier.

So, read it and let me know what it is you want to be!

 

For our more Technical Readers… links to our code

A short discussion of the tools needed to play with the faims android application today.

To play with the following, you’ll want:

  • something somewhat beefy (couple gigs of ram, a modern processor, etc..) running linux (we like Ubuntu 12.04. If you can argue flavours of linux with us, you can run it on anything you want).
  • An access point (we quite like the TP-link wireless N access point series. They’re cheap, they do DHCP, and they don’t get in the way.
  • An Android 4 tablet with usb debugging and developer mode enabled. (While you can run this on phones, all of our UIs tend to get rather too compressed on a 4inch phone.)
Join the following group:

Our code is available at:

Faims-web is a ruby server to run communications for the android app. Its wiki has installation instructions. It needs to be hooked up to the AP to best represent and play with offline mode, but can play on any local network that doesn’t filter UDP.

Faims-android is the android code (deployable via eclipse). An APK is available here.  And a *rather* large tarball (159mb) of our sample projects (with various geotiffs) is available here. (All maps and images copyright their respective owners, used for testing purposes only.).

Extract that tarball to your computer, then put the uuid’d folders in /sdcard/faims/projects/ on your android such that you have

  • /sdcard/faims/projects/04d7fc10-a5cb-47ac-b01f-c6988ee2a7f1/
  • /sdcard/faims/projects/20b02926-d8a0-4a9d-bd97-2e38de2640fa/
and so on.
Then run the app.
Remember, all of this is pre-alpha and everything’s going to be rather more polished in a few months.

We haven’t decided on an exact library/system for our “module” or solution hosting, but I suspect that the code will also have a copy on github, just so we can track both changes and forks as later projects use earlier ones for inspiration.

Limited tech support is currently available for our partners, contributors and supporters.

CSV parsing: a question to our community

Consider, consider:

UUID,GeoSpatialColumn,name,value,timestamp,type,location,picture,supervisor
1000011365058823906,None,”{None, None, brian, 1.0}”,,”{None, None, 2013-04-04 17:59:58, None}”,”{Type C, None, , 1.0}”,”{Loc B, None, foo, 0.46}; {Loc C, None, foo, 0.46}; {Loc D, None, foo, 0.46}”,”{cugl69808.jpg, None, , 1.0}”,”{None, None, superc, 1.0}”
There are some novel formulations in there that are a function of our data structure. The first is the repeating pattern of:
“{None, None, brian, 1.0}” which represents our “inner” multi-valued knowledge representation. Specifically, it represents the “Vocab Name” (none, it’s not a vocab), the measure (none of these are a measure.), the “freetext”, and the Certainty.
Then there’s the repeating repeating pattern of the “Loc B, Loc C, Loc D” tuples, which represents a user-selected multi-valued attribute.
To a large degree, any given tuple-as-column will likely be filled in consistently by the user, which allows for refinement to happen after the user gets the data.
However, the current csv structure basically supports a boolean “in-text” search for presence/absence of a term, and tabular analysis on that search. For our community, is that level of search acceptable in a CSV? Especially as the “real” data is in the database that can be accessed by basically anything?
If it’s not, what kind of research do you do with a CSV?
Please! Tell me!

Instituting some Strong Security

In response to the huge botnet attack on wordpress sites I’ve spent today hardening the site.

One of the crucial things I did was enable two-factor authentication for all users using the Google Authenticator. Please, please, please, if you use google, an apple account, or dropbox for anything, go enable two-factor authentication! (And if you use hotmail or anything from microsoft, keep an eye out for their two-factor solution dropping soon).

If you need help with setting up two-factor authentication, just contact me: it provides an incredible amount of protection against stuff like this.

With all this hardening, if you notice anything funky with our pages, let me know. A number of the security fixes we’ve implemented may have broken a plugin or two.

 

 

Pushing Open Source Android

FAIMS continues to attract media attention. Computer World has published a wonderful article about the capabilities of our app. Check it our and share with your friends!

UNSW researchers push open source, Android for archaeology:

The app allows the recording of text, location, imagery and audio data on Android devices, and a server can be deployed at archaeological sites that, when devices come within range, will synchronise the data on them as well as back it up on the server in an append-only data store (to offer versioning of data, if there needs to be a rollback, for example).

Colour, colour everywhere and not a drop to see…

So it seems like our local library has “lost” their Munsell colour chart.

Anyone willing to share?

If we were going to bake support for a colour system into our device, should we use munsell or should we go with an open standard? If so, which open standard? Is it worth trying to use the device camera?

(Anyone willing to share an spectrophotometer (smaller than a breadbox, please) with us to play with?)