\title{Automatic Generation of Web-Based GIS/Database Applications}
\author{Nirut Chalainanont, Junya Sano and Toshimi Minoura}

\maketitle

\section{Abstract}
\label{sec:Abstract}

We have been developing \emph{web-based GIS/database} (WebGD) applications that allow users to \emph{insert}, \emph{query}, \emph{update}, and \emph{delete geographical features} and the data associated with them from standard Web browsers.  The code shared by these applications is organized as the WebGD framework.  The behavior of the map interface of a WebGD application is defined by \emph{configuration files}.  We have built also the WebGD application generator (WebGD-Gen) that \emph{automatically} produces those configuration files from the database metadata, including those in tables \nohyphens{\texttt{geometry\_columns} and \texttt{spatial\_ref\_sys}}.  WebGD-Gen can generate also Web scripts that interact with the map interface and the database.  Thus the WebGD framework and WebGD-Gen can significantly reduce the development time and the maintenance cost of a complex Web-based GIS/database application.	


\section{Introduction}
\label{sec:Introduction}

The Internet has become the major venue for sharing information.  A dynamic Web-based mapping application allows users without desktop-based GIS software to perform \emph{spatial queries} and produce maps with standard Web browsers.

However, a typical web-based GIS application allows only the retrieval of maps and map-related data.  A web server provides information to the client, but the client cannot feed information back to the server \citep{Kingston:1998}.  This \emph{unidirectional} flow of information is a major problem with a current typical map-server application.  Furthermore, creating an interactive web application with a map interface is time-consuming.  Commercial map servers and geographical database management systems are expensive.  This situation hinders use of Web-based GIS applications in data gathering, analysis and decision-making.

We have been developing a set of tools that significantly reduces the cost of application development \cite{Wangmutitakul et al.:2003,Wuttiwat et al.:2003,Sano et al.:2003,Wangmutitakul et al.:2004}.  The code shared by interactive Internet GIS applications is organized as the Web-based GIS/database (WebGD) framework.  Most of the complex workings for delivering GIS functions over the Web are included in this framework.  With the WebGD framework, we can create a map interface through which users can \emph{insert, query}, and \emph{delete} geographical features and the data associated with them only by providing \emph{configuration files}.

An important feature of a WebGD application is that it tightly integrates spatial data and associated tabular data, enabling analyses involving location-based data \cite{Sharma:2003}.  These functions are available to users at different geographical locations for economical and timely data management.

We developed several years ago a \emph{Web-form generator} that automatically generates scripts for traditional Web-forms from the \emph{schema} of a relational database \cite{Eum et al.:2003}.  This functionality was recently extended as the WebGD application generator (WebGD-Gen).  The new application generator can produce most of the code for an entire \nohyphens{WebGD} application from the schema of a relational database and the information on \emph{geometry columns}.  With the map interface and the Web scripts automatically generated, geographical features (i.e., points, linestrings and polygons) can be \emph{inserted}, \emph{queried}, and \emph{deleted}.  Thus, when a relational schema and the GIS metadata for the map layers are available, a \emph{non-customized} application can be quickly assembled with the WebGD framework and the WebGD-Gen application generator.

The automatic generation of the map interface and Web-form scripts make possible \emph{incremental} and \emph{iterative} development of complex web-based GIS applications.  When a map layer is added or modified, we only need to create or update the configuration file for that layer and then regenerate the Web forms for that layer.  When a database schema is modified, we can regenerate the entire set of Web scripts in several minutes.  Therefore, even with an incomplete set of map layers and a database schema, we can generate a working prototype for an initial review.  Furthermore, we can fix most of the software bugs by modifying only the shared code in the WebGD framework or WebGD-Gen and then by regenerating Web scripts for each application.

WebGD applications use the following \emph{open-source} software components.  PostgreSQL, an \emph{object-relational} database, and PostGIS together manage geospatial data.  PostGIS is an extension of PostgreSQL for GIS applications \cite{Ramsey}.  MapServer \cite{UnivOfMinnesota} generates maps to be displayed on a web browser by using geospatial data provided by PostGIS.  Web pages, including the one that displays the maps, are generated by server-side scripts written in PHP.  The PHP MapScript module interacts with MapServer \cite{McKenna,DMSolutions}.  When a request to insert or delete a map feature is received by a PHP script, the script directly accesses the PostgreSQL database, using the PostGIS extension.  An application developed runs on a PC without any licensed software.

We explain the features supported by the WebGD framework in Section \textbf{WebGD Applications}.  The process of generating map-layer configuration files is explained in Section \textbf{WebGD Framework}, and that of generating Web scripts in Section \ref{sec:AutomaticGenerationOfWebFormScripts}.  The process of automatic generation of map-layer configuration files is explained in Section \textbf{Automatic Generation of Map-Layer Configuration Files}.  In Section \textbf{WebGD Development History}, we describe a brief history of the development of the WebGD framework and WebGD-Gen.  Section \textbf{Conclusions and FutureWork} concludes this paper.

\section{WebGD Applications}
\label{sec:WebGD_Applications}

The Web interface of one of the WebGD applications, Natural Heritage Information System (NHIS) for North Carolina, is shown in Figure \ref{fig:NHIS_App}.  This application provides a map interface for a copy of the Biotics 4.0 database maintained by the North Carolina Natural Heritage Program.  Biotics 4.0 is a desktop GIS application built on the database developed by NatureServe.  The key elements in this database are \emph{element occurrences} (EOs), which are \emph{areas} of land and/or water in which species are, or were present \cite{NatureServe:2002}.  EO records have both \emph{spatial} and \emph{tabular} data, and the database contain approximately 700 relational tables \cite{Fogelsong:2002}.  The Biotics Mapper implemented with ArcView by NatureServe provides a map interface that allows EO representations and associated data to be created, updated, and deleted \cite{NatureServe:2003}.  In our implementation, we can perform these operations with standard Web browsers.  Also, Web forms, approximately 3500 in total, are provided for all tables in the database.

\begin{figure*}[htbp]
\centering
\includegraphics[width=.8\textwidth]{proceedings/minoura/NHIS_App.png}
\caption{Interface of the NHIS Application for North Carolina}
\label{fig:NHIS_App}
\end{figure*}


The NHIS application enables \emph{bi-directional} movement of \emph{geospatial data} as well as ordinary data.  Scientists and others with proper authentication can \emph{insert}, \emph{query}, and \emph{delete} geographical features such as EO polygons, lines, and points, as well as the data associated with them.  Queries can be executed by spatially \emph{selecting an area} on the map or by using a traditional web form.  In addition, one-meter resolution \emph{digital orthographic quadrangles} {DOQ}, or aerial images, are included as a layer.  When DOQ images are combined with other map layers such as highways, county boundaries, streams, and streets, locations can be easily pinpointed by taking advantage of features between map layers \cite{Wuttiwat et al.:2003}.

The major operations supported by the map interface of a WebGD application are as follows:

\begin{enumerate}
\item To retrieve information on the geographical features in the area of interest, the user can zoom in/out to that area by using the map navigation tools.  If the user zoom-in enough, one-meter resolution aerial photos are displayed.  The user can also go to a new area by selecting an entry in the \textbf{Quick View} menu.
\item To get information about a geographical feature, the user can select a layer in the legend and \textbf{Information} in the function menu, and then click the boundary of the feature.
\item Function \textbf{Insert} allows a geographical feature to be added with mouse clicks on the map.  \textbf{Done} need be pressed after all points are entered.
\item Function \textbf{Search by Area} allows the user to retrieve the list of features that are within a \emph{bounding box} specified on the map and that satisfy a search condition.  The features that satisfy the search condition are \emph{highlighted} on the map.  Furthermore, the user can select features in the list by marking the checkboxes associated with them.  Then, if the map is refreshed, the selected features are highlighted.
\item The data administration interface can be activated by clicking on the \textbf{Database} entry in the menu bar below the banner.  A tree icon can be clicked to display a \emph{treeview} for browsing.  The treeview for \textbf{Higher Taxonomy} is the major one.  To access the data of this application, a user must login with a password as some data on endangered species are confidential.  
\end{enumerate}

\noindent Several WebGD applications created with the WebGD framework and WebGD-Gen 
can be accessed from this page.\footnote{WebGD sample applications: \url{http://yukon.een.orst.edu/index_webgd.html}  You may insert/query/update/delete data.  However, please DO NOT disturb existing data.  If login is required, use user name \texttt{cs540} and password \texttt{CSxyz540}.  You may have to login twice, once for the server and then for an application.}

The first application is Natural Heritage Information System.  Although this application can cover the whole USA or the world, the data are currently available only for North Carolina.  The second application provides a map interface for an application that keeps track of conservation practices on land parcels.  The third one is a Web-based mapping application for plant germplasm collection maintained at Western Regional Plant Introduction Station (USDA-ARS).  The fourth one allows the soil information at the location where a mouse click occurs on the map interface to be retrieved.

One salient feature of the current WebGD framework is \emph{dynamic switching of spatial references}.  Typically, different geographic regions and localities have preferred \emph{map projections} in order to avoid distortions in the maps created \cite{Dana}.  The framework allows the whole world to be covered with multiple-levels of maps, e.g., the world map, continent maps, and region maps.  The map interface then automatically selects the most suitable projection for the region whose portion is displayed.  For example, the world can use the \emph{geographical coordinate system}, the United States the \emph{Albers equal-area projection}, and Oregon the \emph{Lambert conformal conic projection}.  Thus, spatial analysis can be performed with the most appropriate projection for a particular area.  The \emph{dynamic switching} of the \emph{spatial reference}, the \emph{map file}, the \emph{legend}, and the \emph{quick view menu} supported by the current WebGD framework allows any part of the world to be covered with its own scale and spatial reference, including regions with one-meter resolution aerial images.  This is a very important feature, especially now that the cost of storing aerial images for the entire US has dropped to affordable levels (10 terabytes needed to store aerial images for the entire US now cost around \$10,000).  Furthermore, many states are putting aerial images in the public domain.


\section{WebGD Framework}
\label{sec:WebGD_Framework}

The WebGD framework supports common features required by the map interface of a WebGD application such as zoom in/out, pan, and insert/query/update/delete operations of geographical features.  The organization of a WebGD application is shown in Figure \ref{fig:Organization}.

\begin{figure*}[htbp]
\centering
\includegraphics[width=.8\textwidth]{proceedings/minoura/Organisation.png}
\caption{Organization of a WebGD Application}
\label{fig:Organization}
\end{figure*}

A map operation that does not manipulate geometry features, e.g., \emph{zoom-in}, \emph{zoom-out}, or \emph{panning}, is processed as follows:

\begin{enumerate}
\item The user action on the map is transmitted from the Web browser to the Web server as an HTTP GET request.
\item The Web server activates a PHP script that handles the user action.
\item Inside the PHP script, various methods in PHP MapScript are called to prepare the new map parameters, such as the special reference and the extent of the map and the names of the layers to be displayed.  The map drawing method in PHP MapScript is then called to instruct the MapServer to create the map image.
\item The MapServer requests data for the map layers whose data are stored in the PostgreSQL database.
\item The data for the layers are returned.
\item The map image created is returned to the PHP script.
\item The HTML page generated by the PHP script is returned to the Web server.
\item The Web server transmits the HTML page including the new map image to the Web browser.
\end{enumerate}

For a map operation that accesses or manipulates geometry features, i.e., \emph{search by area}, \emph{insert}, or \emph{move point}, is processed as explained above, except between steps 2 and 3 the following operations are performed.

\begin{enumerate}
\item[a] The PHP script connects to the PostgreSQL database to perform a spatial operation with PostGIS-enabled SQL statements.
\item[b] The result of the spatial operation is returned to the PHP script by the SQL statements.
\end{enumerate}

Furthermore, \emph{configuration files} are user extensively as part of the WebGD framework for application customization.  Major configuration files are \emph{region configuration files}, \emph{map layer configuration files}, and a \emph{quick view configuration file}.

\subsection{Region Configuration Files}
\label{subsec:Region_Configuration_Files}

In order to minimize map distortion, different map areas can be displayed with different spatial references.  The \emph{current region} is determined to be the \emph{smallest} one that encompass the extent of the map to be generated.  The \emph{spatial reference} is then automatically switched to that of the new region.  Then the layers in the map legend, the list of the map-navigation and data-manipulation commands, and the \emph{quick view} list are reconfigured for the new region.  These reconfigurations are necessary because different regions may require different sets of map layers, command, and quick view list.

A \emph{region configuration file} for each map region includes the following definitions:

\begin{enumerate}
\item the special reference for the region,
\item the \emph{name of the region} displayed on the map interface,
\item the \emph{unit of distance measurement},
\item the \emph{name of the map layer configuration file} for the region, and
\item the \emph{name of the quick view configuration file}.
\end{enumerate}

For example, the region configuration file for the world is as follows:

\begin{footnotesize}
\begin{verbatim}
$region = array(
   "gid" => 1,
   "name" => "world",
   "display_name => "World",
   "srid" => 4326,
   "rank" => 1,
   "units" => "MS_DD",
   "mapfile" => "gmap75_world.map",
   "quickview" => "world_gview.php",
   "legend" => "world_maplayers.php",
   "proj4text" => "+proj=longlat +ellps=WGS84 
         +datum=WGS84"
);
\end{verbatim}
\end{footnotesize}

The following options can be specified in a configuration file:

\begin{description}
\item [gid] -- the unique number assigned to each region, which is the primary key value of the row representing the region in table \texttt{regions} in the database.
\item [name] -- the name of the region for programming.
\item [display\_name] -- the name of the region used on the map interface.  This name may include capital letters, white spaces, and other punctuation marks.
\item [srid] -- the \emph{spatial reference identifier} for the map projection assigned with this region.
\item [rank] -- the priority number used in determining the region for the map area to be viewed.  The region with the highest rank number is selected among the regions that completely encompass the map area to be viewed.  Regions with higher rank numbers cover smaller areas.
\item [units] -- the unit of measurement associated with the region.
\item [mapfile] -- the map file to be loaded when this region is selected.
\item [quickview] -- the name of the quick view configuration file for the region.
\item [legend] -- the name of the map layer configuration file for the region.
\item [proj4text] -- the projection string used for the region.
\end{description}

Whenever the map region changes due to a user action on the map interface, the region configuration file for the new region is loaded dynamically.  Then the map interface is customized according to the new region configuration file.

The region configuration file for Oregon, for example, contains the following definitions:

\begin{footnotesize}
\begin{verbatim}
$region = array(
   "gid" => 150137,
   "name" => "oregon",
   "display_name" => "Oregon",
   "srid" => 6010,
   "rank" => 150137,
   "units" => "MS_FEET",
   "mapfile" => "gmap75_oregon.map",
   "quickview" => "oregon_gview.php",
   "legend" => "oregon_maplayers.php",
   "proj4text" => "+proj=lcc +lat_1=43.0
         +lat_2=45.5 +lat_0=41.75 
         +lon_0=-120.5 
         +x_0=400000.00000 +y_0=0.0"
);
\end{verbatim}
\end{footnotesize}

\subsection{Map Layer Configuration Files}
\label{sec:MapLayerConfigurationFiles}

The \emph{map layer configuration file} provided for a region specifies the layers to be included in the legend and their characteristics.  It is possible for multiple map regions to share one map layer configuration file.

The map layer configuration file for the Oregon region, for example, contains the following definitions:

\begin{footnotesize}
\begin{verbatim}
$layer_groups = array (
  'grp_eo_py' => array(
     'geom_type' => 'polygon',
     'table' => 'eo_py',
     'layer_selectable' => true,
     'gid_column' => 'gid',
     'geom_col' => 'the_geom',
     'legend_label' => 'EO Polygons',
     'search_script' => 
     	'forms/eo/eo_py_eo_search.phtml',
     'select_script' => 
     	'forms/eo/eo_py_eo_select.phtml',
     'edit_script' => 
     	'forms/eo/eo_py_edit.phtml',
     'normal_layer' => 'eo_py',
     'searched_layer' => 'eo_py_searched',
     'checked_layer' => 'eo_py_checked',
     'selected_layer' => 'eo_py_selected',
     'img_src' => 'images/eo_poly.png',
     'img_width' => 26,
     'img_height' => 26,
     'onclick' => 'activate_layer("grp_eo_py")',
     'data_srid' => 32119
  ),     
  'grp_eosrc_pt' => array(
     'geom_type' => 'point', 
     'table' => 'eosrc_pt', 
     'layer_selectable' => true,
     'gid_column' => 'gid',
     'geom_col' => 'the_geom', 
     'legend_label' => 'EOSRC Points', 
     'search_script' => 
     	'forms/eo/eosrc_pt_search.phtml',
     'select_script' => 
     	'forms/eo/eosrc_pt_select.phtml',
     'edit_script' => 
     	'forms/eo/eosrc_pt_edit.phtml',
     'normal_layer' => 'eosrc_pt',
     'searched_layer' => 'eosrc_pt_searched',
     'checked_layer' => 'eosrc_pt_checked',
     'selected_layer' => 'eosrc_pt_selected',
     'img_width' => 5,
     'img_height' => 5,
     'onclick' => 'activate_layer("grp_eosrc_pt")',
     'data_srid' => 32119
  ),     
...
\end{verbatim}
\end{footnotesize}

According to the above configuration file, the map legend shown in Figure \ref{fig:MapLegend} is produced.

\begin{figure}[htbp]
\centering
\includegraphics[width=.5\columnwidth]{proceedings/minoura/MapLegend.png}
\caption{Map Legend of WebGD Application NHIS}
\label{fig:MapLegend}
\end{figure}

We now explain each option used in map-layer configuration:

\begin{description}
\item [geom\_type] -- the type of geometry features contained in the layer.  The value can be \texttt{polygon}, \texttt{multipolygon}, \texttt{linestring}, \texttt{multilinestring}, \texttt{point} or \texttt{multipoint}.  Exact spatial operations performed depend on this type.  For example, if the type is \texttt{point}, a point is inserted on the map with an insert operation.  On the other hand, if the type is \texttt{polygon}, a polygon feature can be inserted.
\item [table] -- the name of the table in the database that contains the geometry column for the layer.
\item [layer\_selectable] -- the boolean option that determines whether spatial operations can be performed on the layer or not.  Some layers, such as those for counties and highways in the above example, are static, and they are not selectable for spatial operations.
\item [gid\_column] -- the name of the column that contains the identifiers for the geometry features in the map layer.
\item [geom\_col] -- the name of the geometry column for the geometry features contained in the layer.  The default name is \texttt{the\_geom}.
\item [legend\_label] -- the name of the layer in the legend.
\item [search\_script] -- the name and the location of the search form associated with the layer.
\item [select\_script] -- the name and the location of the select form associated with the layer.
\item [edit\_script] -- the name and the location of the edit form associated with the layer.
\item [normal\_layer] -- the name of the map layer displayed when no highlighting occurs.
\item [searched\_layer, checked\_layer, selected\_layer] -- the names of the layers used to highlight the geometry features \emph{searched for}, \emph{checked}, or \emph{selected}, respectively.  The geometry features returned by a search operation is \emph{searched for}, those whose checkboxes are turned on in search result form are \emph{selected}, and the geometry feature chosen for editing is \emph{selected}.
\item [img\_src, img\_width, img\_height] -- the file name, the width, and the height of the icon in the legend.
\item [onclick] -- the name of the javascript event handler activated when the user selects the layer in the legend.
\item [data\_srid] -- the \emph{spatial reference identifier (srid)} that designates the map projection used by the geometry features in the map layer.  If this srid is different from that of the map region, then geometry features in the layer are reprojected before they are displayed on the map.
\end{description}

\subsection{Quick View Configuration File}
\label{sec:QuickViewConfigurationFile}

The \emph{quick view} mechanism allows the user to select the map area of her interest.  That is, the user can switch to a new map area quickly by selecting the map area from the quick-view dropdown list.

Each entry in a \emph{quick view configuration file} describes the name of the map area represented by the entry, the map projection used by the \emph{extent} of the map area, and the extent.  The quick view configuration file for the Oregon region shown in Figure \ref{fig:QuickView}, for example, can be as follows:

\begin{footnotesize}
\begin{verbatim}
$qview = array(
  array(
    'name' => 'World',
    'srid' => 4326,
    'extent' => '-180,-90,180,90'
  ),
  array(
    'name' => 'United States',
    'srid' => 4326,
    'extent' => '-125,13,-65,53'
  ),
  array(
    'name' => 'United States, East',
    'srid' => 4326,
    'extent' => '-102,22,-60,50'
  ),
  array(
    'name' => 'United States, West',
    'srid' => 4326,
    'extent' => '-135,30,-105,50'
  ),
  array(
    'name' => 'Whole Oregon',
    'srid' => 6010,
    'extent' => '46461.662375,-43912.968464,
      2487069.754184,1785176.331408',
  ),
...
\end{verbatim}
\end{footnotesize}

The quick view list of regions as displayed in the map interface corresponding to the configuration file above:

\begin{figure}[htbp]
\centering
\includegraphics[width=.5\columnwidth]{proceedings/minoura/QuickView.png}
\caption{Quick View Selection of WebGD Application NHIS}
\label{fig:QuickView}
\end{figure}

Each entry in a quick view configuration file can specify the following options:

\begin{description}
\item [name] -- the name of the map area.
\item [srid] -- the spatial reference identifier for the extent explained below.
\item [extent] -- the \texttt{xmin}, \texttt{ymin}, \texttt{xmax}, and \texttt{ymax} values describing the positions of the lower left and upper right corners of the map area.
\end{description}

\section{Automatic Generation of Web-Form Scripts}
\label{sec:AutomaticGenerationOfWebFormScripts}

Several tools have been developed to augment the WebGD framework and simplify application development.  The WebGD Web-site generator (WebGD-Gen) can create an entire WebGD application, including a web-based mapping interface.  WebGD-Gen \emph{automatically} generates a consistent set of Web scripts from \emph{configuration files}, which are again automatically generated from a relational database schema.  Since form generation is automatic, the cost of application development is greatly reduced.  For a database such as Biotics that contains approximately 700 tables, programming all the required 3,500\footnote{700 x 50} forms manually can be very costly, even unfeasible.

WebGD-Gen is implemented as a collection of \emph{templates}.  Each template, combined with a corresponding \emph{configuration file}, generates one of the following six types of Web scripts: \emph{search}, \emph{select}, \emph{edit}, \emph{information}, \emph{action}, and \emph{treeview} scripts.  Templates and configuration files are written in PHP.  The Web scripts generated by them are also in PHP.  The generated scripts are executed on a Web server by a PHP interpreter.  Each script, except for an action script, creates a Web form that is displayed on a client computer by a Web browser.  Figure \ref{fig:Interactions} illustrates the interactions among the Web scripts and forms.

\begin{figure*}
 \centering
   \includegraphics[width=0.95\textwidth]{proceedings/minoura/Interactions.png}
 \caption{Interactions among Web Scripts and Forms}
 \label{fig:Interactions}
\end{figure*}

Furthermore, WebGD-Gen can automatically generate the statements for inserting, searching, and deleting \emph{geographical features} if the following lines, for example, are added to a configuration file:

\begin{footnotesize}
\begin{verbatim}
 // type of geographical features
$web_gd = 'MULTIPOLYGON';      
// layer group in legend
$layer_name = 'grp_eo_py';     
// geometry column containing shapes
$geometry_column = 'the_geom';
//geographical feature IDs
$gid_column = 'gid';           
// epsg spatial reference
$db_table_srid = 32119;       
\end{verbatim}
\end{footnotesize}

The forms generated for geographical features can perform the following additional functions compared to those for ordinary database tables:

\begin{enumerate}
\item A search form can be activated from a map interface.  In this case, the extent of a search box specified on the map is passed as additional search parameters.
\item A select form includes additional JavaScript code for highlighting geographical features retrieved or selected by the user.
\item An edit form can insert a record for a geographical feature, after transforming the coordinate values from the spatial reference used by the current map interface to the one used by the geometry column for the record.
\end{enumerate}

The forms related are automatically linked to each other.  Figure \ref{fig:EditForm} shows, as an example, the \emph{edit} form for a Student table.  From this edit form, the user can open the forms for the department and courses related to the student.  The information needed to create the links are extracted from the \emph{primary-key/foreign-key relationships} among the tables in the database.

\begin{figure*}
 \centering
   \includegraphics[width=0.7\textwidth]{proceedings/minoura/EditForm.png}
 \caption{Student Edit Form}
 \label{fig:EditForm}
\end{figure*}

In order to generate the Student edit form shown in Figure \ref{fig:EditForm}, the following entry is provided in the configuration file.

\begin{footnotesize}
\begin{verbatim}
$edit_fields=array(
   array("column"=>"student_id", 
     "label"=>"Student Id", "type"=>"numeric", 
     "maxlen"=>"40", "size"=>"40"),
   array("column"=>"first_name", 
     "label"=>"First Name", "type"=>"text", 
     "maxlen"=>"40", "size"=>"40"),
   array("column"=>"age", "label"=>"Age",
     "type"=>"text", "maxlen"=>"40", "size"=>"40"),
   array("column"=>"gender", "label"=>"Gender",
     "type"=>"text", "maxlen"=>"40", "size"=>"40"),
   array("column"=>"department_id", 
     "label"=>Department ID", "type"=>"to_one", 
     "linked_table"=>"departments", "maxlen"=>"40", 
     "size"=>"40"),
   array("label"=>"Courses Taken", "type"=>"to_many",
     "linked_table"=>"courses", "maxlen"=>"40",
     "size"=>"40"),
   array("column"=>"other_info", 
     "label"=>"Other Information", 
     "type"=>"textarea", "rows"=>"4", 
     "cols"=>"32",
);
\end{verbatim}
\end{footnotesize}

Each element in array \texttt{\$edit\_fields} represents a field in an edit form, with options \texttt{column}, \texttt{label}, \texttt{table}, \texttt{maxlen}, \texttt{size}, and \texttt{type}.  Option \texttt{type} can be \texttt{numeric}, \texttt{text}, \texttt{time}, \texttt{date}, \texttt{email}, \texttt{phone}, \texttt{textarea}, \texttt{to\_one}, or \texttt{to\_many}.

\begin{description}
\item [textarea:] The input is a string displayed in a text area.
\item [to\_one:] A field of type \texttt{to\_one} allows a user to view or modify the record related to the current record via a \emph{one-to-one} or \emph{many-to-one} relationship type.  In our example, column \texttt{department\_id} in table \texttt{students} is specified as \texttt{to\_one}.  When the \texttt{View} button is clicked, the edit form showing the record of the student's department is displayed.  Furthermore, a user can search and select a new department record to be linked.  Option \texttt{linked\_table} designates the name of the table storing the associated record.  Option \texttt{child\_column} indicates the column for linking in the associated table.  If this option is omitted, the name of the column for linking is identical to that of the foreign key column in the current record.
\item [to\_many:] The purpose of this type is to list the records related to the current record via a \emph{one-to-many} or \emph{many-to-many} relationship type.  In our example, the field labelled \texttt{Courses Taken} is specified to be \texttt{to\_many}.  When the \texttt{Show} button is clicked, all the courses taken by the student are displayed in the select form for courses.  This type needs options \texttt{linked\_table}, \texttt{parent\_column}, and \texttt{child\_column}.  Option \texttt{linked\_table} and option \texttt{child\_column} can be omitted, when the name of the foreign key column of the associated table is identical to that of the primary key column of the current record.  Option \texttt{parent\_column} indicates the \emph{foreign key} column in the current table.  If this option is omitted, the foreign key column is the primary key column of the current table.
\end{description}

\section{Automatic Generation of Map-Layer Configuration Files}
\label{sec:AutomaticGenerationOfMapLayerConfigurationFiles}

We can semi-automatically create a map-layer configuration file by using information in the table \nohyphens{\texttt{geometry\_columns}} that stores GIS-related metadata and the layer names in a map file.  Figure \ref{fig:CreationProcess} shows this process for region \emph{xxx}.

\begin{enumerate}
\item The default \emph{map-layer meta configuration file} \nohyphens{\texttt{\emph{xxx}\_maplayers.mconfig}}, which lists all the layer groups, can be created by \textbf{map\_mconfgen}.  The map-layer group names are generated from the table names stored in table  \nohyphens{\texttt{geometry\_columns}} and the map-layer group names defined in the map file.
\item We can customize the default map-layer meta configuration file, whose format is identical to a map-layer configuration file, by selecting and reordering the layer groups.  We can also provide customized values for the parameters in each layer group.  The meta configuration file needs to keep only the definitions of customized parameters.
\item Finally, map-layer configuration file \nohyphens{\texttt{\emph{xxx}\_maplayers.config}} is generated by \textbf{map\_confgen}.  The information required by this step is retrieved from the meta configuration file, table  \nohyphens{\texttt{geometry\_columns}}, and the map file.  The default values of the parameters determined by the latter two are overwritten if they are customized in the meta configuration file.
\end{enumerate}



A map-layer meta configuration file can define any parameters that are allowed for a map-layer configuration file.  However, the default one generated by \textbf{map\_mconfgen} contains for each map layer group the definitions only for the following parameters:

\begin{description}
\item [layer\_selectable] -- A boolean option that determines whether the layer can be selected for spatial operations or not.
\item [legend\_label] -- The name of the layer that will be displayed on the map legend.
\end{description}

An example of a default map-layer meta configuration file is shown below:

\begin{footnotesize}
\begin{verbatim}
$layer_groups = array(
   'grp_eo_py' => array(
      'layer_selectable' => true,
      'legend_label' => 'Eo Py',
),
   'grp_eosrc_' => array(
     'layer_selectable' => true,
     'legend_label' => 'Eosrc Pt',
),
...
\end{verbatim}
\end{footnotesize}

The user may modify the values of these definitions and add others.  For example, the meta configuration file can be customized as follows:

\begin{footnotesize}
\begin{verbatim}
$layer_groups = array(
   'grp_eo_py' => array(
      'layer_selectable' => true,
      'legend_label' => 'EO Polygons',
      'search_script' => 'forms/eo/eo_py_eo_search.phtml',
      'select_script' => 'forms/eo/eo_py_eo_select.phtml',
      'edit_script' => 'forms/eo/eo_py_edit.phtml',
      'img_src' => 'images/eo_poly.png',
),
   'grp_eosrc_pt' => array(
      'layer_selectable' => true,
      'legend_label' => 'EOSRC Points',
      'search_script' => 'forms/eo/eosrc_pt_search.phtml',
      'select_script' => 'forms/eo/eosrc_pt_select.phtml',
      'edit_script' => 'forms/eo/eosrc_pt_edit.phtml',
      'img_src' => 'images/eosrc_pt.png',
),
...
\end{verbatim}
\end{footnotesize}

The following customization was done:

\begin{enumerate}
\item \texttt{legend\_label} was changed to the desired layer name for the map legend.
\item The names and locations of the search form, select form, and edit form are specified in \texttt{search\_script}, \texttt{select\_script}, and \texttt{edit\_script}, respectively.
\item The source file name of the icon in the map legend was specified in \texttt{img\_src}.
\end{enumerate}

The order of the map-layer groups can also be changed to that desired in the map legend.

Then the map-layer configuration file shown previously can be generated by \textbf{map\_confgen}.

\section{WebGD Development History}
\label{sec:WebGDDevelopmentHistory}

The WebGD framework and WebGD-Gen were developed \emph{incrementally} and \emph{iteratively} during the last four years.  We first implemented in 2000 an application that allowed point features to be inserted on a map by using ASP with ArcIMS and ArcSDE.  In 2001, we re-implemented this application with ASP.NET as ASP.NET provides Web controls, which are better building blocks for Web pages.  Based on this application, the first version of WebGD framework was created in 2002 in order to support multiple applications.\cite{Wangmutitakul et al.:2004}

In early 2003, we re-implemented an application called Motels Oregon with MapServer, PostGIS, and PostgreSQL\cite{Sano et al.:2003}  This version on Linux was more reliable and faster than the old one, as well as being built with free software.  While implementing the next MapServer application, which was a germplasm resource management system (GEM-GIS), we created the first version of WebGD framework for MapServer.  This framework was then enhanced so that it can handle polygon features as well as point features.

\begin{figure}
 \centering
   \includegraphics[width=1\columnwidth]{proceedings/minoura/CreationProcess.png}
 \caption{Process of Creating a Map-Layer Configuration File}
 \label{fig:CreationProcess}
\end{figure}

The two major enhancements made to the WebGD framework in 2004 were \emph{dynamic switching} of \texttt{spatial references} for different regions and \emph{automatic generation} of Web forms that can be used to insert, query, and delete geographical features.  Compared to an application that simply displays geographical features as points on a map, the current WebGD framework is roughly 20 times more complex in terms of the time we spent implementing the required features.

\section{Conclusions and Future Work}
\label{sec:ConclusionsAndFutureWork}

We have developed the WebGD framework and the WebGD-Gen application generator for rapid development of Web-based GIS/database applications.

\begin{enumerate}
\item Geographical features, such as habitats of plants and animals, road-work sites, and waterlines, can be inserted, queried, and deleted with the map interface and Web forms displayed on a standard Web browser.
\item An application can be created without any programming.  The map interface and Web scripts for data access can be automatically generated from configuration files, and those configuration files can be generated from the database schema and the GIS metadata, i.e. information stored in the table  \nohyphens{\texttt{geometry\_columns}}.  Automatic generation of a Web-based GIS application not only reduces the development cost significantly, but it also facilitate incremental and iterative development of the application.
\item Dynamic switching of spatial references allows an application to cover different regions with different map files, projections, map legends, and quick-view lists.  This is an important feature needed for an application that covers the entire USA or the world.
\item We created the WebGD framework by using only free open-source software.  The software tools we use, such as the University of Minnesota MapServer, PostgreSQL DBMS, PostGIS, Apache, and PHP are all available for free.  The GIS data used, such as those from USGS, TIGER/LINE, and Digital Chart of the World (DCW), are also in the public domain.  Therefore, the framework is available for anyone for free use.
\item The cost of running our applications is extremely low.  We could put copies of such large databases as Biotics, SSURGO2 soil data, and a part of National Germplasm Resource Information System on a \$800PC.
\end{enumerate}

Automatic code generation of a WebGD application will save a great deal of effort in the development of a spatial decision-support system.  Although some manual customization is required, the time needed for customization can be lowered to weeks or months compared to the years required to build a \emph{spatial decision-support system} from scratch.

The WebGD framework and WebGD-Gen are currently available upon request. In order to release them to the public as free and open-source software, we are looking for collaborators. We are also reimplementing the map interface by using OpenLayers to support smooth panning.

\input{proceedings/minoura/publications}  % Bibliography entries in external file

\address{Toshimi Minoura, Nirut Chalainanont, Junya Sano\\
  Oregon State University\\
  \url{http://engr.oregonstate.edu/~minoura/research/creeda/}\\
  \email{minoura AT eecs.orst.edu}
  }
