We will be using a variety of software for this summer which will build upon previous work for the Avkat Archaeological Project. Prior work has been dominated by the creation of an SQL database coded in MySQL. A front-end was created for this database using PHP for query optimization. This database has stored all tabular and image data for the project, however spatial information has been lacking.
ArcSDE is used to store spatial information. Recently the MySQL database was translated to PostgreSQL which employs pgAdminIII. This allows for better communication between the SQL database and the ArcSDE geodatabase.
Currently, we are working on building data queries which result in tables and views which can then be queried by end users. It is important to note here the difference between the two – tables and views. Tables result in a more static image of the data within the SQL database. This means that as the data is changed within SQL database, the table either stays the same or breaks due to information loss. Views, on the other hand, update their information thereby allowing end-user queries on the most recent version of the data. While it seems that views are more ideal than tables, there are situations where a table could be useful. Such a situation could include when a researcher does not need the most up-to-date dataset.
Future work will include uploading this information to ArcServer and at least one web-mapping application (WMA) will be created. Information is uploaded to ArcServer in order to serve out geospatial data which, in this case, has been joined to tabular data. REST services will then be created via ArcServer REST API. These REST services will then be consumed by the WMA.
It might be useful to provide an example for how this applies more directly to archaeological research. Field research for the Avkat Archaeological Project tied artifact information to an observation point, which can correspond with zero to infinity artifacts. These artifacts have been recorded on paper forms which have been entered into a SQL database which stores data in a tabular format.
Geospatial data will then be tied to the tabular data by using ArcSDE. ArcSDE functions as middleware between the tabular and geospatial data. This means that the spatial observation points can then be tied (i.e. joined) to the tabular data. This is where differing versions can be created. For example, here we can join the observation points to a broad overview of all artifacts found at that point or to specific assemblages such as lithics or pottery. The beauty of this is that when the geospatial data is queried, i.e. through selection, the query retrieves all relevant/joined tabular data. Similarly, when tabular data is queried through the WMA the spatial information can also be referenced (i.e. highlighted). This provides a valuable tool to the analyst wishing not only understand the assemblage quantitatively, but also spatially.
A researcher conducting pottery analysis can observe an anomaly of interest at a given point and select nearby points to see if this anomaly continues into other areas. We additionally seek to provide the ability to download relevant data in both tabular and geospatial formats.