The City of Bakersfield, CA GIS Implementation Plan (1997 - 1998)

The City of Bakersfield
Geographic Information System
Implementation Plan (1997 - 1998)

August 30, 2012

Prepared for City of Bakersfield
by Juan Tobar

Filename: P:projects19961996.1 Implementation Planreport_main.wpd

i

1 Introduction.................................................................................................................... 1
1.1 State of the COBGIS from 1990 to 1997 ......................................................... 2
1.2 Direction for 1997 - 1998 ................................................................................ 3

2 Data Survey and Needs Analysis .................................................................................. 4
2.1 Departmental Results ....................................................................................... 5
2.1.1 City Manager‟s Office ..................................................................... 5
2.1.1.1 Data Survey ..................................................................... 5
2.1.1.2 Needs Analysis ................................................................ 5
2.1.2 Community Services - Parks and Recreation................................... 5
2.1.2.1 Data Survey ..................................................................... 5
2.1.2.2 Needs Analysis ................................................................ 5
2.1.3 Developmental Services - Building and Planning Division ........... 5
2.1.3.1 Data Survey ..................................................................... 5
2.1.3.2 Needs Analysis ................................................................ 6
2.1.4 Economic and Community Development ........................................ 6
2.1.4.1 Data Survey ..................................................................... 6
2.1.4.2 Needs Analysis ................................................................ 6
2.1.5 Financial Services ............................................................................ 7
2.1.5.1 Data Survey ..................................................................... 7
2.1.5.2 Needs Analysis ................................................................ 7
2.1.6 Fire Department ............................................................................... 7
2.1.6.1 Data Survey ..................................................................... 7
2.1.6.2 Needs Analysis ................................................................ 7
2.1.7 Police Department............................................................................ 8
2.1.7.1 Data Survey ..................................................................... 8
2.1.7.2 Needs Analysis ................................................................ 8
2.1.8 Public Works Department - Engineering ......................................... 9
2.1.8.1 Data Survey ..................................................................... 9
2.1.8.2 Needs Analysis ................................................................ 9
2.1.9 Public Works Department - Operations and Streets ........................ 9
2.1.9.1 Data Survey ..................................................................... 9
2.1.9.2 Needs Analysis ................................................................ 9
2.1.10 Public Works Department - Solid Waste ....................................... 9
2.1.10.1 Data Survey ................................................................... 9
2.1.10.2 Needs Analysis ............................................................ 10
2.1.11 Public Works - Wastewater ......................................................... 10
2.1.11.1 Data Survey ................................................................. 10
2.1.11.2 Needs Analysis ............................................................ 10
2.1.12 Water Resources Department ...................................................... 10
2.1.12.1 Data Survey ................................................................. 10
2.1.12.2 Needs Analysis ............................................................ 11
2.2 Summary of Results ....................................................................................... 11
2.2.1 Digital Imagery .............................................................................. 11
2.2.2 USGS Digital Elevation Models .................................................... 12
2.2.3 Core Data ....................................................................................... 12

3 System Design............................................................................................................... 14
3.1 Software Platform .......................................................................................... 14
3.1.3.1 INFO .............................................................................. 16
3.1.3.2 DB2 ................................................................................ 16
3.1.3.3 ORACLE ....................................................................... 16

ii

3.2 Hardware Platform ......................................................................................... 16
3.3 GIS Standards ................................................................................................ 17
3.4 Metadata Standards ........................................................................................ 17

4 GIS Implementation Plan 1997-1998 ........................................................................ 19
4.1 Road Center Lines ......................................................................................... 19
4.2 Base Map Porting........................................................................................... 19
4.2.1 Road Center Lines ......................................................................... 19
4.2.2 Control Monuments ....................................................................... 19
4.2.2.1 Master Tic Coverage...................................................... 20
4.2.2.2 Primary Control ............................................................. 20
4.2.3 Parcel ............................................................................................. 20
4.2.3.1 Master Tic or Primary Control....................................... 20
4.2.3.2 Control Ties or Secondary Control ................................ 20
4.2.3.3 Boundaries. .................................................................... 20
4.2.3.4 Parcels and Land Properties........................................... 20
4.2.4 Township/Range and Sections ....................................................... 21
4.2.5 2010 Boundary............................................................................... 21
4.2.6 Ward Boundaries ........................................................................... 21
4.2.7 Railroad Centerlines ...................................................................... 21
4.2.8 River Centerline ............................................................................. 21
4.2.9 Canal Centerline ............................................................................ 21
4.3 COGO Parcels................................................................................................ 21
4.4 APN Update ................................................................................................... 21
4.5 Linking HTE to ARC/INFO and ArcView .................................................... 22
4.6 ArcStorm........................................................................................................ 22
4.7 Linking „PERMITS‟ to ARC/INFO and ArcView ........................................ 22
4.8 Image Classification and Analysis ................................................................. 22
4.8.1 City Limits ..................................................................................... 23
4.8.2 Classification and Analysis ............................................................ 23
4.9 Street Centerlines ........................................................................................... 23
4.10 Implementation Time Lines ......................................................................... 23

5 Conclusion .................................................................................................................... 24

Notes 25

Appendix A

Appendix B

Appendix C

iii

1 Introduction

The objective of the City of Bakersfield Geographic Information System (COBGIS) is the
development of a system which can be used as a shared resource for geographic and spatial
information by City departments, private and public sectors. Within a municipality all
departments operate with the same customer base and geographic domain. This has led to
the recognition that making quality geographic data available for sharing and manipulation
can be a key factor in improving the effectiveness of day to day operations and long term
decision making in municipalities.

This implementation plan is divided into five sections as follows.

Section 1: Introduction - Provides a history of the GIS efforts so far and overall goals for
the 1997 - 1998 fiscal year.

Section 2: Data Survey and Needs Analysis - Categorizes the needs of City departments
individually and for the City as a whole.

Section 3: System Design - Provides information on hardware, software, GIS data base
management, relational database management system software and the COBGIS Model.

Section 4: GIS Implementations - Descries the GIS projects to be completed by the end of
the 1998 fiscal year.

Section 5: Conclusion

City of Bakersfield GIS Implementation Plan 1

1.1 State of the COBGIS from 1990 to 1997

The City of Bakersfield began implementing its GIS in 1990 using existing City staff. In
1994 two technicians were hired on contract to work on creation of a base map. A full time
coordinator was hired in February 1997.

The Planning Department has spearheaded the development of the existing COBGIS
through the use of AutoCAD, GEO/SQL, and ORACLE to create a base map consisting of
the following coveragesi:

1) Monuments. The initial monuments entered came primarily from
County File Maps survey and perpetuation data. Monuments shown on
these maps represent section and 1/4 section corners of the State Planes
Coordinate System. These in turn are used to geo-reference many of the
other layers in the base map. Eventually, all monuments including street
and property line monuments and City benchmarks should be included in
this database. This data set is approximately 90% complete.

2) Control Grid. This coverage consists of section, township and range
data tied to monuments in the Monument coverage. This data set is also
approximately 90% complete.

3) Street Centerlines. This data set includes freeways, state highways,
county roads, arterials, collectors and local streets. This data set is about
85% complete.

4) Other man made features such as canals, railroads, bridges, etc. These
data sets are at different stages of completion, in general more than 50%
and below 90%.

5) Natural Features such as rivers, lakes, etc. This data sets are mostly
100% complete.

6) Cadastral. This coverage includes property lines, right-of-ways and
easements. To the extent of the 2010 boundary this data set is
approximately 40% complete.

1.2 Direction for 1997 - 1998
The GIS activities planned for this fiscal year include the following:

1) implementing the Tri-Service Spatial Data Standards as the model for
the COBGIS (see section 3.3);

2) porting coverages from the six classes above into ARC/INFO;

3) continued parcel database creation and update using COGO and the
updating of Appraiser Parcel Numbers (APN);

4) the linking of HTE and the „PERMITS‟ database;


5) the classification of satellite imagery for Solid Waste.

Please see section 4 for detailed information on these implementations.


2 Data Survey and Needs Analysis

As part of the development of this Master Plan a data survey and needs analysis was
conducted based on discussions with various interested parties in all City departments and
many sub-departments. The goals of the data survey and needs analysis are as follows:

1) To identify as many spatial data sets as possible and to catalog these as:
core or departmental; raster, vector or data sets on two dimensional media;
and tabular.

Where core data is defined as those data sets which are used by
three or more departments and departmental data are data sets
used primarily by a single department.

Where raster is defined as a data structure consisting of an array of
grid cells (sometimes termed pixels or picture elements). Each
grid cell is referenced by a row and column number and it contains
a number representing the type or value of the attribute being
mapped. In raster structures a point is represented by a single grid
cell; a line by a number of neighboring cells strung out in a given
direction and an area by an agglomeration of neighboring cells
(Figure 1(a)).

Where vector is defined as a data structure consisting of points,
lines, polygons and some form of connectivity. The starting and
end points of the lines define vectors that represent the form of an
object; pointers between the lines indicate to the computer how
the points, lines, and polygons link together to form the object
(Figure 1(b)).

Where a data sets on two dimensional media are defined as maps,
mylars, microfiche, and any other data sets on flexible media.

Where tabular data contains attribute information about the spatial
objects being stored in a database.

(a) (b)

Figure 1: An image of a chair (a) raster or grid-cell and (b) vector format.


2) To gain an understanding of each departments functionality, general
geographic activities, possible GIS projects, and levels of GIS users
throughout the City.

3) To prioritize the order of data set incorporation and project
implementation into the COBGIS.

4) To serve as a starting point for a COBGIS Data Dictionary. A data
dictionary is a list that maintains, for each coverage, the names of the
attributes and a description of the attribute values. The construction of a
data dictionary for the COBGIS would serve as an invaluable reference
during projects as well as for transferring information to others.

2.1 Departmental Results
2.1.1 City Manager’s Office

2.1.1.1 Data Survey

The most important database housed in the MIS Department is the HTE Financial
Database. This database is populated with items from the Kern Integrated Property
System (KIPS) which contains attributes such as a land use code, parcel owner name,
parcel owner address, land acres, mineral value and land value.

2.1.1.2 Needs Analysis

In order to support the planned Citywide GIS implementation the MIS department will
need the addition of two full time staff personnel to Geographic Information Services. It is
estimated that to complete the tax parcel vector database will require approximately one
more year of continuous effort by two individuals. In addition, it is estimated that
maintenance of this database once complete will require at least one full time person. Thus,
in order to achieve the timely completion of other GIS projects and support GIS users at
least two full time staff members will be required.

The City Clerks Office also will have the periodic need for council district
reapportionment. With the establishment of ArcView Desktop GIS it is possible to create
an application which would allow reapportionment to be done by staff from this
department with minimal supervision once trained to use the application, the last
reapportionment was done in 1995.

Other needs include basic GIS mapping functionality for upper management and the City
Clerk.

2.1.2 Community Services - Parks and Recreation

2.1.2.1 Data Survey
Some of the data sets in this department include sump locations maintained on Thomas
Brother‟s maps.


Members of this department stated that an important need was the development of a tree
and shrubbery inventory for the entire city. A possible application in this department may
include the use of GIS to help in park planning and park inventorying.

2.1.3 Developmental Services - Building and Planning Division
2.1.3.1 Data Survey

The Planning Division has produced the bulk of the existing vector data sets. These data
sets include control monuments, sections, townships, street centerlines, parcels, railroads,
rivers, lakes, canals, subdivisions, land-use, voter precincts, council wards, school
districts, traffic analysis zones, census tracts, city limits, the 2010 boundary, and
urban/open lands. Tabular data sets include Building‟s Sierra Permits database from Sierra
Computer Systems, Inc. Data sets on 2D media include zoning/land-use, annexations,
noise contours, seismic hazards and addressing grid maps. Aerial photography sets for the
City are available for the years 1952, 1959, 1975, 1980, 1985, 1990 and 1995.


The needs of Building and Planning include the following: a complete and current parcel
base map, the development of a methodology for the more timely update of APN numbers,
and the development of a relation between Sierra „PERMITS‟ database and the COBGIS
and the HTE Financial database and the COBGIS.

2.1.4 Economic and Community Development
2.1.4.1 Data Survey

The data survey revealed that Economic/Community Development has several digital
tabular data sets. These data sets track financial information on loan recipients such as
number of loans, addresses of home loans, demographics, structural information (i.e., 2, 3
bedrooms), and demographic data sets from the U.S. Census Bureau. Vector data sets of
low accuracy exist of census tracts, block groups, city boundaries, street center lines,
enterprise zones and redevelopment areas. Most of these data sets were acquired or derived
from TIGER while others have been acquired and also modified by consultants. The term
TIGER comes from the acronym Topographically Integrated Geographic Encoding and
Referencing which is the name for the system and digital data base developed at the US
Census Bureau to support its mapping needs for the Decennial Census and other Bureau
programs.

Other data sets include a seven-year-old redevelopment survey which was conducted in
downtown Bakersfield which may be of interest for conversion.

ED/CD Services was one of the first departments to start using GIS due to the submission
requirements which HUD has imposed on these organizations throughout the country.
HUD requires that institutions provide them with up to date information on how their
disbursements are being used to help local communities. To achieve this goal HUD and
MapInfo Corp. developed a partnership by which they would provide a copy of MapInfo
GIS, custom mapping applications, and connectivity software for use with HUD‟s bulletin


board system for the timely update of their database. HUD requires map updates to be in
MapInfo‟s MIF format. This compatibility needs to be maintained as we make ArcView
the standard desktop GIS package for the City. This compatibility conflict between
MapInfo and ArcView could be eased by use of software which allows maps produced in
ArcView to be read by MapInfo and vice versa. ArcView comes with a utility which allows
the importing of MapInfo data sets. MapInfo produces a product to import ArcView data
which costs about $100.

Other basic GIS needs in the department include the ability to query data spatially and to
have connectivity to the HTE and Sierra „PERMITS‟ databases. Sample needs include the
ability to display and report on the amount of funds spent in wards or census tracts, and the
ability to display business licences by geographic regions.

Other higher level needs include the ability to generate assessed valuations and the ability
to perform trend analysis.

2.1.5 Financial Services
2.1.5.1 Data Survey

This department makes extensive use of the HTE database. In addition, a property
management database exists in this department consisting of approximately 60 items such
as: deed, square footage, topography, sidewalks, curbing, fence and others.


This department needs basic GIS mapping functionality in order to display parameters
from HTE, Sierra „PERMITS‟, and the property management database maintained by Don
Anderson. Other applications may include the linking of data on business licenses to other
databases for display in ArcView or ARC/INFO in order to identify businesses without
proper licenses.

2.1.6 Fire Department
2.1.6.1 Data Survey

Fire Safety has a very complete tabular digital database of fire hydrants and shut off valves
which are identified on approximately three hundred hydrant location maps of the City.
Additional data sets include the Fire Station Consolidated Monthly Report, an HAZMAT
database, and maps of Fire Station response zones. In addition, two computer systems will
soon be implemented for this Department which include a Computer Aided Dispatching
system from Integraph and a Fire Records System based on HTE.


The Computer Aided Dispatching System will necessitate the incorporation of an up to
date street centerline coverage (see Section 4.1). Additionally, with the use of HTE
software Fire will also need access to their data on from ArcView Desktop GIS. Other
needs of this department include having the hydrant databases available in a digital format
and the ability to access HAZMAT data sets. Another need included upgrading the TIGER
line files used in HAZMAT‟s MapInfo‟s Map X program to the City‟s street center line file


and the creation of HAZMAT Hazard Maps of the City. Complex GIS projects include
emergency response travel time minimization (a routing application) on a citywide basis
for new fire station locations and by updating present EMS Zones.

Routing applications can be accomplished with a street centerline alone, however, to more
accurately model the COBGIS transportation system turn impedances at street
intersections and a digital elevation model (see Section 2.2.2) should be used. Turn
impedances are used to assign an impedance value to a turn, usually expressed in seconds,
or to prevent certain turns. The turn impedance may be any positive numeric value or a
negative value can be used to signify that a turn is prohibited and are stored in a list called
a turntable. Figure 2 gives an example of a turntable for one intersection with one
no-right-turn requisite.

(a) (b) (c)

Figure 2: Turn table entries for a commonly encountered network situation.

2.1.7 Police Department
2.1.7.1 Data Survey

The data survey found that Police has extensive tabular data sets on criminal activity and
crime events, however, because of the nature of this data it is not appropriate for
implementation in the COBGIS. However, these same data sets could be made available to
Police via ArcView the Desktop GIS which we will be implementing. One tabular data set
used in dispatching partitions a street or block face into sections based on building type.

Data sets on two dimensional media which could be converted in the COBGIS include all
levels of data compilation areas, including: dispatch areas, police districts, multiple
reporting districts, special reporting districts and crime cluster areas.



It is likely that the greatest benefit to this department from GIS is in the area of crime
analysis. At present, the only graphic method for the graphic display and crime analysis is
the “pin-map” other than this all analysis is conducted from data printouts. Therefore, the
addition of even basic GIS functionality will significantly improve their capability in crime
analysis. One benefit of a properly addressed street centerline file (See Section 4.1) will be
the ability to automate the assignment of geographic locations to recorded criminal
activity. This street centerline file and the processing power of ArcView will make
“pin-maps” a thing of the past.

A possible application may include the creation of a custom interface for crime analysis as
exemplified by the City of Salinas.ii The police department of this City in cooperation with
ESRI created an intuitive interface developed in Visual Basic to integrate ArcView
functionality with the City‟s police records management system. This Visual Basic front
end is being made available to other Law Enforcement agencies for free and could be the
start of Bakersfield own crime analysis interface.

Other areas of possible improvement include the maintenance of the database used for
dispatching. As already stated, this database partitions streets or block faces into segments
based on the parcel ownership. Take for example a street or block with an address range
from 500 to 599 with a public park on the even side of the street from 540 to 560. Usually,
this street would be represented by two records, one for the even and one for the odd side of
the street. Dispatching on the other hand needs four records: one for the odd side of the
street 501 - 599, and three for the even side of the street 500 - 538, 540 -560, 562 - 598. At
present, this database is maintained with some difficulty since it requires researching maps
and other records. Once the COBGIS is implemented a methodology could be developed to
maintain and update this database more effectively.

2.1.8 Public Works Department - Engineering
2.1.8.1 Data Survey

This department is the single largest resource of data sets on two dimensional media in the
City. The maps in Engineering include sewer, parcel, curb, monuments, bench marks,
openings and closings, annexations, vesting maps, storm drain, project location maps and
others. Three other data sets include: road improvement and recorded map microfiche as
well as aerial photography. Tabular data sets include: traffic volume, speed limits, traffic
accidents, a complaints database, signal inventory, signage and markings, index of all
improvement plans and a parcel map waver log.


The analysis for this department revealed the need for simple and complex GIS
functionality. Simple functionality being the ability to query on the Sierra Permits or HTE
database and have the results displayed graphically on the GIS. Complex functionality
being defined as the ability to conduct network analysis including dynamic segmentation.
A dynamically segmented and accurate street center line coverage will be needed for
modeling traffic volume, speed limits and pavement conditions for the Traffic Operations
Center (TOC) and the Pavement management System (PMS).

Other needs include the ability to link the software which will be used in the TOC and PMS
to the COBGIS.


2.1.9 Public Works Department - Operations and Streets
2.1.9.1 Data Survey

Under Operations, General Services had a digital database of traffic signs and street lights
on the Prime. Since the transition to HTE this department has been using a card database
for recording this data. Streets possesses copies of Engineering maps which depict the
sewer network and storm drain network. At present there is a program to identifying the
quality of both networks through the use of mobile camera units. Two attributes which are
of special interest to this department are: the material type of network elements and the age
of the network elements. Although material type is known for about 90% of the City
material age is not well determined. Another database includes a PMS in Streets which was
lasted updated in 1995. Lastly, Graffiti has a database of graffiti locations with associated
pictures.


General Services is in need of reestablishing the functionality which was available on the
old Prime with the additional benefits of GIS. In addition to accessing the HTE database
there is also a need for spatial access to street lights, street signals and street signs. Streets
will need to have access to some part of the PMS being developed at Engineering.
Applications here include street sweeper routing applications, street sweeper and solid
waste routing optimization, and sewer/storm water network management.

2.1.10 Public Works Department - Solid Waste
2.1.10.1 Data Survey

The data sets found in this department include Residential Operations Pickup Maps. The
names of other databases include Senior Citizens, Hi-Low Residential Pickup Routes,
Front Loader Pickup Routes, Commercial Cart, Commercial Bins, Cart Listing by Street,
and a New Solid Waste Service Database.


As with many of the other departments, Solid Waste needs both simple and complex GIS
functionality. One of the more complex needs involves the determination of which areas
should be serviced by the City‟s Solid Waste Department and Solid Waste Contractors.
The division of service between the City and contractors for an area of land was based on
the ratio of land developed to undeveloped at the time of annexation. At the time of
annexation those lands which are developed are serviced by contractors while all new
development is serviced by the city. The solution to this question involves the
identification of those parcels which did or did not exist at the time of annexation.
Although it may be feasible to identify some of these parcels using Structured Query
Language (SQL) it is unlikely that all parcels would be identified due to the lack of a
historical coverage of the parcel database. Another solution is to identify these parcels
from recorded information, unfortunately, this would take a considerable amount of time.
A more effective method for this identification would be the classification of a satellite
image into two classes such as developed and undeveloped. A satellite image taken in the
winter rainy season would display developed areas in shades of grey while undeveloped or
vegetated areas would be visible in shades of red. A computer algorithm could be used to


classify this image and the resulting polygon could be used to select out all parcels which
where on developed land at the time of the annexation.

All solid waste pickup routes have been created using manual methods. The work to be
performed by Thomas Brothers on our street centerline file will enable us to calculate new
and improved routes. Existing documentation on fuel consumption, distances traveled, and
time taken to complete each route could be used to measure these improvements.

Finally, there is also a need to manage the many databases in this department from a single
database interface.

2.1.11 Public Works - Wastewater

The primary map data sets in this department included water purveyor area maps, water
and sewer pipes maps, as well as maps of the different sewage farm facilities.

A possible applications in this department may include using existing data to create a
rehabilitation strategy for non-critical sewers. GIS could be used to analyze existing sewer
system performance data in order to achieve a priority ranking based on factors such as
structural, hydraulic, and serviceability criteria and taking into account the consequences
of failure of the sewer section in question.

2.1.12 Water Resources Department

The primary map data sets in this department included the different water purveyor in the
area, the canal network, and water pipes. Additional mapped data sets included canal
engineering diagrams, water quality sampling wells, and Kern River Surface Profiles. The
most important tabular data sets included Kern River Dispatch Records, and Water
Quality Well Data


The primary need in this department is for the map to vector conversion of the water pipes
and canal network data sets.

2.2 Summary of Results
The data survey revealed all departments have tabular data, most have custom maps, and
few have vector data sets. The data survey also revealed that the only data set actively
maintained by multiple departments is sumps found in Engineering, Community Services,
and Water Resource Department. Many of the common maps (such as city boundaries and
council wards) displayed redundant data and they varied in currency and accuracy from
department to department.

The needs analysis revealed that all departments could benefit from basic GIS functionality
to manipulate and map data. The most common needs were the ability to access the street
center lines, parcel, city limits and annexations, the 2010 boundary and council ward
boundaries. Another common manipulation includes geocoding the assignment of


geographic location to a point, line or polygon. The display of parcel data as it relates to
HTE and Sierra „PERMITS‟ is also of primary importance. The most common high-level
GIS functions are dynamic segmentation, location and allocation modeling. Other high
level GIS functions include development of an algorithm to update parcel APN numbers
and creation of an updated street centerline file for address geocoding.

There are four levels of GIS users in the City as follows:

1) Professional -These users administer, create, maintain, and use complicated topological
spatial data sets. These users create applications for ARC/INFO and ArcView in Arc
Macro Language (AML), Avenue, and Visual Basic programming languages. These users
can be found in Geographic Information Services.

2) High Desktop - These users create, maintain, and use complicated topological spatial
data sets. These users create applications for ArcView in Avenue and/or Visual Basic
programming languages for their departments. At least one user in each department should
be trained at this level.

3) Intermediate Desktop - These users use ArcView to join spatial data sets such as the
COBGIS parcel data set with a Property Management data set. These users use ArcView to
query and map attributes from HTE, „PERMITS‟ and other data sets. These users are found
in all departments

4) Low Desktop - These users use ArcExplorer and ArcView to query and map attributes in
the COBGIS. These users are found in all departments.

2.2.1 Digital Imagery
The analysis revealed the need for the acquisition of a digital image map of the City of
Bakersfield. Digital imagery can be either scanned and rectified aerial photographs or
rectified satellite imagery. Imagery data complements vector data by allowing the
identification of objects within polygons in a vector coverage and by providing a more
intuitive manner by which persons may orient themselves when examining a vector
coverage.

The USGS is in the process of updating their 1:24,000 scale Topographic Maps through the
use of Digital Orthophoto Quarter Quads (DOQQ). The DOQQs were created by the
rectification of photography acquired from the USDA‟s National Aerial Photography
Program. Unfortunately, coverage for the Bakersfield area to the 2010 boundary is not
complete. Of the 15 quadrangles covering the city only the eastern six have corresponding
digital orthophoto quads. At present, the Kern Council of Governments (KernCOG) is
working on creating a partnership with CALTRANs and other interested parties to
complete the County.

The USGS through its EROS Data Center makes available archived (1972 - 1992)
Multispectral Scanner (MSS) imagery from its LANDSAT Program for around $200 per
scene (170 km by 185 km). Another imagery source includes SPOT Image Corporation
which produces a number of imagery products including panchromatic, multispectral, and
merged imagery. Panchromatic imagery has a spatial resolution of 10 meters and
comprises a single black and white band. Multispectral imagery has a spatial resolution of
20 meters and is composed of three color bands. Merged imagery is a combination of the
two image types producing 10 meter color imagery. Satellite imagery has many uses
including: commercial and retail site selection, site engineering, urban/regional planning.


2.2.2 USGS Digital Elevation Models

A digital elevation model (DEM) is any digital representation of the continuous variation
or relief over space. The most common DEM is known as an altitude matrix which is a
regular rectangular grid of elevation data. The primary reason for incorporating DEM data
into the COBGIS is to effectively model the surface length of a road network. The surface
length will always be greater than or equal to the planimetric length of a road or arc. This is
because the surface length takes into account the variation in elevation as the line travels
along the surface. These variations increase the measured length of all lines that are not
flat. Although most of the city lies in relatively flat terrain, there are pockets of significant
relief especially in the northeast part of Bakersfield. The departments which would benefit
from the integration of this data set include Engineering, Fire, Solid Waste, Traffic
Engineering, and Water.

2.2.3 Core Data

Table 2.2.3 lists core data sets which are being or would be used by three or more
departments, in order of implementation priority.

Table 2.2.3: Core Data
Data Set Data Type

Street Centerlines Vector

Control Monuments Vector

Parcels Vector

THE Tabular

Sierra Permits Tabular

City Limits Vector

Township/Range and Sections Vector

2010 Boundary Vector

Ward Boundaries Vector

Railroad Centerlines Vector

Rivers Centerlines Vector

Canal Centerlines Vector

USGS Topographic Quadrangles Raster

USGS Digital Orthophoto Quarter Quadrangles Raster

USGS Digital Elevation Models Lattice

Although, control monuments, township/range and sections were not specifically


mentioned these data sets form the control for the COBGIS and so by default they are
considered core data sets.


3 System Design
3.1 Software Platform
3.1.1 Geographic Information System Software

The software vendor chosen to supply the City with GIS software is
Environmental Systems Research Institute (ESRI). Table 3.1.1 presents a distribution of
GIS products and their primary users. Professional users would work primarily with
ARC/INFO professional GIS, high to intermediate desktop users would use ArcView
products and low desktop users would have access to ArcView and ArcExplorer.
Appendix B contains a list of the different modules and their uses. In general, at least one
of each of the software products in Table 3.1.1 should be purchased. The only exception to
this is COGO for which three licenses are needed.

Table 3.1.1 Sample GIS Software
Software Price Price Primary User
(Primary) (Secondary)

ARC/INFO $20,000 $10,000 Professional
(ARC,ARCEDIT,ARCPLOT,DBI)

ArcStorm $3,000 $1,400 Professional

COGO $2,550 $1,400 Professional

GRID $2,550 $1,400 Professional

TIN $2,550 $1,400 Professional

NETWORK $2,550 $1,400 Professional

ArcScan $2,550 $1,400 Professional

ArcView $1,195 $1,195 High - Low Desktop

Network Analyst $1,495 $1,495 High - Intermediate Desktop

Spatial Analyst $2,495 $2,495 High - Intermediate Desktop

ArcExplorer Free Free Low Desktop

3.1.2 GIS Database Management with ArcStorm

ArcStorm is a software module designed to facilitate the storage and management of
geographic data which is accessed by multiple users. This software provides a method by
which data can be centrally located and made easily accessible to users. The principal
advantages of using ArcStorm are:

1) that it manages and coordinates the multiuser access to geographic data based
on features,

2) that it manages and coordinates edits on data residing in separate DBMS,


3) and that it has the capability of presenting the database as it existed at any point
in time since its creation.

ArcStorm features includes the followingiii:

1) Feature-level transactions - Since ArcStorm manages geographic data
at the feature level it does not prevent other users from editing features in
the same area.

2) Unified transactions - ArcStorm coordinates geographic or spatial
transactions and tabular or aspatial transactions. In this way a consistent
view of the database is always maintained.

3) Persistent locks on related records in external DBMSs - Once a user
begins a “transaction” process such as updating the spatial attributes of a
feature its related aspatial attributes are protected from other edits until the
transaction is complete. This also applies in reverse so aspatial edits
prevent edits on spatial data.

4) Recovery Mechanism - In the event that a failure of some sort occurs
(e.g., system failure, DBMS failure, power failure), ArcStorm has a
recovery mechanism that returns the database to its last consistent state.

5) Schema integrity - Limits use by unauthorized personnel to alter the
ArcStorm database.

6) Client/Server Architecture - Allows the general system-wide access to
data. Data may be accessed from anywhere on a system or network
without having to know the physical location of the database.

7) Schema flexibility - This feature refers to the ability of ArcStorm to
modify existing libraries, layers, and tables to be modified later as need or
parameters change.

8) Data distribution - Allows ArcStorm to handle large data sets
distributed throughout a system.

9) Direct browse access for clients - Allows ArcView, and ARC/INFO
users to browse the data without using ArcStorm servers.

10) An ArcStorm database consists of libraries containing spatial data and
optional DBMS tables.

3.1.3 Relational Database Management System Software (RDMS)

In a 1970 paper, E.F. Coddiv described the elements of a relational database to be:
relations, attributes, domains, and the relational operators. This paper also
described a RDMS as having the following characteristics:

1) Logical data independence: This desirable characteristic means that
changes made to an attribute - for example, an increase or decrease in size
- have no perceivable effect on other attributes for the same relation.


2) Referential and data integrity: Unlike other database systems, a
relational database would relieve the application software of the burden of
enforcing integrity constraints.

3) Ad hoc query: This would provide the user the capability to indicate
what data should be retrieved by the database without indicating how it
should be accomplished.

3.1.3.1 INFO

INFO is ARC‟s primary database management system. It is also a programming
language that helps store, maintain, manipulate and report information. However,
INFO is not a relational database management system and therefore lacks
referential and data integrity.

3.1.3.2 DB2
DB2 is IBM‟s relational database management system which is used in the City for
management of its HTE database. DB2 is not supported by ESRI under
ARC/INFO or ArcStorm and therefore access to data in DB2 would have to be
done through an Open Database Connectivity (ODBC) driver. Since ODBC is
simply a data extraction protocol for databases it provides no methods for
referential and data integrity. The RDMS supported by ESRI‟s ARC/INFO and
ArcStorm include INFORMIX, INGRES, ORACLE, and SYBASE.

3.1.3.3 ORACLE
ORACLE is already being used as the RDMS for the existing GIS. Since all of the
attribute tables for this GIS are already in the database all of which will be used in
one form or another in ARC/INFO it makes sense to use this platform as the
RDMS for ARC/INFO.

3.2 Hardware Platform

The platform chosen for the COBGIS should be able to handle CPU intensive and
extensive tasks. Two common measure of CPU performance are SPECfp and
SPECint. GIS processes are generally SPECfp intensive because the objects they
model exist in floating point space. That is, points, lines and polygons can
seldom be defined simply in terms of exact x and y integer coordinates, and curves
can never be defined in integer space. Thus, the platform of choice should have a
high SPECfp measure compared with SPECint. It is not uncommon to execute GIS
manipulations which can take 4 to 5 hours to complete on machines with poor
SPECfp.

ESRI bundles their software with popular GIS hardware platforms including Data
General, Digital Equipment Corporation, Hewlett Packard, Silicon Graphics and
Sun Microsystems. A bundle consists of a workstation and the following ESRI
modules: ARC, ARCEDIT, ARCPLOT and DBI. These bundled offerings can
produce software savings of $18,000 off the first ARC/INFO seat and $10,000 for
each additional seat.


3.3 GIS Standards

The implementation of a GIS in such a way that it is not just a mapping system or a
tool for solving complicated spatial queries but an intelligent system of related
layers which can be used for comprehensive master and environmental planning;
architecture, engineering, and construction, and installation facilities management
requires a design. This design exists and was created by The Tri-Services
Computer Aided Design (CAD)/GIS Technology Center which is developing
geographic information system, and CADD and drafting data standards in
cooperation with the federal Geographic Data Committee (FGDC).

The TSSDS were developed as a single comprehensive master and environmental
planning data model for Air Force, Army, and Navy installations, as well as Corps
of Engineers‟ civil works projects. The Spatial Data Standards were designed to
complement FGDC data standards that address small scale mapping (map scales
greater than 1:24,000) with graphic and attribute data standards for entities
depicted in large scale mapping (1 inch = 400 feet (1:4800) to 1 inch = 50 feet
(1:600)).

The organization of the GIS Spatial Data Standards is hierarchical and includes
Entity Sets, Entity Classes, Entity Types, Entities, Attribute Tables, and Domains.

Where Entity Set is defined as a thematic group such as transportation.

Where Entity Class is defined as a theme such as transportation_vehicle.

Where Entity Type is defined as one or more features such as road
centerline.

Where Entity is defined as a feature such as
trveh_primary_road_centerline_a.

Where Attribute Table is defined as a table containing data pertaining to a
particular Entity Type.

Where Domain is defined as a table containing all possible values for a
particular attribute.

3.4 Metadata Standards
One of the most important but often overlooked parts of a GIS implementation is
that of creating a data dictionary composed of metadata. Spatial metadata
describes the content, quality, condition, use limitations, and other characteristics
of a spatial data set. It also documents bibliographic information about a geo-data
set, such as who collected the data, when it was collected, how it was collected,
preprocessed, and converted, its resolution, who holds the data now, and so on.
Metadata is also referred to as additional information that is needed for a spatial
data set to be useful. Such information facilitates understanding of the data and its
content between the provider and the user. It helps users to ensure that a data set
meets their needs and that they use the data set appropriately.


The metadata standards to be used for creating the COBGIS Data Dictionary are
those developed by the Federal Geographic Data Committee (FGDC) in support of
the National Spatial Data Infrastructure (NSDI). These standards can be found in
Appendix C.


4 GIS Implementation Plan 1997-1998

The following section documents the proposed projects to be implemented during
the 1997-1998 fiscal year. The description and scheduling for projects to be
implemented are outlined in Table 4.

Table 4: Implementation Projects
Project Name Description

Street Centerlines Creation of an addressed street centerline coverage by Thomas
Brothers

Base Map Porting Including the importing of street centerlines, control monuments,
sections, parcels, city limits, 2010 boundary, ward boundaries,
railroad centerlines, river centerlines and canal centerlines.

COGO Parcels Continued COGO work.

APN Update The updating of APN for the Parcel coverage.

Linking HTE to Linking the data managed by HTE to the COBGIS.
ARC/INFO and ArcView

Linking „PERMITS‟ to Linking the data managed by „PERMITS‟ to the COBGIS.
ARC/INFO and ArcView

ArcStorm Implementation of ArcStorm to manage the COBGIS.

Image Classification Includes creation of historical city limit coverage, classification of
a satellite image and analysis.

Road Center Lines Verification and incorporation of Thomas Brother‟s Road Center
Line Coverage with the COBGIS.

4.1 Road Center Lines

Thomas Brothers will be assigning left and right addresses, beginning and ending
address, street name, street suffix, prefix and suffix directions to the COBGIS.

4.2 Base Map Porting
4.2.1 Road Center Lines
The road Center Line coverage will consist of a line coverage with section and
route subclasses. Additional work includes associating left and right beginning and
ending addresses to arc segments.

4.2.2 Control Monuments
At present, monuments are identified by their location, type, and accuracy in one
AutoCAD layer. The structure of the existing monument data set is as followsv:

The location and type have exclusive fields for these attributes but are also
tied to the main identification number (ID#). We adopted and expanded on


a system from the County surveyors office. The ID# is broken down into
four sections identifying location and type (separated by dashes) and a
unique three digit identifier (separated by a decimal). A typical ID# looks
like this 30-27-35-01.001. The 30-27-35 refers to the township, range, and
section of the monument the 01 refers to the monument type (in this case a
section corner) and the 001 is the unique identifier for the section the
monument falls within. Using this methodology up to 999 monuments can
be contained within any one section with a given monument type. The
most monuments found in any one section has been about 500
monuments. Monuments which fall on section lines are tied to the
northeast corner of the section. Therefore, a section corner monument is
always the northeast corner of the section described in the ID#, a
north/south 1/4 corner is always the north 1/4 corner monument and an
east/west 1/4 corner is always the east 1/4 corner.

4.2.2.1 Master Tic Coverage

This coverage consists of registration points that represent the location of points on
the Earth‟s surface based on known coordinates. The importance of a master tic
coverage stems from the difficulty of trying to retrofit tics to existing coverages,
this can be time consuming and introduces errors into the data. The master tic
coverage for the COBGIS will consist of established horizontal control
monuments that are first or second order stations (e.g., section corners) adjusted to
NAD83. The control points found in this coverage will also reside in a primary
control COGO point coverage.

4.2.2.2 Primary Control
This coverage consists of primary control points, secondary control points such as
3rd order or higher control points (e.g., quarter-section corners and field ties) in a
COGO point cover, and field ties.

4.2.3 Parcel
The data model for the parcel database will consist of three types of land records:
control, boundary, parcel. A number of other land polygons may be created such
as: right-of-way, flood zone, and school district.

4.2.3.1 Master Tic or Primary Control
This coverage has already been discussed above.

4.2.3.2 Control Ties or Secondary Control

This coverage has already been discussed above.

4.2.3.3 Boundaries.
This coverage consists of all land record objects which are delineated by
boundaries. The boundaries may be digitized lines or COGO entered data. In the
latter case it is desirable to keep the original measurements used to enter the data as
attributes with the line. Using this method it is possible to systematically update
the accuracy of the cadastre with new survey information.

4.2.3.4 Parcels and Land Properties


This coverage consists of polygon themes including parcel, easements,
right-of-way, administrative districts, and land-use are represented with the region
subclass. All region subclasses belong to the same coverage as the boundary
theme. They are sometimes referred to as vertically integrated data sets, meaning
that different region subclasses share common boundaries. Regions are used to
solve three issues in parcel management: overlapping areas, disjoint areas, and
aggregated areas. A overlapping area could be a condo complex, where you have
several owners on a single piece of land, or drainage and utility easements, which
overlap parcel ownership. Since region editing allows you to define multiple
regions on top of the same feature, you can have multiple records in a database
referring to the same parcel of land. A disjoint area could be a piece of land divided
by a road or a stream. A disjoint area needs to be treated as a single feature even
though it‟s composed of multiple features. Region editing allows you to combine
disjoint areas into a single feature, with a single record and area feature in the
database. A aggregated area could be a parcel made up of several lots. For
instance, a person may come into a new subdivision and purchase two lots to make
up their one parcel. Regions allow you to maintain both the lots and parcels in a
single coverage or layer. Through region editing, the parcel would become an
aggregate of the two original lots.

4.2.4 Township/Range and Sections
This data set will be stored as 16 Township/Range Regions each of these in turn
are composed of 36 section regions. The section regions will in turn be composed
of four 1/4 section polygons.

4.2.5 2010 Boundary
The 2010 Boundary will consist of a polygon coverage.

4.2.6 Ward Boundaries
The Ward Boundaries will consist of a polygon coverage.

4.2.7 Railroad Centerlines
The railroad centerline will consist of a line coverage.

4.2.8 River Centerline
The river centerline will consist of a line coverage.

4.2.9 Canal Centerline
The canal centerline will consist of a line coverage.

4.3 COGO Parcels

This project involves the continued COGOing of parcels using AutoCAD followed
by the transition to COGOing with ARC/INFO.

4.4 APN Update
A process has not been established for the timely update of Assessor Parcel
Numbers (APN). At present, Kern County Engineering and Surveying (ESS)
provides Planning/GIS with recorded maps, these are then used to COGO parcel


information into the database and assign APNs. APN‟s can only be assigned to
existing parcels that were created over one year ago. Newer parcels do not have
APN‟s assigned to them for approximately one year after creation. In addition,
parcels that are changed by either direct transfer, cuts, or combines cannot easily
be traced and corrected.

In order to resolve this problem the city will use County Fire‟s Parcel Centroid
Coverage which is updated annually. The goal is to update APNs in the COBGIS
by using data extracts from the County maintained Kern Integrated Property
System (KIPS). These extracts can be used to trace parcel history through time. Of
the 5 events mentioned direct transfers are the simplest to correct since this
involves a one to one relation. Combines are also simple to correct since these are
many to one relations which simply involves identifying the two polygons,
deleting their common arcs, and assigning the new APN. Cuts and creates present
a much more difficult problem because there is no way of identifying the new
polygon topology from the tabular data. However, an interim solution would be to
create a “Altered Parcels Table” and record an APN, an event code identify cuts,
CT, or creates, CR, and associated new polygon APNs. Parcel assigned a deletion
code, DL, could also be output to this file for interactive processing.

4.5 Linking HTE to ARC/INFO and ArcView
Since DB2 is not compatible with ARC/INFO the most efficient method for
relating these two databases is through an ODBC driver. IBM provides such a
solution with their Distributed Database Connection Services (DDCS) for
Windows NT which sells for approximately $3000 for five user licenses.

4.6 ArcStorm

This includes making a determination as to which layers will be managed by
ArcStorm, creating a tiling schema, loading the data into ArcStorm, and becoming
familiar with COGOing in this environment.

4.7 Linking ‘PERMITS’ to ARC/INFO and ArcView

Permits provides a computer based solution to track geo-based land management
and permit tracking information. The „PERMITS‟ system stores data from the
permit and activity tracking function in a relational database environment utilizing
standalone or networked PC‟s and/or UNIX machines.

Sierra‟s approach to linking GIS and their „PERMITS‟ database does not rely on
synchronizing data files and is more accurately described as a conduit approach to
pass necessary parameters between systems.

Sierra has defined this interface as the „PERMITS‟ TrueGIS link. In essence this
product links the relational database formats that are common to the permitting
and activity tracking functions of planning, building, public safety and community
development agencies with the spatial data formats that are found in ARC/INFO
and ArcView. This product sells for approximately $5,000.


4.8 Image Classification and Analysis
This project will be performed for Solid Waste and involves the determination of
which areas should be serviced by the City‟s Solid Waste Department and Solid
Waste Contractors.

4.8.1 City Limits
The city limits will be stored as several City Limit regions composed of earlier
annexation polygons.

4.8.2 Classification and Analysis
This project will involve the classification and analysis of a satellite image.

4.9 Street Centerlines
Verification and incorporation of Thomas Brothers Data into the COBGIS.

4.10 Implementation Time Lines
The following time line is an estimate of the approximate time it will take to
complete each of the above projects, as such, it is likely that some tasks will run
over and others will run short. Revised time lines will be issued when more data is
available.


5 Conclusion

At the very beginning of this implementation plan the data survey identified a
number of spatial data sets which were classified as core or departmental. The core
data sets were then ranked in order of implementation into the COBGIS and
include: street centerlines, control monuments, parcels, city limits,
township/range, 2010 boundary, ward boundaries, railroad centerlines, river
centerlines, and canal centerlines. The needs analysis provided an understanding
of each departments functionality and possible GIS projects including Thomas
Brother‟s addition of address data to our street centerline file, linking HTE and
“PERMITS‟, and the classification of a satellite image for Solid Waste.

The use of standards for the COBGIS model and metadata will result in a faster
development of these base layers. The use of the TSSDS standards assure that the
COBGIS will be an intelligent, expandable and flexible system.


Notes

i.David Dow, “GIS Implementation” (Planning Departmental Report, City of
Bakersfield, 1997), p. 3-4.

2.ESRI, “City of Salinas Tracks Youth Handguns and Crime with GIS,” ArcNews,
Vol. 18 No. 4 1997: 19.

iii.ESRI, “ArcStorm and Map Libraries” (1995), p. 1-5.

iv.E.F. Codd, “A Relational Model of Data for Large Shared Data Banks”
(Communications of the ACM, 1970).

v.David Dow, “Status and Background for GIS Project” (Planning Department
Memorandum, City of Bakersfield, January 1997).


The City of Bakersfield, CA GIS Implementation Plan (1997 - 1998)

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Similar to The City of Bakersfield, CA GIS Implementation Plan (1997 - 1998)

Similar to The City of Bakersfield, CA GIS Implementation Plan (1997 - 1998) (20)

Recently uploaded

Recently uploaded (20)

The City of Bakersfield, CA GIS Implementation Plan (1997 - 1998)