ATOR (Arc-Team Open Research).
The blog spreads tests, problems and results of Arc-Team research in archaeology, following the guidelines of the OpArc (Open Archaeology) project.
this second, brief post is intended to share other open data regarding our underwater archaeology mission in the inland waters of Trentino (Italy).
As you know, this summer, we joined the exploration of the lake Monticello (almost 2600 m asl, near Paradiso Pass), looking for evidences of the WW1 in the Adamello front. If you missed the post, I described here the new methodology we used to achieve a complete 3D bathymetric chart, using just a low-cost sonar sensor. Today I just uploaded on our server the 3D data, so that other researchers can use them, if they will find them of some interest.
Here below I post a screenshot of the data loaded within +QGIS:
The bathymetric chart of Lake Monticello
Here is possible to download the 3d bathymetric chart of Lake Monticello. As always the data are available with the following license:
as you see we are writing few post in ATOR in the summer season, due to different field projects which take us away from home. Today I try to start again to dedicate some time to our research blog.
The topic of this post regard a solution we are currently using to help us in the archaeological exploration of high alpine lakes: the documentation of the bathymetry through a low cost sonar.
As you maybe know, since a couple of year we are working on underwater archaeology projects in the alpine lakes of our region (here an example). This kind of exploratory mission are difficult, due to the altitude of the site we have to investigate (almost always over 2000 meters asl), so that our divers have to acclimate themselves for one whole day, before starting the working. Also for this reason we started again to study archeorobotics and develop, together with our friends of the WitLab, an open hardware ROV called ArcheoROV (in order to help divers in exploratory mission).
The ArcheoROV (photo by WitLab)
This year we focused or research in find a cheap solution to map the bathymetry of the lakes, while WitLab went on working on the Wi-Fi buoy which gives our ROV a long-range operability (respect the limitation of a simple control on shore). For this reason we tested a cheap sonar called Deeper, which normally is used as a fishfinder.
We started our test in the Lake Tovel, thanks to the hep of Prof. +Tiziano Camagna , who is leading the exploration project since many years. This lake is almost our playground to develop and test new solutions for underwater archaeology, since it is a difficult environment, but not extreme (like other high mountain lakes). We chose this location also because, on unlike other lakes, its bathimetry was documented by Edgardo Baldi in the 30s. We already digitized this map, processing a 3D model in GRASS GIS, so that we have some data to check our results with our small sonar (as you can see in the image below).
On the left the map drawn by Edgardo Baldi between 1937 and 1938; on the right the 3D derived map developed by Arc-Team in GRASS GIS
Some more details of the 3D map developed with GRASS GIS
To test the Deeper sonar, Porf. +Tiziano Camagna designed a small buoy which can be towed by a kayak. This solution stabilize the sonar (which remain always in the right position) and, at the same time, avoid its submersion (which causes the lost of the GPS signal).
First positive results (image below) encouraged us to use this solution on a real mission, at the Monticello lake (almost 2600 meters asl), at Paradiso Pass (near Tonale Pass, Trentino, Italy).
A comparison between the digitized map of E. Baldi (on the left) and the map (work in progress) obtained with the Deeper sonar (on the right)
The expedition was joined also by our friends of the Team Nauticamare (Massimiliano Canossa and Nicola Boninsegna) and gave us the opportunity to accomplish a first mapping of the Lake Monticello, during the first day of acclimatization. This helped us very much during the archaeological underwater mission of the second day. As a result we have now a good 3D map of the bathymetry of the lake, which we will use also in the next expedition (September 2017). Her below is a short video (done with +QGIS plugin qgis2threejs), which shows the 3D model of the lake.
PS
I recorded some videotutorial related with the processing of these data. I will try to upload them ASAP in our channel.
The 21st Conference on Cultural Heritage and NEW Technologies (CHNT 21, 2016) took place in Vienna the first week of November 2016. In that occasion we gave a presentation entitled "Digitizing the excavation. Toward a real-time documentation and analysis of the archaeological record". Today I found the time to publish it in our blog, to share our research regarding this topic and in particular some interesting projects of "archeorobotics" we are working on.
Here below you can see the video of the presentation, done like always with the open source software impress.js and Strut...
... and here is a short description of each slide:
SLIDE 1
The title (strictly related with Digital Archaeology in general)
SLIDE 2
A short presentation of Arc-Team
SLIDE 3
All the work has been done thanks to Free/Libre and Open Source Software. In order to keep going on with our research regarding archaeological methodology we need the source code!
SLIDE 4
The fundamental schema of the archaeological cognitive process elaborated by G. Leonardi in 1982. The schema shows the progressive reduction of the informations regarding human actions before and during the archaeological excavation (Human activities --> Traces on the soil --> Natural and anthropological degradation of the record --> archaeological excavation --> archaeological documentation) until the interpretative knowledge starts recover information during the post-excavation stage (with analitical data interpretation and reconstructive hypothesis)
SLIDE 5
A practical example of the schema from the site of Torre dei Sicconi in Italy (a medieval castle):
1. Human activities (summarized in the building of the castle, the medieval battle and the destruction of the main structure and the controlled explosion during the Great War)
2. Traces on the soil (summarized in the evidences of the battle, of the controlled explosion and of recent agrarian activities, while just negative layers were found regarding the construction of the structure)
3. Natural and anthropological degradation (summarized in the battle, the explosion, the agrarian activities and the normal natural dynamics)
4. Archaeological excavation (the most destructive investigation: in Torre dei Sicconi all the layers concerning the tower and the main central building has been removed by this activity)
5. The importance of archaeological documentation comes from distructive analysis (excavation). Being a long term project, Torre dei Sicconi was documented both with traditional and digital methodology
6. Data analysis. During this stage our knowledge of the site started to grow again. In this case both archaeological and historical techniques have been used
7. Reconstructive hypotheses represent the maximum increase of our (interpretative) knowledge of the site. For Torre dei Sicconi this stage has been achieved just for the central part of the castle (tower and main building)
SLIDE 6
The archaeological excavation is the most critical (destructive) stage of our knowledge regarding a site.
SLIDE 7
Arc-Team's excavation strategies:
1. increasing the amount of information registered decreasing the time-consuming operation of archaeological documentation
2. on-site direct observation for a better interpretation, avoiding at the same time any kind of data selection
3. moving the lab into the field (chemical and physical analyses)
SLIDE 8
A milestone of our research: in 2006 the development of the "Metodo Aramus" gave us a better (more precise and accurate), faster and corect (equalized) 2D digital documentation with FLOSS.
SLIDE 9
Another milestone. Between 2008 and 2009 the migration from pure photogrammetric software to SfM and MVSR methods (through the development of a GUI for +Pierre Moulon's application Python Photogrammetry Suite) gave us better and faster 3D digital documentation
SLIDE 10
Even today we still use a combination of 2D and 3D techniques to meet different requirements of various archaeological projects
SLIDE 11
2D digital documentation through GIS is fast enough for on site interpretation during emergency excavation
SLIDE 12
A software like +QGIS allows a direct interpretation on the field without the necessity of long post-rpocessing
SLIDE 13
3D documentation gives better results, but needs longer processing time (even if it does not need long data acquisition on the field, which is always performed)
SLIDE 14
We achieved (a lower quality) 3D data acquisition which has the fundamental characteristic of being real-time, thanks to open hardware (archeorobotics)
SLIDE 15
Our experience in archeorobotics dates back to 2006 with our first prototype of UAV, which could be use professionally just in 2008.
SLIDE 16
Currently or archeorobotics research regards our last prototype of Archeodrone (a UAV specifically designed for aerial archaeology)...
SLIDE 17
... some CNC machines and, above all, the Fa)(a 3D, a 3D open hardware printer which without any kind of modifications was able to satisfy our archaeological needs (like 3D printing casts of unique finds or exctract and print DICOM data form x-ray CT scan)...
SLIDE 18
... and the ArcheoROV, the open hardware Remotely underwater Operated Vehicle which we developed with the +Witlab Fablab
SLIDE 19
Some pictures of the first test of the ArcheoROV
SLIDE 20
A first step into 3D real-time documentation through SLAM (Simultaneous Localization and Mapping) techniques has been done with the open source ROS (Robot Operating System) and RTAB-Map via Kinect...
SLIDE 21
... and tested for 3D real-time documentation in wooden areas (where SfM and MVSR or laserscab would have been too slow), reaching in almost one hour of work a model (with real dimension) of 75000 points.
SLIDE 22
A benefit of archaeorobotic system like these (which are ROS capable) is the possibility to change the sensor in order to adapt the hardware to different situation, using monocular or stereo cameras (for odometry) as well as LIDAR or SONAR devices.
SLIDE 23
Another benefit is the wide range of possibilities offered by the different open source software (e.g. RTAB-Map, LSD-SLAM, REMODE, Cartographer, ecc...)
SLIDE 24
Currently the precision/accuracy level of a real-time 3D archaeological documentation cannot be compared with the results achieved with post-processing through traditional SfM - MVSR systems, but there are good prospects for improvement.
SLIDE 25
Nowadays, basing on our professional experience, the best use of such devices seems to be during extreme operations, such as high mountain archaeology, glacial archaeology, underwater archaeology or speleoarchaeology
SLIDE 26
Another important step to improve the reaction time of professional archaeology, in order to avoid errors during the critical stage of the excavation, is the possibility to perform some basic archaeometrical analyses (chemical and physical) directly on the field.
SLIDE 27
Considering the composition of any archaeological layer based on two different elements, the skeleton (macroscopic) and the fine earth (microscopic), it is obvious that different analyses can be performed in different work environment.
SLIDE 28
For instance, in the case of the skeleton, a fast petrografic (ontoscopic) analysis can be easily performed directly on the field (defining allogeneic elements), while further (more specific) investigations need an equipped laboratory.
SLIDE 29
Also in the case of fine earth, some raw descriptive analyses can be performed on the field, while laboratory investigation can reach very detailed results (e.g. with the Scanning Electron Microscope).
SLIDE 30
The field analysis of the fine earth is more problematic (compared with the skeleton) the most common test (e.g. the Soil texture by feel) are anametric and subjective
SLIDE 31
For this reason, archaeometric test are the better choice (e.g the sedimentation test)
SLIDE 32
The sedimentation test on the field can be improved with basic physical analysis (e.g. considering the Stoke's Law in order to define sand, silt and clay by the tme they need to sediment)
SLIDE 33
Another implementation on the field for the sedimentation test is the possibility to directly store the data into a PostreSQL/PostGIS database (through some specific fields of the archaeological recording sheet), using the open source application geTTexture.
SLIDE 34
An example of the use of geTTexture
SLIDE 35
Other archaeometric test which are simple to perform directly during the excavation are based on basic chemical analyses, and specifically with the quantification of compounds like phosphates or nitrates.
SLIDE 36
Moreover, with some simple workarounds, it is possible to turn anametric (boolean) analyses of carbonates or organic substances, into metric (quantitative) observations.
SLIDE 37
The Archaeological excavation is a destructive process, subject to fatal (not reversible) errors. Moreover the reduced time and budget in professional and emergency archaeology increase stress conditions during decision making stages.
Real-time 3D mapping can speed up data interpretation, avoiding data selection on the field, while on-site chemical and physical analyses (geoarchaeology and archaeometry) can define a better (data-driven) digging strategy.
I hope this presentation can be useful. Have a nice day!
This year, thanks to Prof. Tiziano Camagna, we had the opportunity to prove our methodologies during a particular archaeological expedition, focused on the localization and documentation of the "devils boat".
This strange wreck consists in a small boat built by the Italian soldiers, the "Alpini" of the battalion "Edolo" (nicknamed the "Adamello devils"), during the World War 1, near the mountain hut J. Payer (as reported by the book of Luciano Viazzi "I diavoli dell'Adamello").
The mission was a derivation of the project "La foresta sommersa del lago di Tovel: alla scoperta di nuove figure professionali e nuove tecnologie al servizio della ricerca” ("The submerged forest of lake Tovel: discovering new professions and new technologies at the service of scientific research"), a didactic program conceived by Prof. Camagna for the high school Liceo Scientifico B. Russell of Cles (Trentino - Italy).
As already mentioned, the target of the expedition has been the small boat currently lying on the bottom of lake Mandrone (Trentino - Italy), previously localized by Prof. Camagna and later photographed during an exploration in 2004. The lake is located at 2450 meters above see level. For this reason, before involving the students into such a difficult underwater project, a preliminary mission has been accomplished, in order to check the general conditions and perform some basic operations. This first mission was directed by Prof. Camagna and supported by the archaeologists of Arc-Team (Alessandro Bezzi, Luca Bezzi, for underwater documentation, and Rupert Gietl, for GNSS/GPS localization and boat support), by the explorers of the Nautica Mare team (Massimiliano Canossa and Nicola Boninsegna) and by the experts of Witlab (Emanuele Rocco, Andrea Saiani, Simone Nascivera and Daniel Perghem).
The primary target of the first mission (26 and 27 August 2016) has been the localization of the boat, since it was not known the exact place where the wreck was laying. Once the boat has been re-discovered, all the necessary operations to georeference the site have been performed, so that the team of divers could concentrate on the correct archaeological documentation of the boat. Additionally to the objectives mentioned above, the mission has been an occasion to test for the first time on a real operating scenario the ArcheoROV, the Open hardware ROV which has been developed by Arc-Team and WitLab.
Target 1 has been achieved in a fast and easy way during the second day of mission (the first day was dedicated to the divers acclimation at 2450 meters a.s.l.), since the weather and environmental conditions were particularly good, so that the boat was visible from the lake shore. Target 2 has been reached positioning the GPS base station on a referenced point of the "Comitato Glaciologico Trentino" ("Galciological Committee of Trentino") and using the rover with an inflatable kayak to register some Control Points on the surface of the lake, connected through a reel with strategical points on the wreck. Target 3 has been completed collecting pictures for a post-mission 3D reconstruction through simple SfM techniques (already applied in underwater archaeology). The open source software used in post-processing are PPT and openMVG (for 3D reconstruction), MeshLab and CloudCompare (for mesh editing), MicMac (for the orthophoto) and QGIS (for archaeological drawing), all of them running on the (still) experimental new version of ArcheOS (Hypatia). Unlike what has been done in other projects, this time we preferred to recover original colours form underwater photos (to help SfM software in 3D reconstruction), using a series of command of the open source software suite Image Magick (soon I'll writ a post about this operation). Once completed the primary targets, the spared time of the first expedition has been dedicated to secondary objectives: teting the ArcheoROV (as mentioned before) with positive feedbacks, and the 3D documentation of the landscape surrounding the lake (to improve the free LIDAR model of the area).
What could not be foreseen for the first mission was serendipity: before emerging from the lake, the divers of Nautica Mare team (Nicola Boninsegna and Massimiliano Canossa) found a tree on the bottom of the lake. From an archaeological point of view it has been soon clear that this could be an import discovery, as the surrounding landscape (periglacial grasslands) was without wood (which is almost 200 meters below). The technicians of Arc-Team geolocated the trunk with the GPS, in order to perform a sampling during the second mission.
For this reason, the second mission changed its priority an has been focused on the recovering of core samples by drilling the submerged tree. Further analysis (performed by Mauro Bernabei, CNR-ivalsa) demonstrated that the tree was a Pinus cembra L. with the last ring dated back to 2931 B.C. (4947 years old). Nevertheless, the expedition has maintained its educational purpose, teaching the students of the Liceo Russell the basics of underwater archaeology and performing with them some test on a low-cost sonar, in order to map part of the lake bottom.
All the operations performed during the two underwater missions are summarized in the slides below, which come from the lesson I gave to the student in order to complete our didactic task at the Liceo B. Russell.
Aknowledgements
Prof. Tiziano Camagna (Liceo Scientifico B. Russell), for organizing the missions
Massimiliano Canossa and Nicola Boninsegna (Nautica Mare Team), for the professional support and for discovering the tree
Mauro Bernabei and the CNR-ivalsa, for analizing and dating the wood samples
The Galazzini family (tenants of the refuge “Città di Trento”), for the logistic support
The wildlife park “Adamello-Brenta” and the Department for Cultural Heritage of Trento (Office of Archaeological Heritage) for close cooperation
Last but not least, Dott. Stefano Agosti, Prof. Giovanni Widmann and the students of Liceo B. Russel: Borghesi daniele, Torresani Isabel, Corazzolla Gianluca, Marinolli Davide, Gervasi Federico, Panizza Anna, Calliari Matteo, Gasperi Massimo, Slanzi Marco, Crotti Leonardo, Pontara Nicola, Stanchina Riccardo
I go on today writing about the Time Manager plugin of QGIS we saw in our last post.
This time I will focus the attention on one of the alternative (and unconventional) use we can do of this tool for archaeological aims: an archaeological vector drawing based on RTI-like raster series.
Of course, when I speak about archaeological vector drawing, I mean a GIS based technique (like the one described in this old post). We already developed a little bit further this methodology in order to use it in a semi-automatic way for archaeological finds (related post 1 and 2; bibliography here), so that this post can be seen as an integration of that work-flow. For the concept of RTI, I suggest you to read +Rupert Gietl 's post about a large scale case of study for such an application and my post about the open source tool developed by Giampaolo Palma (Visual Computing Lab of the CNR-ISTI).
The concept of RTI-like raster series is pretty simple: if in a common archaeological excavation is planned an RTI documentation (e.g. to further analyse particular artefacts such as small pottery fragments, coins, inscriptions in stone, etc...), than it is also possible to use some of the original pictures (with different light conditions) to simulate an RTI viewer within any GIS software. Once one of this picture has been rectified (and georeferenced, when needed), the related worldfile can be used also for all the other images (considering that they have all the same size), so that in QGIS it is pretty simple to create a raster series through the Time Manager plugin. The video below shows the result of this operation on a pottery fragment from the excavation of Khovle Gora, an archaeological mission in Georgia which we supported for the University of Innsbruck (Institut für Alte Geschichte und Altorientalistik).
I hope this post will be useful, have a nice evening!
I am back from the CHNT conference, which was held, like every year, in Vienna. There I had many feedbacks and the possibility to speak with colleagues regarding common problems in our profession (soon I hope to report some feedbacks from the session I was attending).
Today I would like to write a fast post about time visualization in GIS for archaeological aims, because I was asked by our friend +Undine Lieberwirth if we ever faced with this topic and especially if we ever used TGRASS. The answer is yes and this reminded me that we never wrote something about it, so I would like to start here a series of post dedicated to chronological GIS visualization with open source GIS in general (and in particular about some non conventional and alternative use of it), considering also the 4D visualization tasks.
By the way, today I will start with something simple, just showing an interesting tool of +QGIS : the Time Manager plugin.
The video below is just a fast demonstration of this tool, with some data coming from an excavation we performed between 2009 and 2011 in the church of S. Giovanni at Massimeno. The raster time series regards the different architectural phases of the structure (from XI to XXI century) we recognized during the excavation.
Just
a short post to spread the announcement of the recent release of two
R packages: rpostgis (see also here) and RQGIS (see also here and here).
The first facilitates transfer between
PostGIS "Geometry" objects (stored in PostgreSQL databases)
and R spatial objects; the latter
establishes an interface between R and QGIS
and allows the
user to access the manyQGIS geoalgorithms from within R.
I
tested them briefly and I think they are very useful tools to perform
and simplify statistical and geo-statistical analyses in
archaeological contexts. Here I
present a quick example of usage.
Firstly I imported a set of
archaeological site-points stored in a PostgreSQL/PostGIS database.
That is very simple with rpostgis package: it's enough to create a
database connection (like in RpostgreSQL package) and launch the "pgGetGeom" function.
Then I
used RQGIS package to run (within R) the QGIS geoalgorithm that
builds a polygon from layer extent. After setting the same parameters
required by QGIS, the function "run_qgis" creates a red polygon
around the outermost points of my dataset.
Actually, must be careful to the version of QGIS we are using. With
2.14 there's no problem, but if you're using 2.16.1 or 2.16.2 (like
me) you must modify the QGIS file "AlgorithmExecutor.py" (path
for linux users should be: "/usr/share/qgis/python/plugins/processing/AlgorithmExecutor.py")
as described in the web page.
In the next future this problem should be correct by QGIS core
team.
At
the end I performed a specific point pattern analysis with the data
imported and created by
our two packages: in this example I calculated the Ripley's K
function (for an archaeological example see here)
in order to identify the distribution model
(random, regular or clustered) of my
archaeological sites.
In my
opinion these two new R packages make easier and faster the
traditional spatial analyses in R and facilitate a more virtuous
integration between GIS, geo-database and statistics.
This short Videotutorial shows you the effect of QGIS "Reshape Features" tool on vector lines.
If you have time to clean and smooth vector-lines manually, you can try that possibility.
If you want to keep up always with our latest videos,
Sometimes we are asked why (after 11 years) we still keep OpenJUMP in ArcheOS, since QGIS became such a functional GIS and could cover all the feature of the other similar software. The main reason for such a choice are two:
1. QGIS developed very fast and can happen that some tools are still buggy when released (like for the newest georeferencer version)
2. the software (Polygontool) our friend +Szabolcs Köllö (aka Keulemaster) developed for us, in order to handle big data in archaeological surveys, is strictly connected with OpenJUMP
The GIS OpenJUMP
Today I just finished to package for (ArcheOS Hypatia) the last version of this GIS (OpenJUMP 1.9.1) and to upload it in our experimental repository (soon we share it), so I prepared a new videotutorial to illustrate one of the operation in which OpenJUMP is still useful, since the similar tool of QGIS are sometimes buggy: the recovering of old excavation data from a local (cartesian) coordinate system to a projected coordinate system (e.g. in the videotutorial, ETRS89 / UTM zone 32 N).
If you are using QGIS in archeology, almost probably you want also to produce georeferenced photomosaics, like we do with the "Metodo Aramus" technique (read the related post 1 and 2) and its further evolutions (check this post), which up to day involves just Kate, QGIS and GIMP). This post is just to warn you that is currently present a bug in QGIS 2.14, so that the georeferencer tool does not work properly. In the screenshot below you can read the details of this bug (and check it at this link).
Screenshot form the official QGIS link (name and images removed for privacy reason)
My advice is to do not update QGIS to the version 2.14 until the bug will be fixed (which I guess will happen very soon).
Have a nice day!
PS
This post reminds e that I should record a new videotutorial with the updated and simplified version of the "Metodo Aramus" (Kate-QGIS-GIMP). I will do it ASAP!
Bibliography
The "Metodo Aramus" in described in English in this publication:
Aramus Excavations and Field School. Experiences in Using, Developing, Teaching and Sharing Free/Libre and Open Source Software (here in ResearchGate and here in Academia)
Proposta per un metodo informatizzato di disegno archeologico (here in ReasearchGate, here in Academia)
The "Metodo Aramus" is part of the methodology we teach during our lessons in master and courses, as you can read in the report of one of this experience:
Corso base di Free Software e Open Source in archeologia: bilancio di un'esperienza di divulgazione pratica (here in ReasearchGate, here in Academia)
I should have written this post since long, but time is always missing... The topic regards the digital archaeological (vector) drawing on the field.
During the CAA conference of 2015, held in Siena Italy), I participate, among others, in the session 9A (Towards a Theory of Practice in Applied Digital Field Methods), moderated by +nicolò dell'unto (Lund University) and James Stuart Taylor. After my speech I was asked if we (Arc-Team), as a professional archaeological society, were really able to perform the digital documentation in real-time during an ordinary excavation. I answered that, at least in Italy, this point is very important for a professional society and that in normal conditions (but this can also happens during most of the emergency excavations) we complete the digital archaeological documentation directly on the field. The reason is simple and it is every year more evident: money are always less and less, as the time goes by, for cultural heritage matters; at least this is the trend of the last decade. For this reason, if on the one hand we have to try to counter this phenomenon, on the other we have to adapt our methodology to the current reality and this means to use the economic resources for the excavation also to produce the related documentation (without counting on a post-excavation budget).
The old video below (2014) shows how we manage the digital archaeological drawing on the field with QGIS.
The vector layers can be related to georeferenced photomosaic (bidimensional photomapping), or to georeferenced orthophoto (coming from 3D operations based on SfM/MVSR techniques). Of course orthophoto are the best solution, but currently the 3D work-flow with standard hardware is pretty slow. This is the reason why for almost all the palimpsestic documentation we still work with both the system: 2D photomapping and 3D SfM; depending on the time-table we have on the field, we choose the post-processing operations.
Within QGIS it is possible to draw vector layers in different ways. Basing on our experience (as you can see in the video), the best two best solution are:
1. to use the plugin Freehand Editing (if you want to experience something that is really similar to the old-traditional methodology, with the pencil and the paper)
2. to use the standard vector drawing tools (if you want to avoid too complex sahpes, like polygons with too many nodes)
IMHO, Freehand Editing plugin is a perfect solution for field operation, so that I am planning to add it into qgis-archeos-plugin, for ArcheOS Hypatia.
Today I will show something particular, that probably many of you will not need very often working on landscape archaeological project, but that will be more important to manage excavation GIS: how to turn a GeoTIFF picture into a TIFF + worldfile image.
As some of you will know a GeoTIFF is a particular kind of raster data in which the georeferencing values are embedded within the TIFF itself. This option can be a nice solution for a topographer but it is extremely annoying for archaeologists. The reason is simple: topographers often work on pictures or maps that are ready to be used, without the necessity of any photo-editing, which (on the contrary) is an important phase in archaeological photo-mapping process (e.g. for the "Aramus method"). The primary difference between a GeoTIFF and a TIFF + worldfile image is that it is not possible to modify the first one without loosing the georeferencing values (which are integrated in the picture), while it is possible to perform some photo-editing operations (change the colors, balance the brightness and contrast, etc...) in the second one, without problems, being the geolocalization data stored in a separate file (the worldfile).
For this reason working with raster images and worldfile is often the best choice for archaeological GIS (especially for excavation), where it can be useful to "erase" all the part of the photo which are outside the area of interest (e.g. outside the rectification region) and to take advantage of transparency in overlapping different raster levels (which can correspond to different stratigraphic levels).
As I wrote previously, the videotutorial I prepared using the data of Project Tovel simply shows how to turn a GeoTIFF, currently the unique option for QGIS georeferencing module) into a TIFF and a worldfile, a more useful format, without exiting the software.
As I was recently asked by some students here at Lund university to provide them with some "alternative" solution (compared to the ArcGIS-based workflow) to import LIDAR data in GIS, I ran into this software package named Fusion (http://forsys.cfr.washington.edu/fusion/fusionlatest.html). It has been developed by a branch of the US Forest Service to manage and analyze LIDAR data. Basically, by using Fusion, users are enabled to convert .las binary data format into a .txt file. Then, the data can be imported in QGIS and filtered based on the classification codes associated to the file itself. Here you can find a short video-tutorial which can help you in understanding the whole data-processing workflow (p.s. please ignore the MS Windows background! :-) ).
In many archaeological GIS a very important step is the study of historical maps. During the Project Tovel this stage has been a primary target, being strictly related to the 3D reconstruction of the underwater surface of the lake. In fact one of the best source for the bathymetry of Tovel is the plan drawn, between 1937 and 1938, by Edgardo Baldi (director of the "Istituto italiano di idrobiologia Dott. Marco De Marchi" of Pallanza, currently incorporated in the National Research Council - Institute of Ecosystem Study).
To Import Baldi's map into my GIS, I simply used the "georeferencer" tool of +QGIS, based on the related CTP (Carta Tecnica Provinciale) I loaded previously. The short videotutorial below describes this operation:
The second minipost regarding the Project Tovel is very short and it simply focuses on the visualization of the raster basic map of the lake district (C.T.P., Carta Tecnica Provinciale), we downloaded as open geodata from the "Portale Cartografico Trentino". For different reasons, I chose to analyze this data in +QGIS (later we will use other software) and, as you can see from the short videotutorial below, this operation is very simple:
I go on recording small videotutorial regarding the software in ArcheOS 5 (codename Theodoric), trying to collecting more material for the official documentation.
In order to avoid the creation of "wasted food" (videotutorial which are not connected with a real project risk to be useless because too theoretical and too few practical), I am collecting examples from our (Arc-Team) work.
This time I will show how to export 3D data from QGIS and visualize them in a browser thanks to the nice plugin "Qgis2threejs". I I had the necessity to do this kind of operation just to create some screenshot to complete this very simple illustration that gives a geological overview of the working area:
Of course this is not the only way to collect 3D views (I could do the same in GRASS with Nviz), but this workflow is very fast, for a small project.
Here is the videotutorial (I hope it will be useful):
QGIS 2.2.0 Valmiera has been released!
In my opinion, one of the most interesting news is the possibility of exporting an image with WORLD FILE from print composer.
I think this new option is very useful and simplifies the workflow in Aramus, Khovle or Corte Inferiore methods for the photomosaic creation.
QGIS
style tools for vector layers allow us to build custom symbols for
archaeological drawings (plans and sections). In this post I will
present some preliminary
examples of customizable styles for graphically representing hachures
and soil texture (clay, silt, sand and so on). For each, the .qml style files are downloadable from http://www.uselessarchaeology.com/ (section programming): you can put them in your QGIS
project and/or add to QGIS style manager for testing and modifying.
Using
vector styles makes the drawing more automatic and fast, because is
no more necessary to draw manually each individual symbol.
Furthermore, vector styles enable to change quickly the size of
symbols when the scale changes: in such way there is no need to scale
any single object.
The
bulding of a new style is managed by QGIS style window: with
button “Add symbol layer”
is possible to make a new symbol joining 2 or more individual
symbols. All symbols settings (dimension, angle, offset, etc.) can be
changed in the same window.
Hachures
In
plans, the edges of holes and ditches and the differences in level are
represented with hachures. They are composed by an isosceles
triangle and a line: the triangle marks the highest part of the
feature, where the slope begins; the line represents the length and
direction of the slope, with the end of the line showing the bottom
of the slope. I created 3 different styles of hachure for point
layers (hachure_pn), linear layers (hachure_ln) and
polygon layers (hachure_pl).
For
representing the differences in level, for example at the top of
wall, I create a shapefile of points connected to an attribute table
with two numeric columns named “angle” and “length”: the
first column records rotation angle of hachures, the latter records
the length of hachure's lines (where lines are not required, the
column value will be always “0”). Then I draw points in the place
where there are differences in altitude, I load hachure_pn
style,
I rotate each points with “Rotate Point Symbols tool” (in
advanced digitizing toolbar)
and I write the line length I desire in attribute table.
All
settings are customizable: from “Marker – Advanced – Rotation
field” you can set attribute columns
for angle; from
“Vector Field Marker” you can set attribute columns
for angle and length; from “Simple marker” you can set triangle
dimensions and offset: usually I give an offset that is half of
triangle dimension for fitting the point to the line.
Hachure_pn
style can be used also for linear or polygon features.
If
I have to draw a scarp, I create a linear shapefile and I load
hachure_ln style. It's possible to modify dimension of
triangles, space between symbols, width of line, etc. changing
parameters in QGIS style window.
For
representing a ditch or a hole, I create 2 polygon shapefiles, one
for top perimeter of the feature, one for the bottom limits. The top
polygon is drawn by hachure_pl style and the bottom polygon is
filled by white color: in the layer tree the bottom polygon must stay
over the top polygon for covering the hachure's lines that exceed the
slope. Like above, dimensions, space between symbols, offset and so
on are editable in QGIS style window.
Soil
texture
I
post some examples of archaeological layers filled with symbols
representing soil components: clay,
silt, sand, silt-sand.
You
have to pay attention to the settings of the these styles. Many
symbols are set in map units and not in absolute measure (i.e.
millimeters) to better fit the variation of scale during the display.
For printing, all style settings must be changed according to the
plot scale; for this purpose printing tests are recommended. Finally,
I suggest to export in .svg format and modify the layout in Inkscape
for adjusting the last details.
In
future I hope to post other examples of archaeological styles. But if
you have other ideas or you want to contribute with your personal
QGIS archaeological styles, we could create a shared library of
archaeological symbols for QGIS.
Hi everybody
Together with Alexamder Sachsenmaier and Alesandro Bezzi i found out a method to create a photomosaic just with QGIS. The problem was to export the single pictures in a good quality and in the size of the whole photomosaic not just the size of the single picture. But this works fine with the print composer of QGIS
So shortly:
1. edith the file of the ground control points to a .csv file
2. import the .csv file into QGIS (plugin is requiered)
3. change the design of the points
4. start the print composer and export the model with the points. Here its possible to set the dpi: e.g. for an area of 3x2m 500dpi gives a resolution of more or less 1mm
5. start the georeferencing plugin of QGIS and georeference the model
6. to export the wordfile from the geotiff of the model, type the following in the terminal
gdal_translate -co "TFW=YES" input_geotif.tif output_tif_tfw.tif
or open the model in OpenJUMP and close it again
7. georeference all the single pictures with QGIS
8. start the same print composer like the one for the model and export all single picures (dont move the pictures)
9. open the model in GIMP and import all single pictures as single layers
10. give the same name to the wordfile of the model and the photomosaic
Alessandro allready maked a videotutorial:
manageR is a QGIS plugin
providing a simple and usefull interface to R statistical
programming environment (http://www.r-project.org/).
It is created by Carson J. Q. Farmer (http://www.ftools.ca/manageR)
and is downloadable from this repository:
http://www.ftools.ca/cfarmerQgisRepo.xml.
To install it in QGIS is enough
add such repository in QGIS
Python Plugin Installer
(Plugins → Fetch Python Plugins).
One of the most interesting things is
that you can take data directly from the .dbf table of the shapefile
layer loaded in QGIS and process them in R environment. Usually, when
I work with PostgreSQL/PostGIS or SQLite/SpatiaLite for managing
attributes table of vector layers, I connect directly database with R
using RODBC or RSQLite packages. But if I have to use shapefiles and
their .dbf tables, manageR could be a good solution, specially
for fast and simple works.
Here, I would like to present a small
example of plugin's use. In QGIS I created a distribution map of
Roman funerary sites in Trentino-Alto Adige region (Northern Italy).
The sites (blue dots) are registered in a simple shapefile and every
single point is associated to a record stored in a .dbf table. As
usual, the .dbf table is divided in several columns each of which
contains different attributes about sites (ID, coordinates, height,
date, etc.).
I need to plot an histogram of heights
above sea level to get an immediate view of sites distribution based
on heights. I can launch manageR from QGIS.
At first sight, manageR
is a simple GUI that includes R command line, some toolbars for
managing data, graphic devices, history, etc. and several buttons to
make some of the most common statistical analysis.
As I said, in manageR I can
import layer attributes with button “Action → Import Layers
Attribute” (or CTRL+T) and then I can select the column I need
(in my case, “height”) using R language.
Typing in R command line or using
button “Analysis” in main toolbar, I can select and launch
the statistical function I need and plot the diagram; in my example I
plotted an histogram of heights a.s.l. of my funerary sites.
This is a simple example, but manageR
plugin could be a very usefull tool for archaeologists, also for more
complex works. Its main advantage is that it works directly with .dbf
table, avoiding the export of data or the opening of .dbf file in
Calc/Excel.
