The master address file of the more than 220,000 active base- and sub-address point features in Jefferson County, Colorado.
<DIV STYLE="text-align:Left;"><DIV><DIV><P STYLE="margin:0 0 7 0;"><SPAN>Data Type: Dynamic. Vintage: Current. Editing of address data within ASPP with the ASP Tools generally occurs on a daily to weekly basis.</SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>The MasterAddress data consists of all base- and sub-address point features, where the latter are addresses with unit designations. </SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>The concept of base- and sub-addresses is essentially a parent-child relationship where referential integrity is employed within the database in conjunction with application logic (via the ASP Tools) to ensure no subaddress (child) may exist without an associated base (parent) address. Column SUBADRUID may be used to delineate base- from sub-addresses as it is null for base addresses and contains a numeric value for subs. Likewise, column SUBADRUNIT may be utilized in a similar fashion given SUBADRUNIT may not be null for a sub-address feature. </SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>The "key" column is ADNO (address number) which is unique for all base- and sub-address features. Columns ADNO and ADRUID are identical on all base address features (and SUBADRUID is null), while ADNO and SUBADRUID are identical for all sub address features, where ADRUID points to the ADNO-ADRUID associated with the base-address for the unit address. Note column ADNO is carried as a foreign key in other enterprise data systems: notably, as PROPGISID1 in Amanda's "Property" table and as CMNADRNBR in the ATSP600 table in the Assessor Treasurer System (ATS).</SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN STYLE="font-weight:bold;">COLUMN "ADNO" AND BRIDGE TABLES</SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>Column ADNO is carried by all "bridge" tables utilized for managing one-to-many or many-to-many relations where address features are involved. As an example, table "ParcelAndAddress" contains all ADNO (address) and AIN (parcel) combinations. Hence where Assessor systems are incapable of attaching more than one address to a parcel, the ASP database manages this complex relation. As of ASP Tool Phase V enhancements, AIN is now directly carried in the MasterAddress table but for attaching other parcel attributes to addresses requires a tabular join, where ParcelAndAddress column AINPRIORITY is employed to narrow the relation to a 1:1 correspondence via the "primary" AIN (where AINPRIORITY = 1). Note where an address (ADNO) is associated with multiple AIN in ParcelAndAddress, only one may have an AINPRIORITY of '1'; the others must be '2'. It is the discretion of the ASP Tool user as to which AIN is the primary for an address. Generally the primary AIN wis the one the address is located within, where disparate parcel geometry is associated with an address. Note this primary AIN 'mechanism 'was employed in propagating ASP transactions to the Endor data repository when that system was live.</SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN><SPAN>Likewise, "SpecialDistrictAndAddress" is a bridge table carring all ADNO (address) and AUTHNO (tax authority number) associations, making it easy to determine what addresses are associated with a special district (if any) and what special districts are associated with any particular address (if any). </SPAN></SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>Other address relations managed through "bridge" tables include points of interest ("POIAndAddress", containing all POIUID-ADNO correspondences), names ("NameAndAddress", containing all NAMEUID - ADNO correspondences), and buildings ("BuildingAndName", containing all BLDGUID-ADNO correspondences). These bridge tables are also propagated to the spatial warehouse (SDEWHP) where relationship classes (RCs) exist within SDEWHP so such associations are readily reported when identifying an address point feature within ArcMap.</SPAN></P><P><SPAN>Column RSN a foreign key for Amanda's PROPERTYRSN. As ioriginally mplemented, ASP was constrained to a 1:1 relation for ADNO and RSN, whereas in reality it is occasionally a 1:M relation- in a few instances, multiple PROPERTYRSN in Amanda point to the same address (ADNO). As of the ASP Tool Phave V enhancements, ASP carries ADNO-RSN relations in a "PropertyAndAddress" bridge table where an ASP 'Property' domain table sits across the other side of the relation via a relationship class.</SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN STYLE="font-weight:bold;">OTHER ATTRIBUTES</SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>Column AIN is a foreign key for the primary AIN (formerly PARID and PIN) from Aumentum per a tabular extract conforming to format Assessor Treasurer System (ATS) table ATSP800. </SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>Column ADR_XYMETA_CODE (address x,y meta code) should be used for display purposes, where column ADR_XYMETA_DESCRIPTION is the textual description for the code. The domain of values for ADR_XYMETA_CODE is four-fold: 'US' (user-specified), 'PC' (parcel centroid), 'PL' (parcel average of labelpoints), and 'I' (interpolated). Most address point features carry either the 'PC' or 'US' designations. 'PL' is a remnant of when the data existed in coverage format and was edited using ArcInfo Workstation; no features now carry this designation. Interpolated addresses are generally those to which no parcel association is known nor do we now have other information as to where the address should be located spatially. Note interpolated addresses are in a continual process of review whereby we determine to what parcel and structure they are associated; otherwise, they are retired. It is worth noting that where ADR_XYMETA_CODE is 'PC' and where multiple parcels are associated with the address, the parcel centroid location is for the primary AIN (where AINPRIORITY = '1'). </SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN><SPAN>To graphically distinguish by both address positioning (ADR_XYMETA_CODE) and the address base code (ADRBASECODE) for display purposes, twice add the feature class to ArcMap's Table-of-Contents (TOC) and then use definition queries to single out base addreses on one and sub addresses on the other, where symbology is then established using ADRXYMETA on both so that one may readily observe not only whether the address is base- or sub but how it was positioned spatially. </SPAN></SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>Column ADDRESS_TYPE is a 32-character field containing the 'description' associated with colunn ADRTYPECODE in the production ASP data, It describes the 'type' of address and is ued in conjunction with Election needs per the State of Colorado Registration and Elections System (SCORE).</SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>Column CITY_POSTAL is the name of the city where postal service originates. This city designation is the same as the CITY_MUNICIPAL designation for those addresses not in unincorporated jefferson County; otherwise, the CITY_POSTAL reflects the city or community name associated with the post office serving the zip code designation.</SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>Column CITY_MUNICIPAL represents municipal status: 'UNINCORPORATED' if the adress is in unincorporated Jefferson County, else the city designation if not.</SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>Numerous jurisdictional attributes have been programmatically attached to this data, for the convenience of the enterprise GIS community, which in the normalized produciton ASP environment require tabular join. </SPAN></P><P STYLE="margin:0 0 0 0;"><SPAN>All column definitions and descriptions are available here: </SPAN><A href="file://admin.co.jeffco.us/admin/share/GIS/MetaData/Address/MasterAddress_Internal_DataDictionary.pdf"><SPAN STYLE="font-weight:bold;">\\admin.co.jeffco.us\admin\share\GIS\MetaData\Address\MasterAddress_Internal_DataDictionary.pdf </SPAN></A></P><P /><P STYLE="margin:0 0 7 0;"><SPAN STYLE="font-weight:bold;"><SPAN>THE RELATIONAL NATURE OF ADDRESSES AND POLITICAL ATTRIBUTION</SPAN></SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN><SPAN>In Jefferson County, core political or jurisdictional polygonal attributes are attached to an address point feature through the relation of each to the appropriate side of an associated street feature. This relational approach- address to matching side of street / side-of-street to matching political polygonal feature- has been employed by the County, in leu of point-in-poly spatial overlay, since the very start of digital County addressing operations in the 1980s. There are two primary reasons for use of this approach:</SPAN></SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN><SPAN>1) It is far easier to maintain the </SPAN></SPAN><SPAN STYLE="font-style:italic;"><SPAN>attribute accuracy</SPAN></SPAN><SPAN><SPAN>of 33,000 street features relative 8,000 political polygons than it is to maintain the </SPAN></SPAN><SPAN STYLE="font-style:italic;"><SPAN>spatial accuracy</SPAN></SPAN><SPAN><SPAN>of 220,000 address point features relative 8,000 polygons, and</SPAN></SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN><SPAN>2) Such a relational approach yields no ambiguity. It results in better data as well as greater confidence in our use of such.</SPAN></SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN><SPAN>This relational approach to attaching jurisdictional attributes to addresses is essentially a two way join- address to street, street to political poly. Hence the street layer serves as the foundational cornerstone for addressing.</SPAN></SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN><SPAN>The core political attributes maintained in this fashion include city code (municipal status), city precinct, city ward, commissioner district, congressional (federal house) district, county precinct, regional transportation district (RTD), southeast Jefferson County local improvement district (SJLID), state house district, state senate district and traffice impact fee area (TIFA). Of these, note only TIFA is not included in an Elections Office ballot style. </SPAN></SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN><SPAN>Only one political element of the ballot style is NOT determined relationally: special districts. Address and tax authority correspondences are the only element of the ballot style determined through point-in-poly spatial overlay. </SPAN></SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN /><SPAN /></P><P STYLE="margin:0 0 7 0;"><SPAN STYLE="font-weight:bold;"><SPAN>ADDRESSING BUSINESS RULES</SPAN></SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>The following are some of the core business rules in terms of County addressing, which are enforced applicationally through the ASP Tools and/or database-wise through Oracle: </SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>1) An address may match to (or is associated with) one side of one and only one street feature.</SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>2) A side of a street feature will have one and only one associated polygonal feature (carrying political/jurisdictional attributes)</SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>3) The political attributes for an address derive from the polygon associated with the side of the street feature on which the address "matches" (is associated with).</SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>4) An address may not be created, or updated in terms of house number or street name attributes, unless a matching street feature exists in terms of street name and address range attribute components (as well as with correct parity).</SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>5) A street feature may not be deleted or updated in terrms of street name or address range attribute components if such would "orphan" addresses.</SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>6) A street feature may not be updated in terms of street name or address range attributes if such would cause an "overlap" with another street feature (potentially creating ambiguity in terms of address-street relations).</SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>7) A sub-address (child) may not exist without a corresponding base (parent).</SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>Many additional business rules are enforced by the ASP Tools, but these form the foundation for overall application and database-logic.</SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN STYLE="font-weight:bold;"><SPAN>SPECIFICS</SPAN></SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>The production "ASP.MasterAddress" feature class lives in the ASPP geodatabase in SDE/Oracle and is maintained by the GIS Services team within the Business and Innovation Technologies (BIT) division through the ASP Tools- a custom extension to ArcMap built in C#/.Net consisting of numerous toolbars and tools. This tool suite was developed expressly for maintenance of the address, street, political and ancillary data within ASPP and enforces Jefferson County's business rules for addressing. Editing of ASP's MasterAddress point data, BaseLine atomic linear and BasePoly atomic polygonal data occurs on an ad-hoc but often daily basis. When such occurs, the automated, integrated nightly Python processies of ASP Derivative (ASPDER) and ASP To Warehouse (ASP2WH) ensure all data remains current in the Jefferson County spatial data warehouse (SDEWHP).</SPAN></P><P STYLE="margin:0 0 7 0;"><SPAN>Quality assurance/quality control (QA/QC) is performed in the form of a report created by the automated ASP QAQC METRICS process. That software gathers nearly 300 data metrics on the address, street, political and ancillary data elements within ASPP and then performs more than 140 evaluations of those metrics, so that integrity is ensured across the numerous data relations maintained in the complex and sophisticated ASP data schema- or, if issues exist- we are aware of such. The ASP schema is available for review here: </SPAN><A href="file://admin.co.jeffco.us/admin/share/GIS/MetaData/ASP/AddressStreetPolitical_GDB_Schema_Phase4_Visio2002_20171001.pdf"><SPAN STYLE="font-weight:bold;">\\admin.co.jeffco.us\admin\share\GIS\MetaData\ASP\AddressStreetPolitical_GDB_Schema_Phase4_Visio2002_20171001.pdf</SPAN></A><SPAN /></P><P STYLE="margin:0 0 7 0;"><SPAN><SPAN>The "MasterAddress feature class data is in State Plane Grid coordinates, Colorado Central Zone, NAD83 (US feet).</SPAN></SPAN></P></DIV></DIV></DIV>
[]
nan
nan
nan