ABSTRACT: Reduction in staff, lack of accurate information, increased liability, duplication of efforts, out-of-date manually drafted maps, and other related problems have plagued Riverside County in their responsibility to provide accurate landuse and planning information to the public. Fortunately by this time, the County's Geographic Information System has been fully implemented and with this, many of the critical data sets have already been converted to replace the old manual system. This paper will focus on the progress that Riverside County has made towards implementation of a GIS based public information counter. It will highlight the benefits and problems that have occurred in order to provide quick and reliable information to in-house staff and to the public and private sector.
For the past eight years Riverside County has been developing a GIS to serve many of the planning and information retrieval needs normally associated with County government agencies. Riverside County began its' GIS program in September 1987 with a 48 square mile pilot project. The pilot project was completed in February of 1989 and by October of 1992 the County had completed the parcel base along with several other related base layers for the unincorporated portion of the County including road centerlines, zoning, and monument control.
From the beginning it was decided that the County's GIS be parcel based. Parcel based systems are based on legal or assessed parcels created through the recording of a deed or subdivision. Because Riverside County covers approximately 7300 square miles and includes approximately 210,903 unincorporated and 402,131 incorporated assessed parcels, the goal of converting to a parcel based GIS would be challenging in itself to say the least. The decision to take on this difficult task, at first, may have seemed too much to expect, for it would require the cooperation of four separate departments (Planning, Building & Safety, Transportation and Assessors Office) overcoming individual political agendas, all working towards developing a common source of information. Each department would be expected to commit substantial resources in both funds and personnel.
In addition to the parcel base many other data layers would be needed. Data sets such as habitat locations for various endangered species, vegetation types, landuse, political boundaries, fee areas, flood zones, etc. would all need to be either converted in- house or obtained from outside sources. For the first five years that the GIS was implemented, the focus of GIS staff would be on getting these and any other necessary layers on-line. By 1992 this goal had been adequately accomplished and the focus of GIS staff would now change from the conversion and acquisition of data to making the data easily accessible to in-house staff and the public and private sectors.
Currently, there are 34 full time staff working on the County's GIS. This staff is dedicated to the continual maintenance and update of ALL the GIS data layers. The Transportation and Land Management Agency functions as the lead Agency for the County GIS. Riverside County also actively markets their data and technical services to other agencies such as cities and water districts. At this time their are two cities and five water districts as well as several other state and federal agencies currently sharing the County's data through License Agreements.
Coincidentally, at this time, Planning Department Land Use Technicians responsible for providing public information at the various information counter locations throughout the County were in serious need of a reliable source of landuse related information such as land ownership, zoning, fee areas, flood zones, etc. The source that they had been depending upon for these types of information was a manual drafting system based on assessor parcel map pages. Approximately 12,000 assessor's parcel map pages exist for the unincorporated area of Riverside County and approximately 50 pages were received weekly from the Assessor's Office for the drafting technicians to manually update with the related landuse information. The process of researching the information was arduous and extremely labor intensive. A single page could take up to two hours to research, update, color and make the appropriate copies. At one time this process was supported by anywhere from three to six drafting technicians, but due to staff reductions, the process was later supported by only two drafting technicians. Additionally, copies of the new pages had to be distributed to the five public information counters and then inserted into the counter books. This system had become very backlogged (by about 408 pages at one time) as well as inconsistent from one counter location to the next. To determine the extend of the inconsistency, pages from the various counter locations were compared. The results of the comparison were discouraging as the many of the pages did not contain the same information. It was obvious that in many cases inaccurate information was being communicated to the public and the possibility of opening up the County to legal actions was very real. A solution to this problem was becoming a critical issue with all those involved.
What seemed an obvious solution to this problem, namely, implementation of a GIS based public information counter, was not so obvious to all of those in the decision making arena. Management and even some of the front counter staff contended that the best solution was to continue with the manual system even with its very obvious flaws. Their reasons included:
What had become apparent over the years, is that GIS was a foreign entity within the County. Many employees knew we existed, but did not really know what we did or more important what we could do for them. Many times in the past, management has said "Give it to GIS, they'll make us a map" or "Give it to GIS, they'll do it for us" and finally "Give it to GIS, it's their responsibility". This became an increasingly impossible task.
It was quite apparent that selling the GIS solution would require a major effort in educating those opposed to what GIS had to offer. To assist in this process a study was conducted to research the issues involved and develop recommendations for management to decide from. The recommendations would have to take into consideration important factors such as the continual trend of staff and budget reductions and the need for a system that would provide quick reliable information in a cost efficient manner. After several weeks of research, the study concluded that the GIS solution was by far the most logical.
Although it would require some extra up front costs related to developing some critical layers that did not yet exist on the GIS, the associated long range benefits could not be ignored. To satisfy concerns over how the front counters would continue to operate in the event that the GIS server was down, a compromise was made. In conjunction with the development of AMLs which would provide the counter staff with a point and click on-line information system, GIS mapping staff would develop and generate large maps covering anywhere from 1 to 36 square miles of land. These maps would contain the same information as the old manual maps, except that they would be automated by an AML. They would serve as a backup to the on-line system. With this and other major concerns out of the way, management then directed the implementation of a GIS based public information counter.
With the implementation of our information retrieval system, later to become our public information counter system, we had to change the way staff thought of GIS. GIS is a tool to help them get their job done more efficiently. It is a tool to help remove the redundancy between departments. It is a tool to alleviate the drawn-out search through paper documents. GIS was not taking over their jobs and GIS were not taking over their responsibilities.
The County's GIS development staff was tasked with providing an ever increasing number of tools, applications, and systems for the general County staff to do their work. Of these, were easy-to-use methods of entering data into the GIS databases and ArcInfo libraries. And of course, simple, easy-to-use standards for extracting or analyzing their data along with data entered by other departments and other agencies. Most noticeable of these, is the public information counter data inquiry system (currently) called PARCEL_INFO. Here the users could directly see their own data at work. They could see what their work meant to others, and what other peoples work could do for them. It was no longer " 's problem" or " 's fault" when thing did not match-up. It was their work, their data, and they were accountable.
One of the first priorities for GIS staff was to assess the status of the many data layers that were to become part of the Parcel Information system. See Appendix 'A' for a full listing of Parcel Information layers being used. Some of the targeted layers had become out-of-date. Others had lacked a good quality control process which allowed for many attribute related mistakes and inconsistencies. Still others needed to be spatially corrected (ie. corresponding boundaries snapped to parcel base layer). For the next few months GIS staff would focus on correcting data related errors.
Once the layers were update-to-date and correct, arrangements were made to ensure that they would be kept up-to-date. As mentioned above, GIS staff was dedicated to the continual update and maintenance of ALL data layers. Because of the continually growing number of Library layers and databases, this was to require the cooperation of non-GIS staff such as planners, engineers, and landuse technicians. Because the GIS mapping staff are already kept quite busy maintaining data layers, they would need to rely upon the above mentioned department staff for notification of changes to the Parcel Information layers. For example, if a school district boundary was legally changed, GIS mapping staff would depend upon the responsible party, in this case the Planning Department, to notify GIS promptly of the change and provide any legal description available so that the school district layer could be updated. This helped spread the responsibility of the data to others besides GIS staff. It also contributed towards a more accurate database since the ones who know most about the information (ie planners, engineers, etc.) are involved in the update process. This is update process is continuing to evolve in the development of applications and training of users to maintain and update their own data sets.
The other important task was to provide a standardized easy-to-use data query and retrieval system. As mentioned above, the most noticeable and commonly used system is the public information application. Parcel_Info is a rather simply conceived AML which steps through a horrendous amount of data. Its original and main purpose is to give specific information about an individual parcel of land. This information is displayed in a text report and print-out. The additional requirement of this application was to be accessible by any terminal type. A graphical display terminal was not required, in fact, graphic displays were originally discouraged.
The information is displayed and reported in such a way as to give a definitive description, location, name, in-out, or yes-no answer to each item. Unlike a graphical display, these answers are not subject to interpretation. That is, to the lay person and general public, the answers are spelled out in blank and white. If a graphical display terminal is used, an option to display or map any of the reported items is available.
Parcel_Info was originally developed and written almost 3 years ago in ArcInfo 5.0 AMLs. It started out simply enough, to help certain front counter staff research, fill-out, and verify application forms submitted by the public. It used a single key item to search on, that being the Assessor Parcel Number. It would verify and retrieve information from the PARCEL layer of one of the Libraries and an abstract of the Assessor Roll database (at that time it was a rather large Info database). It would search through 14 thematic layers in 3 libraries and the above mentioned Assessor Roll database to produce a report only 20 to 24 lines in length or a single screen full. Though this application ran strictly in Arcplot, graphical display options where not available.
At the time, we were still running on our Data General AOS/VS proprietary system. The report generation took over a minute to complete. In the months following, new levels of information were added, and the reporting grew in length. But performance became a critical issue. The more library layers and reselection logic, the slower the process ran, to a point where it was taking two to two and one-half minute to complete upward of 40 lines. To the general staff and end users, this was still a blessing for what it could do in that amount of time, but the experience GIS staff who could see technology changing, began to think it was almost not worth the trouble. About a year and a half ago, GIS was finally able to migrate to a Unix open-system architecture, and migrate to ArcInfo 6.0. This application which previously took over 2 minutes to complete, now ran in under twenty seconds. This software and hardware migration opened the door to a whole new world of changes and enhancements.
Parcel_Info still basically uses ArcInfo 5.0 programming technology, though it has under gone a few modifications to incorporate ArcInfo 6.1 DBMS access. It does not use multi-thread concepts nor is it dependant on X-terminals or any graphical display.
Parcel_Info uses Arcplot reselection logic and DBMS cursors to step though 65 graphical layers in 5 libraries, and 14 Informix and Info databases. It produces a text report 2 pages in length or some where between 100 and 130 lines, depending on what is found. In total there are 143 AML files being invoked with approximately 8000 lines or AML (and SQL) code, not including comments.
The user is prompted to enter any parcel specific key. This key can be:
Any one of these keys will get to the selected parcel of land. The specified information is verified against the ArcInfo Libraries and the Assessor property tax roll.
From here, the application determines the exact location of the parcel of land, it size, and its exact boundary. Because RESELECT with OVERLAP cannot use selected features of a library layer as the overlap cover, a temporary coverage is created using CREATE. Since precise and consistent answers to the selection logic are utmost, the application has to compensate for any inconsistences where linework and coordinates were not exactly coincidental in other data layers. This proved to be a very important step. The temporary coverage is BUFFERed approximately 1 to 2 feet inward (a negative buffer distance). The coordinates of all the vertices for the buffered coverage are extracted using the SHOW command and stored in variables. These coordinate variables are used with as input for RESELECT POLY *, which has proven to be faster and more efficient then RESELECT OVERLAP, particularly since the application is stepping through numerous layers. As the results of each reselection step is completed, a tailored or customized statement is produced depending on the results, then printed to the terminal screen and to a watch file. The entire reporting can take up to 2 minutes to complete, and because of this, the user can interrupt and stop the processing at numerous points in the reports sequence. Appendix 'A' displays a sample of one report printout (names and addresses have been masked for this sample).
Once the report is completed (or interrupted), various options are available. Among these options are display and plotting if a graphical terminal is being used. A pull-down menu is displayed providing query, display, and plotting of any of the graphic information and layers used in the text report. Graphical displays and plots are standardized to include title, scale, north arrow, dynamic legend, and 1000 foot distance area around the parcel in question. A standardized vicinity map is also available from this menu.
This application and reporting mechanism has received great success, particularity over the last year. All of the goals and expectations have been greatly exceeded. Numerous benefits have been realized. These include:
A good deal of this success can be attributed to the formation of a "User Group" specifically in support of this application. GIS programming and mapping staff, middle management and supervisors, and most important the end users meet regularly. This group discusses where the application is going, what new data can be added, and how the efforts of the end users can effect the results of the application. This is back to the idea of making users and departments accountable for their own data and their own work.
As mentioned above, Parcel_Info has been well received by the Transportation and Land Management Agency's general staff as well as by many outside agencies. So much so that management has required it at all public information counters supported by the Transportation and Land Management Agency. It is also used, via remote connection, by outside agencies like the Flood Control and Water Conservation District, the City of Elsinore, and various water districts. On average, this one application is run 175 to 200 times a work day. That is over 42,000 times a year.
Parcel_Info is continually growing. Users want more and they want it quicker. One the major challenges faced with each addition and with each modification, is the performance time. The GIS development staff continually looking into short-cuts and ask for enhancements from Esri. In the near future, when GIS finally upgraded to ArcInfo 7.0, the staff will be looking at inter-application communication (IAC) as one possible source for improvement. This should allow Parcel_Info to be converted into a multi-process application. GIS development staff will also be looking at the "ArcServer" concept posed by Esri. These two approaches offer hope of faster overall processing, but they introduce an another problem (or requirement) of additional ArcInfo licenses.
Why not ArcView 2 ? That question has been posed at the County as well. Remember, this application was originally developed and written almost three years ago. ArcView (1) was just new to the market, and did could not work with Libraries and external databases. Though, in our current open systems configuration, ArcView 2 maybe a possibility in the future. But, there are some fundamental problems with this in the current version of ArcView 2. ArcView is mainly a graphic display tool, and it can handle all the graphics functionality currently supported in Parcel_Info. ArcView does not have any report formatting capabilities, and the text reporting and print-out is a key element of Parcel_Info. Theoretically, you could dynamically merge all the tables in ArcView, but it would be extremely large and unwieldy. Remember, this application is currently searching 65 library layers and 14 Informix and Info databases.
Parcel_Info will continue to grow and change to meet the users needs. While users needs are our primary concern, the GIS staff is constantly looking at ways of increasing efficiency and increasing performance. With the upgrade to ArcInfo 7.0 planned for the near future, GIS staff hopes to take advantage of increased Arcplot functionality and possible IAC and/or multi-processing paths to increase performance.
One major change already being planning for, is toward system integration with our newly installed Land Management (SIERRA PERMIT) System. This is a separate stand-along system that is fully networked with our GIS server and workstations. GIS and Land Management System (LMS) staff are striving toward database sharing and access between the two main systems. GIS will be populating SIERRA PERMIT screens with data from GIS databases along with modeling and reselection logic produced from Parcel_Info. Conversely, LMS will be using SIERRA's tracking, statistics, accounting functionality, and data to help further enhance Parcel_Info's reporting and graphical displays. GIS development staff are already perusing the concept of storing ArcInfo coordinate and graphical 'entities' within Informix Databases as BLOBs, and using ArcInfo selection functionality to retrieve them.
If current trends continue, Parcel_Info and similar applications will direct the way in which GIS is moving, particularly within the Transportation and Land Management Agency as well as the County as a government agency.
We would like to thank Mr. Bob Lyman, Transportation and Land Management Agency Program Supervisor, for his valuable input related to front counter procedures, needs, and concerns.
The following is a sample of the reporting and display format used by PARCEL_INFO. This text report file is generated in ArcPlot, but the application runs independent of terminal or display type. This allows for reporting capabilities by ANY terminal with access to the GIS. (Note - for purposes of this paper, names are masked for privacy)
PARCEL_INFO_(version 3.1)___Riverside County G.I.S.__________March 30, 1995
*IMPORTANT*
This information is made available through the Riverside County Geographic
Information System. The information is for reference purposes only. It is
intended to be used as base level information only and is not intended to
replace any recorded documents or other public records. Contact appropriate
County Department or Agency if necessary. Reference to recorded documents
and public records may be necessary and is advisable.
APN = 123-456-789
OWNER = ******* ***** *
= ******* ****
SITUS ADDRESS = 123 BOZO LANE
SITUS P.O. ZIPCODE = SUN CITY 98765-4321
MAIL TO NAME = C/O ** **** *******
MAIL TO ADDRESS = 1234 CAMBRIDGE RD
MAIL TO P.O. ZIPCODE = SAN FRANSISCO, CA 91735
LOT SIZE = 20 Acres (net)
ELEVATION MIN/MAX = 1519 / 1581 feet
LEGAL DESCRIPTION = PM 24/73
SUBDIVISION NAME & LOT = PM 12345 Lot 3 Por.
RANCHO = RANCHO EL SOBRANTE DE SAN JACINTO
PROTRACTED TOWNSHIP/RANGE = T4SR5W Sec 15
CITY = Unincorporated Area
CITY SPHERE = RIVERSIDE
SUPERVISORIAL DISTRICT = BOB BUSTER District 1
ZONING CODE(S) Ord. 348 = R-A-2 1/2 (CZ 5086)
OPEN SPACE CONSERVATION = AREAS NOT DESIGNATED
SPECIFIC PLAN = Not within specific plan
COMMUNITY PLAN = LAKE MATHEWS
DEVELOPMENT AGREEMENT # = Not in agreement area
AGRICULTURE PRESERVE = Not in preserve
AGRICULTURAL CONTRACT = AGC 012
AG PRES ENLARGE/DIMINISH = AGP 123
NOTICE OF NON-RENEWAL = NNR 098
CHANGE OF ZONE = CZ 5086
CONDITIONAL USE = CUP 1234 Approved 11/22/93
DEVELOPMENT AGREEMENT = DA 12
ENVIRONMENTAL ASSESSMENT = EA 12345
GENERAL PLAN AMENDMENT = GPA 321
PARCEL MAP = PM 12345
PLOT PLAN = PP 43210 Submitted 1/2/95
PUBLIC USE = PUP 321
REVERSION TO ACREAGE = RTA 12345
SECOND UNIT = SUP 123
SPECIFIC PLAN = SP 321A
SURFACE MINING = SMP 321
TEMPORARY USE = TUP 123 Submitted 1/23/94 Expires 1/22/95
TRACT MAP = TR 54321
VARIANCE = VAR 1234
VESTING PARCEL MAP = VPM 12345
VESTING TRACT = VTR 54321
WIND ENERGY CONVERSION = WECS 123
CERT. OF LAND DIV. COMP. = COC 3210
CERT. OF PARCEL MERGER = CPM 987
LOT LINE ADJUSTMENT = LLA 4321
OUTDOOR ADVERTISING DISP = OPP 1234
SETBACK ADJUSTMENT = SBA 3579
1990 FARMLAND DESIGNATION = None
R.S.A. Ord. 659 = 46.3 Fee is $2,605/DU
1990 CENSUS TRACT = 420.02
SCHOOL DISTRICT = CORONA-NORCO UNIFIED # 02
ROAD & BRIDGE DISTRICT = Not in a district
T.U.M.F. = IN FEE AREA
WATER DISTRICT = WMWD
FLOOD CONTROL DISTRICT = RIVERSIDE COUNTY FLOOD CONTROL
DISTRICT
FEMA FLOOD PLAIN = Flood Zone C
SPECIAL FLOOD Ord. 458 = Not in special flood area
SKR FEE AREA Ord. 663 = INSIDE FEE AREA
SKR STUDY AREA Ord. 457 = LAKE MATHEWS Study Area
SKR HABITAT = Occupied/Known habitat
SKR BIOLOGICAL REPORT = FOCUSED BIO and EA required-UNLESS applicant
= provides evidence of focused SKR BIO and EA
= prepared within 1 year of application. ("SKR Study
= Area EA Package" AND "SKR Occupied Habitat Package")
GNATCATCHER HABITAT = Riversidean Sage Scrub
= Riversidean Alluvial Fan Sage Scrub
GNATCATCHER BIO-REPORT = FOCUSED BIO required-UNLESS applicant provides
= evidence of focused CG BIO prepared within 1 year
= of application. ("CG Biological Report Package")
FTL FEE AREA Ord. 457&460 = Outside fee area
FAULT ZONE = Not in fault area
HIGH FIRE AREA Ord. 546 = IN high fire area
LIGHTING Ord. 655 = Zone B 44.25 miles.
COUNTY SERVICE AREA = LAKE MATHEWS #128 ROAD-MAINT
MEADOWBROOK ARCHO SITE = ARCHO STUDIES ARE REQUIRED FOR ANY DEVELOPMENT
GEOLOGIC REPORT ZONE = BOARD RESOLUTION NO. 94-125
SPECIAL NOTES = none
CODE ENFORCEMENT = Case# 94-R-1224 Abandoned vehicle
TAX RATE AREA = 059-028
TAX ASSESSMENT DISTRICTS = GENERAL PURPOSE
= COUNTY FREE LIBRARY
= COUNTY STRUCTURE FIRE PROTECTION
= SUPERVISORIAL ROAD DISTRICT 1
= CORONA NORCO UNIFIED SCHOOL
= CORONA UNIFIED SCHOOL B AND I A
= CORONA UNIFIED SCHOOL B AND I B
= RIVERSIDE CITY COMMUNITY COLLEGE
= SCHOOL EQUALIZATION AID
= INSTITUTIONAL CHILDREN
= JUVENILE HALL PROG-COUNTY
= REGIONAL OCCUPATION PROG-COUNTY
= CO SUPT SCHOOL-GEN PURPOSE
= CO SUPT SCHOOL-CAPITAL OUTLAY B
= COMM COLL TUITION CORONA-NORCO
= COUNTY SCHOOL DEVELOPMENT CENTER
= RIV CO REG PARK & OPEN SPACE
= FLOOD CONTROL ADMINISTRATION
= FLOOD CONTROL ZONE 2
= COUNTY SERVICE AREA 128 *
= CSA 152
= PERRIS VALLEY CEMETERY
= WESTERN MUN WATER IMP DIST 2
= RIVERSIDE CORONA RESOURCE CONSER
end of listing ...