The development of the City of Bakersfield's digital cadastre system exemplifies some of the more common policies and methods which local governments use to implement their cadastre systems. It is the purpose of this paper to describe these policies and procedures where they work and where they do not in order to further those efforts of other local governments developing their own digital cadastre systems.
Juan Tobar, Bob Amos, and Creighton Magers
It was natural for GIS to develop under the Planning Department for the following reasons: the City's first GIS Champion was also the Developmental Services Director, the most competent and enthusiastic person to implement the system was an associate planner, and in its early stages no one understood the potential of GIS like the Planning Department. The City of Bakersfield's digital Cadastre database can trace its lineage to the efforts of the Developmental Services Director who initiated the creation of a GIS Needs Assessment Report in 1988. This report described twenty-two GIS applications divided into five categories of which 18 applications necessitated a mature digital cadastre system. (See Table 1.0)
Table 1.0 - Application Necessitating a Mature Digital Cadastre
| CATEGORIES | APPLICATIONS |
| Processing Cases | Case tracking Generating mailing lists for notifications Generating maps for notifications Creating display maps for specific cases Historical research Infrastructure analysis Identifying specific mitigations or moratoriums |
| Public Assistance and Convenience | One stop permit center - Central Data Source for quick access to inquiries Specific reports available to appraisers, & developers Targeting potential areas for future development |
| Budget and Quarterly Reporting | Creating customized reports for budget activities Generate data for use with free determination |
| Special Mapping Requirements | Availability of multiple scale maps Ward Reapportionment Custom map design/overlays through control of layers |
| Special Reports | Demographic and statistical summaries for specific areas Status reports for a given area Notification maps and lists for various public hearings Total arterial lane or street mileage installed between dates Total feet of sewers by size or material installed between dates Total number of traffic signals the last 10 years with bar graph Traffic accident history for intersections Other report combinations as need arises |
The following year, a task force of staff from six departments proposed purchasing GIS software with funds approaching $55,000. It was also determined that the Planning Department would spearhead the creation of the layers which would form part of the City's GIS. The deciding factors in software selection where as follows:
Lower hardware and software cost than other GIS configurations;
The hardware could be used with other software already available within the City;
The program uses AutoCAD as its "graphic engine" which is a program already widely used by Engineering Staff;
The software is an open architecture design which will allow implementation of third party software as need arises;
The system is very flexible and customizable to our needs;
The systems use and learning curve are probably easier than other systems explored because it uses a user interface already familiar to many of the steering committee members.
With the software in place the Planning Department began work on the "Pilot Project" in 1990. This involved the collection of record parcels, assessor parcels, street features (including utility locations, right of way, curb, gutter, etc.), hazardous material locations, permit activity, zoning, and land-use. This continued until 1993 by which time the "Pilot Project" had evolved into a "Base Map Project" with its main objective the creation of a digital cadastre.
Four issues affecting the future of GIS had become apparent by 1995. With regards to information technology prior to 1995 the City of Bakersfield was a decentralized PRIME/DOS operation and second departments would budget money for software and equipment and the Data Processing Department would normally ruber stamp these requests as long as they remained true to the PRIME/DOS philosophy. The Data Processing Department was restructured into a new Management Information Services Department in 1995 and a vigorous schedule of centralization and technology upgrades began. These efforts where funded by software/hardware rental fees which are charged on a yearly basis to each department by MIS.
With regards to GIS management the two issues where: first, that the GIS Division had always lacked the ability to respond as a service department because it was shielded from non-planning request by management; and second, since the purchase of GIS hardware and software in 1989 there had been no significant change in the software which would allow it to be easily distributed to other desktops without a high learning curve and expense. Thus, in 1997 GIS was transferred from Planning to MIS and GIS's goals was defined as follows.
The role of the Geographic Information Services Division is to advance and promote the use of GIS within the City, to represent the City's GIS interests to outside agencies, and to facilitate the access by the public to the City's spatial data.
In order to advance the use of GIS the GIS Division has the following primary roles:
1) identifying and proposing which hardware/software solutions the City should implement to solve GIS issues;
2) serve as the City's spatial data repository and
3) serve as GIS liaisons to Department lacking their own
expertise.
In order to promote the use of GIS the GIS Division advances the position of a GIS on every desktop and a GIS liaison in each division. The GIS Division also promotes the use of GIS by providing GIS educational resources to City employees.
In order to represent the City's GIS interests to outside agencies members of The GIS Division are present at a number of GIS organization including the California Geographic Information Association (CGIA), and the Kern Chapter of the Urban and Regional Information System Association (URISA).
In order to facilitate the access by the public to the City's spatial data the GIS Division maintains a GIS Web site where public access to spatial data is granted.
The Needs Analysis of the 1997 - 1998 GIS Implementation Plan itemized the digital cadastre needs as follows.
There was a need to reduce the cost of distributing access to the digital cadastre. A typical workstation for the Professional GIS staff under planning consisted of a 486MHZ machine running AutoCAD, GEO/SQL, and ORACLE. Although this software had performed effectively the combined cost and steep learning curve made it impractical as a Desktop GIS. The solution which was recommended was to switch to ARC/INFO and ArcView GIS.
There was a need for complete coverage of the City. The Planning Department had now been working on the digital cadastre for seven years and many projects and applications which where in need of this data could not be implemented for lack of parcel coverage which by 1997 was at 60%. The solution it was determined was to merge our highly accurate COGOed work with the efforts of the Valley Wide GIS which had digitized cadastre maps for the entire San Joaquin Valley but was spatially highly inaccurate.
There was a need for the internal structure of the data to be transparent to the user. At this time, the digital cadastre was divided up into approximately 400 section with no easy way to display them all or do analysis on them as a whole. The solution was determined to be to migrate to a more robust storage mechanism such as LIBRARIAN or ARCSTORM.
There was also a need to preserve more of the COGOed attributes which up to this point where not being preserved. These attributes included items like bearings, radial, distance, and lot area. This would be resolved by using ARC/INFO's COGO module which automatically preserves this information.
One of the first problems we encountered was that of the same polyline boundary being defined in multiple layers. For example, in the old system technicians would enter a tract map polyline boundary in one layer and then use the same polyline in another layer to create lot polyline boundaries. This would not have been a problem except that each of these boundaries occupied different locations and although the positional difference of these lines was in most cases less than .02 it was still a very inefficient way of representing these land records. Our new topological schema consists of a cover known as Cadastral Real-estate Boundary (CDRELBND) which consists of a polygon cover which represents all legal boundaries and is the polygon base from which all other region boundaries are created. These regions include lot polygons, tract map record boundaries, and parcel map record boundaries.
In ARC/INFO the hierarchy of geographic objects consists of points, arcs, polygons and regions. A region is a coverage feature class used to represent a spatial feature as one or more polygons. Many regions can be defined in a single coverage and regions have attributes (PAT) that describe the geographic feature they represent. Regions in land records are used to solve three issues in parcel management: 1) overlapping areas, 2) disjoint areas, and 3) 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 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 aggregate 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.
A second problem we encountered was that of attribute errors. In the old system two "unique" numbers were assigned to each parcel an Assessor Parcel Number (APN) and a Personal Identification Number PIN. The APN is assigned by the Kern County Assessor while the PIN is assigned by GIS staff. The PIN is necessary because in some instances the assessor will not create an APN until after a map has been COGOed into the GIS . The unique key for each parcel in the old system consisted of a unique APN-PIN combination. Unfortunately, the uniqueness of each APN and PIN in and of themselves was never subjected to much scrutiny and this resulted in multiple invalid APNs and PINs. Similar errors in data entry have resulted in incorrect lot numbers, addresses, tract map numbers and parcel map numbers.
Additional errors crop up when deeds are drawn up without going through the proper procedures. For example, sometimes multiple adjacent lots are combined at the request of the owner by the assessor, sometimes larger parcels are given more than one APN because of a change in school district or mid-section lines. The California Subdivision Map Act of 1982 has alleviated many of these procedural errors. The act states that any land alterations or divisions need to have either a Parcel Map, Tract Map or a Certificate of Compliance via a Parcel Map Waiver or Lot Line Adjustment. However, we still have to deal with all those pre-1982 maps where changes are not documented properly and it can be extremely time consuming to find the correct geometry within the recorded maps.
With 28,000 parcels checked we determined that 1,863 of these parcels had erroneous information which is an error rate of about 6.63%. As far as PINs, we decided to use the x and y state plane coordinate of the centroid of each parcel. This ID was chosen because it is always unique, it is easy to calculate, and it can be used to select the parcel in question.
The next procedure involved the merging of about 400 sections into ten township/range covers which where later merged into one contiguous Cadastre Real-estate (CDRELBND) coverage.
One of the advantages of using Esri's COGO module is that it preserves COGO attributes ( meets and bounds ) which are needed in order to duplicate the actual Tract and Parcel maps in digital form. The old GIS software was not configured to store this information and although these attributes could be generated from the existing line work the following problems made this impractical. First, the procedure for generating these attributes, a command known as COGOINV destroys region topology. Second, these generated COGO attributes will not coincide with the actual meets and bounds as shown on the recorded maps. This is because in the process of COGOing a closed traverse (such as a tract map boundary) the beginning and ending points which should be in the same location seldom coincide with 100% accuracy. It is standard procedure for these "closing errors" to be evenly distributed along the entire length of the traverse which in so doing changes the COGO data originally entered. Thus, if the original COGOed data is not captured while COGOing it is lost.
As stated in the Implementation Plan the City had been waiting for a completed digital cadastre since 1990 and by 1997 the project was 60% complete. Thus, in 1998 the Valley Wide Digital Cadastre for the San Joaquin Valley was converted to a common coordinate system and its accuracy compared to some of the COGOed data. This visual comparison of the Valley Wide and COGOed parcels revealed that the spatial uncertainty can range up to +/- 45 feet. On average, it appears that most parcels are within +/- 15 feet of their correct position. Nevertheless, a contiguous parcel coverage is needed if for nothing else to show approximate property lines. A contiguous parcel base is also needed in order to link Sierra Permits and HTE with a parcel base which when queried can find a user specified APN at least 90% of the time (to be determined). Thus, although we will have a completed parcel base map the inaccurate data needs to be replaced as soon as possible with COGOed data. This is likely to take at least one more year but no more than two.
GIS operations can be very computationally intensive and this was certainly the case for the procedure we followed to incorporate the Valley Wide Parcel database with the COGOed parcel database. In preparation for joining these two data sets it was necessary to take the Valley Wide's 50,000 parcels, make them into regions and assign a unique PIN. This procedure took five days of continuous processing on a 200MHZ machine.
The next task was to develop a COGOing procedure. Some of the requirements of this algorithm included the ability to preserves bearings, distances, area, curve data, radial curve data and lot numbers as displayed on the original recorded map. Bearings and distances are keyed in to create the original line work and are preserved even after distributing the closing error. The area is also keyed in because letting the GIS generate this measure has the potential of generating different result than in the recorded map. References to curves (C1, C2, C3...) and radial lines (R1, R2, R3...) are maintained and actually link to the actual COGO attributes. APN and addresses are recorded as annotation, and the annotation is intelligent in that once the annotation is in the correct location we do not have to edit the annotation to make changes to it. This is because annotation is directly linked to our database in this way a change in the database will be immediately be reflected in the annotation. The City's COGOing algorithm can be found in Appendix A.
After reviewing the different storage solutions for our digital cadastre it was decided to attempt to implement 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 two ArcStorm features which where of most importance to the City was the ability to perform feature based checkouts instead of tile based checkouts, and the ability to record the history of the digital cadastre.
Unfortunately, we found that with our existing hardware ArcStorm would not function correctly. It was suggested by Esri that a good configuration for a ArcStorm server would include:
a. Second Processor - We have noticed that our 400MHZ IBM IntelliStation is at 100% CPU usage for extended periods during CHECKOUT and CHECKIN operations. Esri recommends an additional CPU to handle edits from 3 users and queries from other users. It was actually recommended that as a rule of thumb a 1 processor per CHECKIN/CHECKOUT user night be necessary.
b. 256 MB RAM - Esri stated all operations would be improved by this additional resource. They stated one of there clients is running a 350 MHz box with 1 GB of memory.
c. Additional Physical Disks - Esri stated that having another physical disk would remove much of the contention for a single disks resources possibly reducing disconnects.
Due to the above reasons we where not able to implement ArcStorm but instead implemented Esri's older LIBRARIAN technology.
LIBRARIAN was Esri first approach to management of large data sets and as such has had most of the programming bugs eliminated. It should be much easier to setup and maintain than ArcStorm but will note have the ability to do feature level transactions. This means that instead of checking out only the features you need LIBRARIAN checks out entire tiles. LIBRARIAN will also not have the historical facilities of ArcStorm, that is, the ability to dial back the database to an earlier point in time.
LIBRARIAN requires an index cover which defines the positions of the tile boundaries and is used by LIBRARIAN to breakup the digital cadastre into smaller coverages. Our tiling structure for the City's digital cadastre was created to reduce the number of split
parcels, tract and parcel maps.
On December 22, 1998, eight years after the "Pilot Project:" was begun the GIS Division finished loading the parcel base into LIBRARIAN and for the first time the City had a digital cadastre base providing 100% coverage of Bakersfield which was accessible by users through simple mouse commands from an ArcView screen.
It is common for local government implementations to evolve into enterprise GIS implementations. This was certainly true in Bakersfield where a "Pilot Project" eventually lead to a centralized and official GIS Division. This had the effect of changing GIS from a Planning Department support group to a city wide Geographic Information Services Division.
Using non-industry standard hardware and software ultimately will lead to disaster. Keep your options open by having the ability to switch to different operating platforms and software as technology changes. In our own implementation software was purchased in 1988 which was a AUTOCAD/ORACLE GIS hybrid. It is arguable that even as early as 1988 this may not have been a GIS Standard but considering the market in those years one can hardly fault the City for its original choice. However, the fact that their was no technology shift after 1992 when the market was much more defined was an error.
Make sure to establish regular backup procedures for all in house data. A disk crash is inevitable sooner or later. You don't want to have to explain why several months of data input have been lost. In early 1998 a winter storm cut power to the City's computer systems and we were unable to reboot the GIS server do to a hard disk crash. A restore from tape effort was initiated which revealed that all of the City's data including the GIS Server where, indeed, however all file and directory names where truncated to eight characters. In order to rectify this problem, the damaged drive had to be sent out to be salvaged at a cost of $5,000 and two months of down time. Our current GIS server is running RAID 5 and is consistently backed up.
Make sure you know the consequences of conversion procedures. A sample data set should be used to explore the consequences of a complete conversion not simply each conversion operation in isolation. In the conversion of our own cadastre data our first step was the conversion of DXF files to coverages. We first converted one section of data by exporting all layers into a boundary coverage which was then cleaned and built. A visual examination of the resultant coverage at scales as large as 1:300 found no inconsistencies, that is, topologically and spatially the data looked correct. Based on this examination we converted the rest of the 400 cadastre sections using the same procedures. It was only when we began merging sections that we found that many of our boundaries contained sliver polygons. These sliver polygons had been created when the exported CAD line work had duplicate linear representations. The reason these errors where not detected earlier was because they did not occur in all sections. In the sections in which they did occur the sliver polygons had widths of less .02 feet, and lastly, we did not notice the additional polygons in the description of the coverage. This presented a major inconvenience which was solved in most cases just by re-cleaning at a higher fuzzy tolerance, nevertheless, it resulted in a degradation in our spatial accuracy.
Think evolution not revolution when installing and configuring your system. Long-term GIS success necessitates an evolutionary approach to GIS system planning and development. In regards to our digital cadastre once all of our sections where compiled into one massive coverage we tried to implement the newly released ArcStorm for Windows NT as our cadastre storage technology. We were unable to get this technology to to function correctly with our hardware/software combination and we also lost several months worth of work in the process. The ultimate solution was to implement LIBRARIAN which became functional in a matter of days. The City is returning to the implementation of ArcStorm, because unlike ArcStorm LIBRARIAN does not keep a history of all Cadastral data changes. Fortunately, since LIBRARIAN continues to be a reliable component we can take more time in developing a better ArcStorm implementation plan.
While developing a digital cadastral model, be sure to identify the needs of the end users to the appropriate administration. Currently, here at the City of Bakersfield, the GIS professionals have been plagued with the slow growth of network technologies. For example, some of the individuals using the cadastral database, currently are connected to the Local Area Network via 10mb Ethernet cards. This poses a huge problem when trying to illustrates the benefits of using such digital geographic information, because at times it takes longer for the data to display on the users screens than it would take them to go retrieve the information using a more manual process. Therefore, it is critical to explain to the current administration that continuous computer and networking technologies need to be expanded and updated in concurrence with the level of geographical data that becomes available. Without such a commitment it becomes very difficult to convince individuals within the organization that using such geographical information can save them time and money.
Another major concern for most expanding GIS departments is the issue of training of not only the GIS professional but also other end users, as well. Again, getting the administration to appropriate monies toward such training is a very critical component to the success of any GIS department. Maintaining appropriate levels of education adds to the overall efficiency of the GIS shop, and also allows end users to better understand the overall benefits and capabilities of GIS's. Hence, the administration will not only see the benefits of training within the GIS department, it may begin to see such benefits at a more macro level as different departmental users become less GIS newbies and more like power users.
Lastly, it is important to have as many employees as is needed in order to complete a GIS project in a timely fashion. It can be argued rather reasonably that 7 years is too long to wait for a digital cadastre system. The problem in local government is that small increases in the yearly budget are much more easy to pass through council than large appropriations. Municipalities should strongly consider the option of out sourcing this type of data collection allowing municipal GIS Divisions to concentrate on application development rather than data capture.
The City of Bakersfield's GIS department has been using ARC COGO (coordinate geometry) to create and maintain a highly accurate digital cadastral database system. COGO provides a way to record and keep track of the original legal descriptions of line work. Thus, when the creation of an accurate parcel map base is critical, COGO contains the necessary tools to create and maintain such geographical information. The following discussion presents the various levels of implementation used in the development of the City's digital cadastral database model.
The first step to integrating COGO into the geographical operations of a GIS department is to determine your data source monitors. For example, the City of Bakersfield's GIS department collects the official recorded tract maps of future and past developments from the Public Works Engineering Department. However, such public documents are usually housed and maintained by the County's Hall of Records, as well.
After the recorded tract maps have been collected, the GIS professionals then scan and register each of the digital images. Scanning each document helps in the citywide distribution of recorded tract map information. i.e., instead of each department having to collect and pay for their own paper versions, each department can have access to one central data repository server which houses all of the digital tract map images. Next, each map is COGOed using the very line work bearings depicted. This type of procedure not only produces an extremely accurate parcel map layer, the digital data can also be used by public surveyors and engineers.
COGO also provides the users with an additional quality control step. The City's GIS department, requires that line work COGOed using the traverse method should be no more than one foot off from the original recorded line work. Maintaining such a degree of accuracy helps to identify errors that were overlooked during the original drawings of the tract maps. As errors are identified they should be reported to the civil engineers who can take the appropriate actions in having the original map redrawn and recorded.
In addition to maintaining a high level of line accuracy, georeferencing of the COGOed line work also is an extremely critical component in the building of an accurate cadastral database. Each tract map needs to be as close to its real world coordinates as possible. The City of Bakersfield's GIS department uses the State Plane projection model for most of its geographical data.
Before COGOing in a tract map, the nearest major monument point should be located. A monument is a known point determined by surveyors. Once the monument has been located. The next step is to collect the bearing information for the line work that can be used to draw from the monument to the starting point of the current tract that needs to be COGOed. Such a procedure seems to be laborious at times, but it helps to keep each tract as georeferenced as possible. It also points out errors in existing line work that may not have been otherwise caught.
Having found the appropriate starting point the tract(s) can then be drawn. Once the line work has been digitally recorded, the regions tied to the line work must then be created. For instance, the GIS department of the City of Bakersfield keeps track of three major feature sub classes. These consist of the assessor lots, and tract and parcel map regions. Within the lot regions, items such as addresses and lot number id's are recorded. In addition, each line work COGOed is labeled using the stored COGO attribute data. The process of creating annotation labels for each tract is done through a series of ArcInfo commands. The following section further discusses the procedures mentioned above and how they can be applied to a real life working COGO model. The COGO Process:
A. The collection of scanned maps is one of the most important aspects of building a cadastre database. By having the map images on your desktop and ready to use, you greatly reduce time needed to complete digital cadaster procedures in the COGO process. The images will also help enhance how people view the creation of a cadastre system by giving end users immediate access to the data on the images through any type of application that can view and print images without having to have GIS software. This greatly reduces the anxiety and fear that may inhibit or even doom the creation of a digital cadastre database.
B. Maps to be scanned should be appropriated as close to the source of the maps as possible. Currently, we receive tracts from the Public Works Engineering Department, however we are in the process of getting copies directly from the County's Hall of Records. This switch is crucial because as much as 30% of the maps that we receive are not completely legible. By receiving maps straight from the Hall of Records we will increase the legibility of the maps.
C. The maps needed will depend on what you are planning to COGO. Essentially a map can be used as the background for line work to be drawn. This will help correct drawing errors as they occur during the COGOing process.
D. Examples of maps that we currently COGO are listed below:
1. Address maps
2. Tract maps
3. Parcel maps
4. Annexation maps --These usually are received with a sample map and a legal description
5. Lot Line Adjustment maps
6. Parcel Map Waiver maps
7. Record of Survey maps
8. Utility composition maps
A. After receiving the paper versions of the listed maps they are then scanned and then stored on a central data repository server. This helps to increase the citywide distribution of such data.
1. Our default settings are:
a. Format = tifg4 compressed image
b. Resolution = 800
c. Variability = max
A. The ArcInfo REGISTER command is used to georeference the digital image with its COGOed line work. An image can be registered using the road file, the parcel file, or any other file that contains features that are contained in the image. Our preference is to use the parcel file from the cadastre database because it contains the most accurate line work. The steps below show the process of registering an image.
1. Make sure both files are in the directory
2. Register 05905-1-02 cdrelbnd
a. You now have 3 windows open
Overlay = the large window on the left that you will be using the most
Image = the image you are rectifying
Coverage = The cover that you will be using to register the image to.
b. First, The image box
1. The mouse, put the pointer over the bottom right corner and hold down the LEFT mouse button, then without letting up on the button, move the box to the area you want to view, then let go of the mouse button. Now hold down the right mouse button and pull the corner out to enlarge the box. Using these buttons, open the box so that the entire image is within the box.
c. Now the coverage box
1. Using the same procedures as in the image box, move the box so that area highlighted in the coverage box is the same as the area in the image box.
d. The OverLay box
1. The Overlay box is where the 2 areas will be shown. Go to the toolbar and click on VIEW and then REDRAW OVERLAY CANVASS. This will draw the areas you have
highlighted. On top of each other. Your first time view will probably look very disoreintating but after an few times will become clearer.
e. THE STEPS
REMEMBER, YOU ARE REGISTERING THE IMAGE TO A COVER AND NOT THE COVER TO THE IMAGE.
1. Select a point on the image and left click on it and then select the same point in the cover and left click on it. A line should have appeared connecting the two points. If it is off, you should
right click and this will delete the last line drawn. If you make a mistake then just close the register window and start over. Continue matching up points until you have the 4 corners and some others, 7 to 9 points work good. If you have to zoom in, just shrink the box's in both the image and cover box to the same area and choose redraw overlay each time. After you have the points then click on view and then LINK ACTIONS.
f. The LINK ACTIONS box will appear
1. Be careful here, due to the different commands that you have to choose and the problems with this application, simple errors can be ruin your work up to this point. Hopefully this application can be updated by Esri in the future to make it more user friendly.
2. First click on REGISTER
a. This brings up the register box which shows you a list of the points you have selected and the actual distances that the program found. You should not accept any distances over one foot due to the distortion this causes. You can delete a link by typing the link-id number into the delete box and hitting enter. This may help the other links and it might not. If you have to high of distances then you should go back and try again. If you accept the distances then click done.
b. This brings the link actions box back up. Here you first check the lock image check box, then the REDRAW OVERLAY button. If your image lines up with the cover then click on the SAVE TRANSFORMATION button and then look for the little box which asks if you really want to save the image and click OK. And then close the register window.
Caution: By moving the image around to look at the registered image you may change the world file you just created. I have done this many times and after moving things around and then saving the image, I have deleted the world file and re-registered the image because it was not as good as it could be. To prevent problems and in the essence of time I have only clicked on the commands above. I usually have very good luck and this process makes the next one bearable.
3. You now have created a world file with the same name as the image but with an extension of (TFW). These two files must stay together in the same directory to work properly. The world file has the spatial reference for the image, so without it the image does not contain the correct projection information.
A. The rectify command will allow you to see the image in ARC INFO if the registered image was rotated even by the slightest degree. This command can sometimes take a lengthy amount of time to process.
1. The command used is:
RECTIFY 05905-1-02 05905-1-02R
Where 05905-1-02 is the image file to rectify and 05905-1-02R is the resulting image after the rectify process. Rectify will rotate the image so that ARCINFO will be able to display the image without having to rotate it on the fly. You must still keep the image file and the world file together and also you must copy the files out together. Do not just grab the world file and copy it into the directory with the original image file.
A. The directory should contain the parcel file (CDRELBND), Roadfile (TRVEHRCL), CDPLSSEA, or one of the 1/4 or smaller township file, and a COGOpoint file. The COGOpoint file is where the COGO application will store the cogo points as you draw the line work. This file can be used over and over again and can be deleted and recreated at will. The rectified image should also be copied into the Info workspace so that it can be used as a background image. This will enable the user to see the bearing information of the line work being COGOed, and if any of the line work is incorrectly drawn it will be noticed as it occurs. The following syntax specifies how to create a COGOpoint coverage:
Arc: createcogo cogopoint <cover>
For example, in order to create a COGOpoint coverage titled PTS the following command is used. Arc: createcogo cogopoint pts
The following syntax shows how to set ArcInfo COGO Environment.
A. ARC
&WORKSPACE E:\PROJECTS\COGO\T5684-2
LW
LC
AE
COGOENV T5684 POINTS = draws the cover and point file
BACKC CDPLSSEA14CI 2 = draws the township and range sections in red lines
BACKE POLY
DRAW
BACKC TRVEHRCL41CA 19 = draws the road network dotted green lines
BACKE ARCS
DRAW
IMAGE T5684 TRANSPARENT 4 = draws the image in blue lines
IMAGE ALL ON
DRAW
DRAWE NODE ERROR = Draws the nodes that do not close in green (VERY HELPFUL)
NODECOLOR DANGLE GREEN
DRAW
Georeferencing Line Work
Now that the COGO environment has been set the actual practice of COGOing line work can begin. As mentioned, before COGOing a complete tract map region, it is a good idea to try and find a nearby recorded monument point. Having found the monument point, next draw in the line work from the monument point to the starting point of the line work that is going to be added to the COGO_arc_cover. Again, this will help to accurately georeference the line work.
Another georeferencing technique that can be used in place of starting from an existing monument point is to use the Arc TRANSFORM command. For example, a cover can be created to contain just the COGOed in line work. Once all the line work has been COGOed, the transform command can be used to georeference the arcs. In order, to get the transform command to work both covers must contain the same tics and it is imperative that they are chosen in the same order. To add tic points to a cover use the Arcedit ADD command. This command makes it possible to define the specific tics that are needed to georeference the line work. After the arcs have been georeferenced, use the Arcedit PUT command to add the arcs to the appropriate coverage. The actual syntax for the transform command will be discussed in section 14 of this document.
In addition, before any existing line work is deleted from the working coverage be sure to check that there is not any existing regions tied to the arc(s). When an arc is deleted that was tied to an existing region the region is now completely destroyed and in some cases this may corrupt the entire Info coverage. Thus, before an arc is to be deleted from the coverage, each region tied to it should be recorded using a procedure that will allow for easy recreation.
Currently, the City of Bakersfield's GIS professionals use a method of not only taking a print screen picture of each region before it is deleted, but they also copy out any of the recorded attribute data that may be associated with the region, as well. For example, before the selected region is deleted the image is pasted into an imaging software program using the print screen method. This gives the professional a copy of the actual polygons that make up the region. Additionally, the attribute information is listed on the screen and then copy and pasted into a text editor. Once these two steps have been completed the region is then and only then deleted form the current working coverage.
The procedure discussed above allows the GIS professional to accurately recreate any deleted region that may need to be recreated after the COGOed line work has been added to the cover. This procedure also helps to keep tract of any region history that might be associated with a particular coverage. Note, making continuous copies of the current coverage being worked in can also save valuable time and money. At any time during the COGOing process the working coverage can become corrupted and by having numerous backups of the different changes made to the cover can help the GIS professional from having to start from square one after a coverage becomes unrestoreable.
COGO Line Work
To begin COGOing line work, the user can use the Arcedit TRAVERSE OPEN and TRAVERSE CLOSED commands. When using the TRAVERSE OPEN command a starting point needs to be identified. For example, TRAVERSE OPEN is used when COGOing from a monument point to the beginning point of the line work needing to be COGOed. A downside to using this command is that it will not identify how far off the line work is in relation to where the finishing point should be located and it does not store any COGO attribute data.
The TRAVERSE CLOSED command requires the selection of a beginning and closing point (tie point). Once the line work has been COGOed this command will identify how far off the line work was from closing to the specified tie point. If the closure error rate is acceptable–less than 1 foot for highly accurate COGO drawings–then an adjustment can be performed. For example, the Arcedit TRAVERSE ADJUST COMPASS command can be used. Note, that all closed traverses should be adjusted before doing any sort of line editing, such as proportion.
COMPASS indicates that the compass-rule adjustment will be applied to the last entered traverse. Basically, the closer rate error will be applied to each of the arcs contained in the traverse, which will adjust them to their new locations. This adjustment option is one of the most frequently used when there are TRAVERSE CLOSED error closures.
In addition, if line work data contains such things as Public Utility Easements (PUE's), they can either be COGOed in or the Arcedit WIDEN LINE command can be used to add them to the COGOed line work. Step 7 will discuss the CLEAN and BUILD ArcInfo commands.
A. The clean command will:
1. Put a node at every arc intersection
2. Snap lines together depending on your snap tolerances
B. Do not use the clean command if you are creating a road network file because it will connect all arcs where they intersect. This could be disastrous to a road network where bridges, overpasses, tunnels, etc that cross over or under each other but do not actually connect. A build line command can be used to update the AAT feature attribute table for the arcs. Note, make sure not to use the build polygon command.
The regions are created from polygons only .
EDITF POLY
SEL or SEL MANY or SEL BOX or SEL POLY
MAKEREGION CDRELPAR
****************************************************************
This process will create the region cdrelpar by choosing each polgon and
and using the command MAKEREGION CDRELPAR to essentially put the
poly into the region cdrelpar. This must be completed before you can populate the
region in the next step.
****************************************************************
EDITF REGION.CDRELPAR
SEL
ITEMS
LIST
******************************************************************
Here a unique identification number is added to the polygon in the region cdrelpar. This number is then calculated to each poly so that we can use it as a relate to other data sources. Below is list of the actual Arcedit commands used.
******************************************************************
Arcedit: editf region.cdrelpar
28 element(s) for edit feature REGION.CDRELPAR
28 element(s) now selected
Arcedit: additem parc_num 20 20 c
Adding PARC_NUM to PATCDRELPAR...
Arcedit: additem parc_id 20 20 c
Adding PARC_ID to PATCDRELPAR...
Arcedit: editf region.cdrelpar
28 element(s) for edit feature REGION.CDRELPAR
0 element(s) now selected
Arcedit: sel
Point to the feature to select
Enter point
Region 1 User-ID: 1 Symbol: 5
1 element(s) now selected
Arcedit: calc parc_num = '102310183'
Arcedit: sel
Point to the feature to select
Enter point
Region 2 User-ID: 2 Symbol: 5
1 element(s) now selected
Arcedit: calc parc_num = '102310184'
Arcedit: sel
Point to the feature to select
Enter point
Region 3 User-ID: 3 Symbol: 5
1 element(s) now selected
Arcedit: calc parc_num = '102310185'
Arcedit: sel
Point to the feature to select
Enter point
Region 4 User-ID: 4 Symbol: 5
1 element(s) now selected
Arcedit: calc parc_num = '102310186'
Arcedit: editf region.cdrelpar
28 element(s) for edit feature REGION.CDRELPAR
1 element(s) now selected
Arcedit: sel all
28 element(s) now selected
Arcedit: list parc_num
Record PARC_NUM
29 102310183
30 102310184
31 102310185
32 102310186
33 102310187
34 102310188
35 102310189
Decide what new items need to be added to the existing items
already in the main cover. To get a listing of the existing items at the Arc command prompt use the ITEMS command.
ARC items test06cc.aat
ARC list test06cc.aat
FNODE# = 25679
TNODE# = 25680
LPOLY# = 1
RPOLY# = 2
LENGTH = 54.99998
TEST06CC# = 1
TEST06CC-ID = 22643
ANGLE = S82-27-20E
DISTANCE = 55.00
RADIUS =
DELTA =
TANGENT =
ARCLENGTH =
SIDE =
RADIUS2 =
TANGENT2 =
CURVE_ID =
RADIAL_ID =
SOURCE_ID =
To add an item you must use the ADDITEM command. The following syntax will add an item to the coverage test06cc.aat table.
Arc: additem test06cc.aat test06cc.aat radial_id 4 4 c 0 curve_id
Arc: items test06cc.aat
Arc: list test06cc.aat
1
FNODE# = 25679
TNODE# = 25680
LPOLY# = 1
RPOLY# = 2
LENGTH = 54.99998 Actual length of the drawn line
TEST06CC# = 1
TEST06CC-ID = 22643
ANGLE = S82-27-20E Angle of the line from the starting point
DISTANCE = 55.00 Distance typed in from the map
RADIUS = The radius of the curve typed in from the map
DELTA = The delta of the curve either typed in from the map or calculated from the measurement typed in
TANGENT = The tangent of the curve either typed in from the map or calculated from the measurement typed in
ARCLENGTH = The actual length of the curve line
SIDE = left or right side
RADIUS2 =
TANGENT2 =
CURVE_ID = This was added to designate C1, C2, C3, etc...
RADIAL_ID = This was added to designate R1, R2, R3, etc...
SOURCE_ID =
The listing above now shows the items (curve_id and radial_id) have been added to the cover.
This step shows how to add the features that were created in the tract map into the
coverage that you will be joining it to. In this case, T10224mf is the
cover that will be the final cover.
Arcedit: coverdraw1 t10224mf
The edit coverage is now D:\PROD1\COGO\T10224MF
38410 element(s) for edit feature ARCS
*************************************************************
The following annotation features need to be populated in both the
tract you are building and the cover that will have the file will
receive the transformed cover.
P:\Project\The process of cogo to mapjoin\Book\The process.doc 75
anno.ADDR_RANGE = The physical street address of the lot
anno.angle = The direction from the starting point the line goes
ANNO.APN = The assessors parcel number from the cdrelpar table in tssds
anno.area_size = The cubic feet of the lot taken from the tract map, not calculated by ARCINFO
anno.curve = The curve number (Example; C1, C2, C3, etc...)
anno.distance = The length of the line
anno.lot_num = The number of the lot according to the tract map
anno.radial = The radial number of the curve (Example; R1, R2, R3, etc...)
*******************************************************************************
** Arcedit: sel all
** 542 element(s) now selected
** Arcedit: calc parcel_id = cdrelpar//parcel_id
** Arcedit: calc atn_id = cdrelinf//atn_id
** Arcedit: calc addr_id = cdrelinf//addr_id
*******************************************************************************
ANNO.ADDR_RANGE
createfeature anno.addr_range
createattributes
additem boundary_id 4 5 b
additem ai_anno_item 25 25 c
annofeature region.cdrelpar cdrelinf//st_num
annoposition cc
annosize 4
annocapture
drawe anno.addr_range
draw
*************************************************************
ANNO.ANGLE
createfeature anno.angle
ACTUAL COMMANDS TO BE CUT AND PASTED
createfeature anno.angle
createattributes
additem boundary_id 4 5 b
additem ai_anno_item 25 25 c
Commands needed to Capture the information, Display it, Move it
annofeature arc angle
annoposition lr
annooffset 4 9
annosize 2
annocapture
The following commands will draw the data
list
drawe anno.angle
draw
sel
list
editf arcs
sel
list
relate list
y
The following data is used to create a needed relate that is used to acquire the data by Info.
Arclength -- is the item
test.aat ------ the file name
info
Arclength
linear
ro
editf anno.Arclength
REL2
TEST.AAT
INFO
Arclength#
TEST#
LINEAR
RO
RELATE LIST
SELECT ALL
LIST
Y
RELATE LIST
Y
SELECT
RESULTS OF THE COMMANDS
Arcedit: createfeature anno.angle1
Created anno.angle1 within D:\PROD1\COGO\T10224MF
0 element(s) for edit feature anno.angle
Arcedit: createattributes
Adding annotation attributes to D:\PROD1\COGO\T10224MF
Arcedit: additem boundary_id 4 5 b
Adding BOUNDARY_ID to TATANGLE...
Arcedit: additem ai_anno_item 25 25 c
Adding AI_ANNO_ITEM to TATANGLE
*************************************************************
ANNO.APN
createfeature anno.APN
createattributes
additem boundary_id 4 5 b
additem ai_anno_item 25 25 c
annofeature region.cdrelpar cdrelPAR//PARCEL_ID
annoposition cc
annosize 4
annocapture
drawe anno.apn
draw
*************************************************************
ANNO.AREA_SIZE
Arcedit: createfeature anno.area_SIZE
ACTUAL COMMANDS TO BE CUT AND PASTED
createfeature anno.area_SIZE
createattributes
additem boundary_id 4 5 b
additem ai_anno_item 25 25 c
annofeature region.cdrelpar cdrelinf//area_ANNO
annoposition cc
annosize 4
annocapture
drawe anno.area_SIZE
draw
Now use the (SELECT or SELECT MANY) and the MOVE
commands to place the annotation text properly.
*************************************************************
ANNO.CURVE
ACTUAL COMMANDS TO BE CUT AND PASTED
Arcedit: createfeature anno.curve
createfeature anno.curve
createattributes
additem boundary_id 4 5 b
additem ai_anno_item 25 25 c
Stop: Now you must manually enter the radial number
(C1, C2, etc...) into the anno.curve_id feature. this is
accomplished by first using the following commands
editf arcs
select
calc curve = 'C1'
All radial lines must be procesed this way before continuing to the next step
editf anno.curve
annofeature arc curve
annoposition lc
annooffset 4 4
annosize 2
annocapture
drawe anno.curve
draw
RESULTS OF THE COMMANDS
Arcedit: createfeature anno.curve
Created anno.lotnum within D:\PROD1\COGO\T10224MF
0 element(s) for edit feature anno.curve_id
Arcedit: createattributes
Adding annotation attributes to D:\PROD1\COGO\T10224MF
Arcedit: additem boundary_id 4 5 b
Adding BOUNDARY_ID to TATcurve_id...
Arcedit: additem ai_anno_item 25 25 c
Adding AI_ANNO_ITEM to TATcurve_id...
*************************************************************
ANNO.DISTANCE
Arcedit: createfeature anno.distance
ACTUAL COMMANDS TO BE CUT AND PASTED
createfeature anno.distance
createattributes
additem boundary_id 4 5 b
additem ai_anno_item 25 25 c
annofeature arc distance
annoposition lr
annooffset 9 9
annosize 2
annocapture
drawe anno.distance
draw
Now use the (SELECT or SELECT MANY) and the MOVE
commands to place the annotation text properly.
*************************************************************
ANNO.LOT_NUM
Arcedit: createfeature anno.lot_num
ACTUAL COMMANDS TO BE CUT AND PASTED
createfeature anno.lot_num
createattributes
additem boundary_id 4 5 b
additem ai_anno_item 25 25 c
annofeature region.cdrelpar cdrelinf//lot_num
annoposition cc
annosize 4
annocapture
drawe anno.lot_num
draw
Now use the (SELECT or SELECT MANY) and the MOVE
commands to place the annotation text properly.
editf anno.lot_num
select all
list
y
calc ai_anno_item = 'rel2//lot_num'
select all
list
relate save
relate list
Arcedit: relate add
Relation Name: rel1
Table Identifier: CDRELINF
Database Name: ACCESS
INFO Item: PARC_NUM
Relate Column: PARC_NUM
Relate Type: ORDERED
Relate Access: RO
*************************************************************
ANNO.RADIAL
Arcedit: createfeature anno.radial
ACTUAL COMMANDS TO BE CUT AND PASTED
createfeature anno.radial
createattributes
additem boundary_id 4 5 b
additem ai_anno_item 25 25 c
Stop: Now you must manually enter the radial number
(R1, R2, etc...) into the anno.radial_id feature. this is
accomplished by first using the following commands
editf arcs
select
calc radial = 'R1'
All radial lines must be procesed this way before continuing to the next step
editf anno.radial
annofeature arc radial
annoposition cc
annooffset 4 4
annosize 2
annocapture
The following commands will draw the data
select all
drawe anno.radial
draw
Now use the (SELECT or SELECT MANY) and the MOVE
These commands will enable the placement of the annotated text.
*************************************************************
************This is a check to see if we can change**********
*********** the distance data from the command prompt*******
RELATE LIST
SELECT ALL
LIST
Now use the commands
Editf anno.addr_range
Sel;move --To position the text properly
If you have done the above process then you should have a completed tract map within your existing data with annotation that rivals the recorded tract map. If the map has a different basis of bearing than your existing data, then you will have to perform several more steps to put the data in. If the tract is in it's own file then you will need to bring it in using the transform command to rotate and manipulate the image to fit your data.
To make sure that both coverages have the same features in them use the following ArcInfo commands.
ARC:
describe <cover name>
describe test2
Arc: describe t10225mf
Description of DOUBLE precision coverage t10225mf
FEATURE CLASSES
Number of Attribute Spatial
Feature Class Subclass Features data (bytes) Index? Topology?
------------- -------- --------- - ----------- ------- ---------
ARCS 38284 122
POLYGONS 13792 64 Preliminary
NODES 25030
ANNOTATIONS n
0 38
(blank) 0
REGIONS CDRELLLA 15 44 Preliminary
CDRELPAR 12068 84 Preliminary
CDRELPMR 156 64 Preliminary
CDRELPMW 31 44 Preliminary
CDRELTMR 229 64 Preliminary
CDRELTRC 1 24 Preliminary
SECONDARY FEATURES
Tics 5
Arc: describe test2
Description of DOUBLE precision coverage test2
FEATURE CLASSES
Number of Attribute Spatial
Feature Class Subclass Features data (bytes) Index? Topology?
------------- -------- --------- ------------ ------- ---------
ARCS 126 122
POLYGONS 33 44 Yes
NODES 25886
ANNOTATIONS ANGLE 0
ANGLE1 99 38
ARCLENGTH 126 38
DISTANCE 0 38
DISTANCE1 114 38
LOTNUM 28 38
PAR_NUM 0 38
RADIUS 124 38
REGIONS CDRELPAR 28 84 Yes
SECONDARY FEATURES
Tics 5
*************************************************************
Copy the cover into a new file. This is
done because the transform command will delete everything
in the file that was not brought in. The transform command
will put the new tract into the correct coordinates. The put
command will be used to put this file into the new copy.
*************************************************************
Create the tics in each file
*************************************************************
Use the Commnad TRANSFORM
to bring in the new tract into the desired coverage.
Trouble with the transform
Arcedit: coverdraw1 t10225mf
The edit coverage is now D:\PROD1\COGO\T10225MF
126 element(s) for edit feature ARCS
Arcedit: drawe all
Arcedit: draw
ANNO.ANGLE1 file for D:\PROD1\COGO\T10225MF is corrupt.
The number of records between the TXT and TAT do not agree.
ANNO.ARCLENGTH file for D:\PROD1\COGO\T10225MF is corrupt.
The number of records between the TXT and TAT do not agree.
ANNO.DISTANCE file for D:\PROD1\COGO\T10225MF is corrupt.
The number of records between the TXT and TAT do not agree.
ANNO.DISTANCE1 file for D:\PROD1\COGO\T10225MF is corrupt.
The number of records between the TXT and TAT do not agree.
ANNO.LOTNUM file for D:\PROD1\COGO\T10225MF is corrupt.
The number of records between the TXT and TAT do not agree.
*************************************************************
Use the MAPJOIN to combine the coverages
Check to see if the items are exactly the same in both covers by comparing them.
This is accomplished by using the following commands:
Arcedit: coverdraw1 test07cf
The edit coverage is now D:\PROD1\TRANSFORM\TEST07CF
211 element(s) for edit feature ARCS
Arcedit: editf arcs
211 element(s) for edit feature ARCS
0 element(s) now selected
Arcedit: items
COLUMN ITEM NAME WIDTH OUTPUT TYPE N.DEC ALTERNATE NAME INDEXED?
1 FNODE# 4 5 B - -
5 TNODE# 4 5 B - -
9 LPOLY# 4 5 B - -
13 RPOLY# 4 5 B - -
17 LENGTH 8 18 F 5 -
25 TEST07CF# 4 5 B - -
29 TEST07CF-ID 4 5 B - -
33 ANGLE 10 10 C - -
43 DISTANCE 8 8 C - -
51 RADIUS 8 8 C - -
59 DELTA 10 10 C - -
69 TANGENT 8 8 C - -
77 ARCLENGTH 8 8 C - -
85 SIDE 1 1 C - -
86 RADIUS2 8 8 C - -
94 TANGENT2 8 8 C - -
102 CURVE_ID 4 4 C - -
106 RADIAL_ID 4 4 C - -
110 SOURCE_ID 20 20 C - -
Arcedit: coverdraw1 t10231
The edit coverage is now D:\PROD1\TRANSFORM\T10231
4711 element(s) for edit feature ARCS
Arcedit: editf arcs
4711 element(s) for edit feature ARCS
0 element(s) now selected
Arcedit: items
COLUMN ITEM NAME WIDTH OUTPUT TYPE N.DEC ALTERNATE NAME INDEXED?
1 FNODE# 4 5 B - -
5 TNODE# 4 5 B - -
9 LPOLY# 4 5 B - -
13 RPOLY# 4 5 B - -
17 LENGTH 8 18 F 5 -
25 T10231# 4 5 B - -
29 T10231-ID 4 5 B - -
33 USER_FLAG 20 20 C - -
53 DXF-LAYER 16 16 C - -
69 DXF-COLOR 2 2 I - -
71 DXF-THICKNESS 4 12 F 3 -
75 DXF-TYPE 10 10 C - -
85 DXF-ELEVATION 4 12 F 3 -
89 DXF-CURVE 1 1 I - -
90 ANGLE 10 10 C - -
100 DISTANCE 8 8 C - -
108 RADIUS 8 8 C - -
116 DELTA 10 10 C - -
126 TANGENT 8 8 C - -
134 ARCLENGTH 8 8 C - -
142 SIDE 1 1 C - -
Continue? y
The items above from the test07cf file that are not in the
section file that the tract is to be joined to must be added
to the t10231 file.
Draw the map and bring in the annotations.
20. Database Updates
In addition to COGO, registering and rectifying images, there are database updates that may need to be completed, as well. For example, the City of Bakersfield GIS professionals use a combination of hand input and AML (Arc Macro Language) programming to update their databases. Data that is stored within the Info tables are usually updated mostly by using various AML programs, while data updated in some external data sources such as Microsoft Access are sometimes hand updated.
An example of automating the process of updating an Info table is after each tract map has been drawn and the appropriate regions have been created an AML program is run to create unique ID's for each of the created parcel lots. In this particular case, the unique ID is composed of the first seven numbers of the X and Y values of each of the parcel regions. In other words, the two X and Y values are merged together and separated by a period to form an ID such as 1234567.1234567.
Database Relates
The ID created above can be used as a relate in other external relational data source tables, since each parcel region has its own unique and mutually exclusive identifier.
Harvey Hansen, "Geographic Information Systems Acronymically Divulging Pitfalls," GIS World, March 1996: 58.
Loy Wiley, "Think Evolution, Not Revolution, for Effective GIS Implementation," GIS World, April 1997: 48.
Juan Tobar
GIS Coordinator
City of Bakersfield, CA
1501 Truxtun Ave
Bakersfield, CA 93301
Phone 661-326-3062
Fax 661-326-2064
jtobar@ci.bakersfield.ca.us
Creighton Maggers
GIS Analyst
City of Bakersfield, CA
1501 Truxtun Ave
Bakersfield, CA 93301
Phone 661-326-3505
Fax 661-326-2064
cmagers@ci.bakersfield.ca.us
Bob Amos
GIS Analyst
City of Bakersfield, CA
1501 Truxtun Ave
Bakersfield, CA 93301
Phone 661-326-3560
Fax 661-326-2064
bamos@ci.bakersfield.ca.us