the city of bakersfield, ca gis implementation plan (1997 - 1998)

i

The City of Bakersfield

Geographic Information System Implementation Plan (1997 - 1998)

August 30, 2012 Prepared for City of Bakersfield by Juan Tobar Filename: P:\projects\1996\1996.1 Implementation Plan\report_main.wpd

ii

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

iii

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

City of Bakersfield GIS Implementation Plan 1

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


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

2.1.11.1 Data Survey

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 2.1.12.1 Data Survey

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

(Primary)

Price

(Secondary)

Primary User

ARC/INFO

(ARC,ARCEDIT,ARCPLOT,DBI)

$20,000

$10,000

Professional

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

ARC/INFO and ArcView

Linking the data managed by HTE to the COBGIS.

Linking „PERMITS‟ to ARC/INFO and ArcView

Linking the data managed by „PERMITS‟ to the COBGIS.

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)

Technology

data survey

needs analysis

core data

police department

public works wastewater

water resources department

community services parks

financial services