PAGE 173

157 Code Listing 37. Lake Status in DHTML Current Status

Lake Okeechobee Current Status

Code Listing 38. Lookup Page in DHTML Lake Okeechobee

PAGE 175

159

LOSAC Lookup Map

Code Listing 39. Water Supply Calculator in DHTML Lake Okeechobee

PAGE 177

161

Water Supply Calculator



PAGE 179

163 LIST OF REFERENCES Alexander, John, and Kirk Upthegrove. “Int egration of Pen Computer, GPS, GIS, and Digital Photography Technologies for Effi cient Disaster Assessment and Field Data Collection.” Proceedings of the Th irteenth Annual ESRI User Conference . Palm Springs, CA: ESRI. 1.3 (1993) 563-574. Anderson, Jeffrey S. “Implementation an In tegrated Directory Structure System for a Multi-Departmental Countywide GIS.” Ur ban & Regional Information Systems Association 1994 Annual Conference Proceedings . 1 (1994): 219-230. Antenucci, J. C., K. Brown, P. L. Croswell, M. J. Kevany, and H. Archer. Geographic Information Systems -A Guide to the Technology . New York: Van Nostrand Reinhold. 1991. Beardsley, Karen, and James F. Quinn. “Inf ormation Center for the Environment: Public Access to Natural Resource Data Using an Interactive Query System on the World-Wide Web.” Proceedings of 1996 ESRI User Conference . Palm Springs, CA: ESRI. 1996. Berry, Joseph K. “Put Things in Their Proper Places with GPS.” GIS World . September 1995: 31-32. Biggs, Brian, and Allan Falconer. “Impr oving Field Data Collection through the Integration of ArcView 2.1 and GPS, Technology.” Proceedings of 1996 ESRI User Conference . Palm Springs, CA: ESRI. 1996. Biggs, Brian, Kimberly Patraw, R. Douglas Ramsey, and Allan Falconer. “World Wide Web Access to ARC/INFO Databases.” Fifteenth Annual ESRI User Conference Proceedings . Palm Springs, CA: ESRI. 1995. Block, Donald R. “Using ARC/INFO as a GIS Server on the World Wide Web.” Fifteenth Annual ESRI User Conference Proceedings . Palm Springs, CA: ESRI. 1995. Bochenski, Barbara. Implementing Production-Quality Client/Server System . New York: John Wiley & Sons, 1994. Bradshaw, Jeffrey M. Software Agents . Cambridge: MIT Press, 1997.

PAGE 180

164 Burrough, Peter A. Principles of Geographi cal Information Systems for Land Resources Assessment . New York: Clarendon Press, 1986. Burrough, Peter, and Rachael A. McDonnell. Principles of Geographical Information Systems . Oxford: Oxford University Press, 1998. 12-16 Campos D., Daniel, Aleksey Y. Naumov, and Stuart C. Shapiro. “Building an Interface Agent for ARC/INFO.” Proceedings of 1996 ESRI User Conference . Palm Springs, CA: ESRI. 1996. Chang, D. Harkey. Client/Server Data Access with Java and XML . New York: John Wiley & Sons, 1998. 4. Chang, Frank. “HyperGIS -A Potential Solution towards a Global Disaster Information Network.” PSA Workshop: Harnessing th e Communication Revolution Creation of a Global Disaster Information Network . June 6-12, 1995. Beijing, China: Pacific Science Congress. 1995. Chang, Frank. “HyperGIS: Towards Information Highways.” Geoinformatics'95: RS, GIS, and GPS in Sustainable Development and Environmental Monitoring . May 25-28, 1995. Hong Kong: CUHK. 1995. Chang, Frank, and Paul Fishwick. “Simul ation to Environmental Changes over the Internet.” GIS AM/FM ASIA’97 & GeoInformatics’97 . Taipei, Taiwan. 1 (1997): 41-49. Chang, Frank, and M. J. Hasell. “Trends in GIS: Are We Ready for a Global Survey?” GIS & Remote Sensing: Research, Development & Applications, GeoInformatics'96 . April 26-28, 1996. West Palm Beach. 1996. 177-187. Chang, Frank, Z. Ren, and M. Xiao. “GIS Application to Regional Planning and FloodControl Decision Making.” The 6th Canadian Conference on Geographic Information Systems . Ottawa, Canada. June 6-10, 1994. Cheong, Fah-Chun. Internet Agents . Indianapolis, IN: New Riders Publishing, 1996. Churchill, G., and Roger Tomlinson. “GIS Pioneer.” Photogrammetric Engineering & Remote Sensing . 52. 1965. Clinton, William J. “Coordinating Geographic Data Acquisition and Access: The National Spatial Data Infrastructure.” Pr esidential Executive Order 12906. 59 FR 17671. April 13, 1994. Conquest, Julie, and Eddie Speer. “Disseminating ARC/Info Dataset Documentation in a Distributed Computing Environment. ” Proceedings of 1996 ESRI User Conference . Palm Springs, CA: ESRI. 1996.

PAGE 181

165 Cortez, Eli, Randy Meek, and Jim Koger. “G IS to Support Vehicle Routing in Public Education.” Urban & Regional Information Systems Association 1994 Annual Conference Proceedings . Milwaukee, WI. 1 (1994): 387-399. Dacey, M., and D. Marble. “Some Comments on Certain Aspects of Geographic Information Systems.” Technical Report No. 2 . Evanston, IL: Department of Geography, Northwestern University. 1965. Dangermond, Jack, and L. K. Smith. “Geographic Information Systems and the Revolution in Cartography: The Nature of the Role Played by a Commercial Organization.” The American Cartographer 15 (July 1988): 309. Djokic, Dean, Andrew Coates, and James E. Ball. “GIS as Integration Tool for Hydrologic Modeling: A Need for Generic Hydrologic Data Exchange Format.” Fifteenth Annual ESRI User Conference Proceedings . Palm Springs, CA: ESRI. 1995. ESRI. ArcView Internet Map Serv er – Map Publishing on the Web . Redlands, CA: ESRI. 1997. Evans, Betty J., Thomas F. Lundeen, Robert G. Best, and Albert L. Guber. “Team Leader: an ARCVIEW-Based Inspection and Data Collection System.” Proceedings of 1996 ESRI User Conference . Palm Springs, CA: ESRI. 1996. Evans, John D., Joseph Ferreira, and Philip R. Thompson. “A Visual Interface to Heterogeneous Spatial Databases Based on Spatial Metadata.” Proceedings of the 5th International Symposium on Spatial Data Handling . Charleston, SC. 1.2 (1992): 282-293. FICCDC Technology Working Group. “A Process for Evaluating Geographic Information Systems.” Technical Report 1 . U.S. Geological Survey Open-File Report 88-105. 1988. 1200. Fisher, Lawrence T. “Geometrically Corr ecting Multispectral S canner Imagery Using GPS.” Proceedings of the Thirteen th Annual ESRI User Conference . Palm Springs, CA: ESRI. 1.3 (1993): 515-525. Flaig, E. G. and K. E. Havens. Historical Trends in the Lake Okeechobee Ecosystem. I. Land Use and Nutrient Loading. Arch. Hydrobiol. Suppl . Stuttgart, Germany. 107. 1995. 1-24. Forrest, David. “Geographically Enabled Sy stems Provide Real-time Decision Support.” GIS World . 7 (February 1994): 58.

PAGE 182

166 Fowler, M., and K. Scott. UML Distilled: A Brief Guide to the Standard Object Modeling Language . Reading, MA: Addison-Wesley Longman, 2000. 40. Game, Adam, and Stephen Owens. “GIS on th e Information Superhighway: Integration of GIS with Interactive Mu ltimedia Directory Services .” Fifteenth Annual ESRI User Conference Proceedings . Palm Springs, CA: ESRI. 1995. Ghormley, Keith. “Puzzling out the Next-generation GIS.” GIS World . 8 (October 1995): 50-52. Goodchild, Michael F. “Geographic Information Systems.” Journal of Retailing . 67.1 (1991): 3-15. Goodchild, Michael. “Information Highway s.” The AGI Source Book for Geographic Information Systems . London: Taylor & Francis, 1995. 107-111. Goodman, D. Dynamic HTML . Sebastopol, CA: O’Reilly & Associates, 1998. 9. Groff, Jonathan. “Building Database Gate ways with Inter Application Communication (IAC).” Proceedings of 1996 ESRI User Conference . Palm Springs, CA: ESRI 1996. Guan, Weihe, Joyce Zhang, and Dera Musz ick. "Integrating Multiple Databases and Computing Platforms with GIS in S upport of Water Resource Modeling." Proceedings of 1999 ESRI User Conference . San Diego, CA: ESRI. July 26-30, 1999. Hahn, Harley, and Rick Stout. The Internet Complete Reference . Boston: McGraw-Hill, 1994. Hall, Carl L. Building Client/Server Applications Using TUXEDO . New York: John Wiley & Sons, 1996. Hansen, David, and Michael Sebhat. “Repor ting Metadata for Access in ArcView and Across INTERNET within the ARC/INFO Data Model.” Proceedings of 1996 ESRI User Conference . Palm Springs, CA: ESRI. 1996. Hartman, Robert A., and Larry N. Sanford. “GIS Access and Marketing with Multimedia on the World Wide Web.” Fifteenth A nnual ESRI User Conference Proceedings . Palm Springs, CA: ESRI. 1995. Hoffer, Roger M., David S. Linden, and Jean ine L. Paschke. “Integration of GIS, GPS, and Remote Sensing for Inexpensive Asse ssment of Forest Insect Damage.” 61st Annual Convention of the American So ciety for Photogrammetry and Remote Sensing . Charlotte, North Carolina. 3 (1995): 571-578.

PAGE 183

167 Howlett, Virginia. Visual Interface Design for Windows: Effective User Interfaces for Windows 95, Windows NT, and Windows 3.1 . New York: John Wiley & Sons, 1996. Huber, Martin. “Multimedia Enhanc es GIS Applications.” GIS World . 7 (August 1994): 51-52. Ives, M. J., and K. J. Crawley. “GIS Im plementation Issues.” The AGI Source Book for Geographic Information Systems . London: Taylor & Francis, 1995. 39-43. Jin, Kang-Ren, John H. Hamrick, and Todd Ti sdale. Application of Three-Dimensional Hydrodynamic Model for Lake Okeechobee. Journal of Hydroulic Engineering . October, 2000. 758-771. Kaunas, Rimas J., and Scott Marr. “Integ rating ARC/INFO with INFORMIX in a Heterogeneous Client/Server Environment for Environmental Data Management.” Proceedings of the Thirteenth Annual ESRI User Conference . Palm Springs, CA: ESRI. 1.3 (1993): 503-514. Koelmel, Robert L. Implementing Applicati on Solutions in a Client/Server Environment . New York: John Wiley & Sons, 1995. Kunzmann, Michael R., Susan M. Skirvin, Peter S. Bennett, and Craig A. Wissler. “Geographical Information Systems, Remo te Sensing Techniques, and GPS-based Field Verification Methodologies for Mappi ng Vegetation Change at Chiricahua National Monument, Arizona.” Procee dings of 1996 ESRI User Conference . Palm Springs, CA: ESRI. 1996. Lange, Arthur F. “An Introduction to the Globa l Positioning System.” Proceedings of the Thirteenth Annual ESRI User Conference . Palm Springs, CA: ESRI. V2.3 (1993): 179-183. Lange, Arthur. “Precision Agriculture Syst em Requirements for GPS/GIS.” Proceedings of 1996 ESRI User Conference . Palm Springs, CA: ESRI. 1996. Laurini, Robert. “Distributed Geographic Databases: an Overview.” The AGI Source Book for Geographic Information Systems . London: Taylor & Francis, 1995. 4555. Laurini, Robert. “Sharing Geographic Inform ation in Distributed Databases.” Urban & Regional Information Systems Associ ation 1994 Annual Conference Proceedings . Milwaukee, WI. 1 (1994): 441-454. Li, Rongxing, Peter Schwarz, Michael A. Chap man, and Marcel Gravel. “Integrate GPS and Related Technologies for Rapi d Data Acquisition.” GIS World . 7 (April 1994): 41-43.

PAGE 184

168 Mackenzie, Bruce. “Technical Infrastructu re for BC Environment's Distributed Data Warehouse.” Proceedings of 1996 ESRI User Conference . Palm Springs, CA: ESRI. 1996. Maguire, David J., and Jack Dangermond. “Future GIS Technology.” The AGI Source Book for Geographic Information Systems . London: Taylor & Francis, 1995. 113120. Marmie, Amanda. “Promoting and Providing GI S Data via the Internet.” Fifteenth Annual ESRI User Conference Proceedings . Palm Springs, CA: ESRI. 1995. Martin, D. Geographic Information System s and Their Socioeconomic Applications . New York: Routledge, 1991. Meadow, Charles T. Ink into B its: a Web of Converging Media . Lanham, MD: Scarecrow, 1998. 154-165. Microsoft. The Windows Interface Guidelines for Software Design . Redmond, CA: Microsoft, 1995. Moore, Laura A., M. Roy Matsumoto, and Robert D. Holderfield. “Network Access to Geographic Names: Defense Mapping Agency Prototype to the Information Super Highway.” 61st Annual Convention of the American Society for Photogrammetry and Remote Sensing . Charlotte, NC. 2 (1995): 60-65. Nebert, Douglas D. “Implementation of Wide Area Information Server (WAIS) Software to Disseminate Spatial Data on the Inte rnet.” Proceedings of the Thirteenth Annual ESRI User Conference . Palm Springs, CA: ESRI. 1.3 (1993): 575-584. Nebert, Douglas D. “Status of the Na tional Geospatial Data Clearinghouse on the Internet.” Fifteenth Annual ESRI User Conference Proceedings . Palm Springs, CA: ESRI. 1995. Newell, Dick. “Where is GIS Technology Going?” The AGI Source Book for Geographic Information Systems. London: Taylor & Francis, 1995. 19-23. Ohtake, Toshikazu, Michima Ogawa, and Kunihiro Ishikawa. “CD Maps And Their InVehicle Application.” URISA Proceedings . Atlanta, GA: URISA. 2.4 (1993): 209-220. Olson, N. Chrystine, and Bonnie Whalen . “GIS/GPS Applications for Rangeland Analysis.” Proceedings of 1996 ESRI User Conference . Palm Springs, CA: ESRI. 1996.

PAGE 185

169 Parent P. J. “Geographic Information Syst ems: Evolution, Academic Involvement and Issues Arising from the Proliferation of Information.” Master's Thesis. University of California, Santa Barbara. 1988. Phelps, Donald J. “An Architecture for Web-based Simulation.” Master’s Thesis. University of Florida, Gainesville. 1996. Reiner, Anita. “The Benefits Of X-Terminal Based Three-Tier Client/Server Model with ESRI Applications.” Fifteenth Annual ESRI User Conference Proceedings . Palm Springs, CA: ESRI. 1995. Rumbaugh, James, Ivar Jacobson, and Gr ady Booch. The Unified Modeling Language Reference Manual. Reading, MA: Addison-Wesley, 1999. Shoham, Y. “An Overview of Agent-or iented Programming.” Software Agents . Ed. J. M. Bradshaw. Menlo Park, CA: AAAI Press, 1997. Simon, Alan R., and Tom Wheeler. Open Client/Server Computing And Middleware . Boston: AP Professional, 1995. Stephan, Eva-Maria. “Exploratory Data Visu alization for Reliable Integration.” Twelfth International Symposium on Computer-Assisted Cartography . Charlotte, NC. 4 (1995): 100-109. Strand, Eric J. “Remote Calls Open Dist ributed Environment for GIS.” GIS World . 6 (March 1993): 26-28. Sullivan, Robert G., Lorraine M. Hahn, Patrick L. Wilkey, and Ted A. Williams. “An Interactive Multimedia Approach to Presenting Environmental Impact Assessment Information for a Gas Pipelin e Right-of-Way Siting Project.” 61st Annual Convention of the American So ciety for Photogrammetry and Remote Sensing . Charlotte, NC: ASPRS. 2 (1995): 401. Szuprowicz, Bohdan O. Multimedia Technol ogy: Combining Sound, Text, Computing, Graphics and Video . Charleston, NC: Computer Technology Research Corp. 1992. Tang, Q. “Component Software and Intern et GIS.” GIS/LIS’97 Annual Conference and Exposition Proceedings . Cincinnati, OH. October 28-30, 1997. 118-121. Thoen, Bill. “Maximize Marketing Efforts on the Internet.” GIS World . 8 (August 1995): 84-85. Van Diggelen, Frank. “Access the Coast Gu ard Differential GPS Network.” GIS World . 8 (February 1995): 38-41.

PAGE 186

170 Van Liedekerke, Marc, Arwyn Jones, and Giovanni Graziani. “The European Tracer Experiment Information System: Where GIS and WWW Meet.” Fifteenth Annual ESRI User Conference Proceedings . Palm Springs, CA: ESRI. 1995. Watson, Charles C. Jr. “A Practical Worki ng Approach to Distributed Processing in Geographic Information Systems.” UR ISA Annual Conference Proceedings . Washington, D.C.: URISA. 3.5 (1992): 144-150. Weber, Christopher R., Barbara P. Buttenfie ld, and Dennis Jelinski. “A Case Study for Hypermedia Cartography: Radial Growth in Trembling Aspen at Waterton Lakes National Park.” Twelfth International Symposium on Computer-Assisted Cartography . Charlotte, NC: ASPRS. 4 (1995): 32-40. Wood, Jeffrey R. “Combining Remote Sensi ng, GPS, and GIS for Wetlands Mapping in New Jersey.” 61st Annual Convention of the American Society for Photogrammetry and Remote Sensing. Charlotte, NC: ASPRS. 2 (1995): 440-449. Zhang, Li, and Bin Li. “An Object-oriented Approach to Spatial Data Connectivity.” GIS/LIS Annual Conference and Exposition Proceedings . Cincinnati, OH. October 28-30, 1997. 111-117

PAGE 187

171 BIOGRAPHICAL SKETCH After completing a four-year undergraduate study in China in 1985, Frank Chang earned a B. Sc. in Geography from Beijing Univ ersity and taught for two years at the Department of Geography in Hubei University . He returned to Peking University for graduate study in 1997. He won a research fund and the use of lab privileges for his master thesis from the National Laboratory of Resources and Environment Information System, Academia China; and continued to wo rk there as a visiting researcher after he earned a M. Sc. in Urban and Environment Sciences in 1990. In 1993, he came to the University of Florida to pursue a Ph.D. de gree. Between 1998 and 1999, he worked at Raytheon ITSS as a senior programmer and anal yst. Since 1999, he has been working for the Lake Okeechobee Division of the South Fl orida Water Management District as a senior geographer. He is a current member of American Society for Photogrammetry & Remote Sensing (ASPRS) and the Urban and Regional Information Systems Association (URISA).


Citation
HyperGIS

Material Information

Title:
HyperGIS a concept and its applications
Creator:
Chang, Frank C
Place of Publication:
[Gainesville, Fla.]
Publisher:
University of Florida
Publication Date:
Language:
English

Subjects

Subjects / Keywords:
Character encoding ( jstor )
Conferences ( jstor )
Databases ( jstor )
Geographic information systems ( jstor )
Internet ( jstor )
Lakes ( jstor )
Software ( jstor )
Spatial data ( jstor )
Subroutines ( jstor )
Water supply ( jstor )
Dissertations, Academic -- Urban and Regional Planning -- UF ( lcsh )
Urban and Regional Planning thesis, Ph. D ( lcsh )
Genre:
government publication (state, provincial, terriorial, dependent) ( marcgt )
bibliography ( marcgt )
theses ( marcgt )
non-fiction ( marcgt )

Notes

Summary:
ABSTRACT: To envision HyperGIS -- and what HyperGIS can achieve -- is to work at the intersections of GIS, the middleware and agent technology, the object-oriented approach and the integrated user interface design. This dissertation defines and describes HyperGIS as a more efficient and reliable approach for access to heterogeneous spatial data in the rapid-changing information age. Based on a review of the evolution of GIS and client/server networking technology, this research first investigates current approaches used to access spatial information and their limitations in terms of accessibility, efficiency and reliability. The dissertation outlines the needs for a new approach to improve a future GIS, then introduces the concept and components of HyperGIS. Based on a new arrangement for converging and emerging technologies, HyperGIS uses agent technology to deliver directory service, abstraction service, messaging service and work-flow service. This approach is better than the previous approaches because it is able to access broader data sources that are dynamic and heterogeneous in a more efficient and reliable way. To demonstrate the capabilities of HyperGIS, a GIS providing Lake Okeechobee status information was implemented using the centralized, the client-server, the CGI, and eventually the HyperGIS method. The development shows an evolving process in search of new technologies to meet the increasing challenges of the real world. The stages of implementation process for each method are explained, complimented by the system diagrams and genuine code listings.
Summary:
ABSTRACT (cont.): The investigation supports the hypothesis that HyperGIS allows more effective heterogeneous information access. Overall, its directory service offers a registry where required services can be conveniently located. The use of abstraction service simplifies the process of GIS development by hiding technical details from developers and users. In addition, messaging service enables communications between client and server to be more reliable; workflow service introduces true two-way interactivity to a spatial information system where an agent can act provocatively and adaptively. Although there are obstacles and resistance to the adoption of HyperGIS due to social factors, initial costs and short-term performance concerns, the collective indications of many current integration efforts clearly point toward the direction where HyperGIS will eventually prevail. Because HyperGIS advocates a greater accessibility to massive spatial information, its adoption will evidently lead to the empowerment of previously information-poor sectors that do not have much access to the technology. As a result, the digital divide between the information rich and the information poor will be narrowed.
Summary:
KEYWORDS: HyperGIS, GIS, agent, middleware, distributed spatial system
Thesis:
Thesis (Ph. D.)--University of Florida, 2001.
Bibliography:
Includes bibliographical references.
System Details:
System requirements: World Wide Web browser and PDF reader.
System Details:
Mode of access: World Wide Web.
General Note:
Title from title page of source document.
General Note:
Document formatted into pages; contains xvi, 171 p.; also contains graphics.
General Note:
Includes vita.
Statement of Responsibility:
by Frank C. Chang.

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright Chang, Frank C. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Embargo Date:
12/15/2003
Resource Identifier:
028625226 ( ALEPH )
51340416 ( OCLC )

Downloads

This item is only available as the following downloads:


Full Text

PAGE 1

HyperGIS: A CONCEPT AND ITS APPLICATIONS By FRANK C. CHANG A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLOR IDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY UNIVERSITY OF FLORIDA 2001

PAGE 2

Copyright 2001 by Frank C. Chang

PAGE 3

This dissertation is dedicated to those who came before and helped to show the way.

PAGE 4

iv ACKNOWLEDGMENTS Many people made this dissertation possi ble and guided me during my graduate studies at the University of Florida. I woul d like to thank my committee chair, Dr. Paul D. Zwick, for his on-going support. I appr eciated the opportunity I had to work on various interesting projects at the GeoPlan Ce nter. I would also like to thank Dr. Richard H. Schneider of the Urban and Regional Pla nning Department. His conspicuous work in planning strategies and decision making grea tly affected the development of my own creative processes. I thank Dr. R. Raymond Issa of M.E. Rinker, Sr. School of Building Construction for his pioneering work and hi s recognition of the value of distributed information systems. I thank Dr. Weihe Guan of Weyerhaeuser for always stimulating and enhancing my view of HyperGIS. I would especially like to thank my committee cochair, Dr. Mary J. Hasell for her every encouragement and support of this dissertation. I also acknowledge gratefully the valuable advice from Dr. John F. Alexander of the University of North Florida and Dr. Paul A. Fishwick of the Computer & Information Science & Engineering who on ce served on my committee. Part of the implementation experience of this dissertation was enhanced by my involvement with the DIAL system being developed for NASA at the Raytheon ITSS. I appreciated the interaction with the chief sc ientist, Dr. Liping Di and other software engineers. That experience made me realize how HyperGIS could be relevant to realworld problems.

PAGE 5

v My special appreciation goes to Dr. A. S. Herath at the Institute of Industrial Science, University of Tokyo; Dr. Hui Lin at the Department of Geography, Chinese University of Hong Kong; Dr. Ron Li at th e Civil and Environmental Engineering and Geodetic Science, Ohio State University; Dr. Chu Tzu-How at the Department of Geography, National Taiwan University; and Prof. Qi Li at the Center of Remote Sensing, Peking University who generously provided forums for HyperGIS. I benefited tremendously from the critical encouragement and the sharing of experiences from other participants at the seminars, workshops a nd conferences that they organized. I am grateful for the small but vital travel gran ts provided by the Graduate Student Council, University of Florida. The case study was derived from my work experience at the South Florida Water Management District. In addition to provi ding me a challenging and fulfilling working environment, the District also directly funded my Ph.D. study through its generous Employee Tuition Reimbursement Program. I woul d like to thank the Staff and Managers of the Lake Okeechobee Department for their support, especially Dr. Richard T. James and Dr. Todd Tisdale who reviewed my manus cript and offered valuable comments and suggestions. I am indebted to many librarians at th e Marston Science Library and its Map & Imagery Library, the Architecture and Fine Arts Library, and Library West at the University of Florida. I am most thankful for access to these libraries: the Library of Congress at Washington D.C.; the McKeldin Library and the Engineering & Physical Sciences Library at the University of Ma ryland, College Park; the Doe Library, the Kresge Engineering Library, the Earth Scie nces & Map Library at the University of

PAGE 6

vi California, Berkeley; the Alachua County Li brary in Gainesville; and the Palm Beach County Library and the Palm Beach Community College Library in West Palm Beach. Finally, I am thankful to Brian Lai of the Design & Manufacture, De Montfort University at Leicester, UK for designing th e HyperGIS logo and Anne Taylor of the Editorial Office, University of Florida Offi ce of Research and Graduate Education for helping in the text.

PAGE 7

vii TABLE OF CONTENTS page ACKNOWLEDGMENTS ................................................................................................. iv LIST OF TABLES...............................................................................................................x LIST OF FIGURES ........................................................................................................... xi ABSTRACT....................................................................................................................... xv CHAPTER 1 INTRODUCTION ...........................................................................................................1 Problem Statement....................................................................................................... 2 Purpose of Proposed Research..................................................................................... 4 Intended Contributions of Dissertation........................................................................ 6 Structure of Dissertation .............................................................................................. 6 2 BACKGROUND AND RELATED WORK ...................................................................8 Geographic Information System.................................................................................. 8 Client/Server Architecture and the Internet................................................................. 8 Client/Server Architecture ....................................................................................... 8 Internet. ....................................................................................................................9 Internet and GIS.......................................................................................................... 11 Limitations of the Existing Approaches ..................................................................... 18 Expected Characteristics for a Future GIS.................................................................. 19 3 CONCEPT OF HyperGIS...............................................................................................23 HyperGIS: Defining a Future GIS.............................................................................. 23 GIS Components......................................................................................................... 26 Components of HyperGIS ........................................................................................... 26 Usefulness and Significance ....................................................................................... 29 Application Areas ....................................................................................................... 30 4 METHODS OF HyperGIS DESIGN AND IMPLEMENTATION................................32 Background of the Case Study.................................................................................... 33 Regional Background .............................................................................................. 34 Challenges............................................................................................................... 34 System Design ............................................................................................................ 42 Process of an UML Design. .................................................................................... 42

PAGE 8

viii Phases of System Design and Implementation...................................................... 43 Centralized Method of GIS Development ................................................................. 44 Discovering Theme Data and Their Attributes...................................................... 46 Examining Spatial Functions................................................................................. 47 Designing Graphical User Interface....................................................................... 49 Connecting the Information Flow.......................................................................... 51 Measuring System Performance ............................................................................ 60 LOSAC as a Centralized GIS ................................................................................ 60 Client-Server GIS Method......................................................................................... 65 Identifying Data Distribution and Attributes......................................................... 66 Allocating Functions.............................................................................................. 67 Designing Graphical User Interface....................................................................... 69 Connecting Information Flow................................................................................ 71 Measuring System Performance ............................................................................ 71 LOSAC as a Client-Server System........................................................................ 71 CGI GIS Method........................................................................................................ 74 Collecting Inquiry Parameters ............................................................................... 76 Obtaining Remote and Local Data......................................................................... 77 Applying Spatial Functions ................................................................................... 77 Organizing HTML Outputs.................................................................................... 77 Measuring System Performance ............................................................................ 77 LOSAC as a CGI-GIS............................................................................................ 78 HyperGIS Method...................................................................................................... 81 Setting-up Directory Service and Abstraction Service.......................................... 83 Enhancing System Reliability................................................................................ 84 Dynamic Function Allocation................................................................................ 85 Defining DTD and Organizing XML Outputs....................................................... 85 Implementing Workflow Service........................................................................... 90 Customizing Presentations with Style Sheets........................................................ 92 Measuring System Performance ............................................................................ 93 5 RESULTS AND DISCUSSIONS..................................................................................94 Customizable Presentations ....................................................................................... 94 Comparing Simulation Results with Ground Truth and Satellite Images ............... 101 Evaluation of System Performance.......................................................................... 107 Comparison Between HyperGIS and Other Approaches......................................... 112 6 CONCLUSIONS AND RECOMMENDATIONS ......................................................113 Benefits of HyperGIS .............................................................................................. 115 Obstacles and Resistance to Adoption of HyperGIS............................................... 118 Limitations and Future Implementations................................................................. 119 Lessons Learned ....................................................................................................... 120 Recommendations for Future Research................................................................... 121 Impacts of HyperGIS on Digital Divide.................................................................. 123 GLOSSARY ....................................................................................................................125

PAGE 9

ix APPENDIX CODE LISTING..........................................................................................................132 LIST OF REFERENCES.................................................................................................163 BIOGRAPHICAL SKETCH ...........................................................................................171

PAGE 10

x LIST OF TABLES Table Page 1 Features of Centralized GIS...............................................................................................64 2 Features of Client-Server GIS............................................................................................73 3 Features of CGI GIS ......................................................................................................... .80 4 Abbreviations of Field Data...............................................................................................88 5 Document Type De finition in XML ..................................................................................89 6 Format of XML Document................................................................................................89 7 Water Shortage Web Log..................................................................................................108 8 Features of HyperGIS .......................................................................................................112

PAGE 11

xi LIST OF FIGURES Figure Page 1 Compass and Survey in Ancient China ..............................................................................2 2 Structure of Centralized GIS...............................................................................................3 3 Problems Encountered in A ttempts to Integrate GIS..........................................................4 4 Structure of HyperGIS........................................................................................................5 5 Number of Identified Internet Hosts..................................................................................10 6 Common Gateway Interface and GIS................................................................................15 7 Internet Map Server of ESRI .............................................................................................16 8 Structure of ArcIMS Server...............................................................................................17 9 HyperGIS Logo............................................................................................................... ...24 10 Timelines of Notable Events............................................................................................25 11 Components of a Geographic Database...........................................................................26 12 Components of HyperGIS................................................................................................27 13 Banner of the LOSAC Application..................................................................................32 14 Space Image of Lake Okeechobee...................................................................................33 15 South Florida Water Mana gement District Boundary .....................................................35 16 Lake Okeechobee under Hu rricane Andrew’s Impact.....................................................36 17 Agriculture Irrigation in th e Lake Okeechobee Surrounding Area .................................36 18 Fishing at Lake Okeechobee............................................................................................37 19 Boating at Lake Okeechobee ...........................................................................................37 20 Atlantic Coast to Gulf Coast Waterway...........................................................................37

PAGE 12

xii 21 Water Shortage Awareness Campaign.............................................................................38 22 Lake Stage between 1/1/2000 and 9/30/2001..................................................................38 23 Exposed Drainage Pipe that wa s usually Submerged in the Lake...................................39 24 Dry Ending of the Pierce Canal in April 2001.................................................................39 25 Recreation Guide to Lake Okeechobee............................................................................40 26 South Florida Water Manage ment District Facilities ......................................................41 27 Use Case Diagram of LOSAC as a Centralized GIS.......................................................45 28 Grids of the Elevation Data..............................................................................................46 29 Attribute Table of LO_1KMSTAGE89.SHP...................................................................47 30 Interface Design: Form Layout........................................................................................48 31 Interface Design: Menu....................................................................................................4 9 32 Common Dialog Control and Image List Control ...........................................................49 33 Interface Design: Command Buttons...............................................................................50 34 Activity Diagram of Loading the Main Form..................................................................52 35 Class Module: RenderLayers.BAS..................................................................................53 36 Activity Diagram of Show_Stage....................................................................................54 37 ToolTipText Shown on the Slide Bar..............................................................................55 38 Activity Diagram of Classify_Stage................................................................................56 39 Lake Area Calculation .....................................................................................................5 7 40 Lake Capacity Calculation...............................................................................................58 41 Activity Diagram of CalcFeatureClass.BAS ...................................................................59 42 Initial Display of Centralized LOSAC.............................................................................61 43 Lake Status at 9 Feet...................................................................................................... ..61 44 Menu, Shortcut and Command Button for Displaying Lake Area ..................................62 45 Potential Capacity between 8.9 and 8.5 Feet...................................................................62

PAGE 13

xiii 46 Confirmation Window to Quit Program ..........................................................................63 47 Use Case Diagram of Client-Server GIS .........................................................................66 48 Text Report of Field Data ................................................................................................67 49 Classes of LOSAC-RT.....................................................................................................68 50 Interface Design: LOSAC-RT .........................................................................................69 51 New Menu Item and New Command Button of LOSAC-RT..........................................70 52 Routine to Get Real Time Data........................................................................................70 53 Result of Real Time Lake Status .....................................................................................72 54 Use Case Diagram of CGI GIS........................................................................................74 55 Classes of LOSAC_CGI ..................................................................................................75 56 Visual Basic Modules of LOSAC-CGI............................................................................76 57 Output of LOSAC-CGI....................................................................................................78 58 Error Message of Common Gateway Interface Program.................................................79 59 Use Case Diagram of HyperGIS......................................................................................81 60 Agent and HyperGIS........................................................................................................8 2 61 Basin Boundary and Image Data as Background ............................................................83 62 Program LOSAC-C Quits Due to Input Error .................................................................84 63 Type Checking for Textbox Input....................................................................................84 64 Raw Field Data for the Lake............................................................................................86 65 Agent: Generating XML Data .........................................................................................87 66 Reformat Raw Data with DTD ........................................................................................87 67 Listing of LOSTATUS.XML...........................................................................................89 68 Agent: Generating Ar ea and Capacity Data.....................................................................90 69 Activity Diagram of Timer ..............................................................................................91 70 Timer Cont rol on GUI .....................................................................................................92

PAGE 14

xiv 71 Applying CSS or XSL to XML Document......................................................................93 72 Rendered XML Document: Report with Table ...............................................................95 73 Lake Status Rendered by DHTML ..................................................................................96 74 Rendered DHTML Page for Lake Status Lookup ...........................................................97 75 Rendered DHTML Page for Lake Okeechobee Time Series...........................................98 76 Water Supply Calculator..................................................................................................99 77 Lake Condition Broadcasted to a WAP-enabled Cellular Phone ....................................100 78 Lake Condition Beamed to a PDA via IR........................................................................101 79 Simulated Lake Extent and SeaWiFS Image on May 28, 2000......................................102 80 Simulated Lake Extent and MISR Image on October 18, 2000 ......................................103 81 Simulated Lake Conditions and Aerial Photo over S135 ................................................104 82 Simulated Lake Conditions a nd Aerial Photo over Eagle Bay........................................105 83 Aerial Photo over Turner's Cove on June 30, 2001 .........................................................106 84 Simulated Lake Conditions on June 30, 2001 .................................................................106 85 Performance Comparison for One Execution..................................................................107 86 Performance Comparison for Daily Executions ..............................................................109 87 Performance Comparison for Monthly Executions .........................................................110 88 Comparison of Middleware and Other Approaches ........................................................111 89 Same Data Many Faces....................................................................................................113 90 Caching Mechanism to Provide Backup Data .................................................................114 91 Relationship between Complexity and Labor Cost .........................................................116 92 User Bases of Different Approaches................................................................................117 93 Interaction between Distributed Data, Functions and Developments..............................121 94 Bridging Information Poor and Information Rich ...........................................................124

PAGE 15

xv Abstract of Dissertation Pres ented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy HyperGIS: A CONCEPT AND ITS APPLICATIONS By Frank C. Chang December 2001 Chair: Paul D. Zwick Cochair: Mary J. Hasell Major department: Urban and Regional Planning To envision HyperGIS – and what HyperG IS can achieve – is to work at the intersections of GIS, the middleware and ag ent technology, the object-oriented approach and the integrated user interface design. This dissertation defines and describes HyperGIS as a more efficient and reliable approach for access to heterogeneous spatial data in the rapid-changing information age. Based on a review of the evolution of GIS and client/server networking technology, this research first investigates current approaches us ed to access spatial information and their limitations in terms of accessibility, efficiency and reliability. The dissertation outlines the needs for a new approach to devise a future GIS, then introduces the concept and components of HyperGIS. Based on a new arrangement for converging and emerging technologies, HyperGIS uses ag ent technology to deliver directory service, abstraction service, messaging service and work -flow service. This approach is better

PAGE 16

xvi than the previous approaches because it is capable of accessing broader data sources that are dynamic and heterogeneous in a more efficient and reliable way. To demonstrate the capabilities of H yperGIS, a GIS providing Lake Okeechobee status information was implemented using the centralized, the client-server, the CGI, and eventually the HyperGIS methods. The develo pment shows an evolving process in search of new technologies to meet the increasing ch allenges of the real world. The stages of implementation process for each method are explained, complimented by the system diagrams and genuine code listings. The investigation supports the hypothesis that HyperGIS allows more effective heterogeneous information access. Overall, its directory service offers a registry where required services can be conveniently located . The use of abstraction service simplifies the process of GIS development by hiding techni cal details from developers and users. In addition, messaging service enables communica tions between client and server to be more reliable; workflow service introduces true two-way interactivity to a spatial information system where an agent can act provocatively and adaptively. Although there are obstacles and resistance to the adoption of HyperGIS due to social factors, initial costs and shortterm performance concerns, the collective indications of many current in tegration efforts clearly poin t toward the direction where HyperGIS will eventually prevail. Because H yperGIS advocates a greater accessibility to massive spatial information, its adoption will evidently lead to the empowerment of previously information-poor sectors that do not have much access to the technology. As a result, the digital divide between the inform ation rich and the information poor will be narrowed.

PAGE 17

1 CHAPTER 1 INTRODUCTION It is increasingly challenging for urban and regional planners to manipulate, analyze and process data becau se spatial analysis involves handling extensive spatial and nonspatial data. Roger Tomlinson first introduced the term of geographical information system, or GIS, to the Canadian Geographical Information System in 1964; by the 1980s GIS had gradually gained its reputation as a useful tool in dealing with spatial information. In the 1970s, remote-sensing technology opened a new horizon for data acquisition. As a result, massive volumes of new data with unprecedented temporal, spectral, and spatial resolution are being obtai ned. Information overload made it not only impossible but also unnecessary to capture and manipulate all the incoming information at one central location. Thus the 1990s w itnessed rapidly growing interests in the application of GIS in a client/server environm ent. Despite many attempts to integrate GIS with other state-of-the-art technologies, efficient and re liable access to heterogeneous data in an instantly changing environment re mains a challenge. Moving toward resolving this problem is the focus of this dissertation. HyperGIS is the term proposed to describe this new concept for coordinating information resources and services. The new concept is a middleware approach that forms a bridge between the various information providers and the individual end users. One test for this new concept, HyperGIS, is to examine the evolving process of implementing a GIS on Lake OkeechobeeÂ’s status using the centralized, the client-server, the Common Ga teway Interface (CGI) GIS, and eventually the HyperGIS methods.

PAGE 18

2 Problem Statement Geographic information, in its simplest form, is information that relates to specific locations. By nature, it is heteroge neous and usually instantly changeable. For example, there are several different types of geographic information relating to a typical navigation system. The physical environmen t is represented by information about background elevation, weather, vegetation and road network. The current position, velocity, heading and course define the cu rrent moving object. In addition, there are aspects of the socioeconomic and culture environment, such as services rendered at points of interest, which cannot be observed directly, but are also truly geographic in nature. Therefore, those events and phenomen a can be abstracted to point, line, polygon and characterized information for manipulat ion and presentation in time series. Using geographical information and tec hnology in planning is nothing new. An ancient Chinese illustration shows that a Fe ngshui master (planner) was using a compass to survey a site for a new city (Figure 1), along with the Taibao (mayor) and his assistants. Figure 1. Compass and Survey in Ancient China

PAGE 19

3 Nowadays, one usual way of handling ge ographical information is to build a centralized GIS (Figure 2). GI S can analyze spatially refere nced data and convert them into information for a specific set of purpose, or application. The ke y feature of a GIS is its analytic capability of producing new info rmation based on spatia l data (Parent 1988). Figure 2. Structure of Centralized GIS A centralized GIS maintains its database , modeling function and user interface at one location. While maximum efficiency and re liability can be achieved, there are serious limitations to keeping the database and mode ling function current si nce a centralized GIS does not allow access to external information sources. As the number of Geographic Information Systems of all kinds installed all over the world is increasing, the need to share information in different existing databases becomes prominent in order not to duplicate existing data and to benefit from the newest updates located in other databa ses (Lurini 1995). To perform sp atial analysis in a network environment, client/server GIS approaches ha ve been introduced. For example, a simple client/server GIS approach, in particular, the CGI-based Internet GIS approach that uses

PAGE 20

4 the Common Gateway Interface protocol, evokes remote data and function servers according to query from a user, then delivers the result back to the user for display. While the requirement of having instant access to a database could be fulfilled by such an approach, it usually takes too much bandw idth as large amounts of data including graphics need to be transmitted. Therefore its application is limited when bandwidth is scarce, which is still true in a mobile or wireless environment so far. Figure 3. Problems Encountered in Attempts to Integrate GIS In addition, both the centralized GIS a pproach and the CGI-based Internet GIS approach have a limited capacity for dealing wi th heterogeneous data . Unreliable network connectivity is also a problem for the CGI-based Internet GIS approach (Figure 3). Purpose of Proposed Research This dissertation proposes a more effi cient and reliable way to manage, manipulate and present spa tial related information that is both dynamic and heterogeneous in nature. This will be accomplished by introducing the concept of

PAGE 21

5 HyperGIS. A HyperGIS adopts a middleware arch itecture that uses agents to coordinate several components of distributed GIS databa ses, functional servers and Multimedia User Interface in an object-oriented deve lopment environment (Figure 4). Figure 4. Structure of HyperGIS This research is concerned with inves tigating and demonstrating both the concept and the feasibility of HyperGIS. A HyperGIS allows access to heterogeneous spatial data in a dynamic environment more efficiently and reliably than current existing systems. By presenting HyperGIS as a middleware system, consisting of a collection of distributed software agents that can manage distributed processing of spatial data by maintaining directory service, abstraction service, messa ging service and work-flow service, the term HyperGIS is defined and its characteristics are identified. Consequently, for the purpose of demonstrating the framework and the prin ciple of HyperGIS, comparisons have been made for different approaches to implement a GIS querying the current status of Lake Okeechobee1. 1 Disclaimer: All the data and resulted presentations in this dissertation are for the sole purpose of demonstrating the architecture a nd behaviors of HyperGIS. Therefore, they are NOT suitable for any other purposes and may NOT be used for policy making before further calibration.

PAGE 22

6 Intended Contributions of Dissertation The primary contribution in tended is to demonstrate how HyperGIS can function as middleware to provide more efficient and reliable access to dynamic and heterogeneous data. My investigation yields general principles that have the following specific consequences. As a second-generation client-server ar chitecture, middleware ensures that the most flexible and efficient solutions to ha ndle information are likely to be achieved by assigning appropriate portions of functions between the clie nts and servers within an environment. Secondly, Internet agents make it easy to have access to a large number of information servers and function servers fo r a HyperGIS by using directory service. Agents can also provide translation servi ce for different data protocols. Meanwhile, HyperGIS makes information more accessible to other developers and the public by hiding technical details and specification of spatial databases. Furthermore, HyperGIS provides a more efficient way to deliver information by adopting a multimedia user interface. With wireless network connections an d GPS, HyperGIS is able to perform realtime spatial analysis and modeling, and to provide two-way interactivity. Last but not least, HyperGIS can improve a system's reliability by using local/network caches and mirror sites. These principles provide a list of criteria that HyperGIS must perform when it is operational. This dissertation outlines th e theoretical steps to be taken to achieve a HyperGIS and demonstrate the feasibility of such a concept in a case study. Structure of Dissertation The Centralized GIS approach and the In ternet GIS approach are reviewed as Background and Related Work where their limitations are discussed. Then the expected

PAGE 23

7 characteristics of a future GIS are introduced. Next in the Concept of HyperGIS , the concept of HyperGIS is proposed as a bette r and more efficient access to heterogeneous spatial information. Consequently middlew are architecture and agent technology, which extend the foundation for the concept of HyperGIS, are discussed. In the Method of HyperGIS Design and Implementation a case study is presented with the comparisons of implementing a GIS with four different met hods: the centralized, the client-server, the CGI GIS, and the HyperGIS methods. The preliminary results accomplished are illustrated; are discussed in the Results and Discussions . System performance is evaluated; comparisons are made between H yperGIS and other approaches. The benefits of HyperGIS, obstacles and resistance to a doption of HyperGIS, the limitations and the proposed future research ac tivities; lessons learned fr om the past experience; recommendations for future research; and the impacts of HyperGIS on the digital divide are among a few challenging topics examined in Conclusions and Recommendations .

PAGE 24

8 CHAPTER 2 BACKGROUND AND RELATED WORK Geographic Information System A GIS is a system of computer hardware , software, and procedures designed to support the capture, management, manipulati on, analysis, and display of spatially referenced data for solving complex pl anning and management problems (Federal Interagency Coordinating Committee 1988). In general, a GIS is any information management system that can do the following: Collect, store, and retrieve information based on its spatial location, Identify locations within a targeted envi ronment that meet specific criteria, Explore relationships among data se ts within that environment, Analyze the related data spatially as an aid to making decisions about that environment, Facilitate selecting and passing data to app lication-specific analytical models capable of assessing the impact of alternativ es on the chosen environment, and Display the selected environment both graphi cally and numerically either before or after analysis. Most GIS applications can be categorized into one of four distinct types: spatial organization of information, exploratory sp atial analysis, site modeling, and spatial decision-support systems (Goodchild 1991). Client/Server Architecture and the Internet Client/Server Architecture A client/server architecture is an appr oach to computing that has separate processes on separate platforms interacti ng with each other. Th e sharing of these

PAGE 25

9 resources takes the best advantage of each devi ce. It is basically a form of distributed computing or networked computing (Bochenski 1994). It is important to note that the term client/s erver first started to be used in articles and advertisements in trade journals where ve ndors were defining the term in a way that was most beneficial for their own pro ducts. In turn, it led to many different interpretations of the term c lient/server computing. Client/Server technology has rapidly gained a good reputation because it allows the use of lower cost hardware, supports scalability of the system, supports better fault-tolerant systems, provides easier management of distributed data, and supports Graphic User Interface (GUI) front ends that make user interfaces better and smarter (Hall 1996). With client/server architecture, separate processes reside on different platforms and interact by means of networking to acco mplish computing objectives. The client is sometimes referred to as the front end, whereas the server is called the back end. Oneway communication exists between both ends. The front end makes a request to the back end; the back end processes the request (Koelm el 1995). In other words, in a client/server system, a client process makes requests of th e server process, a nd the server process services those requests. Client and server processes generally reside on separate platforms, permitting them to share resources while taking the best advantage of different platforms and devices (Bochenski 1994). Internet The Internet is an extensive cluster of world-wide-linked computer networks for global communications. It consists of over 8,000 separate networks that are interconnected with such protocols as Tr ansmission Control Protocol and Internet Protocol (TCP/IP) into the huge, wo rld-wide network (Bochenski 1994).

PAGE 26

10 The roots of the Internet lie in a coll ection of computer networks called the Advanced Research Projects Agency Network (ARPANET) that was sponsored by the United States Department of Defense ( DOD) in the 1970s (Hahn and Stout 1994). The ARPANET was a computer network which consis ted of tens of thousands of computers developed by the Advanced Research Projects Agency (ARPA) in the 1960s to permit universities and research organizations to exchange information. Although it was sponsored by the DOD, the ARPANET was not a classified network, nor was it dedicated to military research only. The ARPANET was one of the InternetÂ’s backbone networks in 1977. The original ARPANET has long since been expanded and replaced, and the protocol research conducted by ARPA made a significant contribution to the evolution of TCP/IP on which the Internet is based. Figure 5. Number of Identified Internet Hosts

PAGE 27

11 The Internet is growing c onstantly with usage estimated as having doubled every year since 1988. Its growth is expected to continue. In this sens e, it is an obvious and irresistible market. In theory, millions of pe ople can be reached worldwide for little cost (Thoen 1995). From 213 identified hosts as of August 1982 to 6,642,000 identified hosts as of August 1995 to 109,574,429 identified hosts as of January 20012, the Internet has opened a new horizon for the GIS community because it presents massive inter-linked external data resources and the capacity to perform spatial analysis over long distances (Figure 5). Internet and GIS There are grounds to believe that the potential of the information highway is particularly exciting for geographic data (Goodchild 1995). Before long, the GIS Community started to embrace the new dimens ion brought by distributed computing and the Internet. As Robert Laurini noted, th e number of Geographic Information Systems (GIS) of all kinds installed all over the worl d is increasing. Among the important features of future GIS will be the need to share information in different databases. The first goal will be to avoid duplication of existing data while benefiting from the newest updates from other databases. The main challenge facing distributed databases will be the creation of networks of geographic databases that are updated daily for several activities, in other words combining updating and sharing (Laurini 1995). Especially critical will be the sharing geographic information among several institutio ns by means of distributed databases via client/server architectures. It is advocated th at in the future, the interoperability of heterogene ous GIS will be very common (Laurini 1994). 2 http://www.isc.org/ds/host-count-history.html

PAGE 28

12 Examples of attempted distributed GIS range widely from on-line place-name query systems (Moore, Matsumoto, and Holderfield 1995), X-based three-tier client/server models (Reiner 1995), X-window-b ased Unix systems for direct GIS access by PC (Watson 1992), using Distributed Computing Environment (DCE), Remote Procedure Call (RPC) (Strand 1993) and In ter-Application Communication (IAC), to distributed data warehouses that provide online access to metadata through the World Wide Web (Mackenzie 1996; Hansen and Sebha t 1996). As shown by those efforts, the GIS community acknowledges that in the gr owing world of GIS, integration of heterogeneous systems has become commonplace. Integrating with high-level Relational Database Management Systems (RDMS) is becoming increasingly popular. Developers start to look into specific project needs as the driving force for integration and the resulting increase in efficien cy (Kaunas and Marr 1993). The U.S. Geological Survey’s (USGS) spatial data clearinghouse is another early attempt at using the Internet to foster the discovery and retrieval of digital spatial data among federal and non-federal users. It uses the Wide Area Information Server (WAIS) protocol to provide earth-science data users with a consistent inte rface to spatial data holdings. The WAIS system runs on multiple platforms that include X-Windows-based UNIX workstations, IBM-compatible personal computers, and Apple Macintosh computers. Clients may query information servers across the Internet using an American National Standards Institute (ANSI) and Na tional Information Standards Organization (NISO) standard (Z39.50) that permits clie nt-to-server communica tion without requiring user names and passwords. The result of a query may be a portion of a document, a listing of available sources, an image of a da ta set, a computer program, a full or partial

PAGE 29

13 data set, or virtually any other format of information that may be transferred digitally (Nebert, 1993). The World-wide Web, or WWW, is a hypertext-based information and communications application system running on the Internet for information dissemination and collection according to a client/server model. In 1989, CERN European Organization for Nuclear Research began developing the Web technology to enable physicists around the globe to communicate more effectively using hypertext. In August 1991 the Web technology was first publicly released. In February 1993, the National Center for Supercomputing Applications at the University of Illinois (NCSA) published Mosaic, the first graphi cal browser for the Web. Since then, the Web has grown at a phenomenal rate. It became the second largest so urce of traffic on the In ternet in less than two years. The World-wide Web provides GIS a mechanis m for sharing GIS data. At first, it was naturally used to disseminate GIS documentation such as metadata, data dictionary information, history, and custodial info rmation (Conquest and Speer 1996) and to conduct GIS-related surveys (Chang and Hasell 1996). For example, considering the Web an in creasingly convenient medium for data promotion and transfer, Boulder County GIS us es the Web to promote its Assessor Parcel data, thematic layers and metadata with informative pages and graphics. Then users are able to download the interested data via File Transfer Protocol (FTP) (Marmie 1995). Such web sites exhibit the digital equivalent of hard-copy maps and paper reports. While primitive in terms of interactivity, they do repr esent the first efforts to distribute spatial information on-line.

PAGE 30

14 As a result of the President’s Executive Order 129063 in April 1994, Federal agencies in the U.S. started to participate in the development of the National Spatial Data Infrastructure (NSDI) -a system to facilitate the discovery of and access to digital spatial information. To promote access to informati on in the NSDI, the National Geospatial Data Clearinghouse was created to coordinate spa tial data services on the Internet. As of January 1995, Federal agencies with signifi cant digital spatial data holdings were required to begin serving descriptive informa tion for published data in a searchable form on-line. A number of Federal, State, and uni versity participants ha ve also provided links from descriptive data (metadata) to actual data sets so that they may be retrieved directly from the Internet by the public (Nebert 1995). The potential of the World-wide Web as a vehicle for distributing GIS-related information started to attract more and mo re attention (Hartman and Sanford 1995). For instance, users can visit the web site of Ca barrus County, NC for information on parcel boundaries, roads, road centerlines, hydrogra phic network, munici pality limits, voting precincts, house districts, voting locations, EM S districts, fire dist ricts, infrastructure (Major Gas, Power, Telephone, Rail Lines), sc hool districts, school locations, existing zoning, water lines, sewer lines, sewer basi n boundaries, township boundaries, watershed boundaries, 1990 census tracts and blocks, 25foot topographic cont ours, floodplains, and soils, etc4. As the World-wide Web gained popular ity, frequently-updated dynamic maps soon overtook the static ones on the Web in orde r to present the spatial information that changes over time. For interactive mapping, GIS generates maps on-the-fly according to 3 http://www.nara.gov/fedreg/e xecutive_orders_pdf/eo12906.pdf 4 http://www.co.cabarrus.nc.us/Pages/GIS/index.html

PAGE 31

15 the queries specified by the users from the web interface. The CGI-based Web GIS became a common solution (Chang and Fishwick 1997). Figure 6. Common Gateway Interface and GIS In CGI-based Web GIS, by establishing a connection with a GIS (Arc/Info) server, as shown in Figure 6, the WWW client submits a task to Arc/Info server via CGI. The Common Gateway Interface, or CGI, is an interface for running external programs, or gateways, under an information server su ch as Hyper Text Transfer Protocol (HTTP) servers to handle information requests and retu rn the appropriate documents or generate a document on the fly. Gateways conforming to this specification can be written in C/C++, PERL, Bourne Shell and C Shell that can produce an executable file. With the IAC functionality in Arc/Info, it is now possible to communicate between a CGI program and a GIS server. Jonath an Groff (1996) also reported a similar

PAGE 32

16 approach to construct gateways for any da tabase management system that supports a Call-Level Interface (CLI) or Application Programming Interface (API). The Arc/Info client can request that the Arc/Info server perform network simulation to generate a Route Attribute Table (RAT) ba sed on the user-given origin, stops, and destination. This information is obtained from the IAC procedur e. Then the resulting route is added to the View as a new Theme . The RAT keeps track of the optimized route and generates a map with the selected background themes dynamically. Other examples of the CGI-based Web GIS include the European Tracer Experiment Information System (Van Liedekerke, Jones, and Graziani 1995); the National Environmental Database (NED) by the Army National Guard and Utah State University (Biggs et al 1995); Information Center for the Environment for public access to natural resource data usi ng an interactive query system (Beardsley and Quinn 1996) and a population estimation application (Block 1995). Figure 7. Internet Map Server of ESRI (ESRI) In late 1997, Environmental Systems Research Institute, Inc. (ESRI) at Redland, California began to offer the Internet Ma p Server, featuring client/server request management and load balancing capabilitie s. The MapObjects Internet Map Server, designed for Windows developers, extends the power of MapObjects to serve maps over

PAGE 33

17 the Internet. Applications built with the MapO bjects Internet Map Server extension can access spatial data formats supported by MapO bjects such as shapefiles, coverages, Spatial Database Engine (SDE) layers, and many graphic images. In addition, MapObjects Internet Map Server includes a Web server extension that works with Netscape Server and Microsoft Internet Information Server (Figure 7). The Web server extension provides a fr amework for request management and load balancing that provides fast, effici ent, and scaleable map serving capability. Interactive maps can be created from a number of different t ypes of spatial data including shapefiles, coverages, SDE layers, Auto CAD’s DWG and DXF, MicroStation’s DGN, and a variety of graphic images (ESRI 1997). Figure 8. Structure of ArcIMS Server (ESRI) ESRI’s new ArcIMS uses a more powerf ul multi-tier architecture to manage clients, services, and data. It allows users to integrate local data sources with Internet data sources for display, query, and analys is in an easy-to-use Web browser5 (Figure 8). Other 5 http://www.esri.com/software/arcims/index.html

PAGE 34

18 successful Internet GIS examples involve using Component Object Model (COM) (Tang 1997), JavaBeans (Zhang and Li 1997) and Jshape6. Limitations of the Existing Approaches Since a centralized GIS is a standalone system, it does not provide external data and function access that is crucial for inst ant update and real-time analysis. While Internet GIS represents anot her great opportunity to expa nd the technology to a wide range of users, currently, most of webbased GIS systems are based on a traditional client/server model and make no use of the In ternet potential -a real distributed open system (Tang 1997). Those systems simply use the Common Gateway Interface prot ocol or Internet Map Extension (IME) to evoke re mote data and function servers according to a query from a user, then deliver the result back to user for display. While the requirement of having instant access to a databa se could be satisfied by such an approach, it usually takes a very large amount of bandwidth as it i nvolves transmission of large amounts of data. Therefore its application is limited when bandwidth is scarce, which is especially true in a mobile/wireless envir onment. In addition, both the centralized GIS approach and the CGI-based Internet GIS appr oach have very limited capacity for dealing with heterogeneous data. Unreliable network connectivity may as well impose additional problems to the CGI-based Internet GIS approach. To realize the true potential of the dist ributed open system, a search for a more efficient solution is eminent. To recommend a better solution, the characteristics of a future GIS needs to be determined. 6 http://www.jshape.com

PAGE 35

19 Expected Characteristics for a Future GIS Progress in the GIS industry is driven from two ends: customer demands and technological advance (Newell 1995). These two factors are good indicators of the expected characteristics of a future GIS trend. For example, the effort of integrating different kinds of GIS data illustrates the demand for directory service. As Eva-Mari a Stephan (1995) stated, the modeling of environmental data and processes with GIS requires integration of many heterogeneous data sets. Data integration therefore ofte n requires preprocessing of data, such as subsetting, upand downscaling, interpolat ion, merging, format conversion, reprojecting, and/or overlay, to establish compatibility and greater reliability. Jeffrey Anderson (1994) also emphasized the importance of a well-planned and comprehensive database directory structure sy stem in GIS. In the case of the countywide GIS at Snohomish County in Washington Stat e, the system-wide directory structure design has the following attributes: 1) incremental implementation and expansion in both stand-alone and network environments, suppor ting both Unix workstations and personal computers, 2) functioning in a multi-departmental work environment spanning many professional fields, yet refe rencing a common centrally sh ared database, 3) ease of learning and use for both novices and experi enced GIS personnel, and 4) ease of management and database administration. The consensus was that if designed effectively and if implemented early, a good directory stru cture could help fac ilitate the success and growth of the GIS now and through the years to come. In addition, John D. Evans and others present a scheme for cataloging and browsing through a large number of diverse data files using metadata representations to respond to the demands for managing and accessing heterogeneous information in a

PAGE 36

20 timely and direct manner. A workstation-base d browsing tool is used to provide an intuitive and interactive gra phic interface to the metadata. The metadata describes the characteristics of each spatial-data item: da ta-type, history, spatial extent, etc. By performing simple transformations on these characteristics, the browser provides an integrated view of available spatial data, wh ile leaving data items in their native formats and coordinate systems (Evans, Ferreira Jr ., and Thompson 1992). Also notable is Adam Game and Stephen Owens’ (1995) effort on integration of GIS with interactive multimedia directory services. The need for abstraction se rvice is illustrated by following the developments of a knowledge-based interface agent whose mission is to help users without knowledge of ARC/INFO to access and process spatial data stored in ARC/INFO databases. The interface agent, using a client-server sche ma and operating on a Local Area Network (LAN) or Wide Area Network (WAN) network, receives and proce sses requests written in plain English, interacting with the user in case of possible mismatches between his/her concepts and the representation of data in the ARC/INFO database. The agent builds and sends sequences of commands oriented to pr ovide the information requested by the user to an ARC/INFO server, then receives and pr esents the results of those requests to the user (Campos, Naumov, and Shapiro 1996). In the attempt to identify the longstanding problem that has hindered integration of different hydrologic models, Dean Djokic and his colleagues noted that the major problem is the lack of a consistent and sta ndard way of exchanging data between GIS and models, as well as between the models themselves. Their proposed solution is a form of generic, non-proprietary data exchange file formats that would allow different users of hydrologic data (GIS, hydrologic or economic mo dels, etc.) to exchange data regardless

PAGE 37

21 of the source, type, or nature of the data , or the platform on which the data were generated. The exchange file format woul d be open-ended and flexible to accommodate expanding data types and supported programs. It would be maintained on-line to enable easy and timely access, and would be open for discussion to users and developers (Djokic, Coates, and Ball 1995). A portable customized GIS for improving the effectiveness of treaty inspections, developed by the U.S. Department of En ergy's Pacific Northwest National Laboratory and the U.S. Department of Energy's Remote Sensing Laboratory, is an indication of the need for mobility and capacity of managing a variety of devices and information sources. The system, called Team Leader, uses an ArcView interface to integrate GPS, multimedia, and advanced communication technologie s to provide remote users with on-line access to vital data needed during treaty insp ections. Team Leader provides the capability to access previous inspection data (e.g. maps, aerial photographs, reports, photographs, equipment information, and voice notes) for fast and efficient briefings prior to the inspection and for real-time data retrieval during the inspection. An inspector can use Team Leader to capture positional data, digital photographs, voice notes, equipment information, and text reports georegistered to the inspector's position or a selected feature in real-time during the inspection. Insp ection teams can employ Team Leader to communicate with each other, display inspect ion team positions, automatically send new data, and transfer requested data between teams. Team Leader is implemented on two different hardware platforms, a Suitcase Un it using a laptop PC for on-site inspections and a Personal Unit using a belt-mounted PC with a miniaturized "heads-up" monocular display for in-facility inspections. Although Team Leader was created to support treaty inspections, it was directly applicable to a wide range of field-based data collection

PAGE 38

22 applications, including environmental field coll ection, surveillance activities, and utilities management (Evans et al 1996). Keith Ghormley envisioned the next genera tion of GIS as one integrated system: data collection from diverse sources, anal ysis and preparation processes, complex visualization tools and accessible pres entation methods for non-technical users (Ghormley 1995). From the discussions about se parate integration efforts, the conclusion is that in a distributed GIS environment, defining an effective means to register geographic entities will be crucial. In addition, distributed GIS software must also be able to deal with different spatial data formats at the run time. Furthermore, it is equally crucial to intelligently allocate resources be tween client and server to reduce network traffic. Since the middleware architecture and ag ent technology can provide the directory service, abstraction service, messaging service and work flow service needed in GIS, it therefore becomes the natural choice for the next generation of GIS. Hence, the term HyperGIS is invented to present the middl eware approach for agent-based distributed GIS.

PAGE 39

23 CHAPTER 3 CONCEPT OF HyperGIS HyperGIS is middleware within a client -server environment. Middleware is the collection of distributed computing serv ices that, within any given processing environment, enables clients and servers to communicate and inter-operate with one another in the most expedient, fl exible, and correct manner possible. HyperGIS: Defining a Future GIS As defined in this study, HyperGIS a co llection of distributed software agents, which could manage distributed processing of spatial data by maintaining directory service, abstraction service, messaging serv ice and work-flow service. HyperGIS is characterized as a GIS that contains links to other spatial and/or non-spatial information systems. HyperGIS employs an Internet Agent that acts like a broker . The broker takes a request from the user, dispatches the processi ng procedures for spatial information at data servers and function servers accordingly, then optimizes output returned from servers, and generates a presentation to display for the client. A software agent, in turn, is a software entity that functions continuously and autonomously in a pa rticular environment (Shoham 1997). An agent is shown on the HyperG IS logo in the form of a spider (Figure 9). Its four pair of legs represents the se rvices that an agent can provide – directory service, abstraction service, messaging serv ice and work-flow service. The distinctive head and body of the spider suggest modularizat ion. It also indicates that an agent can

PAGE 40

24 separate the content from its presentation. The web with rainbow background symbolizes the distributed and heterogeneous networks on which agents reside and operate. The image of earth highlights that the subject of Hype rGIS is all about spatia l information. Figure 9. HyperGIS Logo The term HyperGIS was first introduced at the Geoinformatics'95 Conference in Hong Kong and the Pacific Science Congre ss in Beijing, China in 1995 (Chang 1995). Figure 10 shows a sequence of major events between the introduction of GIS and HyperGIS. The passage of the Federal Free dom of Information Act in 1966 was the corner stone that led to the broad accessibili ty to government information that we enjoyed

PAGE 41

25 today. Environmental protection legislations th at were passed in the late 1960’s and early 1970’s introduced corresponding mandatory environmental monitoring and survey requirements, which in turn contributed to the steady increase of the national spatial data inventory. When the White House acquire d email addresses in 1993, it marked the beginning of a new era of e-government. President William J. Clinton signed Executive Order 12906 on April 11, 1994 that mandated each federal agency make geospatial data available to the public (Clinton 1994). While t hose data afford the public opportunities to examine how the government functions, their sheer amount and the heterogeneous nature are proven obstacles for the public in finding what they are looking for. HyperGIS is a solution to expedite exchanges of such massive spatial information. Figure 10. Timelines of Notable Events HyperGIS has a set of operational characteristics: It operates on networking environments. It consists of a client process, a data se rver process, a function server process and a middleware agent process that can be distingu ished from all others, yet interact with all others seamlessly. The client portion, the data server porti on, the function server portion and the agent portion can and usually do operate on separate computer platforms.

PAGE 42

26 Any component can be upgraded without having to upgrade other components. The agent is able to service multiple clie nts concurrently and has access to multiple servers. The agent can autonomously perform tasks such as coordinating two-way communications. GIS Components Burrough and McDonnell (1998) considered that a functional GIS comprises three important and balanced components: hardware, sets of application software modules, and a proper organizational context including skilled people. A more detailed dissection placed greater emphasis on data and people w ho developed and used GIS. Thus the GIS components were categorized as hardware; software; data; people; and procedures (Maguire and Dangermond 1995) (Figure 11). Figure 11. Components of a Geographi c Database (Maguire and Dangermond) Components of HyperGIS Similarly, A HyperGIS comprises one or more data servers, function servers, clients and Internet Agents (Figure 12):

PAGE 43

27 Data Server: Includes remote data server s and local data servers that furnish background thematic data and point of interest data respectively. Function Server: Includes remote function se rvers and local function servers that are responsible to provide the system func tion and logic needed for modeling and simulation. Client: Provides a multimedia user interface for interactivity and dynamic presentation. Internet Agent: Coordinates remote and local resources by providi ng directory service and intelligent management. Figure 12. Components of HyperGIS In particular, an Internet Agent is a collec tion of distributed soft ware entities that can do the following: Manage distributed proc essing of spatial data; Maintain directory service for various data sources by providing registry of GIS data servers so that HyperGIS can locate the required services; Maintain abstraction services by hiding details of a specific GIS or Database Management System (DBMS) product from the c lient applications to enable clients to work with different GIS products [i.e. A RC/INFO vs. MapInfo] without having to hard-code the linkage between the different databases; Provide messaging services by enabling clie nts and servers to communicate with one another in a reliable manner such as pr oviding local/network cache to reduce system downtime even when sites are not immediately available; and Furnish work-flow service to route data a nd control automatically to the appropriate server or client for timely processing based on factors such as predefined events, results of query, an internal timer, or externally created situations.

PAGE 44

28 Generally speaking, middleware is the collection of dist ributed computing services within any given processing envir onment that enables clients and servers to communicate and inter-operate with one anothe r in the most expedient, flexible, and correct manner possible. In a client/server environment, a fat client has more processing responsibility than a thin client. The current trend in the client/server computing is moving away from fat clients toward thin clients. Thus client systems intend to relocate as much processing as possible to other computers. There is an a ssumption that the servers should be left to perform the services they do be st and most efficiently such as managing local databases and function libraries. Given these two conf licting trends and assumptions, there are certain distributed transaction pr ocesses left unsuitable for either the client or the server to perform. Therefore, the middleware laye r is where those can and should be done. According to Alan Simon and Tom Wheeler (1995), middleware has evolved to become the most appropriate place for such functionality as: 1. distributed transaction processing; 2. directory service (i.e., finding out wh ere some required service might be procured); 3. abstraction service (i.e., hiding the deta ils of a specific DBMS product from the client application, permitting clients to be architected to work with more than one DBMS without having to hard-code or dynamically construct a large number of DBMS dialects); 4. messaging services enabling clients and servers to communicate with one another in a reliable manner, even when sites aren’t immediately available; 5. inter-application interoperability servi ce – enabling an application running on one system to invoke functionality (i.e., a remote procedure) on another; 6. work-flow service – based on factors such as the results of some query, timers, externally created situations, and so on, data and control can be automatically routed to the appropriate user, applica tion, or service for timely processing.

PAGE 45

29 Physically, middleware can reside on either the client side or the server side; or both; or an independent third tier. The boundaries between server and server-side middleware or between client and client-sid e middleware may appear blurry. However, the distinction between client, server a nd middleware can be determined by their respective functionalities. While server pr ovides information and client consumes information, the sole responsibility for mi ddleware is to facilitate the information exchange. Middleware itself does not own nor consume any information. Usefulness and Significance Research reveals significant demands in GIS for the services that could be rendered by middleware (Simon and Wheeler 19 95). The major advantage of using an Internet Agent approach is that the maximu m flexibility and efficiency for processing spatial data are likely to be achieve d by allocating appropriate portions of analysis/functional logic to the clients and serv ers within a distributed GIS environment. Its directory service offers a registry of GIS data servers where the required services can be conveniently located. By making the existing data and function servers available for reuse, it significantly reduces development cost as well as development span. The use of an abstraction service is adva ntageous because it simplifies the process of GIS development by hiding technical deta ils. Each modularized component of the system can be upgraded without having to upgrade other components. On the other hand, a messaging serv ice enables clients and servers to communicate with one another in a reliable manner. Such a service provides local or network cache to reduce system downtime even when sites are not immediately available.

PAGE 46

30 Work-flow service introduces true two-way interactivity to a spatial information system, because an agent can act provocatively and adap tively – unlike a traditional system that can passively response to a query only. Application Areas HyperGIS has potential for use in ma ny areas that requir e access to dynamic spatial information in an efficient and flexible manner, including public-access of government information; traffic analysis a nd simulation; navigation systems; delivery and service routing; field data collection; environmental simulation; and recreation7. Because of the nature of HyperGIS, whether or not to employ a HyperGIS approach depends on the characteristics of i ndividual projects. The first consideration by developers ought to be to determine whether a networking environment is necessary. A stand-alone system is certainly the most efficient because any networking environment will inevitably introduce performance overhead. Ho wever, if the origin of the query is different from the location of the service, an alternative to the stand-alone system (i.e. a client/server approach) may have to be exploite d. Next to be examined is the sources of spatial information. If massive amounts of data are involved, using HyperGIS can be beneficial because of its directory service. Similarly, when the concerned data are heterogeneous, it is advantageous to utilize an agent to translate data that are in different formats. In a project that requires reus e of many functions as well as data, the modularized architecture in HyperGIS can de finitely save development costs and reduce development time span. Some system designers may argue that the centralized approach is still preferable in mission-critical projec ts because there is little tolerance for 7 http://www.geocaching.com/ using GPS for r ecreational high-tech treasure hunting.

PAGE 47

31 networking interruption. However, people need to be aware that the risk of a system outage is a hazard inherited from the envir onment in which a HyperGIS operates and not a deficiency of HyperGIS.

PAGE 48

32 CHAPTER 4 METHODS OF HyperGIS DESIGN AND IMPLEMENTATION Translating ideas into reality is a prim ary concern in GIS implementation (Ives and Crawley 1995). The main goal of the case studies is to implement the concept and functionality of HyperGIS in a real-world application, with comparisons to other approaches that emphasize what a HyperGIS can achieve. In order to demonstrate the concept and functionality of HyperGIS, the case study examines the design and implantation pr ocess of developing the LOSAC – Lake Okeechobee Stage-Area-Capacity Information System – a GIS application providing water level, lake area and lake capacity info rmation of the Lake Okeechobee, at the South Florida Water Management District (Figure 13). Figure 13. Banner of the LOSAC Application

PAGE 49

33 Background of the Case Study The Lake Okeechobee Stage-Area-Capacity Information System grew out of the popular demand for water level, lake ar ea, and potential water supply capacity information in Lake Okeechobee during the unus ual water shortage period in 2000-2001. However, all the data and resulted presentations in this dissertation are for the sole purpose of demonstrating the architecture a nd behaviors of HyperGIS. Therefore, they are NOT suitable for any other purposes and may NOT be used for policy making before further calibration. Figure 14. Space Image of Lake Okeechobee (NASA)

PAGE 50

34 Regional Background Lake Okeechobee is a subtropical lake lo cated in the south Florida peninsula (Figure 14). The surface area of the lake cove rs 1,732 square kilometers. It is the second largest freshwater lake in the United States. The lake plays an important role in the multiple missions of flood control, water supp ly, navigation, recreation and conservation. It is considered the liquid h eart of the South Florida ecosystem (Flaig and Havens 1995; Jin and Hamrick 2000; Guan, Zhang, and Muszick 1999). Lake Okeechobee is managed by the South Florida Water Management Dist rict (Figure 15) and operated by the U.S. Army Corps of Engineers. The Mission of the South Florida Water Ma nagement District is to manage and protect water resources of the South Florid a region, including Lake Okeechobee and the Everglades Conservation Area, by balancing and improving water quality, flood control, natural systems, and water supply. The S outh Florida Water Management District's Governing Board consists of nine individua ls, each representing specific geographic areas within the District. They are appointed by Florida's Governor and confirmed by the Florida Senate, generally for a four-year term. The Governing Board sets policy and direction for the agency, and appoints the agency's Executive Director, who is also confirmed by the Florida Senate. The Execu tive Director, Deputy Executive Directors and a staff of 1,650 employees carry out the Bo ard's directives and the District’s mission. Challenges Lake Okeechobee serves multiple and somewhat conflicting purposes, therefore, the task of managing the lake is challe nging. The lake was a natural lake for approximately 6000 years until the Herbert H oover Dike was built between the 1930s and the 1960s. The Hoover Dike, along with othe r flood control facilities, has made

PAGE 51

35 significant changes in water flow during th e hurricane seasons (F igure 16) by storing excessive rainfall from the Kissimmee River, and lake water that used to flood the surrounding wetlands and enter the ad jacent Everglades as sheet flow. Figure 15. South Florida Water Mana gement District Boundary (SFWMD)

PAGE 52

36 Figure 16. Lake Okeechobee under Hu rricane AndrewÂ’s Impact (NOAA) The Lake is the major supplier of irrigation water for the Everglades Agricultural Area (EAA), and serves as a critical supplem ental source for urban and the Everglades' water supply (Figure 17). Towns and sm all cities around Lake Okeechobee depend on it for drinking water. It is a backup water s upply for the communities of the lower East Coast of Florida as far south as Miami during dry season. Figure 17. Agriculture Irr igation in the Lake Okeechobee Surrounding Area (SFWMD)

PAGE 53

37 Figure 18. Fishing at Lake Okeechobee (SFWMD) Figure 19. Boating at Lake Okeechobee (SFWMD) The lake also provides habitats for a wide variety of wading and migratory birds, alligators, and the endangered Everglades Snail Kite. Recreational and commercial fisheries (Figure 18), and boating (Figure 19) also occur in Lake Okeechobee. With Caloosahatchee River to the west and St. Luci e Canal to the east, Lake Okeechobee is an important link of the coast to coast waterway that connects the Atlantic Ocean and the Gulf of Mexico (Figure 20). Figure 20. Atlantic Coast to Gulf Coast Waterway (SFWMD)

PAGE 54

38 Figure 21. Water Shortage Awareness Campaign (SFWMD) During 2000 2001, South Florida faced th e worst drought in the past 200 years, which caused serious concerns on water sh ortage. The SFWMD entered Phase II water usage restriction that limited lawn wateri ng lawn and car washing to twice a week. Agricultural irrigation usage was also cut by ha lf (Figure 21). The water shortage was so severe that the District activated its Emerge ncy Operation Center. The lake level reached the lowest stage on record 8.97 feet on May 23, 2001 (Figure 22). Figure 22. Lake Stage between 1/1/2000 and 9/30/2001 The drought left a large area of the lakebe d exposed and dried for the first time in the past 200 years; many channels became too shallow to navigate (Figure 23, Figure 24).

PAGE 55

39 Figure 23. Exposed Drainage Pipe that wa s usually Submerged in the Lake (SFWMD) Figure 24. Dry Ending of the Pi erce Canal in April 2001 (SFWMD)

PAGE 56

40 Geographical information systems are usef ul tools because of their ability to furnish information for better decision making. Different users have distinctive needs and priorities in order to fulfill the competing demands of their missions. Figure 25. Recreation Guide to Lake Okeechobee (SFWMD) During the water shortage period, water managers in charge of the water supply needed to know the water supply capacity of the lake. By calculating the volume between the current water level and the bottom of the irrigation gates, and comparing it with the current water usage, water managers woul d know how long the outflow by gravity could last; how soon and how many pumps would be needed to boast water supply. For the general public, a major interests was the information on accessibility to the lake. For a number of months, some docks and ramps we re located on dry lake beds. when you tried to launch a boat for bass fishing. Meanwhile, researchers were busy f eeding data to their models simulating various lake management scenarios to predict future water conditions. Until recently, the task of providing information remained uncoordinated efforts that

PAGE 57

41 usually resulted in redundancy and inconsistency. Many departments still relied on static maps to respond the public inquiry (Figur e 25). Transporting data between models remained highly specialized chores because of the variety of data formats involved in the models and the lack of a method to describe data meaningfully. Figure 26. South Florida Water Manage ment District Facilities (SFWMD) The complexity of data further conf ounded the matter. The field data were heterogeneous. They were collected and tr ansmitted to the District headquarters by different methods such as telemetry, dial-up, and satellites (Figure 26). In addition to their dynamic nature, they were distributed . They were owned and operated by different departments or even different agencies.

PAGE 58

42 Given the competing demands and the complexity involved, a more efficient and effective GIS approach, which can result in reducing redundant development efforts; reusing resources; simplifying maintenance e fforts; and functioning dynamically in real time, is urgently needed. System Design To effectively present the process of designing and implementing LOSAC, the combination of natural languages, Unified Modeling Language (UML), Object-oriented (OO) diagrams, and genuine codes is used to illustrate the design and implementation process step by step. Diagrams are good not ations to express designs for methods, because natural languages are too imprecise while codes are precise but can be too detailed sometimes. In the view of OO desi gn, using diagrams allows the communication of design concepts to be clear, with a certa in amount of precision without losing details. Through using the combination of natural languages, diagrams and codes, it is possible to display the boundary of the LOSAC system and its major functions; illustrate use cases; represent the system’s structure; model the behavior of objects; and reveal the physical implementation architecture. Process of an UML Design The Unified Modeling Language is a modeli ng language, directly unified from the object-oriented analysis me thods of Rumbaugh, Jacobson, and Booch (1999). It uses graphical notations to express a system desi gn. The UML is a standard for visualizing, specifying, constructing, and documenting the ar tifacts of a software-intensive system. It can be used with all processes, throu ghout the development life cycle, and across different implementation technologies.

PAGE 59

43 The tasks for system design include: Identifying object boundary and f unctions for each component, Defining attributes for each objec t and methods for each functionality, Describing data to be exchanged between th e components in a hierarchical structure, Designing user interface for presentation. Phases of System Design and Implementation Fowler and Scott (2000) indicate that the process of using UML in a system design involves four phases: Inception, Elaboration, Construction and Transition . Inception ranges from an informal discussion for a small project to a full feasibility study for a large project. The inception of LOSA C was directly motivated by the needs to respond to the distinctive requests for the basic hydraulic information about Lake Okeechobee during the water shortage period. The objectives are 1. To present the current lake status incl uding water level, lake area, and potential capacity of water supply in a timely manner; and 2. To provide a more efficient and eff ective way in delivering such spatial information. Elaboration leads to a better understanding of the problems. First, it involves the analysis of system requirements. Unless the requirements have been adequately addressed, a wrong system might be built. The use case diagram provides a useful tool to sort out all required system functions so that all the poten tial scenarios for the system uses can be discovered. During the elaborati on, it is important to keep a conceptual perspective in outlining the domain analysis. Understanding the interaction between the objects is beneficial in expl oring how various system components interact within the system. Further elaboration, investigating the resources and cons trains in technology, skills and time, paves the way for an iterative construction. An iterative construction

PAGE 60

44 means a series of iterations for construction, defining the functionality to be delivered in each iteration. Comparing to a one-time release near the delivery date, which may risk a big impact should there be a failure, an itera tive construction has frequent and smaller releases that are based on previous su ccessful releases. Thus, its incremental implementation is more predictable and mana geable with more control of risks. In transition, there is no development to add functionality but to fix bugs and to optimize performances. Centralized Method of GIS Development The first task to build a GIS is to identify the system boundary and the functions for each component. At the South Florid a Water Management District, a common scenario of using a GIS to provide Lake Okeechobee information can be observed in Figure 27 as a Jacobson Use Case Diagram. In the diagram, stick figures represent actors . An actor is a role that a user plays with respect to the system. Actors can be systems that perform certain tasks. Therefore, they do not need to be human. Actors carry out use cases that are symbolized as shaded ovals. Ovals with light pink background indicate the use cases are part of the information exchange chain, but not in the domain of GIS implementation. Ovals with light yellow background identify the functions that are within the implementation considerations. Under this scenario, the LOSAC can be built as a centralized GIS, where its data, spatial function and user interface are all located in one singl e set of hardware supporting environment. The staff at the District collect s field data, inputs them into the GIS, and generates reports and presentations based on the output of the query to the GIS. Then managers will make recommendations to the Governing Board and publish the

PAGE 61

45 information to the public in forms of press re lease or web page. The GIS does not directly interact with either the field data or the general audiences such as the Governing Board and the public. Researchers who supply the fi eld data to their m odels will need to manipulate the raw data into a format that conforms to model standards. Figure 27. Use Case Diagram of LOSAC as a Centralized GIS The general method of developing a cen tralized GIS is well documented based on a wealth of past experiences. The fundame ntal aspects to build a centralized GIS are to: Identify theme data and their related attributes; Define spatial functions; Describe what messages to be exchanged, i.e. what the input and output will be; Design interfaces to accommodate th e input and present the output.

PAGE 62

46 Discovering Theme Data and Their Attributes The core theme data to be used are lake bottom elevation data and auxiliary data for the surrounding area. The elevation data we re results of a 1989 su rvey stored in an array of one kilometer by one kilometer grids (Figure 28). The grids were later converted into a shape file in State Plane Projection. Figure 28. Grids of the Elevation Data

PAGE 63

47 Figure 29. Attribute Tabl e of LO_1KMSTAGE89.SHP The shape file has an integer field called Stage that stores the elevation data in inches, and a derived floating field named Elevation that stores the same information in feet (Figure 29). Therefore, the minimum ar ea unit is one square kilometer where the minimum water level change can be measured up to one inch. The maximum value in the field Stage is 172 inches (14.5 feet) while the minimum is 17 inches (1.42 feet). Therefore, the range of the elevation that can be queried in the LOSAC is set between 16 feet and 1 foot. Examining Spatial Functions To investigate spatial phenomena, there ar e usually two types of spatial analyses involved. The first type involves overlay with other spatial features, so the relationships among them can be identified. The second type takes additional sp atial or non-spatial parameters as input to generate a subset of new spatial information. For example,

PAGE 64

48 applying flight paths on an area surrounding airp ort, one can derive a noise impact zone. In our case, querying the elevat ion data with the field obse rvation data will yield an extent of water surface that is a subset of the whole lake basin. To implement the query for the lake area, ArcGIS 8 is used to provide spatial analytical functions. The spatial functions are accessed through Ar cObjects library using Visual Basic on Windows platfo rm. Specifically, the shape file is added as a feature class. A query filter is defined based on the i nput of water level data . After the selection to the feature class is made, fill symbols with discrete styles are assigned to the classified feature layer. The lake area and capacity can be consequently calculated from the attribute tables. Ultimately, the display is re freshed with the newly rendered layer. For the purpose of examining the data in detail, gene ral spatial functions such as zoom in, zoom out, zoom to full extent and pan should be implemented. Figure 30. Interface Design: Form Layout

PAGE 65

49 Designing Graphical User Interface Upon the decision on what the input and the output should be, a graphical user interface (GUI) is needed to allow for intera ctions between the users and the system. In Visual Basic, a Form behaves as a container that holds other GUI components such as menus, buttons, and controls. Figure 30 shows the form design of the interface. Figure 31. Interface Design: Menu Figure 32. Common Dialog Control and Image List Control

PAGE 66

50 In the form layout, the first text box on th e upper right is txtInput where the water level is entered as an input. A slide bar, binding with the txtInput, provides users the convenience of dragging it up and down to speci fy the water level without typing into the input text box. A map control on the lower left, mpcLake, and a picture box control on the lower right, picCanvas, are the two e ssential components to visually present the extent of the lake and the water level – area – capacity curve. Two additional text boxes present the area and the capacity data as texts. Another text box serves as auxiliary input to provide the lower limit of lake elevation for computing the potential water supply. The menu and command buttons are on the top of the form (Figure 31, Figure 33), offering users a full array of functions such as zoom in, zoom out, print and exit the program. There are two additional invisible controls – a common dialog control on the left and an image list control on the right (Figure 32) – that provide supplementary supports. Figure 33. Interface Design: Command Buttons

PAGE 67

51 Connecting the Information Flow Now that the data sources and the required function have been identified, and the design of the user interface is completed. The ne xt step is to connect the information flow following the data exchanged between the comp onents. Activity diagrams can be used to understand and better describe the sequencing of the activities of information flows. In an activity diagram, the information flow starts where a process or subroutine begins; it ends where a process is terminated or a routine returns to its calling module. A core symbol with round edges represents the ac tivity state that consists of a sequence of activities. A rectangle symbol represents a routine or function, whose behaviors are modularized and relatively independent to othe r states. Conditional be haviors and parallel behaviors are represented by their usual symbols. When the LOSAC program starts, it pe rforms a series of house keeping tasks including initializing various parameters for later uses by other modules and routines; adding the theme data layers; and assembli ng the initial display. Figure 34 shows the activity diagram as the main form is loaded. The genuine VB codes for loading the main form can be found in Code Listing 1. The Draw_Legend routine (Code Listing 2) is responsible for setting enumerated colors and drawing a legend on the form. The success of obtaining the enumerated colors relies on the GetColor module. The Draw_Legend routine calls two a dditional subroutines. The first one, Set_Breakers, performs a simple task of in itializing an array according to the number of classes defined at the beginning of the program (Code Listing 3). The advantage to set the task as a subroutine is that future main tenance and modification will be simplified by such modularization.

PAGE 68

52 Figure 34. Activity Diagram of Loading the Main Form

PAGE 69

53 The GetColor subroutine is orgainized in a similar way. Furthermore, it can also be used by other modules, even other programs. Therefore, it is pl aced in a separate module class: RenderLayers.bas to expedite co de reuse (Figure 35). See Code Listing 4 for the GetColor function in RenderLayers.BAS: Figure 35. Class Module: RenderLayers.BAS Another important function during the form loading is the Add_Shapefile. It sets up a WorkSpaceFactory interface and a FeatureW orkspace interface in order to properly add the shape file into the feature layer collections (Code Listing 5). After the initialization, the program is r eady to respond to use r’s inputs with the main module Show_Stage (Figure 36). This module responds to the water level data entered by a user. The user input can be either from the te xt box txtInput or the slider bar sldStage. Since txtInput and sldStage are bonded together , a status change to one control will result in the status change of the other control. Code Listing 6 illustrates how those changes occur.

PAGE 70

54 Figure 36. Activity Diagram of Show_Stage

PAGE 71

55 Dragging the slide bar (Code Listing 7) will also update txtInput, and then activate the Show_Stage module. Code Lis ting 8 enables the ToolTipText shown on the slide bar (Figure 37). Code Listing 9 represents the Show_Stage module. Figure 37. ToolTipText Shown on the Slide Bar A crucial subroutine for the Show_Stage function is Classify_Stage. It loops through the classes within the classified f eature layer and handles the assignment of fillsymbols, which affects the final appearance of the map view. Figure 38 shows the activity diagram of the Classify_S tage subroutine (Code Listing 10). Figure 39 and Figure 40 are the activity diagrams showing how to calculate the lake area and the potential water supply cap acity. To calculate the area at each given elevation, the program loops through the la ke elevation between 16 feet and 1 foot, calling an external procedure Get_ALC. Since accuracy of water depth data is one inch, the interval of elevation query is set to one inch. Similarly, the potential water supply capacity at each given elev ation can be calculated.

PAGE 72

56 Figure 38. Activity Diagram of Classify_Stage

PAGE 73

57 Figure 39. Lake Area Calculation

PAGE 74

58 Figure 40. Lake Capacity Calculation Calculating area involves an external procedure CalcFeatureClass.BAS. It contains a class module Get_ALC (Code Listin g 11), which takes a feature class as input and returns the sum of that feature class. Si nce a feature class can be points, lines or polygons, the returned sum will be a total po int count for points, a total length for lines

PAGE 75

59 and arcs, and a total area for polygons (Figure 41). Such behavior is called Polymorphic in object-oriented design. Its application is very beneficial for processing spatial attributes that possess assorted attributes and forms. Figure 41. Activity Diagram of CalcFeatureClass.BAS

PAGE 76

60 The Unit_Conversion subroutine coverts the lake area in square kilometers and the lake capacity in cubic kilometers respectiv ely to the lake are in acres and the lake capacity in gallons for alternative pres entation (Code Listing 12). In assisting visualization of the relationshi ps between the water level and the lake area / capacity, the Water Level – Area – Capacity Curves are drawn by the subroutine Draw_Curve (Code Listing 13). Zoom in, zoom out, and zoom to full extent are accomplished by the following routines. The subroutine Set_Extent is called from Zoom_In and Zoom_Out (Code Listing 14). Zoom to full extent allows user to reset the extent back to the initial state. Similarly, the function Pan is implemented so that a user can click and hold the left mouse key to move the map view horizontally (Code Listing 15). Measuring System Performance It is important to measure a system’s pe rformance so that its efficiency can be evaluated. The performance of a function or subroutine is measured by calculating the elapsed time between the function or subrou tine starts and the function or subroutine ends. For the whole system, its performance is determined by the sum of execution time of all the functions and subroutines that are indispensable to accomplish its major mission. Therefore, the timestamps are placed at the entry points and exit points of the Initialization (Figure 34) and Quer y (Figure 36) procedures. LOSAC as a Centralized GIS When the program LOSAC starts, it presen ts an interface to users as shown in Figure 42, where the initial water level was set to 16 feet (4.88 meters). At that stage, the lake surface covers 1,802 square kilome ters or 445,285.68 acres. The lake capacity between 16 feet and 1 foot is 4.67 cubic kilometers or 1,234.39 billion gallons.

PAGE 77

61 Figure 42. Initial Display of Centralized LOSAC Figure 43. Lake Status at 9 Feet

PAGE 78

62 To query the lake condition, users can either drag the slide bar or type in the text box to set water level as input. The results wi ll be instantly updated as soon as the Enter Key is pressed in the input text box or the slide bar is set. Figure 43 shows the query results with the water level at 9 feet, which represents a situation similar to the lake condition when the Lake reached its recorded low in late May 2001. Users can also use Show menu or the command button (second button with telescope icon) to initiate the query (Figure 44). Figure 44. Menu, Shortcut and Comm and Button for Displaying Lake Area Figure 45. Potential Capacity between 8.9 and 8.5 Feet

PAGE 79

63 Because not all water in the lake capac ity is accessible for a given operation scenario, LOSAC allows users to set the lo wer limit and estimate the actual available volume. In Figure 45, the lower limit is set at 8.5 feet, which is the elevation at the end of the intake pipes. The results indicate that with the lake level at 8.9 feet, the maximum volume of water available is 37.66 billion gallons. Should demands exceed that amount, either the pumps intakes need to be lowere d or a more strict wa ter conservation policy initiated. The command buttons on the interface allow user to zoom in (the fourth button from the left with plus icon), zoom out (the fifth button from the left with minus icon), zoom to full extent (the third button from th e left with global icon), and exit the program (the first button from the left with stop sign icon) respectively (F igure 46). Menu items provide similar functions. You can also pan the map by clicking and holding the cursor on the view. Figure 46. Confirmation Window to Quit Program Built as a centralized GIS so far, the LO SAC can respond instantly to the query of the lake area and capacity from an operator . Since all the major components core data, functions, and the user interface are centrally located either on a standalone machine or on an Intranet, the system can perform efficien tly. In addition, it is reliable because it relies on few external resources.

PAGE 80

64 Table 1. Features of Centralized GIS Centralized GIS Source Data Reuse No Heterogeneous Data No Real Time Data Access No Dynamic Functions N/A Performance Efficiency Excellent System Reliability Excellent Cross Platform No Special Software for End Users Yes User Interactivity Limited Customizable Presentation No Code Reuse Yes Development Redundancy High However, such independence has costs. The inherited weakness for a centralized system requires the data to be homogeneous a nd to be kept locally. It can directly reach neither the external data sources nor an expanded audience beyond the immediate operators. The system depends on its operators to collect and enter the field data, and then translate the outputs into reports, Power Point presentations or web documents in order to reach its intended a udiences. Accessing data as such not only introduces delays in processing real time information, but also causes unnecessary data duplication. Without coordination between the departments or the agencies, the redundant efforts of

PAGE 81

65 re-inventing wheels in GIS development cannot be avoided, which makes maintaining and synchronizing GIS applications extremely difficult. In summary, the advantages and the disadvantages of the centralized GIS approach are inventoried in Table 1 based on acc essibility of data, function efficiency and system reliability, interactivit y, and development redundancy. Client-Server GIS Method Even though the centralized LOSAC performe d well within its design targets, the inability to acquire real-time field data severely limited its usefulness and drew attentions for immediate improvement. Fortunately , because most preceding codes were modularized, many of the code modules can be reused. To distinguish the future development effort, the LOSAC built with the centralized GIS method is calle d as LOSAC-C; the modified system with access to the real time field data is called as LOSAC-RT. For direct access to the external field data source in real time, the system use case diag ram is modified as Figure 47. Again, ovals with light pink background indicate the use cases that are part of the information exchange chain, but not in the domain of GIS implementation. Ovals with light yellow background identify the functions that are within the implementation considerations. Green ovals indicate data sources. According to the use case diagram, the most significant change that occurred was that the LOSAC-RT would directly interact w ith the field data server as a GIS client. When building a client-server system, it is necessary to identify not only what the data are but also where they are located; and to d ecide how the analytic functions are allocated in addition to which functions are involved.

PAGE 82

66 Figure 47. Use Case Diag ram of Client-Server GIS Identifying Data Distribution and Attributes In addition to the local elevation data of the lake basin used in the centralized GIS method, the real time field data are now located at a remote server. The server is hosted by the US Army Corps of Engineers at the Jacksonville District. The plain html page served at http: //www.saj.usace.army.mil/h2o/reports/r-oke.txt (Figure 48) includes the water level data at Lake Okeechobee as a part of the Lake Okeechobee and Vicinity Report . It contains observation data from the District structures C5, S4, S3, S2, S352, S308, S135, S133, S127, and S129, as well as the four interior stations LD01, LD05, LD06 and LZ40 (Figure 26) that are currently used to calculate the average daily lake elevation.

PAGE 83

67 Figure 48. Text Report of Field Data Allocating Functions Depending on how functions are allocated, a client-server system is called a thinclient system if most of the functions reside on the server; or a fat-client system if most of the functions are located on the client. For a thin client, most processing procedures are

PAGE 84

68 done at the server. The client usually only takes the results for presentation purpose. On the contrary, a fat client handles most functi ons while its server plays a limited role in furnishing certain data. Figure 49. Classes of LOSAC-RT In this case, the theme data and the ArcO bjects function library are located at the intranet within the District while the real -time field data reside outside. Since the developers at the District do not have access to any function libraries outside the District, it is logical to build a fat client so that the LOSAC-RT can take the external data as they are and re-format them into a usable format. Therefore, the LOSAC-RT as a client-server system can be represented as such in Figur e 49. Figure 49 is a typical class diagram where clouds represent physical ly separated systems; green drums stand for data sources; yellow drums denote function libraries. Except for the new function to access the external field data, most functions built for the centralized LOSAC-C can be reused.

PAGE 85

69 Designing Graphical User Interface Because the LOSAC-RT now has an add itional requirement to access real time information, its GUI has changed to accommodate added functionalities. Figure 50. Interface Design: LOSAC-RT First, a new control – Microsoft Internet Transfer Control 6.0 – INET is added to the form. INET control provides essential methods for access to the field data on an external HTTP server. A new text box for Universal Resources Locator (URL) also appears on the top of the main form for the purpose of accepting new or alternative HTTP server addresses (Figure 50). A new command button (the second left button with clock icon) and a new menu item are added for enhancing user convenience. Users can either click on the button, use

PAGE 86

70 the menu Show Realtime Stage, or press the shortcut key Ctrl T to trigger a real time query of the lake status. Figure 51. New Menu Item and Ne w Command Button of LOSAC-RT Figure 52. Routine to Get Real Time Data

PAGE 87

71 Connecting Information Flow Since most code modules from the LOSAC-C can be reused, the task of adding the real time field data query becomes re latively easy by implementing a menu item and a tool bar control (Code Listing 16). In Figure 52, The Get_RealTimeData (Code Listing 17) routine starts with the validation of the URL. If the URL is valid, it will proceed to open an HTTP connection and read the field data report into the buffe r. Next, it will use string processing functions to obtain the time stamp and the lake elevati on. Subsequently, the status of slide bar is updated. That change in tu rn triggers the execution of the sldStage_Change subroutine (Code Listing 7), where the Show_Stage rout ine (Code Listing 9, Figure 36) is invoked. Measuring System Performance The LOSAC-RT has similar Initialization and Query procedures. Therefore, the placement of timestamps for those two procedur es are similar to those in the LOSAC-C. The new addition is the Get_RealTimeData pr ocedure (Code Listing 17). The additional timestamps measure the elapsed time between th e Get_RealTimeData starts and the slide bar (sldStage) status change is triggered (Figure 52). LOSAC as a Client-Server System The interface of the LOSAC-RT remains the same except for the new Show Real Time Data button on the toolbar, the new Show Real Time Data item in the menu, and the new URL text box. Users can still manually input the water level data to query the surface area and its corresponding capacity. Figure 53 shows the results of a query performed on September 19, 2001. It indicate s that the water level was 13.3 feet (4.05 meters), with a surface area of 1,677 square kilometers or 414,397.56 acres. The lake capacity between 13.3 feet and 1 foot is 3.22 cubic kilometers or 851.49 billion gallons.

PAGE 88

72 Figure 53. Result of Real Time Lake Status The major improvement of LOSAC-RT is illustrated by its ability to access the real time field data. The improvement is po ssible by breaking the limitation imposed by a centralized system where external data wa s inaccessible. The real time capability of querying external data eliminates the po ssible delay and inaccuracy introduced by the operators. In the meantime, it has retained the original spatial functionality including zoom, pan and manual inquiry. On the other hand, as the system now has an external link, it does acquire vulnerability in reliability and efficiency. If the network connection is broken or the remote server is unavailable for any reasons, the attempts to access real time data will fail. Moreover, the outward information flow patterns have not changed. The general public and the Governing Board still rely on derived reports, presentations or web pages

PAGE 89

73 to obtain information. In order to us e LOSAC-RT for eliminating the second-hand information, specialized software such as Ar cGIS 8.1 and MS NT Service Pack 6 must be installed. However, most people who are inte rested in the Lake status would not have access to the ArcObjects function library b ecause of license limitation and costs. Therefore, it is not a viab le option to deploy the LOSACRT as a tool to reach an expanded audience directly be yond the immediate operators. The advantages and the disadvantages of the client-server GIS approach are summarized in Table 2. Table 2. Features of Client-Server GIS Centralized GIS Client-Server GIS Source Data Reuse No Yes Heterogeneous Data No No Real Time Data Access No Yes Dynamic Functions N/A No Performance Efficiency Excellent Good System Reliability Excellent Good Cross Platform No No Special Software for End Users Yes Yes User Interactivity Limited Limited Customizable Presentation No No Code Reuse Yes Yes Development Redundancy High Average

PAGE 90

74 CGI GIS Method Seeking a remedy to rectify the LOSACRT's impotence of reaching the general public leads to a CGI based GIS approach. A CGI based approach is an attainable extension because it not only offers certain flex ibility of remote data accessibility but also takes advantage of the World-wide Web as a presentation media. To reach a broader audience over the World-wide Web, the system use case diagram is modified as Figure 54 to include a HTTP server. Under such a scenario, although the general public and the Governing Board still receive briefing from the District staff and managers, they now have the choice to query the current lake status on their own. Figure 54. Use Case Diagram of CGI GIS

PAGE 91

75 Once more, ovals with light pink background indicate the use cases that are part of the information exchange chain, but not in the domain of GIS implementation. Ovals with light yellow background identify the func tions that are within the implementation considerations. Green ovals in dicate data sources and blue ovals suggest system outputs. The resulting LOSAC-CGI differs signifi cantly from the LOSAC-C and LOSAC-RT. However, many previous code modules can st ill be reused due to the object-oriented compartmentalized coding practices. Figure 55. Classes of LOSAC_CGI A CGI-based system differs from a centra lized system or a client-server system because it is hosted on an HTTP server and depends on a web browser for output

PAGE 92

76 presentation. Therefore, a CGI module does not need an interface. Compared to LOSACC or LOSAC-RT, LOSAC-CGI acts in a more linear manner. First, it collects the parameters of inquiry from a user. Second, it gathers data from the remote and local servers. Third, inquiry and analysis are applied to the data using the pre-defined functions. The final step will be to format outputs in compliance with the HTML specification so that they will be r ecognized by web browsers (Figure 55). Figure 56. Visual Basi c Modules of LOSAC-CGI Because a CGI program uses web browsers as output media, it does not need an interface. The first change seen is that the main form frmLO in Figure 35 has been replaced by a main module called Modul e1 saved in LOSAC.BAS (Figure 56). Collecting Inquiry Parameters The implementation goal for the LOSAC-CG I is to respond to an inquiry about the current Lake status by retrieving the real time water level, computing the corresponding lake area and gene rating a related map view, then displaying the results in HTML. The initial part of any CGI progr ams has always been collecting inquiry parameters that consist of user inputs as we ll as environment variables (Code Listing 18). User inputs define what information is to be retrieved. Environment variables describe the conditions on the client and the HTTP se rver, which may provide useful information to the CGI program during its run time. Howe ver, for LOSAC-CGI, a user input mainly

PAGE 93

77 indicates the start of the inquiry since the query criteria is acquired from the real time field data server. CGI_In (Code Listing 19) and Clean (Code Listi ng 20) are two support subroutines called by Get_Params (Code Li sting 18). The main program starts by declaring Windows APIs to handle out puts and inputs (Code Listing 21). Obtaining Remote and Local Data Similar to the data access routines in the LOSAC-RT, the water level is extracted from the remote field data server and the theme data is added from a local server (Code Listing 22). Routine AddShapeFile (Code Listing 5) is reused, Applying Spatial Functions After obtaining the remote and local data, the system is ready to apply spatial functions on the elevation data of the lake basin based on th e query criteria acquired from the field data server (Code Listing 23). Th e spatial functions are the same as those identified earlier in the LOSAC-RT. Theref ore, many previous codes are reused. Organizing HTML Outputs So far, the program has generated the map view in jpg. The water level, the lake area and the timestamp are stored in the variables of dblStage, dblArea and strTimeStamp. Next, those results are sent to the HTTP server in order to generate a HTML page to be displayed on a web brow ser (Code Listing 24) using the CGI_Out subroutine (Code Listing 25). Measuring System Performance In the LOSAC-CGI, the Collecting Inquiry Parameters and Obtaining Local Data segments are compatible to the Initializ ation procedure in th e LOSAC-C and LOSACRT. Obtaining the remote data can be compared to the Get_RealTimeData procedure in the LOSAC-RT. After executing the query, th e LOSAC-CGI outputs HTML codes to the

PAGE 94

78 client computer while the LOSAC-C and LOSAC-RT refresh their active views. Therefore, three pairs of timestamps are placed along those three major segments. LOSAC as a CGI-GIS The output of LOSAC-CGI on a Netscape browser is shown in Figure 57. Figure 57. Output of LOSAC-CGI

PAGE 95

79 The key breakthrough brought by LOSAC-CGI is the ability to gather external data and convey the results of spatial anal yses without imposing special hardware and software requirements on its audience. Users can use any widely-available browser to obtain the information that used to be onl y accessible through certain types of expensive and specialized GIS packages. This informati on flow represents a completed circle from remote data servers to its final audience, which ensures a reduction in processing redundant information. The audience can obtain real time information because the system eliminates delay by linking the information s ource and the intended destination directly. However, access to heterogeneous data is st ill limited. In addition, the systemÂ’s performance and reliability have been degr aded compared to LOSAC-C and LOSAC-RT, as the added networking components have intr oduced extra overhead. The efficiency, or even the success, of executing a query is now subject to the ne twork condition between the remote data server, the HTTP server, and the user. Figure 58. Error Message of Common Gateway Interface Program

PAGE 96

80 When an error does occur (Figure 58), th e error message is all but helpful, because the reasons can range from the data server being down; the function library malfunctioning; remote network being unreachable ; swap space at the HTTP server being full; to program timeout due to network traffic congestion. Table 3. Features of CGI GIS Centralized GIS Client-Server GIS CGI GIS Source Data Reuse No Yes Yes Heterogeneous Data No No Limited Real Time Data Access No Yes Yes Dynamic Functions N/A No No Performance Efficiency Excellent Good Average System Reliability Excellent Good Average Cross Platform No No Yes Special Software for End Users Yes Yes No User Interactivity Limited Limited Average Customizable Presentation No No No Code Reuse Yes Yes Yes Development Redundancy High Average High Another significant problem for the LOSACCGI is that the format of output data and the layout of the final presentation are embedded in th e codes of the LOSAC-CGI. Therefore, any changes to the presentation fo rmat would result in modification of the LOSAC-CGI codes, which not only makes cust omizable presentation near impossible but

PAGE 97

81 also causes unnecessary redundancy in main tenance and development. The feature comparisons among LOSAC-C, LOSAC-RT a nd LOSAC-CGI are listed in Table 3. Figure 59. Use Case Diagram of HyperGIS HyperGIS Method HyperGIS attempts to address the problems by employing agent technology. An agent can use directory service to track where the external data sources are and abstraction service to unders tand how those data can be re trieved. Those services will improve the systemÂ’s ability to access distri buted heterogeneous data, shown in Figure 59 as green ovals on the left. For outputs, the agent generates XML documents instead of HTML pages. Applying the XML documents ag ainst various templates in cascading style

PAGE 98

82 sheets, web servers can serve customized web presentations using the same lake status data in multiple formats for broader audiences with distinctive needs. More presentations can be added by creating more templates. Such an approach provides more flexibility in customizing client applications without m odifying the executable codes of the agent. To revamp the LOSAC into a HyperGIS, it initially follows the usual development procedures that consist of: discovering of data sources that ma y include remote and local data; identifying spatial functions involved, whic h may be served from either remote or local servers; and designing user interfaces. Figure 60. Agent and HyperGIS

PAGE 99

83 However, the data, function, and GUI are three conspicuously separated components in the HyperGIS architecture. Next, instead of the typical development procedure of simply connecting the informa tion flows among them, an agent is built to better coordinate the data exchange throughout the system (Figure 60). For the above reasons, developing a competent agent becomes the focus of implementing a HyperGIS. Each development phase of constructing an agent emphasizes on one distinctive aspect of its capacities. Figure 61. Basin Boundary (Left) a nd Image (Right) Data as Background Setting-up Directory Service and Abstraction Service An agent manages data through directory service and abstraction service. By tracking where the external data sources are, the agent will be able to locate the data when needed. Equally important, the agent need s to know how to retrieve those data if they are in different formats. Previously , LOSAC-C only handles homogeneous data –

PAGE 100

84 shape files; LOSAC-RT and LOSAC-CGI introduced limited accessibility of the heterogeneous data by using the Internet Transf er Control to manipulate the field data in HTML format. The agent in HyperGIS truly expands the access to heterogeneous data by incorporating images (Code Listing 26) and other background data such as the basin boundary of the Lake Okeechobee Watershed into the system (Figure 61). The AddShapeFile (Code Listing 5) a nd the AddRasterFile (Code Listing 27) constitute a simple abstraction service for the agent. Enhancing System Reliability The previous systems lack error handling capacity; the systems’ reliability suffers. Figure 62 illustrates that LOSA C-C bailed out when the water level input text box or the lower limit input text box was given a stri ng instead of a number. Implementing errorhandling capacity would incr ease error tolerance. Figure 62. Program LOSAC-C Quits Due to Input Error Figure 63. Type Checking for Textbox Input

PAGE 101

85 In Code Listing 28, the input for the txtLow Limit was first checked to see if it is a number. If not, the program will set the focus back to the txtLowLimit and highlight the dubious field (Figure 63). Therefore, the us er is offered an opportunity to correct the input error and the program will not be able to go forward with an erroneous parameter. Such type checking serves an important pur pose in improving the system’s reliability. In HyperGIS, an agent can take advantage of the established directory service and abstraction service to direct th e data request to an alternativ e path or cache in case of an unreachable data source. From Code Listing 27, the subroutine is changed to a function that can return a true or false value depending on wh ether its execution is successful: Public Function AddRasterFile(strPathname As String, strFilename As String) as Boolean Then an alternative image path is setup. If the first data server is not available, the agent will attempt to obtain similar data from another server (Code Listing 29). Dynamic Function Allocation An agent can also dynamically deploy functi ons to client side or server side according to certain pre-defined conditions or run-time detected parameters. Such a deployment method allows optimized executions of functions, thus achieves maximum efficiency in system performance. Defining DTD and Organizing XML Outputs The most important function that an agent performs in a HyperGIS is to organize eXtensible Markup Language (XML) outputs acco rding to a well-defined data dictionary. XML is very useful in constructing metadata and data dictionaries. The lake status data

PAGE 102

86 are available from the U. S. Army Corps of Engineers at the Jacksonville District (Figure 48) and the facilities of the South Florid a Water Management District (Figure 64). Figure 64. Raw Field Data for the Lake The information listed from either source lacks consistency and structure. In reality, users in different research fiel ds and management positions may only be interested in certain themes. For example, a researcher modeling the in-lake flows may only need to know the water elevation in each station; a water supply manager may only want the pump rate to determine whether the quota for irrigation has been met. However, there is no convenient way for a user to co llect the information easily. The user must either manually go through the records of each station or get assistance from station staff to ask them for a customized report. When the number of servers involved grows larger or the themes become more complex, neither method would be efficient or even practical. However, an agent equipped with a data di ctionary can extract the information (Figure

PAGE 103

87 65) and reformat it in XML using Date Type Definition (DTD), and consequently make it available for use by various users (Figure 66). Figure 65. Agent: Generating XML Data Figure 66. Reformat Raw Data with DTD XML approaches these problems by sepa rating structure from presentation. Therefore, the same data defined in XML can be presented in various formats. Table 4 lists the abbreviations used in the HTML f iles, which can be used as the foundation to build the DTD. Since in LOSAC, the major inte rest is the water level in the lake, other data filtered through the agen t are discarded. During the query, the corresponding lake

PAGE 104

88 area and lake capacity are derived. Those two da ta items thus added to the DTD as a part of the output XML document. Table 4. Abbreviations of Field Data Status is Good ? Status is TEST/OUT OF SERVICE EST Eastern Standard Time (Subtract 1 Hour For EDT in Summer) Telemetry Site Updated Continuously (Every 5 Minutes to 1 Hour Depending On Site) Dial-Up Site Updated Through the Day (Every 1 Hour to 5 Hours Depending On Site) Satellite Site Updated Through the Day (Every 3 Hour to 4 Hours Depending On Site) Manual Site Updated Periodically (G enerally Every 1 Day to 1 Week Depending On Site and Weather Conditions) CRST## Crest Elevation of Board in NGVD FLOW Average Discharge in CFS for Previous Day Ending at Midnight GATE## Gate Opening in Feet LEVL Water Elevation Derived from Multiple Locations RAIN Rainfall in Inches Since 7am EST RPM## Pump Rate in RPM STG Water Elevation at Site in NGVD STG-H Water Elevation On Upstream Side of Structure in NGVD STG-T Water Elevation On Downstream Side of Structure in NGVD Therefore, the new Document Type Definition is listed as Table 5. Based on the definitions, Table 6 illustrates the fo rmat of the XML document output.

PAGE 105

89 Table 5. Document Type Definition in XML Name Type Unit Water Level Double Feet Lake Area Double Square kilometers Lake Capacity Double Cubic kilometers Using a series of File Print statements, th e agent will save the lake status in XML (Code Listing 30). A snapshot of resulted XML file is shown in Figure 67. Table 6. Format of XML Document Figure 67. Listing of LOSTATUS.XML

PAGE 106

90 Similarly, at each given water level, the area data, the map view, the capacity data and the water level-areacapacity curves of the Lake can be output in XML as well (Figure 68). Figure 68. Agent: Generating Area and Capacity Data The subroutine mnuWeb_Click is used to output the map views and the water level-area-capacity charts (Code Listing 31). Two additional subroutines Export_JPEG (Code Listing 32) and Export_Chart (Code Listing 33) are called from the mnuWeb_Click. Implementing Workflow Service One of the most important asset of an ag ent is its capacity of acting autonomously without human intervention. An agent’s automaton is managed by its workflow service.

PAGE 107

91 Figure 69. Activity Diagram of Timer Workflow service can instruct the agen t to perform certain tasks according to certain pre-defined conditions such as timers, de tection of change of state, external input or feedback, etc. For LOSAC, since its main field data server is updated daily, a timer that would trigger the XML update once every 24 hours is an appropriate solution. To implement the workflow service, a Timer control is added to the program’s main form. The control with a timer icon appears on th e right of the INET c ontrol in Figure 70. Then the subroutine timerUpdate_Timer is implemented to carry out daily task of updating the lake status document in XML (Code Listing 34). When the agent is initiated, following statements are called to activate the timer with the daily update set on 7:00am (Code Listing 35).

PAGE 108

92 Figure 70. Timer Control on GUI Customizing Presentations with Style Sheets When the HTTP server receives a request to display lake status, it attempts to match the user’s requirement and apply the lake status XML document (Figure 67) to a corresponding template (Code Listing 36) fr om its Cascading Style Sheets (CSS) or Extended Style Language (XSL) collections. XS L provides features similar to those of CSS. XSL has more flexibility to rearra nge the components in the XML document. Figure 71 illustrates the proce ss of applying a CSS or XSL template to a XML file. With the same XML data, it is possible to create customized presentations that are tailored towards respective target audience by c onstructing correspondi ng style sheets and templates.

PAGE 109

93 Figure 71. Applying CSS or XSL to XML Document Measuring System Performance In the HyperGIS method, the Initializ ation, Get_RealTimeData and Query procedures are similar to those in the LO SAC-RT. The notable difference is that the Query procedure now results in output of fi eld data in XML format. Therefore, the measurement of the Query covers the execu tion of Code Listing 30: Exporting XML. Additional functions include output of the lake capacity charts and lake extent maps (Code Listing 32, Code Listi ng 33), whose execution time needs to be measured and recorded under the Map Output category.

PAGE 110

94 CHAPTER 5 RESULTS AND DISCUSSIONS During the design and implementation processes of the LOSAC system, it evolved from a centralized GIS, to a client-s erver GIS, then to a CGI-GIS, and finally to a HyperGIS. Using UML, a distributed spatia l system with distinctive yet integrated components is developed. XML helps to descri be the format of data exchanged between the components. The agent coordinates the information exchange among the components, which ensures an effective and reliable syst em. The implementation results are exciting. It confirms that the presentations generate d by HyperGIS are diverse and customizable. In addition, the simulation matched th e ground truth and satellite images. Customizable Presentations Figure 72 shows the result of XML document (Figure 67) rendered by the XSL template (Code Listing 36). It is an effectiv e technique to customi ze client presentations reusing the very same XML document. To render XML documents. Dynamic Hypertext Markup Language (DHTML) can also be used. DHTML sets out to addres s another limitation of HTML in presenting dynamic content. The generation of dynamic HT ML pages can be through either serverside or client-side scripting. A presentation in DHTML is described as a Document Object Model (DOM) while document elements are interpreted as obj ects and their attributes as properties of the objects (Goodman 1998). The objects change their behaviors when their attributes are

PAGE 111

95 changed or certain methods are applied to them. In this case, DHTML serves as a template to receive data from the XML data sources. Contents of the data are then extracted, combined and embedded at run-time and displayed in a hi erarchical structure at browsers. Figure 72. Rendered XML Document: Report with Table Figure 73 shows a presentation intended for the general public. It was rendered by DHTML (Code Listing 37) with the same XML document. With some minor modifications, additiona l templates can be quickly created for more customized presentations. In addition to the current lake status, the same XML documents can be used to create a Lake Status Lookup page. The display units of the lake area and capacity were conveniently cha nged from square kilometers and cubic kilometers to acres and million gallons. Figur e 74 shows the result that was rendered by DHTML (Code Listing 38), allowing users to look up the lake area and lake capacity at different stages.

PAGE 112

96 Figure 73. Lake Status Rendered by DHTML

PAGE 113

97 Figure 74. Rendered DHTML Page for Lake Status Lookup

PAGE 114

98 Figure 75. Rendered DHTML Page for Lake Okeechobee Time Series Figure 75 shows a DHTML page that allows a user to play animation of the time series data, and forward or rewind to a specifi c time frame. Such a presentation is highly

PAGE 115

99 useful in spatial-temporal analysis. In addition, a Water Supply Calculator can be constructed (Code Listing 39) to allow a user to calculate the potential water supply capacity between a high water level limit and a low water level limit (Figure 76). It grants broader audiences the access to some complex sp atial analytic functions that used to be accessible only by some GIS specialists. Figure 76. Water Supply Calculator HyperGIS radically changes how spatial information is delivered. A traditional GIS is a passive system. The conventional wisdom is that if the mountain would not come to Mohammed, then Mohammed must go to the mountain. In a passive GIS, the

PAGE 116

100 system disseminates information only when it receives a request from a user. Using work flow service, HyperGIS can proactively provi de critical information instead of operating reactively. Broadcasting the critical lake conditions to managersÂ’ cellular phones is a perfect example of integrating GIS and Wire less Application Protocol (WAP). The WAP protocols, a set of open, global protocols for developing applications and services that use wireless networks, are mainly based on existing Internet protocols, but are optimized for mobile users. Equivalent to HTML, Wirele ss Markup Language (WML) is used to create web pages that can be read by a WAP phone or similar wireless device. Applying the XML field data to a WAP style sheet, the lake status data can be transmitted to an alpha pager as a short message or viewd on a WAP phone using its build-in mini-browser (Figure 77). In that sense, HyperGIS has made the information mountain come to the user. Figure 77. Lake Condition Broadcaste d to a WAP-enabled Cellular Phone Figure 78 shows another wirele ss application in which the lake status data are beamed to a handheld device via IR. Such an application is especially useful for the managers who hold daily situation briefings during a water shortage or flood event.

PAGE 117

101 Managers can synchronize their PDA with the server for the current lake condition and other briefing materials, which ensures ev erybody on the team updated with consistent and current information. Figure 78. Lake Condition Beamed to a PDA via IR Comparing Simulation Results with Ground Truth and Satellite Images It is important to verify the outputs with the ground truth by comparing the generated maps with the ground and aerial su rvey photos, as well as satellite images. Such a comparison can help developers uncove r any deficiency in acquired data, spatial function libraries or implemented subroutines ; therefore reduce the likelihood of errors after the system is deployed for practical operations. It also offer an opportunity to present GIS simulation results along with even broader information resources such as web cam feeds, real-time video streams, rada r data, survey photos, GPS data, and aerial and satellite images. Figure 79 shows a SeaWiFS image obtained by the SeaStar

PAGE 118

102 spacecraft on May 18, 2000, when the lake elevation declined to 13.21 feet before the rainy season (SeaWiFS image courtesy of NASA). The image matched the simulation. Figure 79. Simulated Lake Extent and SeaWiFS Image on May 28, 2000

PAGE 119

103 Figure 80. Simulated Lake Extent and MISR Image on October 18, 2000

PAGE 120

104 The image in Figure 80 was acquired by NASA's Multi-angle Imaging Spectroradiometer (MISR) on October 18, 2000 (MISR image courtesy of NASA). The simulated lake extent was consistent with the MISR image, indicating a serious water shortage ahead as the lake elevation stood at 12.10 feet right after the rainy season. Figure 81 shows a photo taken by a helicopte r over the Structure S135 in April 2001 and the simulated lake conditions for the same time period. The photo revealed the exposed dry lakebed between the structur e and the lake body. The dry lakebed was shown as black strip along the north-east side of the lake on the simulated map when the lake elevation was 9.6 feet. Figure 81. Simulated Lake Cond itions and Aerial Photo over S135

PAGE 121

105 Similarly, Figure 82 shows an aerial photo of Eagle Bay in the north and the simulated lake conditions in April 2001. Th e location of the photo is indicated as a yellow dot in Figure 82. The photo also matche s the lake extent shown on the simulated map. Figure 82. Simulated Lake Conditions and Aerial Photo over Eagle Bay Figure 83 shows an aerial view on the T unerÂ’s Cove on June 30, 2001. The red dot in Figure 84 indicates the location wher e Figure 83 was taken. The photo along with the simulation result (Figure 84) offered an objective snapshot of the lake condition on June 30, 2001 when the lake stage recovered to 9.15 feet. It was just a little more than one month after the lake reached its r ecorded low at 8.97 feet on May 23, 2001.

PAGE 122

106 Figure 83. Aerial Photo over Turner's Cove on June 30, 2001 (SFWMD) Figure 84. Simulated Lake Condition on June 30, 2001

PAGE 123

107 Evaluation of System Performance Since timestamps have been placed on th e strategic points throughout the systems, it is possible to benchmark each systemÂ’s performance so that the efficiency of the respective method can be evaluated. The be nchmark tests of the four systems were conducted at the same time period so that th e external environment could be kept as identical as possible. The results were the average of the three sequential runs. Centralized Client-ServerCGI HyperGIS Initialization 48484 48 Remote Data N/A 41 4 Query/HTML Output 117 1 Map Output N/A N/A N/A 113 Total 495312 166 Figure 85. Performance Comparison for One Execution As a centralized system, the initializa tion of LOSAC-C took forty-eight seconds; a query and refreshing of the active vi ew took one second. For LOSAC-RT, the

PAGE 124

108 initialization and a query also took fortyeight seconds and one second respectively; obtaining remote data took another four sec onds. Since a CGI procedure did not invoke GUI, the initialization of LOSAC-CGI took sign ificantly less time: four seconds. Its access to the remote data was also more effi cient: one second. It needed another seven seconds to perform query and organize HTML outputs. With the HyperGIS approach, the initialization, obtaining remote data, query a nd output of XML field data took forty-eight seconds, four seconds, and one second respec tively. Output of maps and charts took additional one hundred thirteen seconds. Theref ore, the average time for one execution of LOSAC-C, LOSAC-RT, LOSACCGI, and LOSAC-HyperGIS was forty-nine, fiftythree, twelve, and one hundred -sixty-six seconds respectively (Figure 85). For single execution, LOSAC-CGI used the least amount of time. LOSAC-C was the second place while the LOSAC-RT was the closed third du e to remote data access. LOSAC-HyperGIS took the longest time as it needed to output extra maps and charts. Since a system usually handles multiple que ries in one day, it is essential to estimate the intensity of daily requests. Table 7. Water Shortage Web Log Hits 12/12/2000 0:00:00 12/19/2000 23:59:59 Entire Site 11,427 Daily Average 1,632 Visitor Sessions 12/12/2000 0:00:00 12/19/2000 23:59:59 Entire Site 1,797 Daily Average 256

PAGE 125

109 Table 7 summarizes the log for the water shortage web site during a one-week period from December 12, 2000 to December 19, 2000. A web visitor usually views multiple pages, thus a visitor session has multiple hits. On the other hand, a visitor is likely to view each page only once. Therefore, under the assumption that all visitors to the water shortage web site w ould be interested in lake c onditions, the daily requests to LOSAC systems can be presumed as two-hundred-fifty-six in average. Centralized Client-ServerCGI HyperGIS Initialization 48481024 48 Remote Data N/A 1024256 4 Query/HTML Output 2562561792 256 Map Output N/A N/A N/A 113 Total 30413283072 421 Figure 86. Performance Comparison for Daily Executions In daily performance comparison (Figur e 86), LOSAC-CGI reversed to be the worst performer because it needed to be in itialized, access remote data, and organize

PAGE 126

110 HTML output for each execution. Therefore, it placed the greatest burden on the server. On the contrary, once initialized, LOSACC, LOSAC-RT and LOSAC-HyperGIS could have multiple queries. LOSAC-RT took the second longest time as it hit remote data server every time. That also contributed to the network congestions. LOSAC-HyperGIS started to show its efficiency. However, the winner was still LOSAC-C as it had the fewest functions to perform. Centralized Client-ServerCGI HyperGIS Initialization 1440144030720 48 Remote Data N/A 307207680 120 Query/HTML Output 7680768053760 7680 Map Output N/A N/A N/A 113 Total 91203984092160 7961 Figure 87. Performance Comparison for Monthly Executions In long term, LOSAC-HyperGIS became the most efficient system (Figure 87). It even out-performed over LOSAC-C. LOSAC-C tended to be deployed on desktops as

PAGE 127

111 standalone systems. Therefore, over a period of time such as in a month, the usage pattern was more likely to be that multiple individuals launched multiple instances of LOSAC from their own desktops rather than that mu ltiple individuals came to a central station to use a single instance of LOSAC. However, LOSAC-HyperGIS was configured in such a way that it could run autonomously and serve multiple clients. It also optimized the schema for intelligent information update. For example, since the remote data server only updated once a day, LOSAC-HyperGIS was accord ingly set to output the field data in XML once a day. Therefore, it greatly reduced the impact on the remote data server. Nevertheless, the LOSAC-RT and LOSAC-CGI would request the same information from the remote data server for as many times as the number of queries. Client-side Agent Server-side Agent 2:23 PM Monday, March 23, 1998 CHART1 Client Server HTTP Server CGI Client appelet HTTP Server Client Constant Connection Fixed Function Portion at Server Side CGI Server Push Function dynamically distributed to client side Multiple Concurrent Data Connections Java Pre-allocated function portions at both sides Optimized Data Stream RTSP Server RealPlayer Plug-in Middleware Figure 88. Comparison of Middleware and Other Approaches

PAGE 128

112 Comparison Between HyperGIS and Other Approaches The advantages of using either a server-side approach or a client-side approach will depend on the particular network environments. For example, using the Java approach may be beneficial to a powerful clie nt as it will free the server to perform other tasks. However, a server-side approach ma y be the only choice to execute a certain function as a lower end client would eas ily crash under excessive demand for its processing power and data storage capacity. Since the real-world network environments are complex and consist of numerous scenario s, either approach is far from ideal to embrace every situation. That is where a HyperGIS system can be more efficient (Figure 88). The comparisons of the four me thods can be seen in Table 8. Table 8. Features of HyperGIS Centralized GIS ClientServer GIS CGI GIS HyperGIS Source Data Reuse No Yes Yes Yes Heterogeneous Data No No Limited Yes Real Time Data Access No Yes Yes Yes Dynamic Functions N/A No No Yes Performance Efficiency Excellent Good Average Very Good System Reliability Excellent Good Average Very Good Cross Platform No No Yes Yes Special Software (End Users) Yes Yes No No User Interactivity Limited Limited Good Excellent Customizable Presentation No No No Yes Code Reuse Yes Yes Yes Yes Development Redundancy High Average High Low

PAGE 129

113 CHAPTER 6 CONCLUSIONS AND RECOMMENDATIONS In conclusion, the design and implemen tation efforts made by this researcher show that HyperGIS can best serve those a pplications that require the Web client to mediate between two or more heterogeneous data sources. The data sources for the web presentation of a HyperGIS can include GIS coverages, binary numerical model output, descriptive texts, photos and reference da tabase. Using XML enables effective and seamless data exchanges while retaining a hier archical data structure. Combined with CSS and DHTML, the system allows manipula tion of the document objects, thus users can customize the presentations in formats ra nging from otherwise linear and static to fully interactive (Figure 89). Figure 89. Same Data, Many Faces

PAGE 130

114 In addition, the design and implementa tion process also indicates that any component including data server, function server , client and agent itself can be upgraded without having to upgrade other components. In this case, the lake field data web server and other local data servers are independen tly developed and maintained. When a new version of the supporting software becomes ava ilable, the adjustment to the agent can be made if needed. It is unnecessary to m odify the whole system to accommodate the upgrade as other approaches do. An update or upgrade has very limited effects on systemÂ’s operation and users will be ab le to enjoy the improved performance immediately. Figure 90. Caching Mechanism to Provide Backup Data Because the agent employs error-checki ng for the input data and establishes alternative paths to backup data, the system ha s gained enhanced reliability (Figure 90). For example, such services can provide local/network cache to reduce system downtime even when sites are not immediately availabl e. When a server is going to shut down, it will post a notice to the agent. Then the agent will anticipa te the service that will be needed and will retrieve a copy of the data for the client to use during the serverÂ’s down time. The agent uses directory service to maintain a pool of diverse data and takes advantage of abstraction service to access heterogeneous information.

PAGE 131

115 By redirecting or dynamically alloca ting a significant proportion of the functionality from server to client, the be nefits reach beyond the immediate optimization of system performance; it also opens the potential of tailoring information to suit the specific needs of individual users. The agent uses workflow service to perform daily tasks autonomously. The system automaton eliminates human involvement in operating the system, thus improves the over all efficiency of the information delivery. Messaging services provided by the Internet agent in a HyperGIS enable client s and servers to communicate with one another in a reliable manner. Benefits of HyperGIS Developers and general users alike can benefit from HyperGIS. For developers, the object-oriented design empowers m odularized components in HyperGIS, which allows flexibility and expandability in a ddition to the independent development and maintenance for an individual module. The main advantage of building self-contained components using object-oriented technology is that each component in HyperGIS can be individually reused. By taking advantage of existing data and a function server, developers can expect to significantly redu ce development cost as well as development span. The agentÂ’s abstraction services hide details of a specific GIS/DBMS product from the client applications to enable clients to work w ith different GIS products without having to hard-code the linkage between the di fferent databases. In the traditional way of hard coding the relations betw een functions in a GIS, the labor cost grows exponentially along the complexity of the GIS. HyperGIS appears to have a steeper initial curve for labor cost in the short term because it take s more efforts to build reusable components.

PAGE 132

116 However, in the long run, the cost curve will level off in spite of the increase of complexity (Figure 91). The object-oriente d HyperGIS approach can save time and resources in system development and maintenance. Figure 91. Relationship between Complexity and Labor Cost For general users, the Internet agent in HyperGIS is able to furnish work-flow service to automatically route data and control options to the appropriate servers or clients for timely analysis, simulation a nd presentation based on factors such as predefined events, results of query, an internal timer, or externally created situations. Therefore, it brings fundamental changes to the geographical information systems that once passively responded only to a query from the user. An agent in HyperGIS can act adaptively according to the userÂ’s profile and improve its behavior continually by noticing recurrent patterns of actions and ev ents. Such a capacity in troduces true two-way interactivity to a spat ial information system.

PAGE 133

117 Last but not least, Internet agents inte ract with end users via widely available standard browsers. Compared with other special-purposed interfaces from various GIS software packages, the easy-to-use multimedia user interface presents simplified and consistent user control. Thus, it expands the GIS user base and makes geographical information more accessible to the general public (Figure 92). Such accessibility is ultimately important to promote public awar eness and support for development of GIS applications. Figure 92. User Bases of Different Approaches

PAGE 134

118 Obstacles and Resistance to Adoption of HyperGIS It is expected that there may be both obs tacles to the development of HyperGIS and resistance to its adoption. Social factors, cost and performance are major factors in considering adoption of new technology (M eadow 1998). If people can be grouped as innovators , early adapters , early majority , late majority and laggards : according to their attitudes toward adoption of new technology, on ly the first two are ready to move ahead. Most people are deliberate, or skeptical, or just prefer to do things the traditional way. In addition, the initial costs during the transiti on can be prohibitive. People will be even less enthusiastic about abandoning th eir capital investments in th e existing approaches, yet the new technology may eventually save in the long run. Performance concerns include accessibility, quality, dependency, and customization. A new system is subject to multiple fine-tuning before it can perform at its peak level. Since it is new, there will be fewer people who know how to customize it and to provide quality support. Yet some adopt the new technology only after the need is clearly proven. In spite of all those concerns, the collective indications of many current integration efforts clearly point toward the direction where HyperGIS will eventually prevail. For example, the ArcIMS from ESRI now provides access to othe r ArcIMS servers; FME Objects from www.safe.com can translate data between di fferent formats. Those efforts, although limited to their proprietary systems, reflect the trends within the GIS industry towards distributed heterogeneous data. Facilitating the access to distributed heterogeneous data is the fundamental mission of HyperGIS.

PAGE 135

119 Limitations and Future Implementations The development of LOSAC fulfilled the objective of demonstrating how to design and implement a HyperGIS. However, due to time and cost constraints, there are a few limitations to be addressed in the future implementations. The elevation data of the Lake basin is in need of update. First, the current data were collected in 1989. The elevation could ha ve changed during the past decade as more sediment has flowed into the lake. The wave and flow dynamics can also have a significant impact on lake bottom elevation. In addition, the spatial resolution is relatively low with one-kilometer by one-kilometer grids, which prevents any detailed spatial analyses. The directory service can be improved by establishing a metadata archive so that the data directory can be exchanged, indexed and searched. In addition, if conversion of different projections is supported by the abst raction service, the LOSAC will have access to much broader information sources. System reliability can be further im proved by establishing a local cache of historical water elevation data. That mechanism will not only reduce the system uncertainty if the remote field data server is off-line, but also o ffer a new opportunity to carry out time-series analysis. Future implementations may include an image module that is dynamically deployed to allow users to change the band combination of the background image. There are also practical needs to change the bac kground image sources to match the time series or to resample the image to match the desired spatial resolutions. In addition to the timer-triggered event to update the XML documents, the workflow service can be configured so that it can listen for events of theme data update.

PAGE 136

120 Since the real-world network environments are complex and varied, more tests on the combinations of different client/serve r configurations will be beneficial. Lessons Learned Looking back, this researcher has learned va luable lessons from the past research experience on HyperGIS. If this researcher could start all over again, one thing that would not change will be his belief in pur suit of an open GIS. Most human decision making processes involve spatial information. However, the use of spatial information has been limited due to hardware, software, and human factors. All roads lead to Rome . There may be alternative approaches other th an HyperGIS that could achieve the similar results. The mission of facilitating the spatial information flows will remain. This researcher was also fortunate en ough to be able to recognize the hybrid nature of the development environment, a nd appreciate its openness and diversity. There have been a lot of temptations to be is olated in a homogeneous but proprietary environment. However, it is important to stay with a set of open code bases that have abundant reusable components. It is equally sign ificant to resist the attempt to select one development tool unconditionally over the othe r. Each tool has its own pros and cons. A wise man is the one who knows what to use at a given time. This researcher regrets that despite of the earlier attempts to set up a mailing list and a web site, the effort of building a coal ition failed to materialize. Since promoting HyperGIS is such a huge undertaking, it ta kes consensus from many data providers, function providers and developers to make the idea viable. Since a soldier in solitary splendor can not conquer much, it is crucial to build an alliance early . The true potential

PAGE 137

121 for HyperGIS is the interaction among the di stributed data, distributed functions, and distributed developments. Figure 93. Interaction between Distribut ed Data, Functions and Developments Recommendations for Future Research In order to promote HyperGIS, the future research should focus on establishing a HyperGIS Consortium; researching dynamic allocation of functions; and educating the general public. A HyperGIS Consortium should be established to set up guidelines on metadata standards, data exchange standard and cl ass hierarchies for spatial functions. In a HyperGIS, an agent maintains directory serv ice for various data sources by providing a registry of GIS data servers in order to lo cate where required services can be found. For such a service to be truly useful and efficien t, it is crucial for data providers to have a consensus on the standard of the metadata, in particular, the document type definition

PAGE 138

122 (DTD). It will enable users to search and s ubset remote data effectively and efficiently. Without it, sharing data have to be handl ed on a case-by-case basis. Especially, the distributed search capacity will be limited. Considerations should be given to data format standard that would make the efforts of conversion between the different data formats and re-projection between the different projections seamless. Currently, inco mpatible data are still the major obstacle of transferring data between th e different systems. In addition, the framework of class hier archies for spatial functions should be established as soon as possible, so that the developers can coordinate their distributed development efforts and contribute to the distributed spatial function libraries. As envisioned, such a framework for spatial func tions could bring radica l changes in the way that the spatial functions are used. It would be ridiculous if anyone who wants to travel by plane will be asked to buy an airline. Howe ver, that is how GIS software is currently marketed. Just as few people would afford to fly if they had to own an airline, the result is a limited GIS user base. With the modularized libraries of spatial functions, users can cherry-pick the functions that they really need. Using such an Application Service Provider (ASP) model, GIS will become more affordable and the user base can be expanded rapidly, which will in turn to en rich the modularized libraries of spatial functions and make more data available. The research on dynamical allocation of spatial functions should be focused on how to intelligently detect and analyze clie nt resources. Currently, one method is to set up a profile at the server, which may be cons idered cumbersome as it requires client to

PAGE 139

123 sign in each time. Another method is to use c ookies to record the clientÂ’s state, which may cause privacy and security concerns in certain occasions. The next important task is to educate the general public, first, to showcase what spatial information can better their decisi on making process; second, to increase the awareness what the technical limitations are. So that the general public can have a realistic expectation. Impacts of HyperGIS on Digital Divide Since HyperGIS appears to be altering almost every facet of the way we do GIS, such fundamental transformations are now be ginning to raise importa nt questions about their consequences for social divisions, diversity and differences where spatial information has been playing an important role in decision making. The digital divide is an unequal power status because of the di scontinuity caused by unequal access to new technology and information. Some people wa rn that the gap between information haves and have-nots is still widening. Therefore, HyperGIS, among other emerging new technologies, appears likely to at least temporarily contribute to a widening of the social division between the information-rich and th e information-poor as the big corporations are in a better position to redeem their alr eady held advantages in the pursuit of higher profitability and corporate control. However, HyperGIS advocates a greater accessibility to massive spatial information, its adoption has the potential to evidently lead to empowering the previous information-poor and narrowing the digital divide. HyperGIS can reach broader audiences by lessening the requirement on end users for special software. Meanwhile, the threshold of hardware can be lowered corres pondingly due to the elimination of the need

PAGE 140

124 for special software. In addition, the presen tations produced by HyperGIS can be tailored to match the education levels of its intended audiences. Thus, end users no longer have to undergo lengthy special trainings for spatia l information access. Therefore, if we can always keep in mind what social and economic consequences a HyperGIS may bring, we will be able to minimize the negative impact and take advantage of its positive influence when we implement the changes and prepare for the future (Figure 94). Figure 94. Bridging Information Poor and Information Rich

PAGE 141

125 GLOSSARY 3GL . Third-generation language. In the beginnin g of the computing, there was machine code. Then came assembler, which was referred to 2GL. The third generation introduced languages, such as COBOL, FORTRAN, C and PASCAL. The newer object-oriented languages, such as C++ and SmallTalk, generally are still considered to be 3GLs as well or 3.5GLs. 4GL . Fourth-generation language. A higher-le vel language usually constructed upon a 3 GL. 4GLs are especially prevalent when it comes to databases. Examples are PowerBuilder and SQLWindows. Abstraction Service . A procedure of hiding details of a specific GIS/DBMS product from the client application. Agent . A software entity that can perform certain tasks for the user. The idea of agents was originated by John McCarthy in the mid-1950s, and developed and named by Oliver G. Selfridge at MIT. API . Application programming interface. Applet . The name given to dynamic Web pages written using the Java technology. An applet is a computer program that can display smooth animation on a browserÂ’s screen. ASP . Application service provider. Automated Search Service . Any service that locates in formation without requiring a user to make decisions or select from menus. Automated search services either search titles or complete documents. Ex amples includes Lycos, Yahoo!, and Alta Vista. A/V . Audiovisual. Bandwidth . The capacity of a network, usually m easured in bits per second. Bandwidth is the range of frequencies capable of being reproduced by a given system. The higher the bandwidth, the more inform ation can be pumped over the carrying medium. Bookmark . A facility in a browser that can record the location of a particular page, making it possible to return to the page later.

PAGE 142

126 Browser . A browser is a client that can access single or multi-protocol communication. Specifically, it refers to web browsers, computer programs that allow users to view hypermedia documents on the World-wide Web. Bulletin Board Service . A service that permits one person to post a message for others to read. Each bulletin board contains discussi on of a single topic. A bulletin board is sometimes called a computer conference. Caching . A technique to speed data access. Each time a data file is called for, it is copied to an area set aside for caching. The theory is that if one person wants a data file, the chances are good that she/he might need it again or somebody else might too. First-time access wonÂ’t benefit, but subsequent requests for the same file will be much faster, since it now resides in memory or local medium. CGI . Common Gateway Interface. A technology that uses a computer program to assemble a Web page whenever a user requests the page. Pages composed using CGI technology are dynamic; unlike static pages they are not stored on the serverÂ’s disk before requests arrive. Client . A computer hardware or software that makes use of particular resources from a server. Client/Server Architecture . A client/server architecture is an approach to computing that has separate processes on separate platforms interacting with each other permitting the sharing of resources while taking the best advantage of difference devices. Connection . A transport layer (virtual) circuit established between two application programs for the purpose of communication. Cookie . A short file that a web browser used to record the states of the client environment. CORBA . Common Object Request Broker Architect ure. An emerging standard from the Object Management Group. CORBA is intended to assist in the intercommunication of networked objects. In its first rendition, it specifies what ORBs (Object Request Brokers) should generally look like. CORBA 2.0 further defines how they should communicate. ORBs are a new form of middleware that are beginning to make their presence felt. CSS . Cascading Style Sheets. A series of docum ents that are attached to web documents and define the web documents display styl es such as font, color and spacing.

PAGE 143

127 Database . A database can be defined as a collection of information permanently stored in a computer and accessible by a computer application to support application processing. DBMS . Database management system. DCE . Distributed computing environment. DCE is a set of operating system-independent services for the development and use of distributed applications. Designed and developed by the Open Software Founda tion (OSS), DCE contains Distributed File Services, Naming Services, a time serv ice, system management services, and security services. DDE . Dynamic Data Exchange. DHTML . Dynamic HyperText Markup Language. DIAL . Data and Information Access Link (DIA L) is a WWW based data distribution system. It allows data providers to easily serve Earth science data directly to users over the Internet. Digital Library . A large collection of information that has been stored in digital form. A digital library can include documents, images, sounds, and information gathered from ongoing events (e.g., continuous pi ctures from a weather satellite). Directory Service . A procedure of providing registry of information resources such as GIS data and function servers. Directory Service is used to locate where required services could be found. Distributed Computing . Refers to the case where more than one independent computer process is used to complete a specified task. Distributed Database . A distributed database is a data base where the data is divided among more than one database instance, but may be treated as a single logical database by applications. A distributed data base can exist on the same platform or on multiple platforms. Distributed Processing . Means that the processing of an application unit of work uses more than one independent computer process, where the processes included are application processes and ar e not part of an operation system, database, or other support system. DLL . Dynamic Link Library. Used for shari ng Windows resources or small pieces of executable code. DOM . Document Object Model.

PAGE 144

128 Encoding . The process of converting information to certain format. ESRI . Environment System Research Institute, vender of the widely used GIS software ARC/INFO and Arcview. Frame . A single page or screen display of videotext. FTP . File Transfer Protocol. The Internet servic e used to transfer a copy of a file from one computer to another. GIS . Computer-based systems for the collectio n, storage, management, analysis and presentation of geographical or spatial data. Gopher . The name of an Internet browsing servi ce in which all information is organized into a hierarchy of menus. Gopher displa ys a menu on the screen and allows the user to select an item. The selection either leads a file of information or to another menu. GPS . Global Positioning System. GrADS . Grid Analysis and Display System. Groupware . Software designed to assi st individuals at different locations to collaborate and work together as a group. GUI . Graphical User Interface that uses graphi cs to allow human-computer interaction. Host . Any computer directly connected to the ne twork. A host is not the same as a server. HTML . HyperText Markup Language. The computer language used to specify the contents and format of a hypermedia document in the World-wide Web. HTTP . Hyper Text Transfer Protocol. The prot ocol used to access a World-wide Web document. HyperGIS . HyperGIS is a collection of distribute d software agents, which could manage distributed processing of spatial data by ma intaining directory service, abstraction service, messaging service and work-flow service. HyperGIS is a GIS that contains links to other spatial and/or non-spatial information systems. Hyperlink . In hypermedia, a programmed link between items of information in different sections of a program, or in physically different locations within a network. Hypermap . An interactive, digital, multimedia map.

PAGE 145

129 Hypermedia . An information storage system in which each page of information can contain embedded references to images, sounds, and other pages of information. Hypertext . Data that contains links to other data. Information Superhighway . A term used by the popular press to refer to the emerging international information infrastructure. The Internet is the first part of the information infrastructure. Infrastructure . A service or facility that is fundame ntal to a society. Examples include systems for delivering food and water, tran sportation facilities, and telephones. Internet . An extensive cluster of world-wide -linked computer networks for global communications. It is a massive information source. JAD . Joint application development. Key Frame . The reference frame which describes the principal position in a movement, or provides the decision points from whic h the user can choose to branch to another part of the program. MIME . Multipurpose Internet Mail Extensions. Messaging Service . A procedure of transmitting operational information for the purpose of enabling clients and servers to comm unicate with one another in a reliable manner. Metadata . A data dictionary for the pur pose of describing other data. Middleware . Middleware is a collecti on of distributed computi ng services that, within any given processing environment, enable s clients and servers to communicate and inter-operate with one another in the most expedient, flexible, and correct manner possible. There are three types: remote procedure calls, message-passing schemes, and object request brokers. MUI . Multimedia User Interface is a multimedia oriented interface that allows direct manipulation of on-screen objects and events using icons, menus and dialog controls. Multimedia . Originally referred to slide/sound pres entations controlled by a computer. Currently used as a generic term for integration of many media elements on a single computer screen for display and projection. Multicast . The technique used to send a given packet to a selected set of other computers. Internet audio and video se rvices use multicast delivery to send a packet from a single source to many com puters on the Internet, or to allow a

PAGE 146

130 group of users to interact in an audio or video teleconference. Compare to unicast and broadcast. Multithreading . The simultaneous execution of different parts of the same application. ODBC . Open Database Connectivity. OLE . Object Linking and Embedding. Open System . A non-proprietary technology or system; any vendor can use the specifications of an open system to build products and services . The Internet and its technologies are open. Packet . Used informally to describe the unit of data sent across a packet switching network. PDA . Personal Digital Assistant. Plugin . A technology in which a browser can dyna mically load additional software that allows the browser to interpret new or alternative data formats. PNG . Portable Network Graphics. An extensible file format for lossless, portable and well-compressed storage of raster images. PPP . Point-to-Point Protocol. A protocol used to send TCP/IP traffic across a serial transmission line. Protocol . The rule two or more computers must follow to exchange messages. A protocol describes both the format of messages th at can be sent as well as the way a computer should respond to each message. RDBMS . Relational database management system. RPC . Remote Procedure Call. RPCs are an extension to the standard, local, library, or subroutine call. The differences is that th e routines being call ed donÂ’t have to sit on the same host. SGML . Standard Generalized Markup Language. Server . A computer hardware or software that provides particular resources. SQL . Structured Query Language. TCP/IP . Transmission Control Protocol and Intern et Protocol. It is the foundation of the Internet. TCP handles the difficult task of ensuring that all data arrives at the

PAGE 147

131 destination in the correct order. IP is a specification for the format of packets computers use when they communicate across the Internet. UML . Unified Modeling Language. Unicast . The usual technique for sending a pack et through the Internet from a single source to a single destination. Co mpare to broadcast and multicast. URL . Uniform Resource Locator. A short character string used by browsers to identify a particular page of informa tion on the World-wide Web. WAIS . Wide Area Information Server. An Internet automated search service that permits one to locate documents that contain key words or phrases. WAP . Wireless Application Protocol. A protocol used to send World-wide Web contents across wireless networks. Whiteboard Service . A service that permits a group of users to establish a session that permits all of them to see and update the same display. The display can begin blank or can start with a document. When ever a participant modifies the display by adding text or graphics, all other users see the changes immediately. WML . Wireless Markup Language. Pages written in WML can be read by a WAP phone or similar wireless device. Work-flow Service . A procedure to route data and cont rol to the appropriate server or client for timely processing or presenta tion based on factors such as predefined events, results of query, an internal ti mer or externally created situation. World-wide Web . World-wide Web, or WWW, is a hypertext-based information and communications application system r unning on the Internet for information dissemination and collection according to a client/server model. XML . Extensible Markup Language. XSL . Extensible Style Language.

PAGE 148

132 APPENDIX CODE LISTING Code Listing 1. Loading the Main Form Option Explicit ‘ Define system-wide parameters Private Declare Function DIWriteJpg Lib "DIjpg.dll" (ByVal DestPath As String, ByVal quality As Long, ByVal pr ogressive As Long) As Long Private m_pEnv As IEnvelope Dim dblXFactor As Double , dblYFactor As Double Dim pLayer As ILayer, pFLayer As IFea tureLayer, pRLayer As IRasterLayer Dim pCBRenderer As IClassBreaksRenderer Dim pSRenderer As ISimpleRenderer Dim pFillSymbol As ISimpleFillSymbol Dim pColor As IColor, pEnumColors As IEnumColors Dim pGeoLayer As IGeoFeatureLayer Dim pFDefine As IFeatureLayerDefinition Dim strQuery As String Dim pQFilter As IQueryFilter Dim intZoomFlag As Integer, intZoomFactor As Integer Dim lngNumClasses As Long Dim arrBreaks(9) As Integer Dim intBreakIndex As Integer Dim arrArea(192) As Double, arrCapacity(192) As Double Dim strAreaFormat As String, strCapacityFormat As String ‘ Start to Load the Main Form Private Sub Form_Load() ‘ Display the banner while wa iting the initialization Load frmSplash frmSplash.Show ' Set up parameters AutoRedraw = True intZoomFactor = 8 lngNumClasses = 9 strCapacityFormat = "#0.00#####" strAreaFormat = "###0.00"

PAGE 149

133 ‘ Call routine to draw legend Draw_Legend lngNumClasses ‘ Add theme data layers AddShapeFile "d:\gis\full-basin", "lo" AddShapeFile "d:\gis\shapefiles", "Lo_1kmstage89" ' Set the lake boundary Set pFLayer = mpcLake.Layer(1) Set pSRenderer = New SimpleRenderer Set pFillSymbol = New SimpleFillSymbol pFillSymbol.Style = esriSFSHollow Set pSRenderer.Symbol = pFillSymbol Set pGeoLayer = pFLayer Set pGeoLayer.Renderer = pSRenderer ' Set the elevation data layer Set pFLayer = mpcLake.Layer(0) Set pQFilter = New QueryFilter ' Initialize area an d capacity arrays txtInput.Text = "16.00" txtLowLimit.Text = "1.00" lblAnno1.Caption = "between " & Format (CDbl(txtInput.Text), "#0.00") & " ft and " Init_Area_Arrays Init_Capacity_Arrays txtArea.Text = Format(arrArea(CInt (txtInput.Text) * 12), strAreaFormat) txtCapacity.Text = Format(arrC apacity(CInt(txtInput.Text) * 12) arrCapacity(CInt(txtLo wLimit.Text) * 12), strCapacityFormat) ‘ Call routine to convert data for alternative display Unit_Conversion ‘ Call routine to generate the Wate r Level Area – Capacity Curve Draw_Curve CInt(CDbl(txtInput.Text) * 12), CInt(CDbl(txtLowLimit.Text) * 12) ‘ Set map extent mpcLake.Extent = mpcLake.FullExtent Set m_pEnv = mpcLake.Extent dblXFactor = mpcLake.Extent.XMax mpcLake.Extent.XMin dblYFactor = mpcLake.Extent.YMax mpcLake.Extent.YMin ‘ Call routine to classify the feature layer Classify_Stage 12 * CInt(txtInput.Text)

PAGE 150

134 ‘ Dismiss the banner display Unload frmSplash ‘ Form loading ends and waits for further user input End Sub Code Listing 2. Subroutine of Draw_Legend Private Sub Draw_Legend(lngNumClasses As Long) Dim legendColor As Long, dblYLegend As Double Dim lngLegendX As Long, lngLegendY As Long dblYLegend = 1.2 Set_Breaks Set pEnumColors = GetColor(RGB(255, 170, 120), vbBlue, lngNumClasses) CurrentX = sldStage.Left CurrentY = sldStage.T op + sldStage.Height + 500 Print "Depth (feet)" For intBreakIndex = 0 To lngNumClasses 1 Set pColor = pEnumColors.Next legendColor = pColor.RGB lngLegendX = sldStage.Left + 50 lngLegendY = sldStage.Top + sldStage.Height + 700 + intBreakIndex * sldStage.Height / (dblYL egend * lngNumClasses) Line (lngLegendX, lngLegendY )-Step(500, sldStage.Height / (dblYLegend * lngNumClasses)), legendColor, BF Line (lngLegendX, lngLegendY )-Step(500, sldStage.Height / (dblYLegend * lngNumClasses)), vbBlack, B CurrentX = CurrentX + 50 CurrentY = CurrentY sldSta ge.Height / (dblYLegend * lngNumClasses) If intBreakIn dex = lngNumClasses 1 Then Print " > " & CInt(arrBreaks(1) / 12) Else If intBreakIndex = 0 Then Print " < " & CInt(a rrBreaks(lngNumClasses intBreakIndex 1) / 12) Else Print CInt(arrBreak s(lngNumClasses intBreakIndex) / 12) & " " & CInt(arrBreaks(lngNumClasses intBreakIndex 1) / 12) End If End If Next End Sub

PAGE 151

135 Code Listing 3. Function of Set_Breakers Public Function Set_Breaks() As Integer arrBreaks(0) = 156 arrBreaks(1) = 132 arrBreaks(2) = 108 arrBreaks(3) = 84 arrBreaks(4) = 60 arrBreaks(5) = 48 arrBreaks(6) = 36 arrBreaks(7) = 24 arrBreaks(8) = 12 End Function Code Listing 4. RenderLayers.BAS: GetColor Function Option Explicit Public Function GetColor(vbStartColor As Long, vbEndColor As Long, lngNumColors As Long) As IEnumColors Dim pStartColor As IRgbColor Dim pEndColor As IRgbColor Dim pRamp As IAlgorithmicColorRamp Dim blnIsRampOK As Boolean Set pStartColor = New RgbColor Set pEndColor = New RgbColor Set pRamp = New AlgorithmicColorRamp pStartColor.RGB = vbStartColor pEndColor.RGB = vbEndColor With pRamp .Algorithm = esriHSVAlgorithm .FromColor = pStartColor .ToColor = pEndColor .Size = lngNumColors End With pRamp.CreateRamp blnIsRampOK If Not blnIsRampOK Then Exit Function Set GetColor = pRamp.Colors End Function

PAGE 152

136 Code Listing 5. Subroutin e that Adds a Shape File Public Sub AddShapeFile(strPathname As String, strFilename As String) Dim pWorkspaceFact ory As IWorkspaceFactory Dim pFeatureWorkspace As IFeatureWorkspace 'Create a new ShapefileWorkspaceFactory object and open a shapefile folder Set pWorkspaceFactory = New ShapefileWorkspaceFactory Set pFeatureWorkspace = pWorkspa ceFactory.OpenFromFile(strPathname, 0) 'Create a new FeatureLayer an d assign a shapefile to it Set pFLayer = New FeatureLayer Set pFLayer.FeatureClass = pFeature Workspace.OpenFeatureClass(strFilename) pFLayer.Name = pFLayer.FeatureClass.AliasName 'Add the FeatureLayer to the map control mpcLake.AddLayer pFLayer End Sub Code Listing 6. txtInput_KeyPress ‘ Enter key pressed in the txtInput text box indicates a valu e is entered, and results in the change of sldStage’s value. Private Sub txtInput_KeyPress(KeyAscii As Integer) If KeyAscii = vbKeyReturn Then If IsNumeric(txtInput.Text) Then If txtInput.Text > 16 Then txtInput.Text = "16.00" ElseIf txtInput.Text < 1 Then txtInput.Text = "1.00" End If ‘ Trigger the change of slider bar sldStage.Value = (1700 100 * txtInput.Text) Else ‘ Reset focus and highlight the text With txtInput .SetFocus .SelStart = 0 .SelLength = Len(txtInput.Text)

PAGE 153

137 End With End If End If End Sub Code Listing 7. Status Change of Slide Bar: sldStage_Change Private Sub sldStage_Change() txtInput.Text = (1700 sldStage.Value) / 100# frameElev.Caption = "Lake Elevation: " sldStage.ToolTipText = (1700 sldStage.Value) / 100# & " feet" Show_Stage End Sub Code Listing 8. Showing ToolTipText on Slider Bar Private Sub sldStage_Scroll() sldStage.Text = (1700 sldStage.Value) / 100# End Sub Code Listing 9. Show_Stage Private Sub Show_Stage() ‘ Define Query strQuery = "Elevation <= " & txtInput.Text pQFilter.WhereClause = strQuery ‘ Conditional Branch to determine whet her the data layer is a feature layer If (TypeOf pFLayer Is IFeatureLayer) Then Set pFDefine = pFLayer pFDefine.DefinitionExpression = strQuery ‘ Classify the feature layer Classify_Stage CInt(txtInput.Text * 12) ‘ Get area and capacity data txtArea.Text = Format(arrArea( CInt(txtInput.Text * 12)), strAreaFormat) If CDbl(txtLowLimit .Text) > CDbl(txtInput.Text) Then txtLowLimit.Text = txtInput.Text End If

PAGE 154

138 lblAnno1.Caption = "between " & Format(CDbl(txtInput.Text), "#0.00") & " ft and " txtCapacity.Text = Format (arrCapacity(CInt(txtInput.Text * 12)) arrCapacity(CInt(txtLo wLimit.Text * 12)), strCapacityFormat) ‘ Call routine to convert data for alternative display Unit_Conversion ‘ Call routine to generate the Wate r Level Area – Capacity Curve Draw_Curve CInt(CDbl(txtInput .Text) * 12), CInt(CDbl(txtLowLimit.Text) * 12) End If ‘ Refresh display mpcLake.ActiveView.Refresh End Sub Code Listing 10. Subroutine of Classify_Stage Private Sub Classify_Stage(i ntStageInInch As Integer) ‘ Set parameters Set pCBRenderer = New ClassBreaksRenderer pCBRenderer.Field = "Stage" pCBRenderer.BreakCount = lngNumClasses pCBRenderer.SortClassesAscending = False pEnumColors.Reset ‘ Loop through the classified layer For intBreakIndex = 0 To lngNumClasses 1 Set pFillSymbol = New SimpleFillSymbol Set pColor = pEnumColors.Next ‘ Set fillsymbols With pFillSymbol .Color = pColor .Outline = Nothing .Style = esriSFSSolid End With ‘ Assign fillsymbols pCBRenderer.Symbol(intBreakIndex) = pFillSymbol

PAGE 155

139 pCBRenderer.Break(in tBreakIndex) = intStageInInch arrBreaks(intBreakIndex + 1) Next ‘ Render the view Set pGeoLayer = pFLayer Set pGeoLayer.Renderer = pCBRenderer End Sub Code Listing 11. Function of Get_ALC Option Explicit ‘ Set function as public so that it can be used by external procedures Public Function Get_ALC(pFClass As IFea tureClass, pQFilter As IQueryFilter) As Double Dim pFCursor As IFeatureCursor Dim pFeature As IFeature Set pFCursor = pFClass.Search(pQFilter, True) Select Case pFClass.ShapeType 'For case of esriGeometryPo int, esriGeometryMultipoint Case 1, 2 Dim dblCount As Long Set pFeature = pFCursor.NextFeature Do Until pFeature Is Nothing dblCount = dblCount + 1 Set pFeature = pFCursor.NextFeature Loop Get_ALC = dblCount 'For case of esriGeometryPolyline, esriGeometryPath, esriGeometryLine, esriGeometryCircularArc, esriGeometryBezier3Curve, esriGeometryEllipticArc Case 3, 6, 13 To 16 Dim dblLength As Double Dim pCurve As ICurve Set pFeature = pFCursor.NextFeature Do Until pFeature Is Nothing Set pCurve = pFeature.Shape

PAGE 156

140 dblLength = dblLength + pCurve.Length * 0.3048 / 1000 Set pFeature = pFCursor.NextFeature Loop Get_ALC = dblLength 'For case of esriGeometryPolygon, es riGeometryEnvelope, esriGeometryRing Case 4, 5, 11 Dim dblArea As Double Dim pPoly As IArea Set pFeature = pFCursor.NextFeature Do Until pFeature Is Nothing Set pPoly = pFeature.Shape dblArea = dblArea + pPoly.Area * 0.3048 * 0.3048 / 1000000 Set pFeature = pFCursor.NextFeature Loop Get_ALC = dblArea ‘ Return -999 as flag for the feature cla sses other than points, lines and polygons Case Else Get_ALC = -999 End Select End Function Code Listing 12. Converting Data for Alternative Display Private Sub Unit_Conversion() ' 1 foot = 0.3048 meters ' 1 square kilometers = 0.386102 square miles ' 1 square kilometers = 247.105 acres ' 1 cubic meters = 264.172 gallons ' 1 cubic meters = 35.3147 cubic feet lblElevMeters.Caption = "( " & Format (CDbl(txtInput.Text) * 0.3048, "#0.00") & " meters )" lblAreaAcres.Caption = "( " & Format(CDbl(txtArea.Text) * 247.105, "######0.00") & " acres )" lblCapGal.Caption = "( " & Fo rmat(CDbl(txtCapacity.Text) * 264.172, "####0.00") & " billion gallons )" End Sub

PAGE 157

141 Code Listing 13. Subroutine of Draw_Curve Private Sub Draw_Curve(intStage As Integer, intLimit As Integer) Dim intIndex As Integer picCanvas.AutoRedraw = True ' Define canvas extent as (0, -100) (200, 2000) ' (13, 0) (192, 200) is the actual drawing area picCanvas.ScaleLeft = 0 picCanvas.ScaleWidth = 200 picCanvas.ScaleTop = 2000 picCanvas.ScaleHeight = -2100 ‘ Prepare the canvas picCanvas.Cls picCanvas.BackColor = vbWhite picCanvas.ForeColor = vbBlack picCanvas.Line (6, 0)-(200, 0) picCanvas.Line (12, -50)-(12, 1900) picCanvas.Line (193, -50)-(193, 1900) picCanvas.DrawWidth = 2 ‘ Draw the water level axis X For intIndex = 2 To 15 picCanvas.ForeColor = vbRed picCanvas.Line (intIndex * 12, -5)-(intIndex * 12, -50) Next ‘ Draw the area axis Y1 For intIndex = 1 To 3 picCanvas.ForeColor = RGB(255, 190, 0) picCanvas.Line (8, intIndex * 500)-(11, intIndex * 500) Next ‘ Draw the capacity axis Y2 For intIndex = 1 To 5 picCanvas.ForeColor = vbBlue picCanvas.Line (193, intIndex * 2000 / 6)-(196, intIndex * 2000 / 6) Next ‘ Draw current status For intIndex = 13 To 192 picCanvas.ForeColor = RGB(255, 190, 0) picCanvas.Line (intIndex 1, arrArea(intIndex 1))-(intIndex, arrArea(intIndex))

PAGE 158

142 If intIndex >= intLim it And intIndex <= intStage Then picCanvas.DrawWidth = 1 picCanvas.DrawStyle = 0 picCanvas.ForeColor = vbBlue picCanvas.Line (intIndex, arrCapacity(intIndex) / 6 * 2000)-(intIndex, 0) picCanvas.DrawWidth = 2 picCanvas.DrawStyle = 0 End If picCanvas.ForeColor = vbBlue picCanvas.Line (intIndex 1, arrCapacity(intIndex 1) / 6 * 2000)-(intIndex, arrCapacity(intIndex) / 6 * 2000) Next picCanvas.Circle (intStage, arrArea(intStage)), 2, vbGreen End Sub Code Listing 14. Implementation of Zoom Functions Private Sub Zoom_In() Set m_pEnv = mpcLake.Extent Set_Extend m_pEnv, dblXFactor, dblYFactor, 1, intZoomFactor mpcLake.Extent = m_pEnv mpcLake.ActiveView.Refresh End Sub Private Sub Zoom_Out() Set m_pEnv = mpcLake.Extent Set_Extend m_pEnv, dblXFact or, dblYFactor, -1, intZoomFactor mpcLake.Extent = m_pEnv mpcLake.ActiveView.Refresh End Sub Private Sub Zoom_Full() ‘ Set current extent to full extent mpcLake.Extent = mpcLake.FullExtent mpcLake.ActiveView.Refresh End Sub

PAGE 159

143 Private Sub Set_Extend(m_pEnv As IEnvelop e, dblXFactor As Double, dblYFactor As Double, intZoomFlag As Intege r, intZoomFactor As Integer) Dim dblXmax As Double Dim dblXmin As Double Dim dblYmin As Double Dim dblYmax As Double ‘Set envelope dblXmax = m_pEnv.XMax dblXmin = m_pEnv.XMin dblYmax = m_pEnv.YMax dblYmin = m_pEnv.YMin ‘Set new extent m_pEnv.XMax = dblXmax intZoomFlag * dblXFactor / intZoomFactor m_pEnv.XMin = dblXmin + intZoo mFlag * dblXFactor / intZoomFactor m_pEnv.YMax = dblYmax intZoomFlag * dblYFactor / intZoomFactor m_pEnv.YMin = dblYmin + intZoo mFlag * dblYFactor / intZoomFactor End Sub Code Listing 15. Implementation of Pan Function Private Sub mpcLake_OnMouseDown(ByVal Bu tton As Long, ByVal Shift As Long, ByVal x As Long, ByVal y As Long, By Val mapX As Double, ByVal mapY As Double) ‘ Set hand shape cursor mpcLake.MousePointer = esriPointerPan mpcLake.Pan mpcLake.MousePointer = 0 End Sub Code Listing 16. New Menu and Command Button of LOSAC-RT 'New menu item Private Sub mnuRealtime_Click() Get_RealTimeData End Sub

PAGE 160

144 'New toolbar Private Sub tlbLake_ButtonClick(ByVa l Button As MSComctlLib.Button) Select Case Button.Key Case "bttExit" Shutdown Case "bttRealtime" Get_RealTimeData Case "bttDisplay" Display_Lake Case "bttFull" Zoom_Full Case "bttZoomin" Zoom_In Case "bttZoomout" Zoom_Out End Select End Sub Code Listing 17. Subroutine of Get_RealTimeData Private Sub Get_RealTimeData() Dim strBuffer As String, lngPos1 As Long, lngPos2 As Long Dim intCount As Integer, strHtmlD oc As String, strElevation As String Dim strTimeStamp As String, dblStage As Double ‘ Validate URL If txtURL.Text <> "" Then ‘ Read data into Buffer strBuffer = ACEInet. OpenURL(txtURL.Text, icString) intCount = Len(strBuffer) lngPos1 = InStr(1, strBuffer, "O keechobee Lake Elevations", vbTextCompare) lngPos2 = InStr(1, strBuffe r, "Difference from", vbTextCompare) strHtmlDoc = strHtmlDoc & Left$(strBuffer, lngPos2 1) strHtmlDoc = Mid$(strHtmlDoc, lngPos1 + 26) strHtmlDoc = Trim(strHtmlDoc) ‘ Get timestamp strTimeStamp = strTimeStamp & Left$(strHtmlDoc, 11) ‘ Extract elevation data strElevation = Mid$(strHtmlDoc, 12)

PAGE 161

145 strElevation = Trim(strElevation) dblStage = Val(strElevation) txtInput.Text = dblStage ‘ Update slider bar status, which will tr igger the sldStage_Change routine, and consequently invoke th e Show_Stage routine sldStage.Value = 1700 dblStage * 100 frameElev.Caption = "L ake Elevation on " & strTimeStamp End If End Sub Code Listing 18. Subroutine of Getting Parameters for CGI Public Sub Get_Params() Dim p As String, pos As Integer Dim Name As String, Val As String p = CGI_In() Do While (Len(p) > 0) If ((Right$(p, 1) = Chr$(13)) Or (Right$(p, 1) = Chr$(10))) Then p = Mid$(p, 1, Len(p) 1) Else Exit Do End If Loop Do pos = InStr(p, "=") If (IsNull(pos) Or pos = 0) Then Exit Do End If Name = Left$(p, pos 1) Val = Mid$(p, pos + 1) pos = InStr(Val, "&") If (IsNull(pos) Or pos = 0) Then p = "" Else Val = Left$(Val, pos 1) p = Mid$(p, Len(Val) + Len(Name) + 3) End If Name = Clean(Name) Val = Clean(Val)

PAGE 162

146 On Error GoTo DupKeyError params.Add Item:=Name & "=" & Val, Key:=Name On Error GoTo 0 Loop Exit Sub DupKeyError: If Err.Number = 457 Then Resume Next Else Exit Sub End If End Sub Code Listing 19. Subroutine of CGI_In Public Function CGI_In() As String Static buf As String Dim BytesRead As Long Static hStdIn As Long Select Case Environ("REQUEST_METHOD") Case "GET", "PUT", "HEAD": CGI_In = Environ("QUERY_STRING") Case "POST": If (buf <> "") Then CGI_In = buf Exit Function End If buf = Space(5000) If (hStdIn = 0) Then hStdIn = GetStdHandle(STD_INPUT_HANDLE) End If ReadFile hStdIn, buf, Len(buf) 1, BytesRead, 0& buf = Trim$(buf) buf = Left$(buf, Len(buf)) CGI_In = buf End Select End Function

PAGE 163

147 Code Listing 20. Subroutine of Clean Private Function Clean(dirty As String) As String Dim pos As Integer, i As Integer Dim temp As String, buf As String buf = dirty Do pos = InStr(buf, "+") If (pos = 0 Or IsNull(pos)) Then Exit Do buf = Left$(buf, pos 1) & " " & Mid$(buf, pos + 1) Loop Do pos = InStr(buf, "%") If (pos = 0 Or IsNull(pos)) Then Exit Do temp = "&H" + Mid$(buf, pos + 1, 2) buf = Left$(buf, pos 1) & Chr$(CInt(temp)) & Mid$(buf, pos + 3) Loop Clean = buf End Function Code Listing 21. Part 1 of LOSA C-CGI: Getting Inquiry Parameters Option Explicit ‘ Declare Windows APIs Public Declare Function GetStdHandle Li b "kernel32" (ByVal nStdHandle As Long) As Long Private Declare Function WriteFile Lib "k ernel32" (ByVal hFile As Long, ByVal lpBuffer As Any, ByVal nNum berOfBytesToWrite As Long, lpNumberOfBytesWritten As Long, ByVa l lpOverlapped As Any) As Long Private Declare Function ReadFile Lib "kernel32" (ByVal hFile As Long, ByVal lpBuffer As Any, ByVal nNum berOfBytesToRead As Long, lpNumberOfBytesRead As Long, ByVa l lpOverlapped As Any) As Long ‘ Declare global variables Public Const STD_OUTPUT_HANDLE = -11& Public Const STD_INPUT_HANDLE = -10& Public HeadersWritten As Boolean

PAGE 164

148 Dim m_pEnv As IEnvelope Dim pSRenderer As ISimpleRenderer Dim pGeoLayer As IGeoFeatureLayer Dim pFDefine As IFeatureLayerDefinition Dim strQuery As String Dim pQFilter As IQueryFilter Dim arrBreaks(9) As Integer Dim intBreakIndex As Integer Dim strAreaFormat As String Dim pLayer As ILayer Dim pFLayer As IFeatureLayer, pRLayer As IRasterLayer Dim pCBRenderer As IClassBreaksRenderer Dim pFillSymbol As ISimpleFillSymbol Dim pColor As IColor, pEnumColors As IEnumColors Dim lngNumClasses As Long Dim mpcLake As MapControl Dim params As New Collection ‘ Main program Sub Main() ‘ Declare local variables Dim strBuffer As String, strURL As String, lngPos1 As Long, lngPos2 As Long Dim intCount As Integer, strHtmlD oc As String, strElevation As String Dim strTimeStamp As String, dblStage As Double Dim strMapFile As String Dim dblArea As Double Dim ACEInet As Inet Dim intIndex As Integer ‘ Initiate Internet Transfer Control and Map Control Set ACEInet = New Inet Set mpcLake = New MapControl HeadersWritten = False ‘ Set URL strURL = "http://www.saj.usac e.army.mil/h2o/reports/r-oke.txt" ‘ Get parameters Get_Params

PAGE 165

149 Code Listing 22. Part 2 of LOSAC-CG I: Obtaining Remote and Local Data ‘ Define access type, protocol and port for the Internet Transfer Control With ACEInet .AccessType = icDirect .Protocol = icHTTP .RemotePort = 80 End With ‘ Extract water level and timestamp strBuffer = ACEInet.OpenURL(strURL, icString) intCount = Len(strBuffer) lngPos1 = InStr(1, strBuffer, "Oke echobee Lake Elevatio ns", vbTextCompare) lngPos2 = InStr(1, strBuffer, "Difference from", vbTextCompare) strHtmlDoc = strHtmlDoc & Left$(strBuffer, lngPos2 1) strHtmlDoc = Mid$(strHtmlDoc, lngPos1 + 26) strHtmlDoc = Trim(strHtmlDoc) strTimeStamp = strTimeStamp & Left$(strHtmlDoc, 11) strElevation = Mid$(strHtmlDoc, 12) strElevation = Trim(strElevation) dblStage = Val(strElevation) AddShapeFile "d:\gis\full-basin", "lo" AddShapeFile "d:\gis\shapefiles", "Lo_1kmstage89" Code Listing 23. Part 3 of LOSA C-CGI: Applying Spatial Functions ' Set number of classes for water depth classfication lngNumClasses = 9 strAreaFormat = "###0.00" arrBreaks(0) = 156 arrBreaks(1) = 132 arrBreaks(2) = 108 arrBreaks(3) = 84 arrBreaks(4) = 60 arrBreaks(5) = 48 arrBreaks(6) = 36 arrBreaks(7) = 24 arrBreaks(8) = 12 ‘ Set colors Set pEnumColors = GetColor(RGB(255, 170, 120), vbBlue, lngNumClasses)

PAGE 166

150 ‘ Set theme data layer Set pFLayer = mpcLake.Layer(1) Set pSRenderer = New SimpleRenderer Set pFillSymbol = New SimpleFillSymbol pFillSymbol.Style = esriSFSHollow Set pSRenderer.Symbol = pFillSymbol Set pGeoLayer = pFLayer Set pGeoLayer.Renderer = pSRenderer Set pFLayer = mpcLake.Layer(0) Set pQFilter = New QueryFilter ‘Set query criteria strQuery = "Stage <= " & CStr(CInt(dblStage * 12)) pQFilter.WhereClause = strQuery If (TypeOf pFLayer Is IFeatureLayer) Then Set pFDefine = pFLayer pFDefine.DefinitionExpression = strQuery Classify_Stage CInt(12 * dblStage) End If ‘ Get lake area data dblArea = Get_ALC(pFLayer.FeatureClass, pQFilter) ‘ Get map view Export_JPEG Code Listing 24. Part 4 of LO SAC-CGI: Organizing HTML Outputs CGI_Out "" CGI_Out "

Current Lake Okeechobee Status

" CGI_Out "" ‘ Display user submission if necessary 'CGI_Out params.Count & " data items submitted" 'For intIndex = 1 To params.Count ' CGI_Out "

" & params(intIndex) & "

" 'Next intIndex CGI_Out "The water level of Lake Okeechobee: " & CStr(dblStage) CGI_Out " feet on " & strTimeStamp & ".

" CGI_Out "The lake area: " & Form at(dblArea, strAreaFormat) & " square kilometers.

"

PAGE 167

151 strMapFile = "/losac/map" & CInt(dblStage * 12) & ".jpg" CGI_Out "

" ' Some environment variables ' CGI_Out "Server_software: " & Environ("SERVER_SOFTWARE") & "
" ' CGI_Out "Server_name: " & Environ("SERVER_NAME") & "
" ' CGI_Out "Request_method: " & Environ("REQUEST_METHOD") & "
" ' CGI_Out "HTTP_accept: " & Environ("HTTP_ACCEPT") & "
" ' CGI_Out "HTTP_referrer: " & Environ("HTTP_REFERRER") & "
" ' CGI_Out "HTTP_user_agent: " & Environ("HTTP_USER_AGENT") & "
" ' CGI_Out "Script_name: " & Environ("SCRIPT_NAME") & "
" ' CGI_Out "Query_string: " & Environ("QUERY_STRING") & "
" ' CGI_Out "Path_info: " & Environ("PATH_INFO") & "
" ' CGI_Out "Path_translated: " & Environ("PATH_TRANSLATED") & "
" CGI_Out "" ' When finished, close the object and destroy the instance: With ACEInet Do DoEvents Loop While .StillExecuting End With Set ACEInet = Nothing End Sub Code Listing 25. Subroutine of CGI_Out Public Sub CGI_Out(s As String) Dim BytesWritten As Long, temp As String Static hStdout As Long Dim x As Long, dummy As Long dummy = 0 If Not HeadersWritten Then temp = "Content-type: text/html" & vbCrLf & vbCrLf HeadersWritten = True Else temp = "" End If temp = temp & s

PAGE 168

152 If hStdout = 0 Then hStdout = GetStdHandle(STD_OUTPUT_HANDLE) End If Call WriteFile(hStdout, (temp), Len(temp), BytesWritten, dummy) End Sub Code Listing 26. Adding SPOT Images as Background ' Image sources AddRasterFile "s:\images \spot01\mul", "sfl01x04.img" AddRasterFile "s:\images \spot01\mul", "sfl01x05.img" AddRasterFile "s:\images \spot01\mul", "sfl01x09.img" AddRasterFile "s:\images\spot01\mul", "sfl01x10.img" Code Listing 27. Subroutine that Adds a Raster File Public Sub AddRasterFile( strPathname As String, strFilename As String) Dim pWorkspaceFact ory As IWorkspaceFactory Dim pRasterWorkspace As IRasterWorkspace Dim pRDataSet As IRasterDataset Set pWorkspaceFactory = New RasterWorkspaceFactory Set pRasterWorkspace = pWorkspa ceFactory.OpenFromFile(strPathname, 0) Set pRLayer = New RasterLayer Set pRDataSet = pRasterWorks pace.OpenRasterDataset(strFilename) pRLayer.CreateFromDataset pRDataSet mpcLake.AddLayer pRLayer End Sub Code Listing 28. Checking Input Error Private Sub txtLowLimit_KeyPr ess(KeyAscii As Integer) If KeyAscii = vbKeyReturn Then If IsNumeric(txtLowLimit.Text) Then If CDbl(txtLowLimit.Text) < 1 Then txtLowLimit.Text = "1.00" ElseIf CDbl(txtLo wLimit.Text) > CDbl(txtInput.Text) Then txtLowLimit.Text = txtInput.Text

PAGE 169

153 End If lblAnno1.Caption = "between " & Format(CDbl(txtInput.Text), "#0.00") & " ft and " txtCapacity.Text = Format(arrCapacity(CInt(txtInput.Text * 12)) arrCapacity(CInt(txtLo wLimit.Text * 12)), strCapacityFormat) Unit_Conversion Draw_Curve CInt(CDbl(txtI nput.Text) * 12), CInt(CDbl(txtLowLimit.Text) * 12) Else With txtLowLimit .SetFocus .SelStart = 0 .SelLength = Len(txtLowLimit.Text) End With End If End If End Sub Code Listing 29. Alternative Image Paths Dim blnReturnValue as Boolean ‘AddRasterFile returns a boolean value blnReturnValue = AddRasterFile("q:\gis\ database\image\img ", "spot00.img") 'If unsuccessful, use alternative image source If Not blnReturnValue Then AddRasterFile "s:\images \spot01\mul", "sfl01x04.img" AddRasterFile "s:\images \spot01\mul", "sfl01x05.img" AddRasterFile "s:\images \spot01\mul", "sfl01x09.img" AddRasterFile "s:\images\spot01\mul", "sfl01x10.img" End If Code Listing 30. Exporting XML Private Sub Export_XML(strTempFilename As String) Open strTempFilename For Output As #1 Print #1, "" Print #1, ""

PAGE 170

154 Print #1, "" Print #1, "" & txtInput.Text & "" Print #1, "" & txtArea.Text & "" Print #1, "" & txtCapacity.Text & "" Print #1, "" Print #1, "
" Close #1 End Sub Code Listing 31. Subroutine of mnuWeb_Click Private Sub mnuWeb_Click() Dim strTemp As String Dim strTempPathname As String Dim intIndex As Integer strTemp = txtInput.Text For intIndex = 12 To 192 Show_Stage intIndex strTempPathname = "d:\backup\export\" Export_JPEG strTempPathn ame & "map" & CStr(intIndex) & ".jpg" Export_Chart strTempPathn ame & "chart" & CStr(intIndex) & ".jpg" Next Show_Stage CInt(CDbl(strTemp) * 12) End Sub Code Listing 32. Exporting JPEG Private Sub Export_JPEG(st rTempFilename As String) Dim pExporter As IExporter Dim pEnv As IEnvelope Dim pEFrame As tagRECT Dim pHandler As Long Dim dpi As Integer Set pExporter = New JpegExporter Set pEnv = New Envelope pEFrame = mpcLake.ActiveView.ExportFrame pEnv.PutCoords pEFrame.Left, pEFr ame.Top, pEFrame.Right, pEFrame.bottom

PAGE 171

155 dpi = mpcLake.ActiveView.ScreenDi splay.DisplayTransformation.Resolution pExporter.ExportFileName = strTempFilename pExporter.PixelBounds = pEnv pHandler = pExporter.StartExporting() mpcLake.ActiveView.Output pHandl er, dpi, pEFrame, Nothing, Nothing pExporter.FinishExporting End Sub Code Listing 33. Exporting Chart Private Declare Function DIWriteJpg Lib "DIjpg.dll" (ByVal DestPath As String, ByVal quality As Long, ByVal pr ogressive As Long) As Long Private Sub Export_Chart(strTempFilename As String) Dim retval As Long SavePicture picCan vas.Image, "c :\tmp.bmp" retval = DIWriteJpg(strTempFilename, 100, False) Kill "C:\tmp.bmp" End Sub Code Listing 34. Subroutine of Workflow Service Private Sub timerUpdate_Timer() If Not (blnUpdateStatus) Then If strUpdateTime = Format(Now, "hh:mm") Then Export_XML "d:\backup\export\xml_export.xml" stbStatus.SimpleText = "The XML was last updated on" & Now blnUpdateStatus = True End If If Not (strUpdateDate = Format(Now, "mm/dd/yy")) Then blnUpdateStatus = False End If End If End Sub

PAGE 172

156 Code Listing 35. Setting up Timer blnUpdateStatus = False timerUpdate.Interval = 60000 timerUpdate.Enabled = True strUpdateDate = Format(Now, "mm/dd/yy") strUpdateTime = "07:00" Code Listing 36. Style Sheet: LO_STYLE.XSL Lake Okeechobee Status -Text Mode

Lake Okeechobee Status

Date Elevation
(feet)
Area
(square kilometers)
Capacity
(cubic kilometers)