As a low-level GIS toolbox, MapObjects 2 contains many powerful building blocks, but those blocks are not always combined into the more complex tools expected in a GIS application and available in products such as ArcView. This presentation discusses the use of Visual Basic classes for reusable tools such as an Image Catalog, which manages the creation and display of tiled images from a directory, switching between multiple catalogs and, in conjunction with a Projection Dictionary object, also ensuring that the MapObjects display is set to the correct coordinate system and that any overlaid vector data is optimized for faster display.
Introduction
Remember dumping out a giant box of Legos on the floor as a child? So much possibility, so much clutter, if only you could figure out what to do with it. Blocks of all different shapes and sizes, designed to interconnect into all sorts of fun things. After a while, you get the hang of sticking the blocks together to get specific larger shapes you need to build the grand castles you envision. And maybe you find yourself sticking the same pieces together to build those larger shapes, and then leaving them stuck together so you can use them for your next castle. Well, installing Esri’s MapObjects 2 on your system is a lot like that, and it can be a bit overwhelming to developers who must somehow construct applications out of the bits and pieces.
Further complicating matters is the lack of some of the familiar tools of geographic information systems, such as image catalog functionality, which can help the developer create applications which are more complex.
This paper will take a look at the development of an image catalog object as a Visual Basic class and ActiveX DLL. The original development on this object was performed in support of the suite of MapObjects-based applications in the RCAGIS project, and added a few extra items to the image catalog concept.
The image catalog object created to be used in several different applications within a suite of crime analysis tools. The Regional Crime Analysis Geographic Information System (RCAGIS) was conceived of as a way for police departments to map and analyze crime incident data not only for their own jurisdiction, but also for adjoining or otherwise nearby jurisdictions. Developed by the United States Department of Justice’s Criminal Division GIS Staff between 1998 and 2000. The project combined base maps and crime incident information for the members of the Regional Crime Analysis System, an existing consortium of police departments in Maryland which shares crime incident data among its members. While the participating police departments had standardized on a database for collecting the crime incident data, the digital base maps and aerial photographs were maintained by the individual departments and varied not only with respect to the types of data collected, but also the projections in which the data were stored.
Rather than a monolithic application, RCAGIS was designed as a three-piece suite. The primary RCAGIS application includs querying, reporting, mapping, graphic, and printing functionality and serves as the interface for users to actually work with crime incident data. The Administrator application provides system administrators the means to modify an RCAGIS installation, such as adding or removing jurisdictions, tracking the projections associated with different shape files, modifying types of information queryable in the incident database, and defining the way attributes will be queried from within RCAGIS’s query interface. Finally, the Symbolizer application was included as a way to create new symbology for map layers, load and save that symbology, and assign symbols to be used through a police department. Lying behind these three applications is a single database which defines the way the different components will run, where they look for data, and so forth. Only the Administrator application has the ability to make modifications to the backend database, but all three applications must read from it in order to run.
One of the requirements specified for the RCAGIS software was that it needed to be able to display aerial photographs as MapObjects image layers underneath the vector data such as street networks, locations of schools, convenience stores, and so forth. MapObjects 2 introduced the ability to project vector data both for transforming shapefiles and for on-the-fly reprojection as data are drawn to a Map control. Using the on-the-fly projection allows the software to take geometric data in one or more projections and combine them into a single projection for display. Unfortunately, this ability does not apply to raster data. As a result of this, while it would be possible, though certainly not optimal, to ask all members of the consortium to standardize on a single projection for their vector data, the software would still need to be able to adjust the output projection of the vector data to match that of any underlying raster data.
Combining the issues of projection with the need to maintain potentially hundreds of raster tiles organized by jurisdiction and type of image (e.g. aerial photography, plats, etc.) made for a potentially large headache, and so the image catalog object was created.
The image catalog, as it has been implemented in applications such as ArcView is a way of dealing with libraries of tiled, georeferenced images and treating them as if they were one large image for the purposes of display and maintenance. While the individual images which make up a large map may exist on a server in separate files, the user who accesses the catalog containing those images only needs to point to the catalog. All of the work of determining which images need to be displayed at a given time, based on the user’s current map extent, is handled by the catalog, which pulls the appropriate files from the server or database. Further, all of the images can be treated as a single layer by the user in operations such as reordering the layers of a map’s display.
The RCAGIS image catalog object was designed not only to handle the aspects of image retrieval necessary for display, but also the creation and maintenance of catalogs and their necessary spatial indices, as well as ancillary information such as the projection of the images and the color index used to denote transparent areas of the images.
The design of the object was also heavily influenced by RCAGIS’s use of a Microsoft Jet Engine-based object store for data which controlls the operation of the software. This database, accessible by all of the applications in the RCAGIS suite, provides a way to link image catalogs to specific jurisdictions, as well as a convenient place to store the aforementioned ancillary data.
Of course, with an object-oriented design, what becomes important to the software which uses that object is that the software does not need to know that the object is talking to a Jet-based object store, or a text file stored in a specified location, or any other details. The application asks the object for information or data, or even an action, and the object responds as necessary.
As the developers were in a position to place some restrictions defining the nature of the image catalogs, it was decided that a catalog would be, from a data storage perspective, represented by a subdirectory containing the images and their corresponding world files (data files which provide georeferencing data to match the images to real world locations). Given that very basic structure, spatial indices for each catalog would be stored in the form of a shapefile within the catalog’s directory. The image catalog object can then do spatial operations on the index to determine intersection of individual tiles with a specific extent or point.
To further distance the RCAGIS applications from the image catalogs, clsImageCatalog was designed as an object without a user interface. This provides maximum flexibility in the applications which would make use of the object. The primary interface for image catalogs within RCAGIS is found within the Administrator application.
Because RCAGIS tightly couples its image catalogs to the jurisdictions represented by the images in the catalog, catalogs are created and assigned by first selecting a jurisdiction. In the case of image 2, the jurisdiction is Alpha. When the user clicks the "Add" button, they are prompted to select the directory containing the images for the catalog. clsImageCatalog then goes into action, determining if it can open a spatial index in that directory. If it can not, it will attempt to create a spatial index. If the object is unable to write to the directory, a temporary index will be created in temp space for use as long as the current application is running. As jurisdictions may have multiple sets of imagery, each jurisdiction may have multiple image catalogs associated with it. Reindexing can be forced on a directory the contents of which have changed.
Within the primary RCAGIS application, the inclusion of images is largely transparent to the user. The user simply clicks the "Show Images" button and if images are available for the current map extent, they will be made visible below any vector data. As the user pans or zooms, the image catalog object is passed the new extent and queried for a list of image files which are in the current catalog and intersect the display. If any are found, they are included as image layers within the map control. If images are to be visible, the image catalog will also provide information on the projection necessary to properly display the images within the map control, and RCAGIS can adjust projection parameters for input layers and the output map control as necessary.
Visual Basic is an object-oriented language, and it is impossible to program in the language without making use of its objects, such as the basic Form used to create user interfaces. But one can happily write application after application without taking advantage of Visual Basic’s strengths in creating new classes objects.
New objects are written through the use of class modules (*.cls), which contain all of the code which describes the properties, methods, and events of the new object class. The class module includes a few special event procedures which are run when the object is instantiated or destroyed, but is otherwise wide-open for the user to create whatever they’d like. The developer can create their own properties and methods, add events and specify what situations will cause those events to be raised.
When creating new classes, a developer has choices about how the object will be accessed by the application. The object’s source code can be left as is, a .cls module which is simply one of the many modules compiled into the application. Or one or more classes can be compiled into a stand-alone ActiveX library. The ActiveX library option allows the developer more control over how the classes within it will run with respect to the main application thread, as well as the ability to distribute the library and use the classes within it in many applications without having to recompile the code into each application.
Visual Basic makes developing and debugging objects relatively easy. In large part, this is because Visual Basic is an intrepreted language. As such, the user has very tight focus to step through the lines of code as the application runs and see where errors occur. Beginning with the 5.0 release of the language, Visual Basic allowed developers to create project groups: applications which contain multiple projects. With this feature, it becomes possible to not only debug a .cls module which is included in your application, but also to include the separate Visual Basic project of an ActiveX library in the group with the project of the main application. Using this technique, one can verify that the separate library is functioning as a stand-alone unit, while still having access to the code of both projects in the debugger for stepping through and analyzing while the application and library are running.
As a GIS toolbox, MapObjects 2 contains many powerful building blocks, but those blocks are not always combined into the more complex tools expected in a GIS application and available in desktop and workstation products such as ArcView and ArcInfo. Fortunately, MapObjects 2 has enough low-level functionality built in to be capable of almost anything a developer might want from it.
Visual Basic is a suitable development environment for undertaking many such tasks. Beginning with Version 5.0, the language can be compiled to native code, rather than psudeo-code, which greatly improves the speed. Object support is strong, though some might argue that Visual Basic, through version 6.0, is not a "true" object-oriented language, due to the lack of true inheritance. And there are an awful lot of Visual Basic programmers floating around, with even more to come as ArcView developers make the switch from Avenue to Visual Basic for Applications.
Still, as with any development project, the final tool must be planned out and the cost and complexity of development considered. Existing solutions should be considered before time and expense is sunk into recreating thewheel. Just as developers will use MapObjects 2 rather than building their own GIS components from scratch, it is always a good idea to see if the objects you are looking for have already been created and are available in a form that will prove faster and cheaper to the overall development project.
Appleman, Daniel (1997). Dan Appleman's Developing ActiveX Components with Visual Basic 5.0. Ziff-Davis Press.
Appleman, Daniel (1996). Visual Basic Programmer's Guide to the Win32 API. Emeryville: Ziff-Davis Press.
Burka, Jeffrey C. (1999). Breaking Down Jurisdictional Barriers: A Technical Approach to Regional Crime Analysis. 1999 Esri User Conference Proceedings. http://gis.Esri.com/library/userconf/proc99/proceed/abstracts/a622.htm
Environmental Systems Research Institute (1996). Building Applications with MapObjects.
Microsoft Corporation. Programming with Objects. http://msdn.microsoft.com/library/en-us/vbcon98/html/vbconprogrammingwithobjects.asp
Schildt, Herbert (1995). C++: The Complete Reference, Second Edition. Berkeley: Osborne McGraw-Hill.
The RCAGIS package was developed by the Department of Justice Criminal Division GIS Staff. All source code, as well as a demonstration installation (complete with sample data) is available at:
http://www.usdoj.gov/criminal/gis
Authors:
Jeffrey C. Burka
GIS Programmer
INDUS Corporation
1953 Gallows Road, Suite 300
Vienna, VA 22182
703) 506-6700
David Nulph
Senior GIS Analyst
INDUS Corporation
1953 Gallows Road, Suite 300
Vienna, VA 22182
(703) 506-6700