I’m a bit confused. The National Treasures website, set up by the Israel Antiquities Authority, provides a gallery and info: “This on-line site offers a selection of published artifacts from the collections of the National Treasures and is available for researchers, curators, students and the general public in Israel and abroad. This site is updated continuously, and new artifacts are added on a regular basis.” So far so good. However, when you dig down to an actual artifact page, this is what jumps out:

There are two links for “Purchase”? Fortunately, when I clicked these, nothing happened, the page stayed the same. Still, is the IAA in the antique dealing business now?

Correction: As Mark and Catherine were kind enough to point out, the entry page of National treasures actually does state: “The artifact’s information card presents detailed archaeological data about the selected artifact, including provenance, type, dimensions, material, site where discovered, dating and bibliography. In addition, hi-resolution images of on-line artifacts may be purchased on-line from the photographic archives of the Israel Antiquities Authority.” I am sorry for any confusion I may have caused. Just goes to show that it isn’t always a good idea to write blog posts (very) late at night…

Reading the recent posts by Fennelle Miller and Kevin Schwarz got me to look into the spatial data a bit more closely. One of the issues that seems to crop up again and again is cost and complexity.

GIS data is still difficult to share dynamically over the Web, but things are changing. GoogleEarth, Google Maps, Open Layers, etc. provide great tools on the client side for viewing and interacting with spatial data (not just points too, but also vector lines and polygons). GoogleEarth and Google Maps are proprietary, but they are available as free downloads or free APIs. They also work with an XML format (KML) that is pretty simple, enjoys a wide user-community and can work with non-Google developed tools.

There are some tools for transforming the ubiquitous ESRI shape files into KML documents (the XML format used by Google’s applications for spatial data)(See this blog post at PerryGeo, see also the post’s comments). Here’s a link to some “how to” discussions on using PHP to read MapInfo (.mif) files to use with Google Maps. Here’s a link to an open source PHP class that reads ESRI shape files, the first step needed in converting them on a server to KML or other formats. The point of all this is that, with some development work, we can transform (to some degree at least) typical GIS data into formats work better on the Web.

Of course, GML (the community developed open standard) is a better choice for GIS data than KML. KML is needed for Google’s great and easy to use visualization tools, but GML is a much more robust standard for GIS data. GML also has the advantage of being an open, non-proprietary XML format. You’re not locked into any one software vendor and you have important data longevity advantages with GML. It should be noted that Open Layers (the open source equivalent of Google Maps) supports GML.

However, I’m not sure of the immediate need to go through all this effort. Sure it’s nice to have GIS data easily viewable on a web-browser or slick visualization tool like GoogleEarth. But the fundamentals of data access, longevity and discovery need to be in place first before we put lots of effort into online visualization.

Instead, we should look at some strategies to make our GIS data easier to find and maintain. And we need to approach the issue pragmatically, since overly complex or elaborate requirements will mean little community uptake. Perhaps we can look at ways of registering GIS datasets (ideally stored in GML) in online directories with some simple metadata (“information about information”). A dataset’s general location (say Lat / Lon point coordinates), some information about authorship, keywords, etc. and a stable link to download the full GIS dataset would be an excellent and simple start. Simple point data describing the general location of a project dataset will be enough to develop an easy map interface for users to find information about locations.

Such directories can be maintained by multiple organizations, and they can share/syndicate their content with tools such as GeoRSS feeds (RSS with geographic point data). It’s easy to develop aggregation services from such feed. You can also use something like Yahoo Pipes to process these feeds into KML formats for use in GoogleEarth! (We do that with Open Context, though it still needs some trouble shooting).

Also, Sean Gilles (with the Ancient World Mapping Center) is doing some fantastic work on “Mush” his project for processing of GeoRSS feeds. See this post and this post for details and exanples. Thus, simple tools like GeoRSS feeds we can contribute toward a low-cost distributed system that makes archaeological datasets much easier to find and discoverable with map-based interfaces and some types of spatial querying (such as buffers). This may be a good way to address some of Fennell Miller’s concerns about recovering and reusing all that hard-won geospatial data.

Of course, site security is an important issue, and finding ways of making our data as accessible as possible without endangering sites or sacred locations is important. I’m glad Kevin Schwarz raised the issue, and it’ll be very useful to learn more about how he and his colleagues are dealing with it.

         Fennelle makes a good point.  My impression is that agencies are often protective of their GIS data and may fear that wide disclosure will lead to people with nefarious purposes knowing where sites are located.  One of the frustrations (also an opportunity) is that through CRM investigations incredibly detailed GPS and GIS databases are often built-up about archaeological sites or regions, but there is no policy in place or architecture for capturing much of that data long-term.  For example, my firm often conducts GPS-based archaeological survey such that every artifact collected is associated with a GPS point (for example in a controlled surface collection).  But typically, agencies will only want one or a few GPS points for each site (or a shapefile with site boundaries).  A lot of these points are also, or could be tagged with information on stratigraphy, soils, slopes, groundcover, or prior distubance.  So aside from legacy data storage within your own firms’ archives there is no long-term organized effort to preserve the painstakingly collected data.  I am sure there are people in SHPO offices and elsewhere who would be interested in a broader-based archaeology GIS (currently state CR GISs work well but data collection/display is somewhat limited).                                                

          The possibility is that web-based and accessible formats could be used to store and make available archaeological data without compromising the need to secure certain kinds of data.  A collaborator of mine has written an XML data format that could be used to tag archaeological data in ways that could be read by various internet scripts.  It is pretty basic right now but it or something like it could make distributed GIS or GPS archaeology on the web more possible!  He and I also are collaborating on a webviewer that allows for analysis of spatial archaeological data within any webbrowser (he is the programmer not me!).   Both icon and  color-based intuitive analyses (Jacques Bertin’s visual variables) as well as results of quantitative analyses are available. I’ll post some more information on these ideas if anyone is interested in seeing it.


Kevin Schwarz



I have noticed that more and more federal agencies are requiring archaeological contractors to use GPS and GIS, but few of the agencies are then offering the contractors the GIS shapefiles to use in the field. Why are we documenting sites, features, artifacts with sub-meter accuracy and then using paper records to re-locate those same sites the next time out in the field?

I am hoping to persuade everyone to embrace the use of as many of the digital technologies as possible. I use GPS and GIS, but I do not own the hardware and software yet. However, they are the very next purchases I will make, as I consider them almost as important in doing business in 2007 as a computer and shovel.

Interested in hearing other people’s input on this topic. And I’m really interested in hearing what hardware and software people are using for GPS with real-time GIS data. ArcPad, right? Loaded onto what machine?

Fennelle Miller