Conferences Hosted

1989 / 2007

Links

Kern County - home page

Assessor-Recorder - department web site; property search (roll info) and scanned assessor maps (free)

GIS online - interactive GIS mapping service

Mapping Staff

Stuff to Share

Our Story

Once upon a time, we had seven people in our map room, all using the now-primitive Rapidograph inkpens, straightedges, circle templates, lettering guides, and other high-precision gallimaufry that once were the standard tools of the trade, drafting our maps slowly yet artistically on vellum and mylar sheets. Then, one day in 1995, our department decided to install personal computers on the desks of all its employees for the first time. It was a sudden and sweeping change, with the promise of faster and easier workloads that required far fewer instances of having to get up out of our chairs and walk 50 feet to go look up some records once archived in file cabinets, on microfilm, or in some big dusty books with deteriorating hardcovers. Some employees were eager to explore these new technological tools, while others frowned upon them, firmly crossing their arms in front of their chests, going about stomping their feet and gnashing their teeth. Fortunately, the map room had several folks of the former variety who saw the glass half-full and embraced the winds of change that swept through the halls.

It was a slow and rocky start with these new machines. Each was a Dell Pentium Pro 200MHz, with 64MB of RAM (later upgraded to 128MB), a whopping 3GB hard drive, and a 21-inch monitor. The really fun and interesting part was that they had installed Windows NT 4.0 and OS/2 Warp in a dual-boot configuration. This was because our document imaging system was being designed with some IBM software components that would only run on OS/2 Warp (which also powered our local network server), while AutoCAD and certain other programs would only run on Windows. So, to draw a map in AutoCAD while following a deed description, we had to boot OS/2 and print out the deed, then reboot Windows to draw the map. It wasn't exactly the paperless office that we envisioned. But the problems didn't end there. Trying to configure AutoCAD release 13 and a printer in Windows NT 3.51 was an exercise in futility, a phenomenon that came to be known later as a process that involved (figuratively, mind you) the "swinging of dead cats" because of the voodoo-like rituals that were necessary to get all the software and hardware pieces to work together. Then there was the printer we purchased for $1300, only to have Epson abandon support for it when Windows NT upgraded to version 4.0, which was no longer compatible with older device drivers.

From about 1988 to 1993, we lost two mapping positions (permanently) as the budgets got tighter, leaving five mappers in a county with more than 375,000 land/surface parcels (over 15,000 map pages), at a time when Bakersfield was soon to become one of the fastest growing cities in the nation. So, we experienced staff shrinkage, but eventually gained some technology to help take up the slack. Interestingly, most people expect it to happen the other way around; that is, technology comes in and ends up resulting in fewer people being needed.

In the mid-to-late 1990's, we used AutoCAD Map exclusively, for drafting the Assessor maps on a sheet-by-sheet basis, so that each sheet was a separate DWG file. Then we obtained a single copy of ArcView 3.2 and began maintaining a shapefile of all the parcel polygons. This shapefile was originally created by the Merced County Association of Governments (in conjunction with the Kern Council of Governments), who scanned and digitized all of our paper maps during a 3-year project known as the Valley-Wide GIS Project (completed in 1998). It was a trade-off, because we had a loose sort of "agreement" wherein they could copy our maps and digitize the data and use it for their own planning purposes, and they bought us 5 copies of AutoCAD, so that we could take custody of the dataset and maintain it going forward. The entire project involved 8 contiguous counties in the San Joaquin Valley.

So in 2002 we began maintaining the shapefile as a separate dataset, in addition to our CAD drawings. In fact, the other mappers would first edit or create the CAD drawings, then export the changed or new polygons as shapefiles (thus our need for AutoCAD Map, rather than basic AutoCAD, for shapefile support). I would then take those shapefiles and insert them into the main shapefile, so as to maintain the seamless parcel fabric. After a few years, it became obvious that this arrangement with two disparate datasets was just terribly inefficient. Also, since we were working with shapefiles, our precious data was unable to contain any true circular arcs. That's when we started looking into the possibility/feasibility of using ArcGIS to store the parcel fabric AND publish the Assessor map sheets.

We visited two other counties -- Santa Cruz and Los Angeles -- to see how they were working with ArcGIS. It seemed to us that both counties were doing some pretty fantastic things with the software, although we brainstormed some pretty ambitious modifications to their designs. Once we became convinced that our vision was at least a possibility, we made the pitch to our fearless leaders that we should purchase ArcGIS. We ended up purchasing 1 ArcInfo and 4 ArcEditor licenses with annual maintenance. We have since lost one more mapping position to budget cuts, so we're down to 4 mappers. We also canceled our AutoCAD maintenance subscription, so we last received upgrades for AutoCAD Map 2007, although we actually still use AutoCAD Map 2004 (because we didn't like certain program changes that Autodesk made after that).

Our use of AutoCAD was demoted to coordinate geometry (COGO) data construction and editing of simple primitive lines and arcs (drawn on layer 0), which are then copied into the geodatabase. It is still much easier and faster to use AutoCAD for COGO and other data construction techniques; it's just too clunky and time-consuming to do it in ArcMap (although it can be done). We also use AutoCAD if we need to edit an existing CAD drawing (in heavy workload scenarios when we don't have enough time to convert it entirely into the new system). Technically, we're not actually "converting" drawings, we're re-creating them almost from scratch, since we're starting from the existing parcel fabric. Because of the reduced role of AutoCAD in the process (i.e., we no longer need any of the fancy new features, just the ability to draw lines and arcs really fast and accurate) we figured we could do without the yearly upgrades, at least until someday when we get a version of Windows (newer than XP) that no longer supports it. Then we'll try to make a case for upgrades, if ArcMap hasn't sufficiently improved its drafting capabilities by then.

Our new GIS-based mapping system is now fully capable of storing a single dataset that can also support the publication of the official Assessor map sheets. This system was demonstrated at the 2009 CCMA conference in Los Angeles. It employs design elements and techniques that may be rather unique, in that no other county is doing anything exactly like it. For instance, our data is modeled almost entirely with lines and points, rather than polygons. Polygons are periodically generated as distinct datasets, as often as we need them. Also, we do not store ANY map sheets as files (i.e., MXD files), because the system is designed around a "master template" file and a standalone table that can generate map sheet layouts on demand. These features (among many others) are accomplished with a fair amount of custom programming (a Visual Basic .NET Add-In). The parcel generation process involves quite a few ModelBuilder models (scripts) that are designed to help clean up errors in the data.