NOAA Coastal Services Center ArcIMS ActiveX Template Code Base

Although a number of organizations use ArcIMS® sites to serve data, many only employ ArcIMS's "out of the box" functionality. A template for ArcIMS applications developed by the National Oceanic and Atmospheric Administration (NOAA) Coastal Services Center provides a standardized, fully featured code base that ArcIMS ActiveX Connector programmers can use to quickly create and customize new ArcIMS sites. The template provides a uniform look and feel for Internet mapping services but allows complex customizations that include integration with ArcObjects® and ArcSDE®. This paper highlights the features particular to the Center's template and highlights a successful project that substantially customized the template's code.

An ActiveX Code Base

There were four main goals for this new code base. The first was to create a standard look and feel for all Center ArcIMS sites. The second was to allow for customized sites that employ ArcObjects, which led to the use of Microsoft® Active Server Pages (ASP) technology. The template should also provide richer functionality via the Web than ArcIMS Designer built sites. Finally, the template was created to encourage other programmers to share code when creating new ArcIMS sites - even sites not produced by the Center.

Though the appearance of the ArcIMS Designer's HTML viewer can be greatly customized, many ArcIMS sites on the Web look similar. The HTML viewer does not allow for its look to be changed easily chiefly because its design is not as modular as it could be. Moving or removing one file or frame can result in a number of errors. The NOAA Coastal Services Center template was created to more easily support interface changes by eliminating unnecessary interdependence within sections of code, which allows interface designers more flexibility to customize look and feel.

Allowing for an interface with ArcObjects steered the choice of technologies for the template. Esri® has greatly utilized Microsoft's Component Object Model (COM) technology in the ArcGIS® suite of tools. Server-side GIS development should anticipate interactions between ArcObjects and server-side applications. Ease of integration with COM pushed template development away from JavaScript as well as Java Server Pages, or JSP. COM is not part of the .NET family so ASP.NET, and therefore VB.NET or C#, were also poor choices for an ArcIMS code base. The ability to natively interface with Microsoft SQL Server 2000, a database supported by ArcSDE through the ActiveX Data Object (ADO) was an additional point in ASP's favor.

The final advantage of using ASP is its use of Visual Basic Script (vbscript). Vbscript closely resembles Visual Basic for Applications (VBA), which is used to customize ArcGIS. Vbscript also resembles Visual Basic 6.0, which is the most common language for MapObjects programming. By making some form of Visual Basic standard for ArcGIS extensions, MapObjects stand-alone applications, and now ArcIMS development, programmer training and research needs are minimized.

The template development team also wished to create a thin client for ArcIMS that provided features traditionally expected in thicker, stand-alone clients. In the HTML viewer one cannot view the symbology of the legend while also viewing the active layer. Other features, like an easier to use query tool, were also desired. Implementing a minimum browser requirement allowed the use of dynamic HTML (DHTML) and JavaScript to achieve the goal of providing features normally reserved for stand-alone applications.

ActiveX example code from Esri was useful in the creation of this new code base, but still does not have all of the features found in Esri's JavaScript-powered HTML viewer. This template fills out these functions using the ActiveX connector with tested code that also strives to improve on many features of the HTML viewer. By releasing this code, the template can grow in ways needed by NOAA and other programmers, not just in ways predicted by the Center. The release of this code base is designed to reduce the number of sites that overlook the ActiveX connector as an option to ArcIMS Designer-built HTML viewer sites.

Customization Example

The most recently released application that employs this code is the Historical Hurricane Tracks application. This site takes advantage of ASP and ADO to increase spatial query performance. The system was designed to allow the public to query areas of interest for historical tropical cyclone activity, and greatly benefited from having a modular, generic code base to provide standard Internet mapping features. Development time was overwhelmingly spent solving new problems, with only a few files from the template code base needing to be edited for the final product.

Historical Hurricane Track ArcIMS Website

The Historical Hurricane Tracks system uses SQL Server Replication tools to create a non-spatial mirror of the ArcSDE databases used to create the ArcIMS MapService. The data are replicated on a Microsoft SQL Server (MS-SQL Server) server that is not equipped with a Spatial Database Engine (SDE), placed outside of a network firewall, and used to drive a series of ASP files.

These ASP files provide several query interfaces split along a number of query paths. These interfaces enable users to define a set of parameters to filter hurricane data, including zip code, place name, storm name, a specific point of latitude/longitude, or El Nino/Southern Oscillation (ENSO) periods. All of these parameters and their possible values are drawn directly, using ADO, from the publicly accessible server that holds the replicated data, and are done without the overhead of passing a query through ArcIMS and ArcSDE.

Once users finish selecting their search constraints, these parameters are forwarded to a final ASP page. The parameters are run through a custom Structured Query Language (SQL) stored procedure to find the hurricane tracks matching the query.

If one or more hurricanes are found within the area-of-interest, another query is executed to return the storms Best Track ID (BTID) of the hurricane. This list of BTIDs is passed to the ArcIMS code base for rendering and viewing by the user.

The most complex task performed by this system is its direct queries of spatial tables to determine whether a storm intersects a specific area of interest as selected by the user. While some database management system (DBMS) packages offer extensions that allow this type of analysis to occur inside a Data Manipulation Language (DML) statement, MS-SQL Server, the DBMS used in this application, does not have this capability. The method used to overcome this hurdle involved implementing SQL stored procedures against the SDE system tables, specifically the SDE_Layers table and the f<table> of the user-selected layers.

Throughout the query process, the user is offered sets of options to use as parameters, such as county, ENSO years, or city. The ASP page then constructs a SQL query to match these constraints.

One example of how this query might be run via a DML statement is shown below.

SELECT BTIDs FROM hurricanes

WHERE SomeLayer.Feature INTERSECTS hurricanes.track

To simulate this DML query within MS-SQL Server, a set of stored procedures that analyze the hurricanes and SDE system databases was created.

The first step in the process is to determine the extent of the feature the user wants to use to intersect with the hurricane data. The name of the layer is determined by which query interface is being used. For example, when a user selects a zip code query, the layer name is US_ZIPCODE_CENTROIDS<table>.

Querying the SDE_Layers table with the known layer name will produce the f<table> value for any ArcSDE layer by concatenating the letter f<table> with the value of the column layer_id. This is the name of the table that contains the spatial features corresponding to the known layer name. The spatial_column name will be needed in the final step that returns the matching hurricane features to ArcIMS as a list of BTIDs.

Using the f <table> value produced above, the layers table is searched for features matching the column/value parameters submitted. In the zip code example above, the f<table> might be queried for the centroid that corresponds to a zip code value of 29405.

At this point in the process a specific Feature ID (FID) will match the user's spatial area of interest. The FID is used to construct another SELECT statement that will compare the envelope based on this FID with the extent for of the line segments making up the hurricane tracks. This process will return a subset of hurricane line segments that potentially fall within the user-selected area of interest.

For queries that use a point and radius as the feature, instead of an existing feature class within the database, the list of hurricane segments is run through another set of stored procedures. These procedures are designed to solve for the coefficients of the quadratic equation to determine if any part of the line segment falls within the radius of the circle. The evaluation of -b 2 +/- 4ac from the quadratic equation returns 0, 1, or 2 possible intercepts for a given line and circle. If the line, in this case a hurricane track, intersects the circle, its BTID is returned in the list for display in the ArcIMS application.

In the end, these queries, run through customized stored procedures, return a simple list of BTIDs and a spatial extent of interest. The ArcIMS template only needed to add one new tool that processed these two sets of values, zoomed the map to the correct extent, and displayed those cyclone tracks that were included by the list of BTIDs. To add the code to this tool in a modular fashion only required the addition of one file and the edit of another file.

Other Web sites using this code base can be found at the following URL:

http://www3.csc.noaa.gov/ArcIMS/

Ruffin Bailey and Jason Marshall
Database Management Systems Group
Technology Planning and Management Corporation at the National Oceanic and Atmospheric Administration (NOAA) Coastal Services Center