1. Introduction This paper addresses the topic of administrative boundaries and describes the state of the boundary administration process at Metro. It proposes a design for an Administrative Boundary Model based on the Census Data Model as proposed by ESRI. (See footnote number 1) Administrative boundaries are closely tied to two principle components: geographic mapping data for physical features and tabular data associated with those physical features. The geographic mapping data utilized to construct administrative boundaries consists primarily of the linear features. A single linear feature type, however, cannot define all of the variations of Administrative boundaries. For example using a street centerline linear file to construct an administrative boundary only works if all of the boundaries follow the middle of a street. Boundaries may, however, extend to one side of the street right-of-way or the other. Or they may be drawn coincident with parcels or tax lots on either side of the street. Therefore, in this example, the location of the boundary line relative to the street will determine what base geographic features should be used to construct the boundary. There are several different methods being currently utilized to maintain administrative boundaries in Oregon. Metro has been maintaining transactional administrative boundary files on its Regional Land Information System (RLIS) since 1999 using ESRI software products. Each boundary is maintained separately in its own data file. A polygon feature is added to a master boundary for each annexation action. A coverage is edited when an annexation is proposed and again with the annexation is completed. The original boundary that existed at the time maintenance was initiated by Metro and all of the polygons added over time are contained in this coverage. In order to construct a single polygon(s) boundary file for any particular Administrative area the file is dissolved on one of the fields in the associated tabular data. Another method utilized by County Assessment and taxation departments is to maintain a levy code geographic coverage for their County. The levy code (also called tax code) describes the set of special districts (school, fire, etc) associated with tax parcels. This coverage contains polygons that are registered to physical linear data contained within their County GIS data primarily tax lots. Any of the district boundaries described by the levy code can be derived from this coverage. From an assessment and taxation standpoint this may be the preferable method of maintaining Administrative boundaries. This method contains flexibility for calculating and mapping tax levy rates for any particular tax lot and any number of Administrative boundaries (Figure 1). Figure 1: An Image showing the calculation and mapping of tax levy codes, or set of special districts associated with tax parcels, for the city of Forest Grove. It contains six layers: Sewer districts, water districts, school districts, park districts, fire districts and a layer for the City of Forest Grove, Oregon. Another means of constructing administrative boundaries is based on the GIS tax lot coverage that many Counties maintain. That coverage is dissolved utilizing the tabular levy code data for each tax lot or parcel. This method has a major drawback, however, in that it produces groups of tax lots within a block without including other physical features such as the street. By using this method the resulting boundary must be modified to include streets, rivers and many other physical boundaries (figure 2) each time the file is recreated. The preferable approach is to combine all three methods into an Administrative Boundary geodatabase model. Figure 2: An example of the Administrative Boundaries based on the GIS tax lot information many counties maintain. It is made by dissolving the tabular levy code data for tax lot parcel. 2. ORMAP All Counties in Oregon utilize a system of Tax Code maps whether generated by hand or by a GIS system. The ORMAP project has been developed to share statewide the base property records. ORMAP has three components: Component one: Digital maps of taxlots, taxcodes, and basic taxing districts. Component two: Digital images representing the standard assessor’s taxlot map. Component three: Digital tables containing descriptions of taxlots. Presently ORMAP has digital images on the internet for all Oregon Counties. These images reflect current tax code areas and thus the corresponding administrative boundaries. They provide the necessary information for determining the current state of administrative boundaries in a particular county. Figure 3: Ormap Components: These components are Digital maps representing taxlots and basic taxing districts, Digital Images representing the standard assessor’s taxlot map and digital tables containing descriptions of taxlots. The digital maps are Zoning and Others, School, Fire, City, TaxCode, Taxlots and Map Control. The digital image shows a map of tax lots and the digital table has two parts: ownership and map images. Ormap is a project designed to share statewide property records. 3. Beginnings at Metro In 1999 certain duties of the Portland Metropolitan Area Local Government Boundary Commission (PMALGBC) were transferred to Metro. The Metro Policy Advisory Committee (MPAC) had formulated a new chapter of the Metro Code, 3.09, during 1998. One of the duties transferred to Metro was the creation and maintenance of jurisdictional boundaries of all cities, counties and special districts within Metro. (See footnote 2) The Boundary Commission transferred to Metro the Final Orders for all Annexations completed between 1968 and 1999. It also provided boundary maps for the Units of Government. The Boundary Commission provided annexation services to 214 Units of Government at the time of its dissolution. Metro decided to maintain boundaries for the following Units of Government within the Metro boundary: Cities (26) Water Districts (32) Park Districts (4) Sewer Districts (5) Fire Districts (24) In addition there are other boundary files that reside on the Metro RLIS system that are maintained by the local jurisdictions. Metro had developed its RLIS (Regional Land Information System) data prior to accepting annexation and boundary change duties. The opportunity presented itself to integrate the new boundary change duties into the RLIS data. City boundaries existed in the RLIS data, but district data needed to be further developed. Initially Metro checked with the individual governmental units to see if they had developed a data layer or knew where the data existed. When a digital data layer could not be obtained, the boundaries were “digitally traced” on screen utilizing existing data. The descriptive material provided by the Boundary Commission in the form of maps and final ordinances was used to construct and confirm district boundaries. Another method of deriving many of these boundaries was to utilize the ability of GIS to select map features based on their attributes. At the heart of the RLIS GIS lies the ownership or land records data. District boundaries are related to property parcel boundaries and the associated mill levies. 4. Annexation Processing at Metro As previously noted the duties of Portland Metropolitan Area Local Government Boundary Commission (PMALGBC) became the responsibility of the Cities and Counties on January 1, 1999. At that time Metro began to provide boundary change mapping and ministerial functions for the region's cities and special districts. Metro does not initiate or prepare annexation documents. Metro handles the statutorily required distribution of the Final Annexation packet on each boundary change with the Oregon Secretary of State, County Elections Supervisor, and County Assessor. The Oregon Department of Revenue’s Cartography Unit requires taxing districts to file a map, legal description and approved resolution of the annexed property by March 31 for that ensuing fiscal year. The Cartographic Unit checks the maps, descriptions, and ordinances for compliance and accuracy. Once the Cartographic Unit approves an annexation, a “Notice to Taxing Districts” is sent to the jurisdiction and county. Packets sent to the DOR Cartographic Unit must include: A copy of the annexation Order, Ordinance, or Resolution; A valid legal description of the annexation; A copy of the assessor's map book page(s) with the area to be annexed highlighted. The jurisdiction may also wish to obtain ‘Preliminary Approval’ of an annexation’s legal description and map(s) to insure that they meet the requirements for use with the local Order, Ordinance, or Resolution. Once the “Notice to Taxing Districts” is received the jurisdiction sends a copy to Metro along a copy of the Ordinance, Order, or Resolution, and the map(s), legal description, and any staff comments and findings. Metro then maps the annexation, posts the changes on its annexation Web page, and makes the appropriate notifications to the Secretary of State, Archive Division, the County Elections Supervisor and the County Assessor. Distribution of final annexation packets to interested parties is conducted by Metro primarily by distribution of Adobe Acrobat PDF files to a standardized e- mail list. Interested parties can sign up to receive final action packets by e- mail at http://www.metro-region.org/article.cfm?articleid=163. Boundary map shape files for jurisdictions and special districts are stored on Metro’s FTP server at ftp://ftp.metroregion.org/dist/gm/boundary/.These files are in (ESRI) shape file format and ArcInfo (ESRI) .e00 format. An annexation is not in effect until filed with the Secretary of State's subject to ORS 199.461 and/or ORS 22.180 and/or ORS 222.750. The Secretary of State’s letter acknowledging receipt and filing is included in the final packets and the Final Packet is posted at http://www.metro-region.org/annexations. A mapping/filing fee is charged by Metro for annexation and boundary changes according to the following schedule: Single tax lot less than 1 acre $150.00 1 to 5 acres $250.00 5 to 40 acres $300.00 Greater than 40 acres $400.00 or actual cost ($85.00/hour) Jurisdictions may have their own fees that they charge to process an annexation. Metro utilizes a transactional approach to keeping the jurisdictional boundaries current. Each coverage is maintained in a separate administrative workspace on the file system: R:\rlis-apps\tech\bdyadmin\citylim City Limits R:\rlis-apps\tech\bdyadmin\fireadmin Fire Districts R:\rlis-apps\tech\bdyadmin\hauleradmin Hauler Areas (Solid Waste) R:\rlis-apps\tech\bdyadmin\irrigadmin Irrigation Districts R:\rlis-apps\tech\bdyadmin\lawadmin Rural Law Enforcement Districts R:\rlis-apps\tech\bdyadmin\lightadmin Rural Lighting Districts R:\rlis-apps\tech\bdyadmin\counciladmin Metro Council R:\rlis-apps\tech\bdyadmin\metroadmin Metro Service District R:\rlis-apps\tech\bdyadmin\parkadmin Park Districts R:\rlis-apps\tech\bdyadmin\seweradmin Sewer Districts R:\rlis-apps\tech\bdyadmin\schooladmin School Districts R:\rlis-apps\tech\bdyadmin\stormadmin Storm Water Districts R:\rlis-apps\tech\bdyadmin\transadmin Transit Districts R:\rlis-apps\tech\bdyadmin\ugbadmin Urban Growth Boundary R:\rlis-apps\tech\bdyadmin\wateradmin Water Districts Annexations, Additions, and Mergers to many of the above are covered under the Oregon Revised Statutes: Chapter 198 — Special Districts Generally and Chapter 222 — City Boundary Changes; Mergers; Consolidations; Withdrawals.(see footnote 3)A transaction consisting of a boundary change, merger, consolidation or withdrawal is legally documented in a Final Action Packet that consists at a minimum of an ordinance or local order/resolution, a staff report and recommendation, a legal description(s), and map(s). The districts mentioned in ORS Chapter 198 are: 198.010 “District” defined for chapter. As used in this chapter, except as otherwise specifically provided, “district” means any one of the following: (1)A people’s utility district organized under ORS chapter 261. (2)A domestic water supply district organized under ORS chapter 264. (3)A cemetery maintenance district organized under ORS chapter 265. (4)A park and recreation district organized under ORS chapter 266. (5)A mass transit district organized under ORS 267.010 to 267.390. (6)A metropolitan service district organized under ORS chapter 268. (7)A special road district organized under ORS 371.305 to 371.360. (8)A road assessment district organized under ORS 371.405 to 371.535. (9)A highway lighting district organized under ORS chapter 372. (10)A health district organized under ORS 440.305 to 440.410. (11)A sanitary district organized under ORS 450.005 to 450.245. (12)A sanitary authority, water authority or joint water and sanitary authority organized under ORS 450.600 to 450.989. (13)A vector control district organized under ORS 452.020 to 452.170. (14)A rural fire protection district organized under ORS chapter 478. (15)An irrigation district organized under ORS chapter 545. (16)A drainage district organized under ORS chapter 547. (17)A water improvement district organized under ORS chapter 552. (18)A water control district organized under ORS chapter 553. (19)A weather modification district organized under ORS 558.200 to 558.440. (20)A port organized under ORS 777.005 to 777.725 and 777.915 to 777.953. (21)A geothermal heating district organized under ORS chapter 523. (22)A transportation district organized under ORS 267.510 to 267.650. (23)A library district organized under ORS 357.216 to 357.286. (24)A 9-1-1 communications district organized under ORS 401.818 to 401.857. [1971 c.23 §2; 1975 c.782 §48; 1977 c.756 §1; 1981 c.226 §18; 1987 c.671 §10; 1987 c.863 §10; 1989 c.793 §19; 1993 c.577 §15] 5 Boundary File Construction Each boundary file began with a polygon(s) for each city or district boundary as of the date that Metro began to maintain the official boundaries for those jurisdictions (see footnote #4). Each original polygon was confirmed by producing a map of the boundary for each jurisdiction. Those maps were sent to City Mayors and District Boards for review and to approve the boundary or to make changes. Metro staff subsequently began to receive copies of each annexation, consolidation, or withdrawal from local governments. A polygon(s) was added to the boundary file for each of those transactions. That polygon(s) is associated with tabular data that provides the necessary information about the transaction. An example of a database schema is the City Boundary master coverage (as seen in the bdymstr.pat table): Row 1: Column names: COLUMN ITEM NAME WIDTH OUTPUT TYPE N.DEC ALTERNATE NAME INDEXED? Row 2 1 AREA 8 18 F 5 bland - Row 3 9 PERIMETER 8 18 F 5 - Row 4 17 BDYMSTR# 4 5 B - - Row 4 21 BDYMSTR-ID 4 5 B - - Row 5 25 SYMBOL 3 3 I - - Row 6 28 JUR 4 4 I - - Row 7 32 PROPOSAL 10 10 C - - Row 8 42 ANNEXATION 15 15 C 0 - Row 9 57 ORDINANCE 15 15 C - - Row 10 72 ORDDATE 8 10 D - - Row 11 80 DOR 15 15 C - - Row 12 95 SECSTATE 15 15 C - - Row 13 110 FILEDATE 8 10 D - - Row 14 118 JURFUTURE 4 4 I - - Row 15 122 JURNAME 50 50 C - - Row 16: 172 COMMENTS 25 25 C - - Row 17: 197 POSTED 8 10 D - - The first four fields are attributes contained within the ESRI Arc/Info coverage architecture (see footnote5) The symbol field is an attribute that is utilized in the Metro, Automated Mapping Language (AML) mapping routines. The field jur is the five digit FIPS, City identifier utilized by the US Census bureau to designate that jurisdiction within the State of Oregon. This field designates that the annexation has been completed and is the item utilized to dissolve the polygons in the coverage in construction of the official City Boundary file. The proposal field is an identifier assigned by Metro when a transaction is initially logged. It consists of the county abbreviation followed by a consecutive two digit transaction number and the two digit year. Thus the first transaction in Multnomah County in 2004 was proposal# MU0104. The annexation field is the annexation designator assigned by the local jurisdiction. The ordinance field is the local ordinance, order, or resolution number/designator. The field designated orddate is the date that the local ordinance, order, or resolution was signed. The field titled DOR is the number assigned to the transaction by the Oregon Department of Revenue. (See footnote 6) This number consists of the county designator, serial number, and year. A recent DOR number assigned in Clackamas County for the formation of a Library District was 3-1645-2004. The field secstate is the file number assigned by the office of the Oregon Secretary of State, Archives Division. The field filedate contains the date of filing as referred to in 222.180. The field jurfuture contains the same Census ID as the jur field. It is utilized in Metro’s AML (see footnote 7) mapping routines. The jurname field contains the official name of the City/district. The comments field is utilized to provide information on the annexation. Entries in the comments field are: Active Annexation Completed Annexation Annexation Withdrawn Annexation Appealed Inactive Annexation Failed at Election Failed at council The final field contains the date that the Final Order Packet was posted on the Metro Web Server. 6 Urban Growth Boundary Another example of a transactional boundary file is the Metro Urban Growth Boundary (UGB). Prior to having the RLIS GIS data, Metro kept a set of sepia paper quarter section maps that constituted the official description of the Metro Urban Growth Boundary. The Metro Council had adopted this set of sepia maps as the official description of the boundary. When a change was made to the UGB the appropriate paper map(s) would be changed by hand to reflect that particular transaction. The Metro Council has subsequently adopted the RLIS/GIS coverage as the official boundary Map of the Portland Metropolitan UGB. This brought about the need for strict tracking of UGB boundary change transactions and establishing a transactional procedure to produce hard copy maps that matched the look of the old sepia map books. See details of this process in the Appendix. Figure 4: The official RLIS/GIS boundary Map of the Portland Metropolitan Urban Growth Boundary. The schema for the UGB boundary file follows: Row 1 column names COLUMN ITEM NAME WIDTH OUTPUT TYPE N.DEC ALTERNATE NAME INDEXED? Row 2 1 AREA 8 18 F 5 - Row 3 9 PERIMETER 8 18 F 5 - Row 4 17 UGBMSTR# 4 5 B - - Row 5 21 UGBMSTR-ID 4 5 B - - Row 6 25 UGB 1 1 I - - Row 7 26 CASE1 8 8 C - - Row 8 34 ORDINANCE1 20 20 C - - Row 9 54 ADOPTDATE1 8 10 D - - Row 10 62 CASE2 8 8 C - - Row 11 70 ORDINANCE2 20 20 C - - Row 12 90 ADOPTDATE2 8 10 D - - Row 13 98 CASE3 8 8 C - - Row 14 106 ORDINANCE3 20 20 C - - Row 15 126 ADOPTDATE3 8 10 D - - The first four fields are attributes of the ESRI ArcInfo data structure. The UGB field denotes whether the polygon is inside (1) or outside (0) of the Urban Growth Boundary. There can be multiple transactions involving one polygon in the UGB coverage file. This necessitated the need for repeating data fields to record additional case numbers, ordinance numbers, and adoption dates. The instructions and AMLs for UGB processing and map production are included in the Appendix section. This process is similar to the production of the County levy maps and a similar process could be adapted to their production. Data Model This Administrative Boundary Geodatabase model is theoretical and is based on the Census Data Model (see footnote 8) and the transactional data structure that Metro is currently utilizing. It is only now in the process of being implemented. Metro is still editing the Master Boundary files as coverages utilizing Arc Workstation. As the model is implemented by Metro and other jurisdictions there will be changes. The Geodatabase model contains six thematic categories: Census Administrative Units, State Administrative Units, Local Administrative Units, Other Administrative Units, Annexation Master Files, and Other Geographies (See Figure 4). Census Administrative Units The Census geographies utilized in this model are Block, Block Group, and Tract. They can be aggregated upwards block to block group, block group to tract, and so on in a ‘containment hierarchy’ to construct many of the other Administrative Boundaries. There are both statewide and regionally specific boundaries in this group. Topology rules can be developed so that certain other administrative boundaries must be contained by the boundaries of the Census geographies. The problem with this rule is that it will generate many error exceptions as the Census geography relationship reflects a snapshot which is accurate only once every decade. Annexations for example to a City boundary file will not be reflected in Tract boundaries until the next Census. Figure 5: The Six thematic Categories of the Geodatabase model: Census Administrative Units, State Administrative Units, Local Administrative Units, Other Administrative Units, Annexation Master Files, and Other Geographies. The Census Administrative Units category consists of the Polygon feature class CensusTract layer, the Polygon feature class CensusBlockGroup layer, Polygon feature class CensusBlock layer, Ploygon feature class TractState layer, Polygon feature class BlockState layer and the Polygon feature class BlockGroupState layer. The Polygon feature class CensusTract layer contains small, relatively permanent subdivisions of a county. The Polygon feature class CensusBlockGroup layer is a cluster of census blocks made up of the Polygon feature class CensusBlock layer, which contains census block areas. The Polygon feature class BlockState layer has small, relatively permanent subdivisions of counties in the State of Oregon. The Polygon feature class BlockState layer is a cluster of Census block areas in the State of Oregon made up of Polygon feature class BlockGroupState layers, which are clusters of Census blocks in the State of Oregon. State Administrative Units consist of the Polygon feature class State layer, the Polygon feature class CountyState layer and the Polygon feature class CityState layer. The Polygon feature class State layer is the State of Oregon Boundary. The Polygon feature class CountyState layer contains the primary legal divisions in the State of Oregon. The Polygon feature class CityState layer has Incorporated Cities in the State of Oregon. Local Administrative Units consist of the Polygon feature class CityFill layer, Polygon feature class CityMaster layer, the Polygon feature class CountyMetro layer and the Polygon feature class Metro layer. The Polygon feature class CityFill layer contains the incorporated cities in the Portland Metropolitan Area. The Polygon feature class CityMaster layer contains the current city Annexations and annexation history and has nine subtypes: Original Jurisdiction, Active Annexation, completed annexation, annexation withdrawn, annexation appealed, inactive annexation, failed at election, failed at council and no jurisdiction. The Polygon feature class CountyMetro layer contains the primary legal divisions in the Portland Metropolitan Area. The Polygon feature class Metro layer is the Geographic Area served by the Metro Regional Government. Other Administrative Units consist of Polygon feature class FireDistrict layer, Polygon feature class ParkDistrict layer, Polygon feature class Neighborhood layer, Polygon feature class SchoolDistrict layer, Polygon feature class SewerDistrict layer, Polygon feature class TransitDistrict layer, Polygon feature class UGBFill layer and the Polygon feature class Water District layer. The Polygon feature class FireDistrict layer contains the geographic areas with Fire Protection Districts. The Polygon feature class ParkDistrict layer has the geographic areas served by park districts. The Polygon feature class Neighborhood layer contains geographic neighborhoods in the Portland Metro area. The Polygon feature class SchoolDistrict layer contains geographic areas served by school districts. The Polygon feature class SewerDistrict contains the geographic areas served by sewer districts. The Polygon feature class TransitDistrict layer has the geographic areas served by transit districts. The Polygon feature class UGBFill layer is the Metro Portland Urban Growth Boundary. The Polygon feature class WaterDistrict layer is the water district boundary file. Annexation Master Files consist of the Polygon feature class MetroMaster layer, the Polygon feature class Firemaster layer, the Polygon feature class ParkDistMaster layer, the Polygon feature class SchoolDistMaster layer, the Polygon feature class SewerDistMaster layer, the Polygon feature class TransitDistMaster layer, the Polygon feature class UGBmaster layer and the Polygon feature class WaterDistMaster layer. The Polygon feature class MetroMaster layer has the current Metro Regional Government annexation activity and annexation history. The Polygon feature class Firemaster layer contains the current fire district annexations and annexation history. The Polygon feature class ParkDistMaster layer has the current park district annexation activity and annexation history. Polygon feature class SchoolDistMaster layer is the school district master file. The Polygon feature class SewerDistMaster contains the current sewer district annexation activity and annexation history. The Polygon feature class TransitDistMaster layer is the transit district master file. The Polygon feature class UGBmaster layer is the urban growth boundary master file. The Polygon feature class WaterDistMaster layer has the water district current annexations and history file. Other Geographies contains the Polygon feature class TaxCode layer, the Polygon feature class VoterPrecinct layer and the Polygon feature class Zip Code layer. The Polygon feature class TaxCode layer has the county tax levy areas. The Polygon feature class VoterPrecinct layer contains the geographic areas utilized in elections. The Polygon feature class Zip Code layer has the primary mail delivery areas. Local Administrative Units The Local Administrative Units topographically related group includes City, County, and Regional Administrative boundaries. State Administrative Units The State Administrative Units topographically related contains statewide boundaries for the State, its Counties, and Cities. Other Geographies This topographically related group contains boundaries related to all the other topologies and includes Tax Code boundaries, Voter Precinct boundaries, and Zip Code boundaries. Other Administrative Units This topographically related grouping includes all other administrative units including Fire Districts, Park Districts, Neighborhood Boundaries, School Districts, Sewer Districts, Transit Districts, Urban Growth Boundaries, and Water Districts. Annexation Master Files This topographically related group contains boundary files that provide the annexation history utilized to construct the boundary files for Other Administrative units. Reference Layers Tax Lots, streets, and rivers are part of the cartographic base and are used as a background and reference objects in this model. They are not part of the geodatabase. These reference layers can be raster (rasterized cartography, remote-sensed images) or vectorial. Reference layers are modified in separate geodatabases. Replacing one reference layer or background with another more updated one has no consequences for the administrative boundary geodatabase. In addition, reference layers can be archived and over time provide specific references for boundary layers. APPENDIX Tips for Producing Hard Copy Boundary maps Receive annexation packet from a local jurisdiction Create a hard-copy folder of the ordinance. The folder does not need all the exhibits, but should include the signed and dated ordinance, map and legal description. The following information is needed for the UGB: ordinance number case number adoption date Update summary.xls. Coordinate with planning department. Edit UGBMSTR To edit UGBMSTR. Archive current UGBMSTR in the ARCHIVE directory. Make additions/corrections to UGBMSTR, making sure that UGB, CASE1, ORDINANCE1 and ADOPTDATE1 are populated. If there is more than one ordinance affecting a polygon, use the ORDINANCE2, etc fields for subsequent changes. (Add ORDINANCE3, etc. when it becomes necessary). QC. And run TOCENT.AML to dissolve the coverage and copy it to the central database. Make a new shape file for UPDATES. The remaining steps are run in the MAPBOOK subdirectory under UGBADMIN. Run MK_REVISE_TABLE.AML (see footnote #9) - creates a list of amendments by section. Does this amendment add or subtract a map page (section)? If so, edit SECTIONS.TXT. This is the master list of sections. Edit UGBANNO START.AML - starts your ArcEdit session and sets the drawing environment. NEWSEC.AML - zooms to a new section and puts tax lots in the background. Anno Attributes Size Symbol URBAN/NON-URBAN/METRO, IN, NOT IN, OUT 200/100 3 FLOODPLAIN, RIVER, Misc. Boundary Labels 75 3 Place annotation away from the overlap area, or use small anno in the center of the overlap area. Revise the FLOODSEC info file if necessary. This info file is a list of sections containing UGB defined as floodplain. It is unlikely that this list will grow, but it could decrease. Create EPS file by running PLOT.AML (calls UGB.AML). Syntax: &r PLOT
. Puts a rotated EPS file under the EPS_ROT subdirectory. for plotting. you can use SPOOL.AML if you want to run a township, or as a guide to make your own spool. Plot the map. The plot goes to The UGB Map Book. Previous copy moves to Historical Map Book. Replot the regional maps, if the change was significant enough to show up at a regional scale. Regionmap.apr and indexmap.apr. If there was a significant change, have a .pdf made of the regional map and send to staff for the web site. Figure 5: An example of a map made by MK_REVISE_TABLE.AML This map is the official UGB/ Metro boundary. TOCENT.AML /* /* Run to recreate ugb for central database * 1. dissolved on ugb /* 3. copied to central database, don't forget to be 'tech' /* /* knightb /* 10.17.01 &type ********Now dissolving bdy dissolve ugbmstr ugbdis ugb build ugbdis arc &type ********Now copying to central database kill r:/tl/reg/ugb all copy ugbdis r:/tl/reg/ugb &type *********Now killing dissolved version kill ugbdis all MK_REVISE_TABLE.AML /* creates a revision lists for the Metro/UGB boundary /* alanh, 7/17/01 /* METRO boundary &if [exists metromstr_sec -poly] &then kill metromstr_sec all intersect r:\rlis-apps\tech\bdyadmin\metroadmin\metromstr ~ $tl/reg/section metromstr_sec poly &if [exists metro_revise -info] &then &type [delete metro_revise info] ap resel metromstr_sec poly ordinance ne '' infofile metromstr_sec poly metro_revise1 section ordinance date init q frequency metro_revise1 metro_revise section ordinance date end end dropitem metro_revise metro_revise case# frequency end tables select metro_revise sort date kill metro_revise1 q /* &if [exists metromstr_sec -poly] &then kill metromstr_sec all /* UGB &if [exists ugbmstr_sec -poly] &then kill ugbmstr_sec all intersect r:\rlis-apps\tech\bdyadmin\ugbadmin\ugbmstr ~ $tl/reg/section ugbmstr_sec poly &if [exists ugb_revise -info] &then &type [delete ugb_revise -info] ap resel ugbmstr_sec poly ordinance1 ne '' and ordinance1 ne '79-77' infofile ugbmstr_sec poly ugb_revise1 section ordinance1 case1 adoptdate1 ~ init clears resel ugbmstr_sec poly ordinance2 ne '' infofile ugbmstr_sec poly ugb_revise2 section ordinance2 case2 adoptdate2 ~ init q tables sel ugb_revise2 alter ordinance2 ordinance1 ~ ~ ~ ~ ~ ~ alter case2 case1 ~ ~ ~ ~ ~ ~ alter adoptdate2 adoptdate1 ~ ~ ~ ~ ~ ~ q ap infofile ugb_revise2 info ugb_revise1 section ordinance1 case1 adoptdate1 ~ append q frequency ugb_revise1 ugb_revise section ordinance1 case1 adoptdate1 end end dropitem ugb_revise ugb_revise case# frequency end tables select ugb_revise sort adoptdate1 kill ugb_revise1 kill ugb_revise2 q /* &if [exists ugbmstr_sec -poly] &then kill ugbmstr_sec all This form is completed by local jurisdictions when submitting annexation requests. It is accompanied by the documents necessary to process the annexation. From: To: Carol Hall/Bob Knight Metro Data Resource Center Date: Subject: Final Boundary Change Submission Checklist Final Signed Resolution/Order/Ordinance required Notice to Taxing Districts from Oregon Dept. of Revenue Required Legal Description* Final Map(s) – Red Outline on Assessor Map Page(s) required Staff Report Certified Copy of Election Results (If election was required.) Application/Petition for Annexation Metro Mapping Fee (see reverse) This Form Required *Required Property Information: (Address, Tax Map/lot number) Send packet to: Carol Hall/Bob Knight Metro Data Resource Center 600 NE Grand Ave. Portland, OR 97232-2736 (503) 797-1589/1591 (503) 797-1909 (fax) Footnote #1: Designing Geodatabases · Case Studies in GIS Data Modeling, Chapter 6: Census Units and Boundaries. 2004, ESRI, 380 New York Street, Redlands, California 97373-8100 USA. Footnote #2: Metro Code; 3.09.110, Ministerial Functions of Metro Footnote #3: Oregon Revised Statutes – 2003 Edition Footnote #4: 5 January 1, 1999 Footnote #5: ESRI, ArcInfo; Copyright © 1982-2004 Environmental Systems Research Institute, Inc. Footnote #6: Each legal description and map(s) that is included in a final order must be certified as to form by the DOR, Cadastral Information Systems Unit7 (formerly known as the Cartographic Unit). Footnote #7: ESRI, Arc/Info; Copyright © 1982-2004 Environmental Systems Research Institute, Inc. Footnote #8: Designing Geodatabases · Case Studies in GIS Data Modeling, Chapter 6: Census Units and Boundaries. 2004, ESRI, 380 New York Street, Redlands, California 97373-8100 USA. Footnote #9: See following for AML scripts and map example