The Electronic Cultural Atlas Initiative and Geographical Information Systems Technology (ECAI-GIS)
L. W. Crissman, ACASIAN, Griffith University
November , 1997
Annotations between < … > added by Ian Johnson 26/5/98
Additional comments between [ … ] by L. Crissman 28/5/98
This document explores issues such as the nature of GIS, choice of GIS software for ECAI, the need for a unitary base map, and ways to make ECAI GIS databases accessible over the Internet and on CD-ROMs. Attention is also given to how scholars who are not particularly computer oriented can access and contribute to ECAI GIS-based materials, and the kind and degree of technical support they will require.
The Nature of Geographical Information Systems (GIS)
Something called an 'Electronic Cultural Atlas', rather than just a 'database', implies that the information it contains will be mapped or otherwise referenced or represented spatially. There is an existing technology that accomplishes precisely that, most generally manifested as Geographical Information System (GIS) software, of which a number of commercial products are available. Those suitable for ECAI- GIS purposes utilize vector-based digital cartography (in the first instance, anyway -- see the discussions of raster images and output, below) in which spatial features or objects are represented by points, lines, networks of lines, and polygons (multiple lines, or vectors, that are joined end to end and ultimately join up to enclose a space). Because vectors (other than points) begin at one point and have both direction and straight-line length to another point, they also have a left and a right side and polygons therefore have insides and outsides. Such topological properties allow GIS software to determine whether objects intersect or are otherwise related, as with adjacent polygons, for instance. When GIS data are defined in a coordinate system that represents some portion of the earth's surface in some known map projection, the objects in the GIS are said to be 'geo-referenced', and can be spatially analysed in relation to topographic or other geographic features of the landscape to which they therefore belong as well as other objects it contains. So can attributes of GIS objects, which can be any kind of information about them held in linked databases (or even spreadsheets), including even such things as URLs (Universal Resource Locators, like Internet sites). The advantages of organising ECAI databases with GIS software are apparent to those who are familiar with the technology. Everyone participating in contributing data to ECAI's spatially integrated databases should understand the fundamentals of GIS, including some of the basic concepts, above.
ECAI's choice of GIS software
If ECAI participants in many institutions in many countries are to both access and contribute to its GIS data bases, then only those software programs that run on all personal computer platforms are suitable, eliminating both 'shareware' and 'industrial strength' software available for the UNIX environment. Programs that work in the Microsoft Windows environments (NT as well as Windows 95 and 98) are particularly suitable because of the existence of Asian language versions of Windows as well as other third-party programs that allow CJK (Chinese, Japanese, and Korean) characters to be utilised along with roman characters. Ultimately, ECAI will need to adopt the 'Unicode Standard', a two-byte per character system that will potentially accommodate all known orthographies from hieroglyphics and Sumerian cuneiform to contemporary Tibetan and Mongolian, and it is more likely to be implemented in Windows environments before any others. [Someone said in Taipei that the next release of Windows NT will have provisions for Unicode.] That basically leaves the choice of ECAI's GIS software to MapInfo or ArcView, the latter being an ESRI (Environmental Science Research Institute) product closely linked to ARC/INFO, the premier GIS program at least in the UNIX environment.
MapInfo (MI) Advantages
With all due respect to ESRI and its ArcView product, the choice of MapInfo for ECAI's basic and standard GIS software is the obvious one. <I agree with Larry, but some of his argument overlooks strengths of the competion, which I have added in below> First, it is available for Macs (and UNIX) as well as PCs in Windows environments <so is ArcView>. It is also quite easy to learn, and is thoroughly 'user friendly' in virtually all operations, particularly including CJK input and display in the requisite Windows environments or with third- party programs. It has a powerful inbuilt menu driven SQL utility (Structured Query Language - the basis of Relational Data Base Management Systems, or RDBMS) <this is one of the big points in its favour compared with other systems> and uses MapBasic as a Macro/Programming language that can automate complex operations and generate special interfaces, such as one that could be designed for ECAI productions <ArcView has an equivalent, Avenue, and most systems can also be programmed using a third-party language such as Visual Basic or Delphi>. MI is particularly suited for generating and displaying visual versions of GIS analysis and searches, and in preparing data and analysis for hard copy output in the form of camera ready color maps. Map projections are readily manipulated, and even automated. It also has inbuilt raster facilities, both for display and output. Its drawbacks, shared with ArcView, are the difficulty of modifying some forms of existing spatial data and directly inputting complex spatial objects. Points and even simple lines, on the other hand, are very easy indeed to input and even move. Finally, the academic price for MI is very low internationally <in Australia about US$800 for 10 copies or US$500 for 1 copy - non-academic price is US$1500. Unfortunately upgrades don’t benefit from academic pricing so generally come in at about $150 - 250 per copy depending on scope of upgrade>, and it is by far the most widely installed <though ArcView is not far behind and closing> 'desk-top mapping system', a term the company itself uses to describe the program. Many universities have site licenses or other access to it.
<two other mainstream alternatives might be considered: GeoMedia from Intergraph, the other big player in the heavyweight GIS field, and Maptitude from Caliper Corporation, a lesser known GIS heavyweight. GeoMedia uses an Access Vsn 2.0 format for ALL its data, including geographic data, and has some very nice analytical smarts built into it, but is a little less intuitive than MapInfo and requires more horsepower - at least a Pentium. Maptitude is inexpensive (US$400) is full-featured, can read and write just about all types of GIS and database formats, comes with worldwide 1:1M map data which can generate a multi-layer map of any given country with the click of a couple of buttons. It should certainly be considered by anyone not attached to a University because it is much more affordable than the commercial price of the other products which is US$1500 or more. The only real drawback of Maptitude is it is less widely used than MapInfo or ArcView so finding someone with expertise is harder. As far as I know, GeoMedia and Maptitude only run on PCs> [Yet another possibility is Bentley’s GeoGraphics, which comes bundled in an Academic Suite with Descartes, a raster veiwing and manipulating program, and MicroStation, a CAD program that ACASIAN prefers to AutoCAD for spatial data generation 10 Academic Suite licences cost only A$1,500! However, one |HUGE drawback is that GeoGraphics doesn’t seem to know how to handle different map projections, so until Bentley teaches it how to do that, it is worthless for most ECAI purposes.]
Other software requirements
GIS software is primarily designed to handle the topological relations among vector entities, and most programs use other database programs to organise and hold attribute data, using codes of some sort to relate the spatial objects to their attributes (some kind of unique identifiers are required). MapInfo is a partial exception to this generalisation <ArcView and Maptitude use Dbase, GeoMedia uses Access 2>. Although it can interface with powerful RDBMS software, such as ORACLE, it has its own SQL-based attribute data management facility, mentioned above <the other products use non-SQL forms of query, which is not such a ‘clean’ solution>. Although its 'browser' tables look like Excel tables, they are actually more like Access data bases because of their relational functions, and many users would rather use MI browsers than Access because of its powerful menu-driven querying system <hmmm … I think one should avoid entering data through MapInfo browsers because there is no data entry control, nor is there any extended text field type. Access is a MUCH better environment because one can set up nice user-friendly data entry forms>. In any event, the MI attribute data structure is basically compatible with Excel, and data can be written back and forth between the two programs with ease. (Microsoft Map, which comes with the latest versions of Excel, is in fact a version of the MapInfo 'engine'.) Since most Windows and even Mac users already have Excel (and Access) as part of Microsoft Office, there will be no need to acquire, and learn, other expensive and complex software programs to use in conjunction with MI. The only exception is the need for either CJK Windows environments or something like Chinese Partner (Twin-Bridge) or its Japanese or Korean equivalents necessary for using CJK characters with MI.
ECAI-GIS base map requirement
ECAI needs a common base map on which to build its GIS in addition to a common software system. If everyone contributing geo-referenced materials to the Initiative starts from scratch (even using the same GIS software) and creates their own original digital cartography from heterogenous paper sources, the problems of eventual integration of ECAI data become virtually insurmountable. <I absolutely agree - basing recording on paper maps is an absolute no-no.>. On the other hand, if ECAI adopts existing digital cartography from a single source as its fundamental base map, there are abundant advantages beyond mere compatibility, such as for instance the ability to relate spatial objects to one another in the same coordinate system that the base map provides, no matter how distant they are on the earth's surface, including from one end of Asia to another. <I think Larry is overstating the case. At the risk of complicating the issue, we can use different digital base-maps, because GIS allows different coordinate systems to superimpose cleanly, provided we know exactly what they are and our software can cope with the projection used. [Sure, and if everyone contributing data to ECAI understands at least the fundamentals of map projections!] However, the Digital Chart of the World base map (see next section) is a very good starting point promoting uniformity, and I would strongly support this.> Features contained in the base map need to include general physical objects, such as rivers, lakes, and mountain ranges, along with man-made objects such as international boundaries and an assortment of cities, towns, roads, and rails. Without such a common base map, everyone digitising maps for ECAI would only be reproducing the electronic equivalent of their original paper maps, and there would be no overall spatial coherence to ECAI-GIS, or ECAI itself for that matter.
The Digital Chart of the World (DCW)
Fortunately, there is a source for worldwide digital cartography at an appropriate scale. In the early 1990s the US Defense Mapping Agency (DMA) contracted with ESRI to produce a digital version of the Operational Navigation Charts (ONCs), a 1:1,000,000 scale topographic map series covering the whole world that is universally used for jet aircraft navigation and is readily available from DMA listings in any large US Yellow Pages. The resulting Digital Chart of the World (DCW), which faithfully reproduces all the features on the ONCs, has its drawbacks discussed below, but it is the only digital map available at that, or any larger, scale with pan-Asian or worldwide coverage. Again, the price and availability are right, as there are DCW versions available in most GIS software formats, including MapInfo, from diverse sources and at generally affordable prices (or even free, but unfortunately not for MI). <note that Maptitude comes with a CD including the DCW in Maptitude format for free. This is particularly good because the tiling has been removed, or at least hidden, and Maptitude can generate a DCW-based map for any country at the click of a few buttons>
The drawbacks of the DCW do not include its 1:1m scale, which is neither too large nor too small for national or even international GIS use. At that scale, one kilometer (.6 of a mile) is equivalent to one milimeter (.04 of an inch) ON PAPER. Scale is actually meaningless in digital cartography or GIS, as the software programs allow for virtually infinite zooming in and out on-screen or for output, but the related resolution of spatial data IS important for two reasons. One is the ability to represent spatial objects of relevant size, and 1:1m is adequate to indicate the outlines of objects such as all significant rivers, medium to biggish lakes, ranges of hills if not every single small hummock, and even the outlines of largish cities.
If someone working on a single archaeological site or city streets wants to show more detail down to say 1:1000 scale (one meter to one millimeter), or even one to one, then the zooming power of MI (or any contemporary GIS program) will allow that degree of precision but will still hold the spatial relationships of even such microscopically large-scale data to the overall, worldwide coordinate system if that was used from the beginning. On the other hand, although the files holding reasonably complex 1:1m resolution data for places the size of China are quite large (the 1:1m boundaries of the 2,500 county-level administrative units of China occupy several Megabytes of disk space), they are not beyond the contemporary capabilities of normal personal computer hardware or software systems.
In fact, there is often too much detail at 1:1m resolution to produce attractive maps on standard (A4 or 8.5 by 11 inch) pages as, for instance, at that resolution the 1:1m detail of the southeast coast of China produces an ugly, thick blur of merged objects. Such overly detailed (for such purposes) digital cartography is easily and automatically simplifiable, if necessary, but to add more detail involves complex technical problems. ECAI should obtain low resolution versions of the DCW for continent sized base maps, and then implement an automatic zoom system that will bring up more and more detailed specific coverages as the screen scale is enlarged and data for the particular tiles are appropriate to display.
Deficiencies of the DCW
Unfortunately, the deficiencies of the DCW are legion. One is that the basic cartography is decades old, going as far back as WWII for at least some features in at least some places. The coast of China provides many examples, where Macao is still depicted as three separate islands instead of an artificially connected peninsula and the same sorts of problems exist for many parts of Hong Kong and Amoy, etc. The built-up areas of cities and even towns are of similar vintage, and the meagre selection of places represented does not necessarily represent contemporary significance. Canals, road and rail networks are also very outdated, while many even quite large contemporary reservoirs are not represented and the detail of the hydrological data in general is not great in comparison with some other 1:1m sources which have an order of magnitude more small streams. Contour intervals, following aeronautical practice, are in feet by thousands, apart from some supplemental ones at 250, 500, and 750 feet, whereas the international scientific community now operates in meters and there are places such as North China where far narrower intervals are required. Differences of land-cover are not well represented, and are also often of only historical interest by now in any event.
Standard DCW data are also not very easy to use, as the world is divided into hundreds and hundreds of 5 degree by 5 degree latitude/longitude grids that are arcanely coded. Each such 'tile' consists of dozens of separate spatial/attribute files containing particular features, often duplicating things (such as contours) in visually identical lines and polygons. <Note the cleaned-up and de-tiled version which comes free with Maptitude. This data can be easily exported to any other GIS. If you can afford it, it’s worth getting a copy of Maptitude just for this function alone>
There is a newly released, improved version of the DCW called VMAP0, but it mostly just fills in gaps in the original data, such as missing tiles in South America, and somewhat simplifies the data structure in terms of the annoying duplications, etc. However, it is presently available only in the US Government (military) Vector Product Format (VPF), and it will be so time consuming and therefore expensive to (re)produce MapInfo versions of the new version that ECAI cannot plan on using it. <without wishing to sound like a Maptitude salesman, Maptitude will read the new format CDs and export to just about any other format>
All in all, the bottom line is that there is no substitute for the DCW in MapInfo format (apart from such eventual improvements to it), despite its deficiencies, as available smaller scale data (usually 1:3m, like ArcWorld) are even worse, while larger scale data are either not available or not affordable for all of Asia, to say nothing of the world, and would be too voluminous to be practical if they were available. Where such data can be found, and are appropriate, nothing stops ECAI participants from using them provided that they know how to integrate them with DCW features, thus preserving the overall integrity of the ECAI databases, or appropriate technical support is available to help them accomplish that. However, the DCW should provide adequate resolution and detail of features for most ECAI-GIS purposes.
Administrative boundary data
One major deficiency of the DCW from the ECAI perspective not mentioned above is its lack of administrative boundaries below the ADM0, or international, level. In addition to the point locations of cities, towns, or archaeological sites, the polygons representing low-level administrative units, historical as well as contemporary, are perhaps the most salient spatial objects for ECAI purposes. The Australian Centre of the Asian Spatial Information and Analysis Network (ACASIAN) has for the past seven years or so specialised in producing administrative boundary GIS databases for most of Asia, and in addition to county-level (ADM3) data for China that incorporate all changes to the administrative system of the PRC from 1980 through 1996, also has rayon and gorsoviet (technically mostly ADM2, but equivalent to China's xian and shi) boundaries for the entire former Soviet Union as of the last census in 1989. ADM2 or ADM3 data are also available for all mainland Southeast Asian countries, plus the Philippines, as well as Mongolia and both Koreas. Work is near completion on similar data for all South Asian countries (apart from India, for which excellent commercial data are available) including Afghanistan and even Iran, while Turkey has also been completed. So, ACASIAN can soon supply ECAI with administrative boundary data for all of Asia apart from Israel, the Arab countries of the Near East, and Japan (otherwise available), while the Worldwide Map Consortium, in which ACASIAN participates, can add Oceania, Africa, Europe, and the Americas. Although such data cannot be supplied to ECAI without cost, ACASIAN at least is willing to negotiate very favorable terms for ECAI, and its Director is always willing to consider participating in collaborative activities such as the one planned with Thomas Hahn to geo-reference all of the local histories of China for the ECAI 'China Atlas'.
Other kinds of available data potentially relevant to ECAI-GIS
In the last several years various agencies, particularly those involved with the scientific 'global change community' have produced or are producing worldwide coverages of data derived from remote sensing, which in this context means satellite imagery or other observations. Although some of the older data sets are at scales/resolutions smaller than 1:1m, that is becoming the basic defacto standard, and, for instance, the Japanese government is promoting global thematic mapping at that scale, which generally equates to minimal resolutions of approximately one kilometer (or 30 arc seconds). Some results, such as the Global Ecosystems Database (produced by the World Data Center, NOAA), are available on CD-ROM but most others such as the DTED (Digital Terrain Elevation Data) and those for vegetation cover distributed by the EROS Data Center in Sioux Falls, SD, are mainly available on 9mm tape data cartridges. With few exceptions, such datasets require specialised and sometimes quite expensive software to access, and are not suitable for 'amateur' operation on PCs or Macs due to the enormous sizes and complexities of the files and the need to learn to operate the complicated software programs. <however, it is quite feasible for one or two suitably equipped labs to extract appropriate datasets for individual projects to use on PCs>[Indeed, see below.]
Problems with Raster Data
In addition, most such data sets are in raster, not vector, format. (A raster image is bit-mapped, like a fax, with variation in individual pixels, or minimal display units, constituting patterns that the human eye can discern. However, unlike an image generated from mathematically defined vectors, there is actually no more real structure to raster images than there is among grains of sand on a beach, apart from the order in which they are stored and displayed.) <one of the real problems with rasters is that they have an inherent projection which cannot be changed easily, so that it becomes difficult to overlay different datasets on one another>[without that expensive and complex software mentioned in the last paragraph and in the next sentence.] Most GIS and desktop mapping software, such as MapInfo, will handle geo-referenced and projected raster imagery, but specialised software programs are usually required to prepare them. A more fundamental drawback to raster data is that zooming is inherently limited by pixel size, so that at some point the individual square pixels become visible, and if they are each one kilometer square that is a severe limitation as more finely grained, local data cannot be included or combined in the same database as it can in a vector GIS. On the other hand, unless one has very powerful workstation computer hardware/software <a 1km raster satellite image of Asia is going to take up something like 50 Mbytes uncompressed>, continental scale raster images are usually produced by generalising the data in one way or another in order to produce even larger but fewer pixels.
Remote sensing is all raster based, which limits its utility for ECAI. Resolution of the more recent Landsat Thematic Mapper (TM) images is around 50 meters, which can be resampled to produce minimal pixels of around 30 meters, while the French Spot <monochrome> images have 10 meter resolution. How wonderful, as one can even discern individual houses and terraced rice paddies at such fine resolutions (some military satellite images would allow one to count fence posts). However, at the equivalent of 1:100,000 scale, the pixels in Landsat images become visible, and annoying. In addition, file sizes and costs multiply inversely with resolution, so producing country scale, let alone continental scale, satellite coverages requires the resources of governments, not communities of like-minded scholars. Although some individual research projects could well make good use of 'local' satellite images, they require skilled if not professional interpretation, which often involves producing vector representations of features of interest. In addition, either the original raster images or the interpreted vectors still need to be integrated into whatever base-map framework ECAI-GIS will employ before they will be useful.
Technical support required for ECAI-GIS
If ECAI is to adopt a standard GIS-based approach to organising its databases, some central technical support facility will be required. Most large universities have some kind of GIS facility these days, and often even more than one. However, the more sophisticated and elaborate those facilities are, the less likely that their staff will be interested in supporting the use of MapInfo by scholars in the humanities and social sciences who do not have a computer science background <this is a VERY good point. Beware the GIS expert - they will try and sell you on the idea of using Arc/Info>. In the exceptional cases where such help might be readily available at affordable costs, there would still be problems of overall ECAI-GIS systemization and integration. Therefore, if ECAI is to formally adopt GIS as its basic technology for organising spatial data (and there would seem to be no available alternative), some central facility will be needed to provide at least the following technical functions in addition to normal, ongoing support:
1. Basic design of the ECAI-GIS database framework. Although the adoption of MapInfo, the DCW, and ACASIAN administrative boundaries simplifies many database design issues, there are still many decision to be made to establish procedures and techniques that all ECAI-GIS participants should adopt in order to produce overall coherence and compatibility. That is as necessary for the organisation of attribute data (information about spatial objects) as it is for the spatial data themselves. A sophisticated ECAI-GIS database design would allow for spatio-temporal relations and changes, a subject too complex and technical to elaborate on in this context, apart from what is covered in the next point.
2. Establishing systematic coding systems to link spatial and attribute data is an important central database design function. It deserves special mention because an adequate coding system will have temporal aspects that will allow historical entities that are not (or are no longer) included in the official coding systems (if any) used by national governments (like China's Guobiao Administrative Codes), which should always be employed if available and used as the basis for additional historical coding systems. 'Official' ECAI-GIS coding systems for countries and historical periods will go a long way to eliminate problems that would otherwise arise from variant spellings and orthographies, alternative names, and different languages.
3. Producing, distributing, and maintaining a base map framework, for Eurasia at least. In this proposal for ECAI-GIS, this would be based on the DCW PONET (Political and Ocean) data, with corrections and modifications as required (for Macao, for instance). Selected topographical and hydrological features (perhaps simplified greatly, as for mountain ranges) would be provided as separate MI files as part of the base map and for use in producing maps for publication. A DCW tile, grid would be included as a key to the additional full data coverages that are available to be called up in the background.
5. Supporting the incorporation of additional spatial features in ways compatible with the overall ECAI-GIS database design. Objects that ECAI-GIS data bases need to include from the outset are best created by its central facility. However, many participants will want to add their own spatial objects as well as specialized attribute data. MapInfo (MI) makes the addition of point features very easy, and individual participants should have no difficulty in mastering this although they should do it in the standard ways, particularly with respect to their coding. Line objects are somewhat more complex, particularly if they need to precisely join other features. Adding, deleting, or modifying polygon features are another matter entirely in MI, and in fact this should normally be done using a CAD (Computer Aided Drafting, or Design, software program such as MicroStation or AutoCAD) rather than in MI itself, although there are add-on utilities that make such operations far easier than in MI alone. The technicalities involved go way beyond basic issues of original map scales and projections to arcane technical problems such as sliver polygons, as gaps or overlaps between adjacent polygons are called, to such things as 'bleeding' polygons and dangling nodes. Alignment and rubber sheeting of additional data so that it fits seamlessly with existing features is not a simple or straightforward task, either. The integration of additional complex spatial objects from paper maps into the ECAI-GIS data bases should usually be left to the central technical facility, which can advise participants on how to prepare such materials in order to facilitate the work (ideally they should be drawn by participants on paper versions of the base map materials).
6. The technical support facility would also be able to provide ECAI-GIS participants with raster files, such as satellite images and extracts from things like the large EDC datasets that would fit the projections and local areas of the base maps that they were working on.
7. Participants would be supported in making their data available in standard ECAI-GIS formats on CD-ROMs and over the Internet.
Costs of an ECAI-GIS central technical support facility
A central ECAI-GIS technical support facility could probably be equipped from scratch with essential hardware and software for something in the neighborhood of $50,000 at the present time. However, there would be annual maintenance costs of $5- 10,000 in subsequent years. Those costs are actually minor in comparison with the salary costs of the personnel who would be required to maintain and operate the equipment and programs, which would be at least $50,000 and probably more like $100,000 per year. Rather than operate its own central facility, ECAI-GIS would be far better off to associate with an established GIS operation that was prepared to contract to provide functions such as those listed above.
Equipment and training required by ECAI-GIS participants
Unlike the central technical support facility, the equipment needs of ordinary ECAI-GIS participants are so modest that nowadays most academics would already have what is required. A pentium PC with lots of RAM and a large hard disk is now the standard entry-level machine, but even an old 386 (remember them?) or 486 can usually be upgraded with a new 586 or better motherboard, 32 Mb of RAM, and a 1 Gb Hard Disk for less than $1,000. Macs are not so readily upgradable, but powerful Mac clones are now available too. A high quality 15" or especially 17" screen is nice to display the graphics on but is not absolutely essential, while color bubblejet or inkjet printers are now cheap. The only other item of equipment that someone needing to input their own point or line objects would probably require (although it can be done entirely on screen relative to base map features) would be a small (12" by 18") digitising tablet, which cost under $400. A scanner with OCR software might or might not be helpful in capturing attribute data, but would be useless for generating new spatial data in conjunction with MapInfo alone.
Training in using MapInfo is readily available from MI suppliers on frequent schedules at a cost that can be as high as $500 per day but is usually less expensive. Short courses can also be found at some universities at very low or no cost. Five days of quality training is both desirable and sufficient. <Commercial break: The Sydney University Archaeological Computing Laboratory puts on occasional MapInfo courses and publishes a user-friendly book on MapInfo "Understanding MapInfo", which is adequate for most people to use MapInfo effectively without training.>[Ian showed me his book in Taipei, and I certainly agree that it is much more helpful and user-friendly than the MapInfo manuals, which are themselves a model of simplicity and clarity in comparison with the documentation for ARC/INFO and ArcView, to say nothing of Intergraph’s MGE!]
Outputting, distributing, and accessing ECAI-GIS data
Participants in ECAI-GIS who have had some MapInfo training will have no difficulty in preparing whatever maps the databases, including their own individual data, will support. Ease of producing good looking choropleth thematic maps is in fact one of the great strengths of MI in comparison with many other GIS products, as is its support for placing names or other text. Such maps can be output either as paper versions through standard printers or in the form of raster files. This is in fact the major role for raster images in ECAI-GIS, as such bit-mapped images can be transferred to practically any graphics or desktop publishing program for further manipulation for publication, or transformed into HTML 'clickable' on-screen maps using a number of semi-automated programs that have become available in recent years and months.
Public distribution of ECAI data on CD-ROMs and over the Internet could (and perhaps should) be limited to such derivative raster images, which need no special GIS software like MapInfo to display or explore through clickable features and regions, as only standard Netscape or Explorer are required. In other words, access to the ECAI-GIS databases themselves could be limited to bone fide participants, however they are selected, while all the features of HTML and Java aplets could be utilised in the public distribution of prepared 'views' of the underlying, and restricted, data themselves.
Software that will allow remote interactive searches of GIS spatial and attribute data to produce on-line output are becoming available, but the programs are and probably will remain rather expensive (in the neighborhood of $20,000). The ECAI-GIS technical support facility could acquire and operate such software, allowing public access to the GIS databases themselves, but careful consideration would need to be given to the desirability as well as the expense of doing that.
If ECAI-GIS is to grow out of the present ECAI, a number of organizational issues will need to be addressed and solved. Funding will be required, at a significant on-going level, to provide the central technical support functions. Some form of governance will need to be established to obtain and manage the funding. Potential additional participants will need to be identified and convinced of the benefits of contributing their work to the Initiative, and those applying for participant status will need to be vetted and accepted or rejected. Decisions will need to be made concerning how public access to the ECAI-GIS data bases will be controlled. Experience in organizing and directing the Spatial Information Infrastructure for Asian Studies in Australia (SIIASA) suggests that the simplest possible form of governance that can accomplish those functions will be the best.