Robert Agnew
Jason Lewis
Richard Wells
BACKGROUND
The City of Las Vegas acquired its GIS from Esri in 1988. Installed on a Prime Computer for compatibility with the Clark County GIS (installed in 1982), the City's GIS Group embarked on a Pilot Study in January, 1989.
SYSTEM INFO
Following Esri's move to SUN MicroSystems SPARCstations, the City of Las Vegas initially deployed a SPARC 1+ in the GIS Group and a SPARC 1 in the Public Works Department.
Currently, the City of Las Vegas' GIS consists of 5 SPARC 20's running Solaris 2.3, a super SPARC 20 running Solaris 2.5 at the Fire Department (Fire Mapping Group) and a SPARC LX at the Metropolitan Police Crime Analysis Group. Each SPARC has a total of approximately 4.5-5GB disk space, 64MB RAM (32 in the LX), and three (3) of the SPARCs have dual processors.
These various GIS Groups are attached to eachother, and also to the County GIS group, GISMO, via fibre-optic line provided by our local telephone company. Other local entities, also signatories to the County's InterLocal Agreement, are similarly configured and attached.
DATABASE INFO
After our initial Pilot Study, we continued to digitize and create what have come to be know as the nine (9) layers of geographic data which make up the "base" of our repository. The County, through the Assessor's Office, began providing the PARCEL layer (from scanned orthophotos) in 1993. (Actually, there are 5 "base" <coverages> supplied by the Assessor for each section of land: AE (Assessor Easements), RE (Road Easements), CD (ConDos), LL (Lot Lines) and PL (ParceL)). In 1988, we had 56,024 parcels in the City, within about 32 sections of land. Our database now consists of about 184,000 parcels of land in nearly 120 sections.
We, like most other entities in the Las Vegas Valley, receive updated <coverages> in the form of export files. Based on the Las Vegas Valley's rapid rate of growth, we receive updates twice a week. All InterLocal users have a login and a workspace at GISMO's system, from where we FTP these export files. Additionally, some of the entities such as Henderson and Las Vegas provide entity-specific data back to GISMO for use in the Central Repository.
BASE DATA UPDATE/MAINTENANCE
Generally, these exported <coverages> are downloaded on Monday and Thursday as they become available. (Occasionally, specific requests for data are made on behalf of the Fire Mapping Group in a somewhat futile attempt to keep up with latest subdivisions on the ground.) The export files are then deleted from the GISMO system - for disk space conservation and user etiquette reasons. (The County is currently testing Digital UNIX preparatory to transitioning from VMS/VAX to Digital UNIX/Alpha stations. Once on UNIX, we could conceivably "mount" their Central Repository to obtain their data via an ARC copy.)
Once these exported <coverages> are downloaded, they are processed into our System's repository via an AML . The AML produces a report for our Production Mgr., Kim, so she knows which sections have been updated There can be as few as two (2) sections of data (times 5 <coverages>) to as many as 60 sections (times 5 <coverages>). This AML also performs a name change on the <coverages>, since the City's naming convention is different from the County's. (Our Library INDEX <coverage> contains the three different names used to designate a section of land in Las Vegas: CLV, CC, Fire.)
Once Kim receives the import report, she processes the annotation contained therein to TAT's. (We stopped using ANNO levels in favor of subclassing for purposes of clarification.) These imported <coverages> are then installed into the City's repository and used as the basis for the creation of the City's additional layers. The PL (parcel) <coverage> is also put into the Library using another home-grown AML which performs a "puttile" function. (NOTE: since our PARCEL base layer is not created/maintained by us, we never perform tile extractions/replacements/insertions - only puttile.)
ADDITIONAL LAYER CREATION/MAINTENANCE
There are currently two (2) GIS Techs whose primary function is to perform layer creation/maintenance. The layers on which they work are all based on the PL (ParceL) layer received from the County Assessor and include ADD (ADDress), LU (Land Use), Z (Zoning), SUB (SUBdivisions), GPA (General Plan Amendment), ST (STreets), AOADM (Assessor Office ADMin), SID (Special Improvement Districts), PED90 (Population/Economic/Demographic 1990 census). Much of the data which makes up these additional layers is created by hand (digitizing or free-hand drawing). The rest is the product of relates (addresses) or dissolves (zoning). All processes are automated via AML's written by Kim. One of these techs, Jason Lewis, will cover these procedures in more detail.
Once sections are completed, a "MOVE SLIP" is filled out by the tech so Kim knows which section/layer/pathname is now available for her automated QC procedures. A suite of AML's she wrote to QC each layer has been conglomerated into an all-encompassing QC function. Once a section passes her QC, she passes the "MOVE SLIP" to the Library Administrator which is the authorization to place it into the Library.
We currently maintain two (2) Libraries. One is for use by the SUN/UNIX/ARC-INFO group and the other is a carbon copy for use by the ArcView users. Additional data areas have also been duplicated onto a single SUN disk for access by the ArcView via an NFS mount point. The AML used to update the Library has the option of updating either Library or (most often) both. We've found that the Library updating AML performs additional QC on the data that we sometimes don't catch: spatial features on annotation <coverages>, data item definition mismatches, no fit conditions vs. the Index <coverage>. Once the section has passed successfully into the Library, the "MOVE SLIP" goes to the Database Mgr. who keeps these "MOVE SLIPS" in binders in chronological order. We also have automated our procedures for processing the tabular data as well.
TABULAR DATA UPDATE/MAINTENANCE
We maintain two (2) types of tabular data: the Assessor's Office Secured Tax Roll (the tabular version of the PL (parcel) <coverages>, and the DETAIL files.
ASSESSOR'S OFFICE SECURED TAX ROLL (AOEXTLV)
This is a tabular data file received from the Assessor's Office via the County network. It is generally updated monthly and is made available to all the InterLocal signatories. It is processed into the City's System via an AML which also produces some interesting sub-files: a key file based on the PARCEL NUMBER, a key file based on the PARCEL ADDRESS, a key file based on the PARCEL's OWNER, a key file based on the TILE NAME, and a key file based on the PARCEL VALUE. These additional (key) files are each sorted on their key item for optimization. A relate file (PARCEL.RT) is also maintained in the same INFO area to facilitate query of spatial data via tabular constraints. (There is an AML used to update a user's area with the latest version of this relate file. Any additional relationships which users want to establish are added to this relate file, then the SET-RELATE.AML is used to update the user's area.)
The latest version of the AOEXTLV file contains over 184,000 records (by 480 bytes wide) and took about 1.5 hours to process into the System. This includes the time required to replace these files in the area used by the ArcView users, as well as the time required to create the VALUE KEY, which is based mostly on data calculated on the fly.
DETAIL FILES
Much of the additional spatial data the City creates is based on (tabular) information from in-house Departments Consequently, many times, we need to relate the spatial/parcel data with the in-house tabular data with the AOEXTLV data. Kim devised the DETAIL files for this purpose. An AML is run on a section of land which gleans all tabular information found in all layer .PAT's/.AAT's for that section into a single INFO file: i.e.: L27.DET. This allows for one-to-many and many-to-one relates. We also have an AML which will combine all these individual DETail files into a single DETAIL.FIL for the entire City, for relating with the Library. These files allow the City to perform analysis such as multiple uses on a single property, multiple zonings on a single property, or properties built in which year by zipcode for R-E zoning. These files are updated along with the spatial data to maintain synchronization.
Getting the data out in a useful and timely manner is a primary goal of the GIS Division. As stated earlier the City of Las Vegas GIS Division has substantial data layers that are either developed in-house or made available through the interlocal agreement. As the available data sets began to grow in numbers so too did the need for consistent quality cartographic output.
One way the Division deals with turning out high quality products quickly is through the use of the Plot Generation Program (PGP). PGP was developed to provide an easy to use menu interface that allows the user to point and click to generate the product desired. Presently PGP offers choices for Zoning, Land Use, Parcels, City Council, and Metropolitan Area. The first three choices provide numerous options giving the user the freedom to choose the desired pagesize and orientation for the data that has been developed on top the county assessor's parcel layer. Parcel based, these options range for a simple 8.5 x 11 to a large 55 x 43. Once the user has determined the appropriate page size a map can be generated with either a user defined area or a section tile (one square mile of land). If a user defined option is chosen, a street centerline graphic of the city is drawn on the screen showing major streets and street names. The user first clicks on a general area that they wish to map. Next a zoom in will give the user a clearer look at the area they are dealing with. At this point the user defines the lower left and upper right area on the screen. The map is then generated using interactive map composition. If a section tile is the desired mapextent a menu comes up offering the different township and ranges available to the user.
The City Council and Metropolitan Area options offer the user a number of Street Centerline based products. The contents of these products range from City Council Ward maps to County-wide products. Options such as zip codes, census tracts, and county commission districts comprise these options.
Once PGP has been told what type of map and the appropriate page size, the program pauses and allows the user to add or delete any map elements they wish to further manipulate. Although the program is designed so that no GIS experience is necessary, the more experienced user can use PGP to create a template to suit their needs. By using PGP the user is guaranteed that a particular style of product is going to be generated. All of the plot options have been standardized so that the City Logo, North Arrow, Keyfile and Title always come out in the same position. As a result most products generated in the past can be regenerated with minimal effort.
In order to promote the various options available to the user, a Sample Products handout has been created. This handout shows examples of the various options available. As a result, staff uses the booklet to show customers both inside and outside the organization the different types of plots that can be obtained. Currently PGP has options that highlight the data sets available that pertain to the planning department. As the City's GIS continues it's move towards becoming an enterprise wide GIS, further PGP templates will be developed. The end goal of the program is to offer a menu choice for all the various departments within the City. Under each of these choices would be a host of products that enable the workers to complete their tasks in a timely and efficient manner. Under such an arrangement each department can specify how they would like to see their data displayed. This allows for custom mapping that meets the needs of the user and at the same time conforms to the cartographic standards of the GIS division.
Because of the ease of use of PGP, the Division has created a walk up workstation that allows user's within the organization to generate their own products. In addition the analysts and technicians that process map requests are able to generate quality products with a minimal turnaround time. The average time it takes to generate a plot with PGP is about 15 minutes (not including plotting time).
G.I.S. FIELD CHECK MAP
and updating procedure's
Purpose: Field Check Maps are used as a reference by G.I.S. staff for notating what actually exists within the City limits. These maps that are produced by staff, help tremendously when updating a square mile section of land.
Layers of Data:
parcels - (subdivided land)
land use - (building footprints ex: house, apt., condos etc.)
addresses
subdivisions - (lot and block numbers) if needed
streets
A. Information on existing base map:
1. The Clark County Assessor's Office (sent over through fiber link by G.I.S. System's Administrator) provides Assessor's parcels eliminating the need for G.I.S. staff to create a base layer themselves.
2.. Land Use is created and field checked by G.I.S. staff (notates on map what is actually out there).
3. Addresses come from the Clark County Assessor parcel records. Some from books at front counter and also new address subdivision lists. (C of O's) Certificate of occupancy
4. Subdivisions are rarely but sometimes needed and is maintained by G.I.S. staff
5. Streets are updated per C.C.A.O Road easement layer
B. Updating base map process
G.I.S. staff wrote many computer programs most of which are not mentioned
but the ones that are I use to update existing Land use layers.
Steps: ( 8 to 12 hrs. to complete one square mile section)
1. Each Tuesday both technicians are assigned to go into the field to gather data. Each square mile
section of land is generated by a plot program called (P.G.P). The field check option within the
program places the parcel, land-use, address, and street layers on a 24x36 canned template. The map is
then sent to our color electrostatic plotter and is ready to be used for field purposes. (All Day)
2. Upon successful completion of our field work the Land-use, addresses, street layers are then updated
manually by G.I.S. staff and placed accordingly on top of the parcel layer within the city limit
boundaries.
3. Run program (UPDATE_LAYERS) that sets-up the coverage (all the different layers). 1 hr. 45 mins
I then begin adding land-use making sure the uses are placed neatly within the parcel. They are then
given a code, shade, and capacity.
4. When running (UPDATE_LAYERS) it sometimes gives you the addresses and places them directly in
the middle of the parcel but most of the time they are generally entered manually from the sub-lists.
Addresses tend to take a little more time however, when placing anno within the parcel I have to make
sure it is placed facing the street name in a nice orderly fashion moving them from one orientation to
the other. This can obviously be very time consuming but once these addresses are entered they rarely
ever have to be touched again 4 to 6 hrs.
5. For subdivisions however lot, block, and subname are added as well and moved around accordingly
6. The coverage is then quality controlled by myself or a member of staff for any errors. 2 hrs.
7. A move slip is then given to the supervisor for the QA process.
8. The final step is to run the program (DISTRICT-MAPS) allows you to make 8 - 1/8 square mile
section of land adding as many layers needed for front counter use.