City of Ontario
303 East "B" Street
Ontario, California, USA 91764
Telephone: (909) 986-1151
Fax: (909) 391-0692
The vision of GIS technology filtering into the masses has long been a goal of many GIS professionals. The advent of desktop GIS solutions combined with a drive to offer public access to government data and the growing popularity of the Internet is making this vision a reality. However, the path to successfully implementing applications for casual users can sometimes take some interesting twists and turns. Like many organizations, the City of Ontario, California, has joined the crusade to develop applications the casual user can utilize via "kiosk" oriented interfaces. The final products include public access GIS through the municipal library, reusable applications, and front counter kiosks. The purpose of this paper is to describe the history of kiosk development, to convey the reactions of the casual GIS user, and to demonstrate examples of Avenue based interfaces.
The quest to implement an enterprise GIS solution is a common goal among many organizations. The mere term "enterprise solution" implies that GIS technology can be utilized by nearly every department in an organization. Although Ontario has been able to identify uses for nearly every department, a gap exists between the need for individuals who are versed in desktop GIS and a need to use the technology sporatically. More specifically, the need to tap into the rich data sources GIS offers exists on an as needed basis. Instillling GIS expertise into these casual users did not make a lot of sense. What did make sense was developing front ends that could walk the end user through an application.
What is difficult to gauge is how the end user, often times a "John Q. Public" citizen, will react to the screens and the means in which the the data will be received. The development of the "kiosk" oriented approach was conceived around this level of experience. For purposes of this paper, anything referred to as a "kiosk" is a front-end type graphical display which is utilized to be visually and capable of being used every day by the common citizen. During the development of our first kiosk, it became apparent that even though we may be well versed on the data and how to utilize that data, we knew very little about how to make that data understandable and not overwhelming to the average citizen.
The next version utilized individual projects for each piece of information. To access any of the information, the customer would open the project which cooresponded to the particular piece of information he or she was seeking. Each project in turn portrayed two basic items. The first item was the necessary background components. These consisted of items such as streets, city limits, and other similar articles which were essential to local the geographic regions the information was dealing with. The second item was the actual information the consumer was seeking. This was in most cases a single coverage defined to show just one particular category, such as number of white males by census block.
This solution was by far the best answer that we could come up given our project restrictions. It was not however the end all solution. Once it was made available to the public, we quickly found that nothing is ever fool proof. We had configured windows to eliminate the FILE menu option to eliminate the possiblity of someone accidently overwriting our view with an altered view. It was a good concept, but it proved a false hope in real life.
We quickly found out that it was still possible to make changes to our projects. Some of the changes were made purely by accident. However, we also found out that we had a local computer jockey who had just enough knowledge to make himself a nuisance. He liked to utilize the computer to further his name. That is, he liked to create files with his name on them and he especially liked to change the elements in our existing files. Because we were unable to completely eliminate his ability to save files (Windows has a built in save option which we have yet to find a way around), we instead built a set of backup projects. We kept these projects in a hidden directory and once a week we would run a routine which would overwrite our working projects with our hidden copies. This project is still being utilized by our library patrons. As requests come in, we have continued to build new projects to meet the needs.
Our next test of a kiosk system involved the City of Ontario's City Clerk's department. In a casual conversation, one of our librarians had made a statement regarding how many phone calls they get during the election season. It seems that a lot of people forget where their polling place is or if they remembered to re-register after moving. They indicated that they refered the caller to the city clerk's department. In a separate conversation with the city clerk's department, they affirmed that they did in fact have a problem. Under the current system, the city clerk would verify the information by skimming through microfiche to locate the voter.
We saw an opportunity to kill the proverbial two birds with one stone. We asked "If we build a system which will give you all the information contained on the fiche by simply typing in the voter's name, would you use it?" They expressed a prowess at using the microfiche. Why, "It only takes a few seconds for most callers." The city clerk's department was a little bit apprehensive about the idea. They did not want to have to learn a big complex new program for such a little task.
After many assurances about its speed and simplicity, we convinced them to go ahead and try the system. The library, being much more experienced in our system, was a much easier client to convince. We started out by obtaining a digital voter registration from the County of San Bernardino. In an effort to keep the file size down and response times up, we chose to handle just the City's voters, however this project would have worked just as easily on a county wide level.
It only took about a day to complete the entire application. It was written in ArcView 2.0 utilizing Avenue scripting. Functionally speaking, it worked exactly the way it was designed to work. Speed wise however, we had major problems. We found that to perform some searches, it could take up to 2 and 3 minutes. Big Problem. This was when we first discovered the splendor of indexes. By utilizing an index, we were able to cut our 2 and 3 minute response times down to a few seconds. End of problem. We showed it to the city clerk's office and they liked it.
This kiosk was first utilized in the election that contained Proposition 187. With such a heated election, the number of phone calls to the city clerk's department totalled more than 400. We were actually pleasantly surprised to find that our kiosk had undergone such extensive "field testing" and had experienced no major problems. They did have a few minor problems such as spelling a person's name wrong and similar problems, but we viewed it as enhancements for the next version, which will be released on election day, November 1996.
Our final kiosk example was up to this time our most ambitious endeavor to develop Public Access GIS. The City's Building Department, along with several other agencies had expressed a desire to have access to the same basic information that was being utilized on the Planning Department's front counter. Back in 1991, we developed a database querying system based in FoxPro 2.0 which we often refer to as our "Mapless" GIS. It was simply a front end that provided all pertinent information regarding a particular parcel in the city. The parcel was located by either an APN, a situs address or a file number. It was quick, it was easy to use and it gave valuable information, a noble goal for any front counter system.
What the building department and others wanted was a system very similar to that one, except they wanted a map to go with it. The people that would be using the system were counter techs. They were basically computer illiterates who did not have a lot of time to spend clicking this button, defining that region, listing this table, and other similar acts. They wanted to "push a button and have it just magically do all that for us".
We decided to start the project off with a "Big Buttons" approach. In other words, the screen area would be comprised of six to ten big push buttons to select the different options. For example, one button would be labeled "Land Use", another "General Plan" and so on. In order to keep user interaction to a minimum, we would have to combine upwards of 20 into one or two individual choices.
The first step was to create the initial front screen. This screen was created in CorelDraw and exported out as a TIFF file. Once we had the TIFF in ArcView, our work began. A shape file was created which sat behind the TIFF file. All the shape file did was provide us with different squares which could be used to create the appearance of hot linking to the TIFF file. Some of these hot links were simply different views pulled up with the requested information. Examples of these are our assessment districts and our flood zones. Others however required some in depth programming behind the scenes. Our General Plan was built using Visual Basic's Help tool. It utilized the entire General Plan text as a pointer to the map data. By clicking on different items of data, you could invoke DDE calls to ArcView maps or simply skip to the section of text which pertained to it. By creating the links, the entire General Plan document was completely on-line.
The other section which required extensive programming was the Land Use section. This was the section that the masses had been clamoring about. The major problem behind this section was trying to figure out how to perform such complex search, retrievals and draws all while keeping the user input to a bare minimum. The first thing we did was determine that they would only be able to do searches by APN or by situs address. Once we had the code complete for locating the parcel in question, we ran into a major stumbling block. How do you present the data to the user without leaving ArcView? There is no report type function built into ArcView. Pulling up the table and trying to negotiate it was too cumbersome. We finally hit on the idea of utilizing the multi-input box not as a input screen, but as an output screen. It wasn't perfect, but it would have to work.
Once we had that worked out, the hard part was over. The user inputs the APN or situs address and then ArcView goes to work. First it locates the parcel, then it displays the data in the mult-input box, then it zooms to the parcel and pulls up the map. Indexes were created to speed up selection and display times and the project was ready for its trial run. With the exception of a few glitches here and there, the implementation of this kiosk went pretty smooth. There is still one small problem regarding the updating of the indexes, but we hope to have that problem resolved by mid April, 1996.
The City of Ontario is by no means done in the kiosk oriented approach to GIS. Currently, we have to more projects either in the early stages or nearing completion. A front end presently is being developed to allow the Economic Development Department the ability to target revenue loosing properties such as vacant land and vacant buildings. A second project is taking place in the building department as well. An address assignment application is currently in its early stages. This application will allow the building department to automatically update the GIS databases the second a new address is assigned. The building department staff will select the parcel needing addressing and get a listing of existing address. They will then type in the new address, press and OK button and instantly update all GIS databases while priming all necessary letters to be sent to the appropriate parties.
Building front end type kiosks is a worthwhile and viable means of opening information up for public observation. It is by no means fail proof, but given the time and energy, any problem can be dealt with in a rational and conclusive manner. The development of these kiosks allows access to data for every user, whether an advanced user or the very beginner. The key that we have found in all instances, is to keep it as simple as possible. The end user tends to comprehend the data better if the amount of user interaction is kept to a minimal.