Previous | Next

Clearly, there would be a use for some sort of on-line GIS sitting on top of a National Archaeological Database. A map-like interface would allow greater visualisation of the data, and enable a greater understanding of our archaeological heritage, both for the public and academics.

The choice of front-end will probably play a large part in the design of the back end of any such system. If the NMR were to opt for applications such as AutoDesk"s MapGuide, then the server software would be decided for you – you would have to use AutoDesk MapGuide Server.

The use of HTML forms would mean that custom server programmes could be written more easily, perhaps interfacing with free software like GRASS. However, development and maintenance costs could be high and it may be that only the original programmer would be able to provide any high level of support. There are proprietry GIS packages that also have web add-ons available, such as ESRI"s ArcView Internet Map Server, or MapInfo"s MapXtreme. These would probably all integrate quite well with the NMR, and use either the standard HTML forms interface or a Java GUI. From what I have seen of them, they function perfectly well, but they output raster files which is not good, and the use of HTML forms means repetitive use could get very frustrating.

However, the use of formally established data standards by the NMR and SMRs should enable a more modular approach to the design of any such system. Already, most of the "popular" GIS applications will read data from other "popular" databases or GISs. As data standards are refined, it may be that all databases end up using standard data storage techniques, enabling easy integration with or migration between software. Already, the use of SQL and JDBC enables a fairly standard approach to database connectivity.

Table 4 summarises the advantages and disadvantages of the commercial versus custom route for on-line GISs.
 

Table 4: The advantages and disadvantages of a Commercial versus Custom Solutions

While these commercial packages could function quite well with the NMR, it would not be too hard for a programmer to design a custom applet that simplified the user interface and allowed the dynamic and visual display of data. Hopefully, the Java programmes included have illustrated this point. They are capable of communicating with other programmes, and reading in data streams to draw on the screen. I am certainly no programmer, and have only been playing with Java for a few months, but it was still possible for me to develop some fairly functional programmes. Imagine what an experienced programmer could do!