GIS tools fall into one of two categories: general-purpose or specific-purpose.

General purpose GIS tools are programs such as ARC/INFO and ArcView, which have extensive functionality and
can be difficult for users unfamiliar with GIS to learn.
Specific-purpose GIS tools are programs that are written by a GIS programmer to provide a user group with very
specific functions in an easy to use package. In the past, specific-purpose GIS tools were written primarily using a
macro language such as Avenue (ArcView's macro language) or AML (ARC/INFO's macro language). This method of
delivering specific-purpose GIS tools requires that each user have a copy of the host program (ARC/INFO or
ArcView) to run the macro language application.
GIS programmers now have a far richer set of tools for application development. Programming libraries with classes
for interactive mapping and spatial analysis functions have made it possible to develop specific-purpose GIS tools
using industry-standard programming languages that can be compiled and run without a host program (stand-alone).
Internet development tools have matured as well, making it possible to develop fairly complex GIS-based programs
that users can use through the World Wide Web. The UMESC programmers make extensive use of these
development tools and actively search out new and emerging tools and techniques to get the right product in the
hands of the decision-makers at the right time.
Spatial decision support systems (SDSS) are designed to help decision-makers solve complex spatial problems.
Through closely coupling analytical models SDSS overcome the GISystem limitationss for tackling complex, illdefined, spatial decision problems.
Internet-based decision support systems can increase public access and involvement in decision-making. The rise of
the Internet and the World Wide Web (WWW) has created many opportunities for increased involvement in GIS and
decision support research. Internet technology has been widely used for application development because of
advantages such as platform independence, reductions in distribution costs and maintenance problems, ease of use,
ubiquitous access and sharing of information by the worldwide user community. There is now increased interest in
pursuing the development of SDSS on the web to support better decision-making and policy formulation.
The design of the online SDSS is based on a three-tier client/server architecture, which consists of three well-defined
and separate processes each running on a different platform. The front-end tier is the client - the end user interface that runs on the end users computer. The middle tier is the application server - the functional modules that actually
process data - that runs on a server, or rather two servers - a web server (Microsoft Internet Information Server (IIS)
and a www-based GIS server (ESRI Mapobjects Internet Map Server (Mapobjects IMS)). IIS allows communication
and transfers data between the client side (Web browser) and the Mapobjects IMS. Sockets (a common TCP/IP
protocol) are used to pass messages between IIS and Mapobjects IMS. The third tier is the database server - a
database management system (DBMS) that stores the data required by the middle tier, which runs on a second
server. In this system, the client is the computer at your desk. The client displays information from the server using a
web browser. The application server is a powerful centralized system that performs complex calculations and
analysis. Microsofts object-oriented program language - Visual Basic (VB) 6.0, ESRI Mapobjects 2.1 and ESRI
Mapobjects IMS 2.0 is used to develop these application programs. The Database server stores the data as records
in a relational database and performs database manipulations. A relational database - Oracle - is used as the nonspatial database. The interaction within the web system takes place using two protocols: TCP/IP, HTTP. The
communication between the application server and database server is through ODBC (Open Database
Connectivity).

Figure 3. The three-tier client/server architecture

A typical SDSS has four components: analytical tools enabling data investigation; decision models enabling "whatif"/scenario investigations; a geographic/spatial database; and a user interface providing easy access to decision
models, databases, analytical tools, and an attractive and comprehensive display of the output (Densham, 1991).
The following sections present the architecture of the SDSS system and detail how to build on these four
components.
This requires full use of WebGIS techniques. WebGIS is Internet-based GIS, which inherits the advantages of
traditional GIS in vivid spatial information display, retrieval and analysis functions, and incorporates the advantages
of an Internet-based information system of easy access, easy use, quick communication for multiple users and low
price. A WebGIS-based spatial analysis system is especially suitable for online and group spatial decision-making.
The aim of the system functions will be: (1) display conservation background information, (2) allow users to query the
information, (3) run the model to provide results.
The SDSS will be run on a Web Server. Any user can access the system at anytime by the standard Internet
addressing system. The Web Server can dynamically accept the users input data and send feedback to the user.
Microsofts object-oriented program language - Visual Basic (VB) 6.0, ESRI Mapobjects 2.1 and ESRI Mapobjects
IMS 2.0 is used to develop this application.
The system has three main functions: (1) Online Mapping - the user can zoom in and out, and can pan the map via
Internet; (2) Online spatial information query - the system provides the functions of query from map to attribute; (3)
Online multi-criteria analysis - via the developed model the user can determine the location of critical conservation
areas.
Based on the ER model, the relational database for the system is constructed, to include both the spatial database
and the non-spatial attribute database. Compiling the database can be done in several ways, for example through
digitizing existing maps, and by extracting information from remote sensing images, such as air photos and satellite
images. We use an Ikonos satellite image as the basis for the land use map in this research. In addition, it is possible
to download digitized data from the Internet and to obtain digitized information from other sources. At this preliminary
stage, much information is still necessary and the database is under construction.

Since the system is a web-based SDSS, the first important design principle is that information should be structured in
ways that allow for connection, interaction and interference. The second important design principle is simplicity; since
the end users are policy decision-makers or members of the public who cannot be assumed to possess extensive
computer knowledge, the system interface needs to be easy to understand and use. Users need simply to input
some values in text box or click some buttons in order to access the final result map. This is a characteristic of the
Spatial Decision Support System, in which JavaScript, HTML is used to develop the client user interface (Figure 6).
Analytical tools, such as zoom in, zoom out, pan and query, were developed to help the end user analyze the
background information about the landscape. The overall communication between the client and the server is as
follows. On the client side, the user interacts with the web interface. The web servers Esrimap.dll receives the users
request from the browser in the form of extended URLs, and interprets and passes that information to the Visual
Basic application program. The VB application program performs the model calculation, GIS and database
processing. After data processing, the VB application program uses a socket to return the results of the request in
the form of images and text information to the Esrimap.dll. Finally, the Esrimap.dll passes the results to the users
web browser through html format. The web browser displays the map result and other information to the end-user.
Web-based mapping isn't the same as GIS/desktop mapping!
A major error in selecting a Web mapping solution is in the implicit view that Web mapping is simply an extension of
existing enterprise GIS/desktop mapping activities; this is not the case. Web mapping solutions are directed at a
different audience than GIS/desktop mapping packages. The level of expertise required, training to be expected and
intensity of involvement are much different. This is a key distinction, and Web mapping developers need to keep the
user base's characteristics in mind if a site is to meet its goals.
It all happens together.
One of the more confusing aspects to selecting the best Web mapping product is that everything is interlocked. For
example, the speed of the Internet connection affects the amount of data transferred; the type of data also affects
transfer volumes, which, in turn, also influences the speed, etc.
In addition, everything is rapidly changing. The capabilities of many Web mapping products in 1999 are different from
those available just last year. In the following paragraphs, I look at the various parts separately, but talk about how
they affect each other.
What do you want to do?
Before going too far, it's essential to decide a site's purpose and audience. Do you want to simply display a static
map and let users pan and zoom, or do you want to allow users to define an area on a map to generate complex
reports and new maps? Do you want to provide maps or spatial data (they're different)? Do you want users to be
able to access local data along with your data, or do you want to ensure that your data are secure and can only be
viewed--not used or "stolen?" Do you have a lot of corporate database data that just need to be spatially
represented, or are you trying to perform complex geographic analyses? Are all your users linked through a highspeed intranet, or do you plan to serve maps to the world, including users at the end of telephone lines with 28.8K
modems attached? Are your users a well-defined small part of your corporation, or do you plan to open your site to a
global Internet audience?
All these options (and more) are possible. But they're not all possible with every software package available.
What's the speed and extent of client/map interactivity?
A key selection criteria revolves around the complex interaction of Web performance, data complexity and the extent
of interaction users will have. The following is an example: There's a map in a Web browser, and a user wants to
zoom into a selected portion. It seems simple enough, but there are two radically different strategies with different

implications. One approach is the "image map," in which the Web server creates a simple image (usually a JPEG or
GIF) and ships it to a browser. If the user wants to zoom in, he or she would click an icon on that said "zoom in,"
which would lead to a command to the server to redraw the image map using only half the map area. Other options
may include first clicking on a point on the image (the X and Y coordinates of the click are stored) and then clicking
on "zoom in." In this case, the zoom is centered on the location selected.

Bentley's ModelServer Discovery software is used by the Grested Gilleleje kommune

http://discovery.bentley.com/demos/ggk/mainmenu_us.htm to provide access to community data.
An alternative approach involves having a certain amount of user capacity at the client. This capacity ranges from
having users obtain full, but lightweight, applications or browser plug-ins, or sending Java applets to the browser.
Although there are exceptions, greater user interactivity means more functionality must be included in either the
plug-in or Java applet, increasing their size and the time it takes to download them.
Plug-ins vs. image maps vs. Java applets.
User interactivity is an important factor that needs to be given considerable thought. The basic trade-off is time and
when it's spent. An image map generally is fairly small and can be downloaded quickly after it's produced. Thus, the
first image sent to a user will be delivered quickly. Further interaction requires the client to send information to the
server, and a new map is generated and resent. Although transmission time is short, all image/map interaction
places a demand on the server and may lead to excessive volumes, which lead to slow response times. In addition,
the results of any interaction aren't known until the map is redrawn, and it's not unusual for many interactions to be
required before the desired map is displayed.
In contrast, if an applet or plug-in is used, the first download will be relatively lengthy. Map-browser plug-ins generally
are about 2MB in size, resulting in a fairly lengthy download if a slow modem is used. Conversely, if the application is
for a corporate intranet with all systems centrally administered, then each user already will have the client installed.
Java applets generally are more modest in size than plug-ins, but they have to be downloaded each time users
access the mapping site.
A related performance factor is that many plug-ins (and now Java applets) allow servers to ship more complex data
to the client than just simple image maps. Several vendors now have mapping solutions that ship "smart" vector data
to the plug-in/Java applet, allowing clients to zoom and pan data, and interrogate maps for attributes or other
content. Also, users may be able to locally modify display parameters, but this is a good news/bad news issue.
Increased local interaction means less Internet traffic and faster response for local operations. Conversely, the
amount of data downloaded may be substantial, resulting in long download times.
Another factor to be considered when assessing local interactivity is the degree local users may want to meld
information delivered from the map server with local data. Several map servers now allow local data to be brought
into a map browser. Such a situation may be desirable when local corporate data are compared to data from external
data providers, such as overlaying local company data on potential store locations with up-to-date demographic data
distributed from the U.S. Census Bureau or other online providers.
Maps vs. data, and data distribution vs. map distribution.

Many (but not all) map servers that download data to the client also allow the data to be captured locally. In this
situation, users can browse data interactively and then select a "local save." This may not be desirable in some
settings. For example, data may be proprietary. In such situations, many servers permit the data to be viewed but not
saved locally. Some servers even encrypt the data so that they can't be captured--even with reverse engineering.
Data distribution is a relatively new capability for Web mapping systems, creating a set of important new
opportunities. As a general rule, systems that "stream" or ship data to a browser allow local data saves, but this isn't
always true. Some image-mapping options also now allow a data download operation. In these cases, the data are
extracted on the server, packaged (usually in a ZIP file) and "FTPed" to the local client.
Spatial Decision Support Systems: (SDSS) :
Decision support systems are computer programs that are designed to bring the whole of the knowledge base to
bear on a problem. This is achieved by providing a flexible and adaptive solution system that makes explicit use of
both the analyst's models and the decision-maker's expert knowledge. Here, the objective is to support (rather than
replace), judgement in such a manner that the strengths of both man and machine processes will be utilised to the
fullest. Such systems create supportive tools under the control of users without automating the total decision
process, predefining objectives, or imposing solutions.
A DSS is designed to support semi-structured (a class of problems for which no automatic algorithm exists)
decision-making tasks. The solution procedure consists of evaluating alternatives to find a good solution as
opposed to the optimum solution.
A DSS provides three subsystems:
Knowledge System - containing data and data manipulation procedures;
Language System - the user interface;
Problem Processing System - to interface models and data
The objectives of any DSS can be put as to :
Assist managers in their decision processes in semi-structured tasks.
Improve the effectiveness of decision-making rather than its efficiency.
They are used to tackle ill or semi-structured problems.
They are designed to be easy to use through a user-friendly front end.
They reach to solution adaptively.
They are designed to enable the user to make full use of all the data and models that are available
through interfacing routines and database management systems.
The user develops a solution procedure using the models as decision aids to generate a series of
alternatives. (Scenarios)
They make explicit use of decision makers expert knowledge.
They support a decision maker but does not replace.
They are suitable for a class of problems where there is no automatic algorithm.