Authors: Luis F. Penedo and Daniel W. Teaf
ABSTRACT
This paper briefly explains how to work with dynamically loaded raster images that are not part of the map service of an ArcIMS application. The paper is based on the experiences gathered during the development of the Turnpike Management Information System (TMIS). The first part of the paper presents a summary of how TMIS works with images. The following parts include a description of the variables involved, like external database tables, metadata, etc., to end with a summary of the two algorithms "click-and-load algorithm" and " Corner Validation algorithm" and their implementation.
INTRODUCTION
The purpose of this paper is to present a practical way of handling aerial photographs of different formats by the Turnpike Management Information System (TMIS). Although this application was developed for a public sector transportation agency, the methods presented are of general-purpose application and are discussed in terms that everybody can apply them to specific needs.
TMIS is an intranet decision support system developed for the Florida Department of Transportation Turnpike District by URS Corporation. Because the need of professionals working for the Turnpike of having and using spatial data to support every day decisions, TMIS started as a map system to provide access to GIS data and among its tools, it had the capability to load and unload aerial photographs taken along the Turnpike corridor facilities. TMIS was intended to evolve at that point to become a decision support system. Initially it was a Map Objects – Internet Map Server application (MOIMS) and later, it was re-developed to run as an ArcIMS application.
TMIS currently runs in a Microsoft Windows 2000 platform. It uses IIS as a Web server and New Atlanta’s Servletexec as a servlet connector. TMIS is an ArcIMS HTML Viewer customization that takes advantage of the open architecture offered by the JavaScript environment provided with ArcIMS by Esri and enhanced with the power and flexibility offered by ASP to handle server components to interact with Microsoft Access tables.
The reason for selecting the HTML viewer was its flexibility to adapt to the Information Technology platform of the Turnpike. This means, it was the more suitable way to integrate spatial data, user work, and organizational goals. This viewer efficiently uses server resources to support the right activity in the client side. The HTML viewer in general is highly customizable and has allowed developing a set of tools to provide solutions to different situations. The HTML viewer may not provide the best environment that ArcIMS delivers to Esri customers but it has been the one that has better fits Turnpike needs, and it has demonstrated that it is easy to implement in most of the spatial data environments.
TMIS DESCRIPTION
Figure 1 presents the graphical interface of TMIS. It is divided in three main components: the Map Area, which is the display area of the map. The Map Tools, which is the set of icons that enable the user to perform different actions directly on the map such as zoom in and out, pan around, print, etc. And the Data Tools organized in tabs and can be accessed by clicking on them. The Data Tools are the most important part of the application since it gives the user access to the data that will conform the map. In TMIS, this section contains the tools to handle image catalogs.
Figure 1
TMIS contains basically two kinds of aerials: Turnpike Aerials and State Wide Aerials. Both are accessed from a set of buttons under the Aerials Tab. The Turnpike Aerials are a collection of aerial photographs that have been taken on different dates along the Turnpike right of way. To access these images in TMIS first it is recommended to zoom in into the area of interest until a dashed line rectangle becomes visible. This indicates that the map scale is suitable to display aerial photographs for that location. Figure 2 shows a map after zooming in enough to make these dashed lines visible.
Figure 2
After zooming in, the user needs to click on the Aerials tab. By d oing so, the aerials buttons will appear at the left side of the map area. These buttons display the Turnpike Aerials button or the State Wide aerials button. The Turnpike aerials are displayed by clicking on the Add Aerial button and then clicking on the rectangle corresponding to the aerial to display (Figure 3) or by clicking on the Turn Aerials On button, which will display the aerials of all the rectangles shown on the map (Figure 4). The second option will allow TMIS to turn on the aerials for all the rectangles appearing in the map and any time the user zooms in our out, or pans around, TMIS will update the displayed set of aerials by turning on and off the corresponding photographs.
Figure 3
Figure 4
State Wide aerials are displayed in a similar way to the Turnpike aerials. The user clicks on the button Add Aerial and then clicks the map location for which he or she needs to see an aerial (Figure 5). To turn the aerials off, in both cases, just click the “Turn Aerials Off” button. The way these sets of buttons work is discussed in the following sections of this paper.
Figure 5
ACCESSING IMAGE CATALOGS
There are two forms of adding images to an application. First, by including them as part of the map service, and second, loading them “on the fly”. The first one is the more simple way but is not suitable for wide geographic areas. The aerials are turning on and off by zooming in and out, which makes the scale of the map area greater or less than the maximum viewable scale of the layer. The main disadvantage of this method is that the group of photographs represent a static group of images bundled to the map service. Since the whole set of photos is included in the map service, this may cause an overload of the system and cause increments in the response time of the application.
The other way to load aerials is the one to be analyzed in this paper. It constitutes a dynamic way of adding images to a web map application with the least of processing overhead involved. This method provides the advantage of having aerials grouped in different ways and the quantity of images in each group can be endless. As an additional advantage, metadata is more efficiently handled.
METADATA AND IMAGES
When TMIS started as a project a few years ago, the main objective was to put GIS data on everybody’s desktop. There was a clear definition of the objective and understanding of the technology evolution. It was a clear vision of the magnitude of the project. That was the main reason to give metadata not only a special place in the project development plan. Metadata got the place it occupies in a GIS project. And in part, the success of TMIS as a mapping application is due to a serious evaluation of data made from the beginning of the project.
To process images, metadata has an important role also. One disadvantage of a raster image is its lack of providing more intelligent information in a simple way, as vector data does. Metadata helps to overcome this limitation by providing the foundation for processing of image attributes contained in a separate table. This allows building viewable scenarios based on raster data. The processing of the tables along with the images gives more control of the kind of information that can be delivered to the end user. To achieve this, the image catalogs ought to be seen as a part of a dynamic spatial data model, not as a static one as currently has been the tendency among many GIS users.
WHY CATALOGS: DIFFERENT IMAGES
There are many kinds of aerial photographs in a public organization. As a result, a map system must have a well-organized collection of image catalogs. Additionally, there is data related to these aerials since they differ from each other in format, date of flight, resolution, place and many other characteristics that constitutes particular attributes. These attributes can be organized and stored in a database system to complement the image catalogs. Therefore, image catalog processing involves querying external database tables that can be stored in one or more Access files, or can be part of an Oracle or MS SQL server database accessed through the ArcSDE interface.
IMAGE ALGORITHMS
This paper proposes two ways of displaying raster images to the screen. These are very obvious procedures that are formally analyzed in order to take full advantage of them. They constitute an integral part of the user interaction with the mapping application and can be applied for other purposes, as we will see later, to transform the static application in a more intelligent dynamic application. These two ways are formally described by the following algorithms:
Click-and-load algorithm: This is not the most simple way to load an image that is not part of the map service but is the one involving less processing. In general, the user clicks a button that indicates the program will load an image and then clicks on the map to indicate to the program that the image corresponding to that location must be loaded.
This algorithm is user specified location dependent. It can be implemented in two ways: First, the user clicks on the map area the location of the image to be displayed and the program grabs the X Y coordinates of the click and sends the values to an ASP page that accesses a table containing each aerial minx, minY, maxX, maxY, and the path of the image file for each record. The ASP page will process the record to find the point that falls inside the aerial limits. With this path, an ArcXML request can be built and sent to the server to display the image.
Another way of implementing this algorithm is building a modified version of the select function provided by the ArcIMS HTML viewer. The map must contain a layer with the attributes needed to build the XML request that will result in bringing the aerial to the screen. This alternative involves more processing time since it requires two XML requests but is more precise and efficient than the first one. It provides a more maintainable spatial data model.
Both options can be expanded to handle images of different type, nature, and even different format. Different nature means that one location there may have many different images associated with it. They may be different because they correspond to different work or projects or just because the aerials were taken in a different date. The possibility of analysis with this approach is endless. A region may be analyzed under different conditions by processing different kinds of aerials. Satellite images can provide photos of that region under extensive brush fires, floods, etc. that can be studied together with aerials taken for different projects. The way to achieve this is by providing a collection of buttons corresponding to the type of aerial or photo to be loaded.
Corner Validation algorithm: This algorithm allows the user to load the images falling in the current extent of the map area. It involves a little more processing time but requires less user participation. This algorithm is extent location dependent, does not depend on user requests. It depends on the location currently displayed on the map area of the screen. TMIS adds the images which one or more corners fall inside the rectangle defined by the current extent of the map area right after the user clicks on the button corresponding to a kind of aerial he or she needs to work with.
To implement this algorithm is necessary to grab the envelop of the current extent after any time it changes. By current extent we understand whatever is displayed any time the user zooms in, out, pans around, etc. These coordinates are captured by custom functions (located in the aimsCustom.js file) and sent to an ASP node. The ASP node will query a database to determine what aerial corners fall into the square defined by the envelope of the current extent.
Finding the corners that fall into the display area is the validation process, and every time the program (the code in the ASP node) finds a corner, it validates that record sending a message to TMIS saying that "it is OK to display this image". The Algorithm analyzes for every corner of the display area the following cases:
The basics of this algorithm may have other applications. The extent processing can provide a more intelligent interface by displaying some other kinds of information related to the current extent of the map area.
The key element of this algorithm is to access somehow the geometry of a feature and compare it against the corners of the current extent. In the case of regular shapes like the rectangles representing the aerials, it is an easy step. It gets a little more complex and requires more processing when it is an irregular shape like most of the geographic of spatial data features that GIS professionals deal with. Fortunately, ArcIMS provides a simple way to capture this geometry building the ArcXML functions of the type writeMapXML using GET_FEATURES with geometry=”true” requests. The response will include a set of features that satisfy the conditions of the request.
IMAGE ALGORITHMS IMPLEMENTATION
Based on the description of the algorithms used by TMIS, it is easy to intuit that to implement them, it is necessary to design the supporting data structures that will enable loading, handling, and unloading the aerials during an ArcIMS session. In order to accomplish efficiently these functions, a catalog has to be linked or related somehow to an object catalog or another kind of data structure. In terms of software engineering, this data structure will sit on top of the image catalog and provide the necessary functions to load, unload, keep track of loading images, etc. Just like using objects to process a set of database tables.
There are many ways to build this logical layer of the system. One is considering the image catalog an abstract data type with specific attributes, procedures, and methods. The catalog object may reside in the server either as a part of a COM component or Java bean.
Another way to build this logical layer, and the way TMIS implements, is building a logical collection of images. The lack of object oriented capabilities of java script made it necessary to keep the attributes, procedures, and methods as independent functions but, the advantage provided by JavaScript in the way it handles arrays, helped to developed and manipulate an organized group of arrays, variables, and functions that logically, behave as a whole and is what constitutes the catalog collection of TMIS.
SOFTWARE COMPONENTS
Prior to writing code to customize ArcIMS, the first thing to do is to determine the locations of the ArcIMS image catalog definitions. TMIS has them as part of the map service file at the top, between the <WORKSPACE></WORKSPACE> labels. The other option is to include the location in the code of every ArcXML request. The first method is more convenient since it hides the physical location of the aerial photograph files.
The software components that have be added to the ArcIMS HTML viewer customization are server side and client side components. Server side components include Java beans, ActiveX and COM components, and ASP pages. On the client side, there are JavaScript or VB script functions. TMIS does not have Java beans or Active X - COM components. Its server side processing is performed by ASP pages. On the client side, it uses Java script functions.
To process image catalogs, together with tables containing the image metadata, TMIS has the following type of JavaScript functions in .js files. A function or procedure that retrieves the set of parameters from the Access files and sends them to a function that displays the image on the map area. These parameters will include image name, a Boolean to indicate when the image is visible or not, minimum and maximum scales, data set name (which is the file name) and workspace (wich is the catalog name defined in the AXL file).
There are more functions to support other activities. TMIS includes a function to keep control of what image has been added to the ArcIMS session, which one is on and which one is off, or if there are no images currently loaded. This task help to reduce processing time because is easier to turn on and off an image that has been added to the ArcIMS session rather than un-load it and load it again. At the same time, this function controls that an image is not going to be loaded twice. Another function initializes the whole image collection if the user clicks on a button to remove all aerials.
An additional function receives from the ASP page information about the image file such as the image file name and type. With the whole file name, this function determines what catalog this image belongs.
There are many other types of task performed by an equal number of functions included in TMIS, and some of these have been re-used in another applications to enhance another tools, such as displaying the counties that are currently displayed in the map area. When the scale is not big enough, up to six county names are displayed below the map area to help the user to determine the location observed.
CONCLUSIONS
Image catalogs are special data type in a web mapping application and must be treated like that in order to obtain optimum results. We recommend handling them from server side elements such as a java bean or ActiveX component if possible but client side solutions provide acceptable results for an intranet application.
Having a well-organized collection of image catalogs supported by the right tools gives some advantages for maintenance of the image catalogs. This tools need to be designed in a way that adding new images will not result in major changes to the code. To achieve this, the fields of the databases must reflect all possible intrinsic and extrinsic properties of the element (in this case, the image file). For example, when TMIS aerials files are added, the corresponding tables are updated without adding new code to the application.
Having a well-organized collection of image catalogs helps to have better scenarios for analysis. For example, images, implicitly or explicitly, introduce to a spatial data scenario the dimension of time, allowing the user to compare different situations by observing the change of two aerials of the same area taken in a different date.
ABOUT THE AUTHORS
Luis F. Penedo is currently a Senior GIS Analyst/Programmer working for URS Corporation at the Florida's Turnpike Enterprise in Orlando, Florida. Mr. Penedo holds a Licentiate Degree in Civil Engineering from Mariano Galvez University of Guatemala, a Bachelor in Science in Computer Science, Master in Arts in Computer Resources and Information Management, MBA, and a Master in Science in Computer Science from Webster University, St. Louis, Mo. For the past several years, Mr. Penedo has worked in the GIS field, first in the Water and Sewer Utilities sector and currently in the Transportation sector. He has focused on developing faster and better applications to deliver GIS solutions to support daily activities of managers and engineers.
Luis F. Penedo
Senior Spatial Data Analyst/Programmer
Florida Department of Transportation
Turnpike Headquarters
Milepost 263, Florida's Turnpike
Bldg 5315, Turkey Lake Plaza
Ocoee, Florida 34746
Tel: (407) 532-3999 Ext. 3814
Fax: (407) 822-6612
e-mail: luis.penedo@dot.state.fl.us
Daniel W. Teaf is an employee of URS Corporation working as the Program Manager of the Spatial Data Analysis Department at the Florida's Turnpike Enterprise. He has been working with the Turnpike for 6 years and holds a M.S. in Geography from Florida State University.
Daniel W. Teaf
Program Manager
Turnpike Headquarters
Milepost 263, Florida's Turnpike
Bldg 5315, Turkey Lake Plaza
Ocoee, Florida 34746
Tel: (407) 532-3999 Ext. 3807
Fax: (407) 822-6612
e-mail: daniel.teaf@dot.state.fl.us
ACKNOWLEDGEMENTS
The authors would like to recognize all who have participated in the different stages of the project development life cycle of the Turnpike Management Information System (TMIS) , including the following past and present managers: Edward "Terry" Denham, Bruce Barrett, and Randy Fox.