The documentation below is in reference to this items placement in the NM Supply Chain Data Hub. The documentation is of use to understanding the source of this item, and how to reproduce it for updatesTitle: Soil Survey Geographic Database (SSURGO) DownloaderItem Type: Web Mapping Application URLSummary: Download ready-to-use project packages with over 170 attributes derived from the SSURGO (Soil Survey Geographic Database) dataset.Notes: Prepared by: Uploaded by EMcRae_NMCDCSource: https://nmcdc.maps.arcgis.com/home/item.html?id=cdc49bd63ea54dd2977f3f2853e07fff link to Esri web mapping applicationFeature Service: https://nmcdc.maps.arcgis.com/home/item.html?id=305ef916da574a71877edb15c3f47f08#overviewUID: 26Data Requested: Ag CensusMethod of Acquisition: Esri web mapDate Acquired: 6/16/22Priority rank as Identified in 2022 (scale of 1 being the highest priority, to 11 being the lowest priority): 8Tags: PENDINGDOCUMENTATION FROM DATA SOURCE URL: This application provides quick access to ready-to-use project packages filled with useful soil data derived from the SSURGO dataset.To use this application, navigate to your study area and click the map. A pop-up window will open. Click download and the project package will be copied to your computer. Double click the downloaded package to open it in ArcGIS Pro. Alt + click on the layer in the table of contents to zoom to the subbasin.Soil map units are the basic geographic unit of the Soil Survey Geographic Database (SSURGO). The SSURGO dataset is a compilation of soils information collected over the last century by the Natural Resources Conservation Service (NRCS). Map units delineate the extent of different soils. Data for each map unit contains descriptions of the soil’s components, productivity, unique properties, and suitability interpretations.Each soil type has a unique combination of physical, chemical, nutrient and moisture properties. Soil type has ramifications for engineering and construction activities, natural hazards such as landslides, agricultural productivity, the distribution of native plant and animal life and hydrologic and other physical processes. Soil types in the context of climate and terrain can be used as a general indicator of engineering constraints, agriculture suitability, biological productivity and the natural distribution of plants and animals.Dataset SummaryThe map packages were created from the October 2021 SSURGO snapshot. The dataset covers the 48 contiguous United States plus Hawaii and portions of Alaska. Map packages are available for Puerto Rico and the US Virgin Islands. A project package for US Island Territories and associated states of the Pacific Ocean can be downloaded by clicking one of the included areas in the map. The Pacific Project Package includes: Guam, the Marshall Islands, the Northern Marianas Islands, Palau, the Federated States of Micronesia, and American Samoa.Not all areas within SSURGO have completed soil surveys and many attributes have areas with no data. The soil data in the packages is also available as a feature layer in the ArcGIS Living Atlas of the World.AttributesKey fields from nine commonly used SSURGO tables were compiled to create the 173 attribute fields in this layer. Some fields were joined directly to the SSURGO Map Unit polygon feature class while others required summarization and other processing to create a 1:1 relationship between the attributes and polygons prior to joining the tables. Attributes of this layer are listed below in their order of occurrence in the attribute table and are organized by the SSURGO table they originated from and the processing methods used on them.Map Unit Polygon Feature Class Attribute TableThe fields in this table are from the attribute table of the Map Unit polygon feature class which provides the geographic extent of the map units.Area SymbolSpatial VersionMap Unit SymbolMap Unit TableThe fields in this table have a 1:1 relationship with the map unit polygons and were joined to the table using the Map Unit Key field.Map Unit NameMap Unit KindFarmland ClassInterpretive FocusIntensity of MappingIowa Corn Suitability RatingLegend TableThis table has 1:1 relationship with the Map Unit table and was joined using the Legend Key field.Project ScaleSurvey Area Catalog TableThe fields in this table have a 1:1 relationship with the polygons and were joined to the Map Unit table using the Survey Area Catalog Key and Legend Key fields.Survey Area VersionTabular VersionMap Unit Aggregated Attribute TableThe fields in this table have a 1:1 relationship with the map unit polygons and were joined to the Map Unit attribute table using the Map Unit Key field.Slope Gradient - Dominant ComponentSlope Gradient - Weighted AverageBedrock Depth - MinimumWater Table Depth - Annual MinimumWater Table Depth - April to June MinimumFlooding Frequency - Dominant ConditionFlooding Frequency - MaximumPonding Frequency - PresenceAvailable Water Storage 0-25 cm - Weighted AverageAvailable Water Storage 0-50 cm - Weighted AverageAvailable Water Storage 0-100 cm - Weighted AverageAvailable Water Storage 0-150 cm - Weighted AverageDrainage Class - Dominant ConditionDrainage Class - WettestHydrologic Group - Dominant ConditionIrrigated Capability Class - Dominant ConditionIrrigated Capability Class - Proportion of Map Unit with Dominant ConditionNon-Irrigated Capability Class - Dominant ConditionNon-Irrigated Capability Class - Proportion of Map Unit with Dominant ConditionRating for Buildings without Basements - Dominant ConditionRating for Buildings with Basements - Dominant ConditionRating for Buildings with Basements - Least LimitingRating for Buildings with Basements - Most LimitingRating for Septic Tank Absorption Fields - Dominant ConditionRating for Septic Tank Absorption Fields - Least LimitingRating for Septic Tank Absorption Fields - Most LimitingRating for Sewage Lagoons - Dominant ConditionRating for Sewage Lagoons - Dominant ComponentRating for Roads and Streets - Dominant ConditionRating for Sand Source - Dominant ConditionRating for Sand Source - Most ProbableRating for Paths and Trails - Dominant ConditionRating for Paths and Trails - Weighted AverageErosion Hazard of Forest Roads and Trails - Dominant ComponentHydric Classification - PresenceRating for Manure and Food Processing Waste - Weighted AverageComponent Table – Dominant ComponentMap units have one or more components. To create a 1:1 join component data must be summarized by map unit. For these fields a custom script was used to select the component with the highest value for the Component Percentage Representative Value field (comppct_r). Ties were broken with the Slope Representative Value field (slope_r). Components with lower average slope were selected as dominant. If both soil order and slope were tied, the first value in the table was selected.Component Percentage - Low ValueComponent Percentage - Representative ValueComponent Percentage - High ValueComponent NameComponent KindOther Criteria Used to Identify ComponentsCriteria Used to Identify Components at the Local LevelRunoff ClassSoil loss tolerance factorWind Erodibility IndexWind Erodibility GroupErosion ClassEarth Cover 1Earth Cover 2Hydric ConditionHydric RatingAspect Range - Counter Clockwise LimitAspect - Representative ValueAspect Range - Clockwise LimitGeomorphic DescriptionNon-Irrigated Capability SubclassNon-Irrigated Unit Capability ClassIrrigated Capability SubclassIrrigated Unit Capability ClassConservation Tree Shrub GroupGrain Wildlife HabitatGrass Wildlife HabitatHerbaceous Wildlife HabitatShrub Wildlife HabitatConifer Wildlife HabitatHardwood Wildlife HabitatWetland Wildlife HabitatShallow Water Wildlife HabitatRangeland Wildlife HabitatOpenland Wildlife HabitatWoodland Wildlife HabitatWetland Wildlife HabitatSoil Slip PotentialSusceptibility to Frost HeavingConcrete CorrosionSteel CorrosionTaxonomic ClassTaxonomic OrderTaxonomic SuborderGreat GroupSubgroupParticle SizeParticle Size ModCation Exchange Activity ClassCarbonate ReactionTemperature ClassMoist SubclassSoil Temperature RegimeEdition of Keys to Soil Taxonomy Used to Classify SoilCalifornia Storie IndexComponent KeyComponent Table – Weighted AverageMap units may have one or more soil components. To create a 1:1 join, data from the Component table must be summarized by map unit. For these fields a custom script was used to calculate an average value for each map unit weighted by the Component Percentage Representative Value field (comppct_r).Slope Gradient - Low ValueSlope Gradient - Representative ValueSlope Gradient - High ValueSlope Length USLE - Low ValueSlope Length USLE - Representative ValueSlope Length USLE - High ValueElevation - Low ValueElevation - Representative ValueElevation - High ValueAlbedo - Low ValueAlbedo - Representative ValueAlbedo - High ValueMean Annual Air Temperature - Low ValueMean Annual Air Temperature - Representative ValueMean Annual Air Temperature - High ValueMean Annual Precipitation - Low ValueMean Annual Precipitation - Representative ValueMean Annual Precipitation - High ValueRelative Effective Annual Precipitation - Low ValueRelative Effective Annual Precipitation - Representative ValueRelative Effective Annual Precipitation - High ValueDays between Last and First Frost - Low ValueDays between Last and First Frost - Representative ValueDays between Last and First Frost - High ValueRange Forage Annual Potential Production - Low ValueRange Forage Annual Potential Production - Representative ValueRange Forage Annual Potential Production - High ValueInitial Subsidence - Low ValueInitial Subsidence - Representative ValueInitial Subsidence - High ValueTotal Subsidence - Low ValueTotal Subsidence - Representative ValueTotal Subsidence - High ValueCrop Productivity IndexEsri SymbologyThis field was created to provide symbology based on the Taxonomic Order field (taxorder). Because some map units have a null value for soil order, a

This dataset was updated May, 2025.This ownership dataset was generated primarily from CPAD data, which already tracks the majority of ownership information in California. CPAD is utilized without any snapping or clipping to FRA/SRA/LRA. CPAD has some important data gaps, so additional data sources are used to supplement the CPAD data. Currently this includes the most currently available data from BIA, DOD, and FWS. Additional sources may be added in subsequent versions. Decision rules were developed to identify priority layers in areas of overlap.Starting in 2022, the ownership dataset was compiled using a new methodology. Previous versions attempted to match federal ownership boundaries to the FRA footprint, and used a manual process for checking and tracking Federal ownership changes within the FRA, with CPAD ownership information only being used for SRA and LRA lands. The manual portion of that process was proving difficult to maintain, and the new method (described below) was developed in order to decrease the manual workload, and increase accountability by using an automated process by which any final ownership designation could be traced back to a specific dataset.The current process for compiling the data sources includes: Clipping input datasets to the California boundary Filtering the FWS data on the Primary Interest field to exclude lands that are managed by but not owned by FWS (ex: Leases, Easements, etc) Supplementing the BIA Pacific Region Surface Trust lands data with the Western Region portion of the LAR dataset which extends into California. Filtering the BIA data on the Trust Status field to exclude areas that represent mineral rights only. Filtering the CPAD data on the Ownership Level field to exclude areas that are Privately owned (ex: HOAs) In the case of overlap, sources were prioritized as follows: FWS > BIA > CPAD > DOD As an exception to the above, DOD lands on FRA which overlapped with CPAD lands that were incorrectly coded as non-Federal were treated as an override, such that the DOD designation could win out over CPAD.In addition to this ownership dataset, a supplemental _source dataset is available which designates the source that was used to determine the ownership in this dataset. Data Sources: GreenInfo Network's California Protected Areas Database (CPAD2023a). https://www.calands.org/cpad/; https://www.calands.org/wp-content/uploads/2023/06/CPAD-2023a-Database-Manual.pdf US Fish and Wildlife Service FWSInterest dataset (updated December, 2023). https://gis-fws.opendata.arcgis.com/datasets/9c49bd03b8dc4b9188a8c84062792cff_0/explore Department of Defense Military Bases dataset (updated September 2023) https://catalog.data.gov/dataset/military-bases Bureau of Indian Affairs, Pacific Region, Surface Trust and Pacific Region Office (PRO) land boundaries data (2023) via John Mosley John.Mosley@bia.gov Bureau of Indian Affairs, Land Area Representations (LAR) and BIA Regions datasets (updated Oct 2019) https://biamaps.doi.gov/bogs/datadownload.html Data Gaps & Changes:Known gaps include several BOR, ACE and Navy lands which were not included in CPAD nor the DOD MIRTA dataset. Our hope for future versions is to refine the process by pulling in additional data sources to fill in some of those data gaps. Additionally, any feedback received about missing or inaccurate data can be taken back to the appropriate source data where appropriate, so fixes can occur in the source data, instead of just in this dataset.25_1: The CPAD Input dataset was amended to merge large gaps in certain areas of the state known to be erroneous, such as Yosemite National Park, and to eliminate overlaps from the original input. The FWS input dataset was updated in February of 2025, and the DOD input dataset was updated in October of 2024. The BIA input dataset was the same as was used for the previous ownership version.24_1: Input datasets this year included numerous changes since the previous version, particularly the CPAD and DOD inputs. Of particular note was the re-addition of Camp Pendleton to the DOD input dataset, which is reflected in this version of the ownership dataset. We were unable to obtain an updated input for tribral data, so the previous inputs was used for this version.23_1: A few discrepancies were discovered between data changes that occurred in CPAD when compared with parcel data. These issues will be taken to CPAD for clarification for future updates, but for ownership23_1 it reflects the data as it was coded in CPAD at the time. In addition, there was a change in the DOD input data between last year and this year, with the removal of Camp Pendleton. An inquiry was sent for clarification on this change, but for ownership23_1 it reflects the data per the DOD input dataset.22_1 : represents an initial version of ownership with a new methodology which was developed under a short timeframe. A comparison with previous versions of ownership highlighted the some data gaps with the current version. Some of these known gaps include several BOR, ACE and Navy lands which were not included in CPAD nor the DOD MIRTA dataset. Our hope for future versions is to refine the process by pulling in additional data sources to fill in some of those data gaps. In addition, any topological errors (like overlaps or gaps) that exist in the input datasets may thus carry over to the ownership dataset. Ideally, any feedback received about missing or inaccurate data can be taken back to the relevant source data where appropriate, so fixes can occur in the source data, instead of just in this dataset.

Note: The schema changed in February 2025 - please see below. We will post a roadmap of upcoming changes, but service URLs and schema are now stable. For deployment status of new services beginning in February 2025, see https://gis.data.ca.gov/pages/city-and-county-boundary-data-status. Additional roadmap and status links at the bottom of this metadata.This dataset is regularly updated as the source data from CDTFA is updated, as often as many times a month. If you require unchanging point-in-time data, export a copy for your own use rather than using the service directly in your applications. PurposeCounty boundaries along with third party identifiers used to join in external data. Boundaries are from the California Department of Tax and Fee Administration (CDTFA). These boundaries are the best available statewide data source in that CDTFA receives changes in incorporation and boundary lines from the Board of Equalization, who receives them from local jurisdictions for tax purposes. Boundary accuracy is not guaranteed, and though CDTFA works to align boundaries based on historical records and local changes, errors will exist. If you require a legal assessment of boundary location, contact a licensed surveyor.This dataset joins in multiple attributes and identifiers from the US Census Bureau and Board on Geographic Names to facilitate adding additional third party data sources. In addition, we attach attributes of our own to ease and reduce common processing needs and questions. Finally, coastal buffers are separated into separate polygons, leaving the land-based portions of jurisdictions and coastal buffers in adjacent polygons. This feature layer is for public use. Related LayersThis dataset is part of a grouping of many datasets:Cities: Only the city boundaries and attributes, without any unincorporated areasWith Coastal BuffersWithout Coastal BuffersCounties: Full county boundaries and attributes, including all cities within as a single polygonWith Coastal Buffers (this dataset)Without Coastal BuffersCities and Full Counties: A merge of the other two layers, so polygons overlap within city boundaries. Some customers require this behavior, so we provide it as a separate service.With Coastal BuffersWithout Coastal BuffersCity and County AbbreviationsUnincorporated Areas (Coming Soon)Census Designated PlacesCartographic CoastlinePolygonLine source (Coming Soon)State BoundaryWith Bay CutsWithout Bay Cuts Working with Coastal Buffers The dataset you are currently viewing includes the coastal buffers for cities and counties that have them in the source data from CDTFA. In the versions where they are included, they remain as a second polygon on cities or counties that have them, with all the same identifiers, and a value in the COASTAL field indicating if it"s an ocean or a bay buffer. If you wish to have a single polygon per jurisdiction that includes the coastal buffers, you can run a Dissolve on the version that has the coastal buffers on all the fields except OFFSHORE and AREA_SQMI to get a version with the correct identifiers. Point of ContactCalifornia Department of Technology, Office of Digital Services, gis@state.ca.gov Field and Abbreviation DefinitionsCDTFA_COUNTY: CDTFA county name. For counties, this will be the name of the polygon itself. For cities, it is the name of the county the city polygon is within.CDTFA_COPRI: county number followed by the 3-digit city primary number used in the Board of Equalization"s 6-digit tax rate area numbering system. The boundary data originate with CDTFA's teams managing tax rate information, so this field is preserved and flows into this dataset.CENSUS_GEOID: numeric geographic identifiers from the US Census BureauCENSUS_PLACE_TYPE: City, County, or Town, stripped off the census name for identification purpose.GNIS_PLACE_NAME: Board on Geographic Names authorized nomenclature for area names published in the Geographic Name Information SystemGNIS_ID: The numeric identifier from the Board on Geographic Names that can be used to join these boundaries to other datasets utilizing this identifier.CDT_COUNTY_ABBR: Abbreviations of county names - originally derived from CalTrans Division of Local Assistance and now managed by CDT. Abbreviations are 3 characters.CDT_NAME_SHORT: The name of the jurisdiction (city or county) with the word "City" or "County" stripped off the end. Some changes may come to how we process this value to make it more consistent.AREA_SQMI: The area of the administrative unit (city or county) in square miles, calculated in EPSG 3310 California Teale Albers.OFFSHORE: Indicates if the polygon is a coastal buffer. Null for land polygons. Additional values include "ocean" and "bay".PRIMARY_DOMAIN: Currently empty/null for all records. Placeholder field for official URL of the city or countyCENSUS_POPULATION: Currently null for all records. In the future, it will include the most recent US Census population estimate for the jurisdiction.GlobalID: While all of the layers we provide in this dataset include a GlobalID field with unique values, we do not recommend you make any use of it. The GlobalID field exists to support offline sync, but is not persistent, so data keyed to it will be orphaned at our next update. Use one of the other persistent identifiers, such as GNIS_ID or GEOID instead. Boundary AccuracyCounty boundaries were originally derived from a 1:24,000 accuracy dataset, with improvements made in some places to boundary alignments based on research into historical records and boundary changes as CDTFA learns of them. City boundary data are derived from pre-GIS tax maps, digitized at BOE and CDTFA, with adjustments made directly in GIS for new annexations, detachments, and corrections.Boundary accuracy within the dataset varies. While CDTFA strives to correctly include or exclude parcels from jurisdictions for accurate tax assessment, this dataset does not guarantee that a parcel is placed in the correct jurisdiction. When a parcel is in the correct jurisdiction, this dataset cannot guarantee accurate placement of boundary lines within or between parcels or rights of way. This dataset also provides no information on parcel boundaries. For exact jurisdictional or parcel boundary locations, please consult the county assessor's office and a licensed surveyor. CDTFA's data is used as the best available source because BOE and CDTFA receive information about changes in jurisdictions which otherwise need to be collected independently by an agency or company to compile into usable map boundaries. CDTFA maintains the best available statewide boundary information. CDTFA's source data notes the following about accuracy: City boundary changes and county boundary line adjustments filed with the Board of Equalization per Government Code 54900. This GIS layer contains the boundaries of the unincorporated county and incorporated cities within the state of California. The initial dataset was created in March of 2015 and was based on the State Board of Equalization tax rate area boundaries. As of April 1, 2024, the maintenance of this dataset is provided by the California Department of Tax and Fee Administration for the purpose of determining sales and use tax rates. The boundaries are continuously being revised to align with aerial imagery when areas of conflict are discovered between the original boundary provided by the California State Board of Equalization and the boundary made publicly available by local, state, and federal government. Some differences may occur between actual recorded boundaries and the boundaries used for sales and use tax purposes. The boundaries in this map are representations of taxing jurisdictions for the purpose of determining sales and use tax rates and should not be used to determine precise city or county boundary line locations. Boundary ProcessingThese data make a structural change from the source data. While the full boundaries provided by CDTFA include coastal buffers of varying sizes, many users need boundaries to end at the shoreline of the ocean or a bay. As a result, after examining existing city and county boundary layers, these datasets provide a coastline cut generally along the ocean facing coastline. For county boundaries in northern California, the cut runs near the Golden Gate Bridge, while for cities, we cut along the bay shoreline and into the edge of the Delta at the boundaries of Solano, Contra Costa, and Sacramento counties. In the services linked above, the versions that include the coastal buffers contain them as a second (or third) polygon for the city or county, with the value in the COASTAL field set to whether it"s a bay or ocean polygon. These can be processed back into a single polygon by dissolving on all the fields you wish to keep, since the attributes, other than the COASTAL field and geometry attributes (like areas) remain the same between the polygons for this purpose. SliversIn cases where a city or county"s boundary ends near a coastline, our coastline data may cross back and forth many times while roughly paralleling the jurisdiction"s boundary, resulting in many polygon slivers. We post-process the data to remove these slivers using a city/county boundary priority algorithm. That is, when the data run parallel to each other, we discard the coastline cut and keep the CDTFA-provided boundary, even if it extends into the ocean a small amount. This processing supports consistent boundaries for Fort Bragg, Point Arena, San Francisco, Pacifica, Half Moon Bay, and Capitola, in addition to others. More information on this algorithm will be provided soon. Coastline CaveatsSome cities have buffers extending into water bodies that we do not cut at the shoreline. These include South Lake Tahoe and Folsom, which extend into neighboring lakes, and San Diego and surrounding cities that extend into San Diego Bay, which our shoreline encloses. If you have feedback on the exclusion of these

Survey results are available in two seperate formats. The .csv output contains all non-spatial data from the main survey form, and can be loaded in spreadsheet programs such as Microsoft Excel. The spatial content of the survey is available as a zipped collection of one or more shapefiles. These files can be opened in GIS applications such as ArcGISor QGIS. Please note, only completed survey responses are exported. Those still in draft will be excluded.Output columns in both the CSV and shapefile formats are named based on the exportidspecified in the form field configuration. If you are looking to analyze spatial data from the shapefiles based on attributes collected in the main response form, you can join fields from the CSV file with spatial features by joining on the RESPONSE_ID field.

This dataset contains files created, digitized, or georeferenced by Chris DeRolph for mapping the pre-urban renewal community within the boundaries of the Riverfront-Willow St. and Mountain View urban renewal projects in Knoxville TN. Detailed occupant information for properties within boundaries of these two urban renewal projects was extracted from the 1953 Knoxville City Directory. The year 1953 was chosen as a representative snapshot of the Black community before urban renewal projects were implemented. The first urban renewal project to be approved was the Riverfront-Willow Street project, which was approved in 1954 according to the University of Richmond Renewing Inequality project titled ‘Family Displacements through Urban Renewal, 1950-1966’ (link below in the 'Other shapefiles' section). For ArcGIS Online users, the shapefile and tiff layers are available in AGOL and can be found by clicking the ellipsis next to the layer name and selecting 'Show item details' for the layers in this webmap https://knoxatlas.maps.arcgis.com/apps/webappviewer/index.html?id=43a66c3cfcde4f5f8e7ab13af9bbcebecityDirectory1953 is a folder that contains:JPG images of 1953 City Directory for street segments within the urban renewal project boundaries; images collected at the McClung Historical CollectionTXT files of extracted text from each image that was used to join occupant information from directory to GIS address datashp is a folder that contains the following shapefiles:Residential:Black_owned_residential_1953.shp: residential entries in the 1953 City Directory identified as Black and property ownersBlack_rented_residential_1953.shp: residential entries in the 1953 City Directory identified as Black and non-owners of the propertyNon_Black_owned_residential_1953.shp: residential entries in the 1953 City Directory identified as property owners that were not listed as BlackNon_Black_rented_residential_1953.shp: residential entries in the 1953 City Directory not listed as Black or property ownersResidential shapefile attributes:cityDrctryString: full text string from 1953 City Directory entryfileName: name of TXT file that contains the information for the street segmentsOccupant: the name of the occupant listed in the City Directory, enclosed in square brackets []Number: the address number listed in the 1953 City DirectoryBlackOccpt: flag for whether the occupant was identified in the City Directory as Black, designated by the (c) or (e) character string in the cityDrctryString fieldOwnerOccpd: flag for whether the occupant was identified in the City Directory as the property owner, designated by the @ character in the cityDrctryString fieldUnit: unit if listed (e.g. Apt 1, 2d fl, b'ment, etc)streetName: street name in ~1953Lat: latitude coordinate in decimal degrees for the property locationLon: longitude coordinate in decimal degrees for the property locationrace_own: combines the BlackOccpt and OwnerOccpd fieldsmapLabel: combines the Number and Occupant fields for map labeling purposeslastName: occupant's last namelabelShort: combines the Number and lastName fields for map labeling purposesNon-residential:Black_nonResidential_1953.shp: non-residential entries in the 1953 City Directory listed as Black-occupiedNonBlack_nonResidential_1953.shp: non-residential entries in the 1953 City Directory not listed as Black-occupiedNon-residential shapefile attributes:cityDrctryString: full text string from 1953 City Directory entryfileName: name of TXT file that contains the information for the street segmentsOccupant: the name of the occupant listed in the City Directory, enclosed in square brackets []Number: the address number listed in the 1953 City DirectoryBlackOccpt: flag for whether the occupant was identified in the City Directory as Black, designated by the (c) or (e) character string in the cityDrctryString fieldOwnerOccpd: flag for whether the occupant was identified in the City Directory as the property owner, designated by the @ character in the cityDrctryString fieldUnit: unit if listed (e.g. Apt 1, 2d fl, b'ment, etc)streetName: street name in ~1953Lat: latitude coordinate in decimal degrees for the property locationLon: longitude coordinate in decimal degrees for the property locationNAICS6: 2022 North American Industry Classification System (NAICS) six-digit business code, designated by Chris DeRolph rapidly and without careful considerationNAICS6title: NAICS6 title/short descriptionNAICS3: 2022 North American Industry Classification System (NAICS) three-digit business code, designated by Chris DeRolph rapidly and without careful considerationNAICS3title: NAICS3 title/short descriptionflag: flags whether the occupant is part of the public sector or an NGO; a flag of '0' indicates the occupant is assumed to be a privately-owned businessrace_own: combines the BlackOccpt and OwnerOccpd fieldsmapLabel: combines the Number and Occupant fields for map labeling purposesOther shapefiles:razedArea_1972.shp: approximate area that appears to have been razed during urban renewal based on visual overlay of usgsImage_grayscale_1956.tif and usgsImage_colorinfrared_1972.tif; digitized by Chris DeRolphroadNetwork_preUrbanRenewal.shp: road network present in urban renewal area before razing occurred; removed attribute indicates whether road was removed or remains today; historically removed roads were digitized by Chris DeRolph; remaining roads sourced from TDOT GIS roads dataTheBottom.shp: the approximate extent of the razed neighborhood known as The Bottom; digitized by Chris DeRolphUrbanRenewalProjects.shp: boundaries of the East Knoxville urban renewal projects, as mapped by the University of Richmond's Digital Scholarship Lab https://dsl.richmond.edu/panorama/renewal/#view=0/0/1&viz=cartogram&city=knoxvilleTN&loc=15/35.9700/-83.9080tiff is a folder that contains the following images:streetMap_1952.tif: relevant section of 1952 map 'Knoxville Tennessee and Surrounding Area'; copyright by J.U.G. Rich and East Tenn Auto Club; drawn by R.G. Austin; full map accessed at McClung Historical Collection, 601 S Gay St, Knoxville, TN 37902; used as reference for street names in roadNetwork_preUrbanRenewal.shp; georeferenced by Chris DeRolphnewsSentinelRdMap_1958.tif: urban renewal area map from 1958 Knox News Sentinel article; used as reference for street names in roadNetwork_preUrbanRenewal.shp; georeferenced by Chris DeRolphusgsImage_grayscale_1956.tif: May 18, 1956 black-and-white USGS aerial photograph, georeferenced by Chris DeRolph; accessed here https://earthexplorer.usgs.gov/scene/metadata/full/5e83d8e4870f4473/ARA550590030582/usgsImage_colorinfrared_1972.tif: April 18, 1972 color infrared USGS aerial photograph, georeferenced by Chris DeRolph; accessed here https://earthexplorer.usgs.gov/scene/metadata/full/5e83d8e4870f4473/AR6197002600096/usgsImage_grayscale_1976.tif: November 8, 1976 black-and-white USGS aerial photograph, georeferenced by Chris DeRolph; accessed here https://earthexplorer.usgs.gov/scene/metadata/full/5e83d8e4870f4473/AR1VDUT00390010/

911 Public Safety Answering Point (PSAP) service area boundaries in the United States According to the National Emergency Number Association (NENA), a Public Safety Answering Point (PSAP) is a facility equipped and staffed to receive 9-1-1 calls. The service area is the geographic area within which a 911 call placed using a landline is answered at the associated PSAP. This dataset only includes primary PSAPs. Secondary PSAPs, backup PSAPs, and wireless PSAPs have been excluded from this dataset. Primary PSAPs receive calls directly, whereas secondary PSAPs receive calls that have been transferred by a primary PSAP. Backup PSAPs provide service in cases where another PSAP is inoperable. Most military bases have their own emergency telephone systems. To connect to such a system from within a military base, it may be necessary to dial a number other than 9 1 1. Due to the sensitive nature of military installations, TGS did not actively research these systems. If civilian authorities in surrounding areas volunteered information about these systems, or if adding a military PSAP was necessary to fill a hole in civilian provided data, TGS included it in this dataset. Otherwise, military installations are depicted as being covered by one or more adjoining civilian emergency telephone systems. In some cases, areas are covered by more than one PSAP boundary. In these cases, any of the applicable PSAPs may take a 911 call. Where a specific call is routed may depend on how busy the applicable PSAPs are (i.e., load balancing), operational status (i.e., redundancy), or time of day / day of week. If an area does not have 911 service, TGS included that area in the dataset along with the address and phone number of their dispatch center. These are areas where someone must dial a 7 or 10 digit number to get emergency services. These records can be identified by a "Y" in the [NON911EMNO] field. This indicates that dialing 911 inside one of these areas does not connect one with emergency services. This dataset was constructed by gathering information about PSAPs from state level officials. In some cases, this was geospatial information; in other cases, it was tabular. This information was supplemented with a list of PSAPs from the Federal Communications Commission (FCC). Each PSAP was researched to verify its tabular information. In cases where the source data was not geospatial, each PSAP was researched to determine its service area in terms of existing boundaries (e.g., city and county boundaries). In some cases, existing boundaries had to be modified to reflect coverage areas (e.g., "entire county north of Country Road 30"). However, there may be cases where minor deviations from existing boundaries are not reflected in this dataset, such as the case where a particular PSAPs coverage area includes an entire county plus the homes and businesses along a road which is partly in another county. At the request of NGA, text fields in this dataset have been set to all upper case to facilitate consistent database engine search results. At the request of NGA, all diacritics (e.g., the German umlaut or the Spanish tilde) have been replaced with their closest equivalent English character to facilitate use with database systems that may not support diacritics.

This feature layer provides digital tax parcels for the Organized Towns of the State of Maine. Within Maine, real property data is maintained by the government organization responsible for assessing and collecting property tax for a given location. Organized towns and townships maintain authoritative data for their communities and may voluntarily submit these data to the Maine GeoLibrary Parcel Project. "Maine Parcels Organized Towns Feature" and "Maine Parcels Organized Towns ADB" are the product of these voluntary submissions. Communities provide updates to the Maine GeoLibrary on a non-regular basis, which affects the currency of Maine GeoLibrary parcels data. Another resource for real property transaction data is the County Registry of Deeds, although organized town data should very closely match registry information, except in the case of in-process property conveyance transactions. In Unorganized Territories (defined as those regions of the state without a local government that assesses real property and collects property tax), the Maine Revenue Service is the authoritative source for parcel data. "Maine Parcels Unorganized Territory Feature" is the authoritative GIS data layer for the Unorganized Territories. However, it must always be used with auxiliary data obtained from the online resources of Maine Revenue Services (https://www.maine.gov/revenue/taxes/property-tax) to compile up-to-date parcel ownership information. Property maps are a fundamental base for many municipal activities. Although GIS parcel data cannot replace detailed ground surveys, the data can assist municipal officials with functions such as accurate property tax assessment, planning and zoning. Towns can link maps to an assessor's database and display local information, while town officials can show taxpayers how proposed development or changes in municipal services and regulations may affect the community. In many towns, parcel data also helps to provide public notices, plan bus routes, and carry out other municipal services.

This dataset contains municipality-submitted parcel data along with previously developed parcel data acquired through the Municipal Grants Project supported by the Maine Library of Geographic Information (Maine GeoLibrary). Grant recipient parcel data submissions were guided by standards presented to the Maine GeoLibrary Board on May 21, 2005, which are outlined in the "Standards for Digital Parcel Files" document available on the Maine GeoLibrary publications page (https://www.maine.gov/geolib/policies/standards.html). This dataset also contains municipal parcel data acquired through other sources; the data sources are identified (where available) by the field “FMSCORG”. Note: Join this feature layer with the "Maine Parcels Organized Towns ADB" table (https://maine.hub.arcgis.com/maps/maine::maine-parcels-organized-towns-feature/about?layer=1) for available ownership information. A date field, “FMUPDAT”, is attributed with the most recent update date for each individual parcel if available. The "FMUPDAT" field will not match the "Updated" value shown for the layer. "FMUPDAT" corresponds with the date of update for the individual data, while "Updated" corresponds with the date of update for the ArcGIS Online layer as a whole. Many parcels have not been updated in several years; use the "FMUPDAT" field to verify currency.

Update information can be found within the layer’s attributes and in a table on the Utah Parcel Data webpage under LIR Parcels.In Spring of 2016, the Land Information Records work group, an informal committee organized by the Governor’s Office of Management and Budget’s State Planning Coordinator, produced recommendations for expanding the sharing of GIS-based parcel information. Participants in the LIR work group included representatives from county, regional, and state government, including the Utah Association of Counties (County Assessors and County Recorders), Wasatch Front Regional Council, Mountainland and Bear River AOGs, Utah League of Cities and Towns, UDOT, DNR, AGRC, the Division of Emergency Management, Blue Stakes, economic developers, and academic researchers. The LIR work group’s recommendations set the stage for voluntary sharing of additional objective/quantitative parcel GIS data, primarily around tax assessment-related information. Specifically the recommendations document establishes objectives, principles (including the role of local and state government), data content items, expected users, and a general process for data aggregation and publishing. An important realization made by the group was that ‘parcel data’ or ‘parcel record’ products have a different meaning to different users and data stewards. The LIR group focused, specifically, on defining a data sharing recommendation around a tax year parcel GIS data product, aligned with the finalization of the property tax roll by County Assessors on May 22nd of each year. The LIR recommendations do not impact the periodic sharing of basic parcel GIS data (boundary, ID, address) from the County Recorders to AGRC per 63F-1-506 (3.b.vi). Both the tax year parcel and the basic parcel GIS layers are designed for general purpose uses, and are not substitutes for researching and obtaining the most current, legal land records information on file in County records. This document, below, proposes a schedule, guidelines, and process for assembling county parcel and assessment data into an annual, statewide tax parcel GIS layer. gis.utah.gov/data/sgid-cadastre/It is hoped that this new expanded parcel GIS layer will be put to immediate use supporting the best possible outcomes in public safety, economic development, transportation, planning, and the provision of public services. Another aim of the work group was to improve the usability of the data, through development of content guidelines and consistent metadata documentation, and the efficiency with which the data sharing is distributed.GIS Layer Boundary Geometry:GIS Format Data Files: Ideally, Tax Year Parcel data should be provided in a shapefile (please include the .shp, .shx, .dbf, .prj, and .xml component files) or file geodatabase format. An empty shapefile and file geodatabase schema are available for download at:At the request of a county, AGRC will provide technical assistance to counties to extract, transform, and load parcel and assessment information into the GIS layer format.Geographic Coverage: Tax year parcel polygons should cover the area of each county for which assessment information is created and digital parcels are available. Full coverage may not be available yet for each county. The county may provide parcels that have been adjusted to remove gaps and overlaps for administrative tax purposes or parcels that retain these expected discrepancies that take their source from the legally described boundary or the process of digital conversion. The diversity of topological approaches will be noted in the metadata.One Tax Parcel Record Per Unique Tax Notice: Some counties produce an annual tax year parcel GIS layer with one parcel polygon per tax notice. In some cases, adjacent parcel polygons that compose a single taxed property must be merged into a single polygon. This is the goal for the statewide layer but may not be possible in all counties. AGRC will provide technical support to counties, where needed, to merge GIS parcel boundaries into the best format to match with the annual assessment information.Standard Coordinate System: Parcels will be loaded into Utah’s statewide coordinate system, Universal Transverse Mercator coordinates (NAD83, Zone 12 North). However, boundaries stored in other industry standard coordinate systems will be accepted if they are both defined within the data file(s) and documented in the metadata (see below).Descriptive Attributes:Database Field/Column Definitions: The table below indicates the field names and definitions for attributes requested for each Tax Parcel Polygon record.FIELD NAME FIELD TYPE LENGTH DESCRIPTION EXAMPLE SHAPE (expected) Geometry n/a The boundary of an individual parcel or merged parcels that corresponds with a single county tax notice ex. polygon boundary in UTM NAD83 Zone 12 N or other industry standard coordinates including state plane systemsCOUNTY_NAME Text 20 - County name including spaces ex. BOX ELDERCOUNTY_ID (expected) Text 2 - County ID Number ex. Beaver = 1, Box Elder = 2, Cache = 3,..., Weber = 29ASSESSOR_SRC (expected) Text 100 - Website URL, will be to County Assessor in most all cases ex. webercounty.org/assessorBOUNDARY_SRC (expected) Text 100 - Website URL, will be to County Recorder in most all cases ex. webercounty.org/recorderDISCLAIMER (added by State) Text 50 - Disclaimer URL ex. gis.utah.gov...CURRENT_ASOF (expected) Date - Parcels current as of date ex. 01/01/2016PARCEL_ID (expected) Text 50 - County designated Unique ID number for individual parcels ex. 15034520070000PARCEL_ADD (expected, where available) Text 100 - Parcel’s street address location. Usually the address at recordation ex. 810 S 900 E #304 (example for a condo)TAXEXEMPT_TYPE (expected) Text 100 - Primary category of granted tax exemption ex. None, Religious, Government, Agriculture, Conservation Easement, Other Open Space, OtherTAX_DISTRICT (expected, where applicable) Text 10 - The coding the county uses to identify a unique combination of property tax levying entities ex. 17ATOTAL_MKT_VALUE (expected) Decimal - Total market value of parcel's land, structures, and other improvements as determined by the Assessor for the most current tax year ex. 332000LAND _MKT_VALUE (expected) Decimal - The market value of the parcel's land as determined by the Assessor for the most current tax year ex. 80600PARCEL_ACRES (expected) Decimal - Parcel size in acres ex. 20.360PROP_CLASS (expected) Text 100 - Residential, Commercial, Industrial, Mixed, Agricultural, Vacant, Open Space, Other ex. ResidentialPRIMARY_RES (expected) Text 1 - Is the property a primary residence(s): Y'(es), 'N'(o), or 'U'(nknown) ex. YHOUSING_CNT (expected, where applicable) Text 10 - Number of housing units, can be single number or range like '5-10' ex. 1SUBDIV_NAME (optional) Text 100 - Subdivision name if applicable ex. Highland Manor SubdivisionBLDG_SQFT (expected, where applicable) Integer - Square footage of primary bldg(s) ex. 2816BLDG_SQFT_INFO (expected, where applicable) Text 100 - Note for how building square footage is counted by the County ex. Only finished above and below grade areas are counted.FLOORS_CNT (expected, where applicable) Decimal - Number of floors as reported in county records ex. 2FLOORS_INFO (expected, where applicable) Text 100 - Note for how floors are counted by the County ex. Only above grade floors are countedBUILT_YR (expected, where applicable) Short - Estimated year of initial construction of primary buildings ex. 1968EFFBUILT_YR (optional, where applicable) Short - The 'effective' year built' of primary buildings that factors in updates after construction ex. 1980CONST_MATERIAL (optional, where applicable) Text 100 - Construction Material Types, Values for this field are expected to vary greatly by county ex. Wood Frame, Brick, etc Contact: Sean Fernandez, Cadastral Manager (email: sfernandez@utah.gov; office phone: 801-209-9359)

🇺🇸 미국 English This feature class was derived from the GIS polygon datasets BLM Grazing Allotments and BLM Grazing Pastures, which were downloaded from the Geospatial Gateway in April 2025. Fields were added to the feature classes and calculated as needed to allow the Rangeland Administration System (RAS) tabular data to be joined to the GIS datasets. RAS tabular data for Billed allotments and pastures (as of April 2025) was provided by BLM Rangeland Management Specialist Josh Robbins in April 2025 and processed as dbfs, with fields added and calculated as needed to match the BLM GIS Grazing Allotments feature class. RAS tables and BLM GIS data for allotments were joined using the State Allotment Number, a concatenation of allotment number and BLM Administrative State for allotments (ST_ALLOT_NUM). To match numbered pastures in the RAS data and BLM GIS data, the pasture number (if present) was added to the State Allotment Number (ST_ALLOT_PAST_NUM). RAS records for Billed Allotments that did not match during a join operation were tracked in a separate excel sheet from the matching records. Matching records were then joined back to the BLM GIS Allotments grazing feature class and Allotment name fields were edited as necessary. A Status field was added to indicate if the data are either Billed or Authorized and a Source field was added to indicate if the data came from Allotments, Trailing Allotments, or Pastures. An additional field, TR_ALLOT_NUM, was added to designate any Trailing Allotments in the data. Trailing allotments were identified and processed separately for Nevada, since these allotments overlap portions of other allotments. Any overlaps in the data were removed via dissolve and Spatial Join. Billed Allotments and Pastures final feature classes were then unioned together, with fields examined to ensure that all data was captured. Input BLM GIS Grazing data:BLM Grazing Pastures and BLM Grazing Allotments are areas of land designated and managed for grazing of livestock. It may include private, state, and public lands under the jurisdiction of the Bureau of Land Management and/or other federal agencies. An allotment is derived from its pastures, where the grazing of livestock is occurring. The attributes of the BLM Grazing Allotment features may be duplicated in RAS, but are considered to be minimum information for unique identification and cartographic purposes.Input RAS Data:The Rangeland Administration System (RAS) provides grazing administrative support and management reports for the BLM and the public. The Rangeland Administration system serves as an electronic calendar for issuance of applications and grazing authorizations, including Permits, Leases, and Exchange-of-Use Agreements. The Billed data is current as of April 2025 and was provided by BLM Rangeland Management Specialist Josh Robbins in April 2025.

Geotweet Archive v2.0 The Harvard Center for Geographic Analysis (CGA) maintains the Geotweet Archive, a global record of tweets spanning time, geography, and language. The primary purpose of the Archive is to make a comprehensive collection of geo-located tweets available to the academic research community. The Archive extends from 2010 to the present and is updated daily. The number of tweets in the collection totals approximately 10 billion, and it is stored on Harvard University’s High Performance Computing (HPC) cluster. The Harvard HPC supports many applications for working with big spatio-temporal datasets, including two geospatial tools recently deployed by the CGA: OmniSci Immerse, and PostGIS. The Geotweet Archive consists of tweets which carry two types of geospatial signature: 1) GPS-based longitude/latitude generated by the originating device 2) Place-name-centroid-based longitude/latitude from the bounding box provided by Twitter, based on the user-define place designation (typically a town name). Any tweet which carries one or both of these signatures is included in the Archive. Approximately 1-2% of all tweets contain such geographic coordinates, (this percentage needs verification and may vary over time). The current version of the Archive is Version 2.0. The original Version 1.0 archive began in 2012 as part of a project with Ben Lewis of CGA and then Harvard graduate student Todd Mostak, to develop a GPU-powered spatial database called GEOPS. GEOPS formed the basis for technology startup MapD Technologies, which is now OmniSci. OmniSci Immerse software now runs on Harvard’s High Performance Computing (HPC) environment to support interactive exploration and analytics with the Geotweet Archive and any other large datasets. Version 2.0 of the archive represents the results of a merge between the CGA archive, and an archive developed by the Department of Geoinformatics at the University of Salzburg in Austria, as well as several other archives. Clemens Havas and Bernd Resch at University of Salzburg, and Devika Kakkar of Harvard CGA collaborated to deploy Version 2.0. ======================================================== Schema of Geotweet Archive v2.0 Field name_TYPE_Description message_id----BIGINT----Tweet ID tweet_date----TIMESTAMP----Date and time of tweet from Twitter (utc) tweet_text----TEXT ENCODING----Text content of tweet tags----TEXT ENCODING DICT----Tweet hashtags tweet_lang----TEXT ENCODING DICT----Language that the tweet is in source ----TEXT ENCODING DICT----Operating system or application type used to create the tweet place*----TEXT ENCODING NONE----The geographic place as defined by the user, usually a town name. A bounding box determined by Twitter based on this field, from which centroids (see longitude and latitude fields) and the spatial_error field are derived, and used when not overridden by a GPS coordinate. See Twitter tweet object for place. retweets ----SMALLINT----Number of retweets as of last time it was checked tweet_favorites----SMALLINT----Now known as ‘likes’ photo_url----TEXT ENCODING DICT----URL of any image referenced quoted_status_id ----BIGINT----ID number for quote status user_id ----BIGINT----User ID number user_name----TEXT ENCODING NONE----User name user_location*----TEXT ENCODING NONE----User defined location, usually a city or town. See Twitter user object. followers ----SMALLINT----Followers as of the last time checked friends ----SMALLINT----Number of users followed by this user user_favorites----INT----Number of topics the user is interested in status----INT----Code for what user is doing as of last time it was checked user_lang----TEXT ENCODING DICT----User defined language latitude----FLOAT----Latitude from GPS or bounding box based on Place field longitude----FLOAT----Longitude from GPS or bounding box based on Place field data_source*----TEXT ENCODING DICT----The source crawler or dataset for the tweet gps----TEXT ENCODING DICT----Flag for whether lon/lat is from GPS or town name bounding box (SRID – 4326). When both are present, the GPS coordinate takes priority. spatialerror----FLOAT----Estimate in meters horizontal error for lon/lat coordinate. 10m for GPS coordinates, error for bounding boxes calculated as radius of circle with area of bounding box. ===================================================== *data_source_Code U. Salzburg REST API crawler----1 Harvard CGA streaming crawler----2 U. Salzburg streaming API crawler----3 Ryan Qi Wang and Harvard Medical School datasets----4 U. Heidelberg dataset----5 Archive.org dataset----6 ---------------------------------------------------------------------------------------------- Note: Before April of 2015 the default for GPS coordinate capture was turned on for Twitter users. After this date users have had to opt-in to share their precise location. This is one reason for the large decrease in volume of geotweets after this date. A number of automated...

WARNING: This is a pre-release dataset and its fields names and data structures are subject to change. It should be considered pre-release until the end of 2024. Expected changes:

• Metadata is missing or incomplete for some layers at this time and will be continuously improved.
  
• We expect to update this layer roughly in line with CDTFA at some point, but will increase the update cadence over time as we are able to automate the final pieces of the process.

Purpose

County and incorporated place (city) boundaries along with third party identifiers used to join in external data. Boundaries are from the authoritative source the California Department of Tax and Fee Administration (CDTFA), altered to show the counties as one polygon. This layer displays the city polygons on top of the County polygons so the area isn"t interrupted. The GEOID attribute information is added from the US Census. GEOID is based on merged State and County FIPS codes for the Counties. Abbreviations for Counties and Cities were added from Caltrans Division of Local Assistance (DLA) data. Place Type was populated with information extracted from the Census. Names and IDs from the US Board on Geographic Names (BGN), the authoritative source of place names as published in the Geographic Name Information System (GNIS), are attached as well. Finally, the coastline is used to separate coastal buffers from the land-based portions of jurisdictions. This feature layer is for public use.

Related Layers

This dataset is part of a grouping of many datasets:

1. Cities: Only the city boundaries and attributes, without any unincorporated areas
   • With Coastal Buffers
   • Without Coastal Buffers
2. Counties: Full county boundaries and attributes, including all cities within as a single polygon
   • With Coastal Buffers
   • Without Coastal Buffers
3. Cities and Full Counties: A merge of the other two layers, so polygons overlap within city boundaries. Some customers require this behavior, so we provide it as a separate service.
   • With Coastal Buffers (this dataset)
   • Without Coastal Buffers
4. Place Abbreviations
5. Unincorporated Areas (Coming Soon)
6. Census Designated Places (Coming Soon)
   
7. Cartographic Coastline
   • Polygon
   • Line source (Coming Soon)

Point of Contact

California Department of Technology, Office of Digital Services, odsdataservices@state.ca.gov

Field and Abbreviation Definitions

• COPRI: county number followed by the 3-digit city primary number used in the Board of Equalization"s 6-digit tax rate area numbering system
• Place Name: CDTFA incorporated (city) or county name
• County: CDTFA county name. For counties, this will be the name of the polygon itself. For cities, it is the name of the county the city polygon is within.
• Legal Place Name: Board on Geographic Names authorized nomenclature for area names published in the Geographic Name Information System
• GNIS_ID: The numeric identifier from the Board on Geographic Names that can be used to join these boundaries to other datasets utilizing this identifier.
• GEOID: numeric geographic identifiers from the US Census Bureau Place Type: Board on Geographic Names authorized nomenclature for boundary type published in the Geographic Name Information System
• Place Abbr: CalTrans Division of Local Assistance abbreviations of incorporated area names
• CNTY Abbr: CalTrans Division of Local Assistance abbreviations of county names
• Area_SqMi: The area of the administrative unit (city or county) in square miles, calculated in EPSG 3310 California Teale Albers.
• COASTAL: Indicates if the polygon is a coastal buffer. Null for land polygons. Additional values include "ocean" and "bay".
• GlobalID: While all of the layers we provide in this dataset include a GlobalID field with unique values, we do not recommend you make any use of it. The GlobalID field exists to support offline sync, but is not persistent, so data keyed to it will be orphaned at our next update. Use one of the other persistent identifiers, such as GNIS_ID or GEOID instead.

Accuracy

CDTFA"s source data notes the following about accuracy:

City boundary changes and county boundary line adjustments filed with the Board of Equalization per Government Code 54900. This GIS layer contains the boundaries of the unincorporated county and incorporated cities within the state of California. The initial dataset was created in March of 2015 and was based on the State Board of Equalization tax rate area boundaries. As of April 1, 2024, the maintenance of this dataset is provided by the California Department of Tax and Fee Administration for the purpose of determining sales and use tax rates. The boundaries are continuously being revised to align with aerial imagery when areas of conflict are discovered between the original boundary provided by the California State Board of Equalization and the boundary made publicly available by local, state, and federal government. Some differences may occur between actual recorded boundaries and the boundaries used for sales and use tax purposes. The boundaries in this map are representations of taxing jurisdictions for the purpose of determining sales and use tax rates and should not be used to determine precise city or county boundary line locations. COUNTY = county name; CITY = city name or unincorporated

Update information can be found within the layer’s attributes and in a table on the Utah Parcel Data webpage under LIR Parcels.In Spring of 2016, the Land Information Records work group, an informal committee organized by the Governor’s Office of Management and Budget’s State Planning Coordinator, produced recommendations for expanding the sharing of GIS-based parcel information. Participants in the LIR work group included representatives from county, regional, and state government, including the Utah Association of Counties (County Assessors and County Recorders), Wasatch Front Regional Council, Mountainland and Bear River AOGs, Utah League of Cities and Towns, UDOT, DNR, AGRC, the Division of Emergency Management, Blue Stakes, economic developers, and academic researchers. The LIR work group’s recommendations set the stage for voluntary sharing of additional objective/quantitative parcel GIS data, primarily around tax assessment-related information. Specifically the recommendations document establishes objectives, principles (including the role of local and state government), data content items, expected users, and a general process for data aggregation and publishing. An important realization made by the group was that ‘parcel data’ or ‘parcel record’ products have a different meaning to different users and data stewards. The LIR group focused, specifically, on defining a data sharing recommendation around a tax year parcel GIS data product, aligned with the finalization of the property tax roll by County Assessors on May 22nd of each year. The LIR recommendations do not impact the periodic sharing of basic parcel GIS data (boundary, ID, address) from the County Recorders to AGRC per 63F-1-506 (3.b.vi). Both the tax year parcel and the basic parcel GIS layers are designed for general purpose uses, and are not substitutes for researching and obtaining the most current, legal land records information on file in County records. This document, below, proposes a schedule, guidelines, and process for assembling county parcel and assessment data into an annual, statewide tax parcel GIS layer. gis.utah.gov/data/sgid-cadastre/It is hoped that this new expanded parcel GIS layer will be put to immediate use supporting the best possible outcomes in public safety, economic development, transportation, planning, and the provision of public services. Another aim of the work group was to improve the usability of the data, through development of content guidelines and consistent metadata documentation, and the efficiency with which the data sharing is distributed.GIS Layer Boundary Geometry:GIS Format Data Files: Ideally, Tax Year Parcel data should be provided in a shapefile (please include the .shp, .shx, .dbf, .prj, and .xml component files) or file geodatabase format. An empty shapefile and file geodatabase schema are available for download at:At the request of a county, AGRC will provide technical assistance to counties to extract, transform, and load parcel and assessment information into the GIS layer format.Geographic Coverage: Tax year parcel polygons should cover the area of each county for which assessment information is created and digital parcels are available. Full coverage may not be available yet for each county. The county may provide parcels that have been adjusted to remove gaps and overlaps for administrative tax purposes or parcels that retain these expected discrepancies that take their source from the legally described boundary or the process of digital conversion. The diversity of topological approaches will be noted in the metadata.One Tax Parcel Record Per Unique Tax Notice: Some counties produce an annual tax year parcel GIS layer with one parcel polygon per tax notice. In some cases, adjacent parcel polygons that compose a single taxed property must be merged into a single polygon. This is the goal for the statewide layer but may not be possible in all counties. AGRC will provide technical support to counties, where needed, to merge GIS parcel boundaries into the best format to match with the annual assessment information.Standard Coordinate System: Parcels will be loaded into Utah’s statewide coordinate system, Universal Transverse Mercator coordinates (NAD83, Zone 12 North). However, boundaries stored in other industry standard coordinate systems will be accepted if they are both defined within the data file(s) and documented in the metadata (see below).Descriptive Attributes:Database Field/Column Definitions: The table below indicates the field names and definitions for attributes requested for each Tax Parcel Polygon record.FIELD NAME FIELD TYPE LENGTH DESCRIPTION EXAMPLE SHAPE (expected) Geometry n/a The boundary of an individual parcel or merged parcels that corresponds with a single county tax notice ex. polygon boundary in UTM NAD83 Zone 12 N or other industry standard coordinates including state plane systemsCOUNTY_NAME Text 20 - County name including spaces ex. BOX ELDERCOUNTY_ID (expected) Text 2 - County ID Number ex. Beaver = 1, Box Elder = 2, Cache = 3,..., Weber = 29ASSESSOR_SRC (expected) Text 100 - Website URL, will be to County Assessor in most all cases ex. webercounty.org/assessorBOUNDARY_SRC (expected) Text 100 - Website URL, will be to County Recorder in most all cases ex. webercounty.org/recorderDISCLAIMER (added by State) Text 50 - Disclaimer URL ex. gis.utah.gov...CURRENT_ASOF (expected) Date - Parcels current as of date ex. 01/01/2016PARCEL_ID (expected) Text 50 - County designated Unique ID number for individual parcels ex. 15034520070000PARCEL_ADD (expected, where available) Text 100 - Parcel’s street address location. Usually the address at recordation ex. 810 S 900 E #304 (example for a condo)TAXEXEMPT_TYPE (expected) Text 100 - Primary category of granted tax exemption ex. None, Religious, Government, Agriculture, Conservation Easement, Other Open Space, OtherTAX_DISTRICT (expected, where applicable) Text 10 - The coding the county uses to identify a unique combination of property tax levying entities ex. 17ATOTAL_MKT_VALUE (expected) Decimal - Total market value of parcel's land, structures, and other improvements as determined by the Assessor for the most current tax year ex. 332000LAND _MKT_VALUE (expected) Decimal - The market value of the parcel's land as determined by the Assessor for the most current tax year ex. 80600PARCEL_ACRES (expected) Decimal - Parcel size in acres ex. 20.360PROP_CLASS (expected) Text 100 - Residential, Commercial, Industrial, Mixed, Agricultural, Vacant, Open Space, Other ex. ResidentialPRIMARY_RES (expected) Text 1 - Is the property a primary residence(s): Y'(es), 'N'(o), or 'U'(nknown) ex. YHOUSING_CNT (expected, where applicable) Text 10 - Number of housing units, can be single number or range like '5-10' ex. 1SUBDIV_NAME (optional) Text 100 - Subdivision name if applicable ex. Highland Manor SubdivisionBLDG_SQFT (expected, where applicable) Integer - Square footage of primary bldg(s) ex. 2816BLDG_SQFT_INFO (expected, where applicable) Text 100 - Note for how building square footage is counted by the County ex. Only finished above and below grade areas are counted.FLOORS_CNT (expected, where applicable) Decimal - Number of floors as reported in county records ex. 2FLOORS_INFO (expected, where applicable) Text 100 - Note for how floors are counted by the County ex. Only above grade floors are countedBUILT_YR (expected, where applicable) Short - Estimated year of initial construction of primary buildings ex. 1968EFFBUILT_YR (optional, where applicable) Short - The 'effective' year built' of primary buildings that factors in updates after construction ex. 1980CONST_MATERIAL (optional, where applicable) Text 100 - Construction Material Types, Values for this field are expected to vary greatly by county ex. Wood Frame, Brick, etc Contact: Sean Fernandez, Cadastral Manager (email: sfernandez@utah.gov; office phone: 801-209-9359)

This dataset contains model-based census tract level estimates in GIS-friendly format. PLACES covers the entire United States—50 states and the District of Columbia—at county, place, census tract, and ZIP Code Tabulation Area levels. It provides information uniformly on this large scale for local areas at four geographic levels. Estimates were provided by the Centers for Disease Control and Prevention (CDC), Division of Population Health, Epidemiology and Surveillance Branch. PLACES was funded by the Robert Wood Johnson Foundation in conjunction with the CDC Foundation. Data sources used to generate these model-based estimates are Behavioral Risk Factor Surveillance System (BRFSS) 2022 or 2021 data, Census Bureau 2010 population estimates, and American Community Survey (ACS) 2015–2019 estimates. The 2024 release uses 2022 BRFSS data for 36 measures and 2021 BRFSS data for 4 measures (high blood pressure, high cholesterol, cholesterol screening, and taking medicine for high blood pressure control among those with high blood pressure) that the survey collects data on every other year. These data can be joined with the Census tract 2022 boundary file in a GIS system to produce maps for 40 measures at the census tract level. An ArcGIS Online feature service is also available for users to make maps online or to add data to desktop GIS software. https://cdcarcgis.maps.arcgis.com/home/item.html?id=3b7221d4e47740cab9235b839fa55cd7

Update information can be found within the layer’s attributes and in a table on the Utah Parcel Data webpageunder LIR Parcels.In Spring of 2016, the Land Information Records work group, an informal committee organized by the Governor’s Office of Management and Budget’s State Planning Coordinator, produced recommendations for expanding the sharing of GIS-based parcel information. Participants in the LIR work group included representatives from county, regional, and state government, including the Utah Association of Counties (County Assessors and County Recorders), Wasatch Front Regional Council, Mountainland and Bear River AOGs, Utah League of Cities and Towns, UDOT, DNR, AGRC, the Division of Emergency Management, Blue Stakes, economic developers, and academic researchers. The LIR work group’s recommendations set the stage for voluntary sharing of additional objective/quantitative parcel GIS data, primarily around tax assessment-related information. Specifically the recommendations document establishes objectives, principles (including the role of local and state government), data content items, expected users, and a general process for data aggregation and publishing. An important realization made by the group was that ‘parcel data’ or ‘parcel record’ products have a different meaning to different users and data stewards. The LIR group focused, specifically, on defining a data sharing recommendation around a tax year parcel GIS data product, aligned with the finalization of the property tax roll by County Assessors on May 22nd of each year. The LIR recommendations do not impact the periodic sharing of basic parcel GIS data (boundary, ID, address) from the County Recorders to AGRC per 63F-1-506 (3.b.vi). Both the tax year parcel and the basic parcel GIS layers are designed for general purpose uses, and are not substitutes for researching and obtaining the most current, legal land records information on file in County records. This document, below, proposes a schedule, guidelines, and process for assembling county parcel and assessment data into an annual, statewide tax parcel GIS layer. gis.utah.gov/data/sgid-cadastre/ It is hoped that this new expanded parcel GIS layer will be put to immediate use supporting the best possible outcomes in public safety, economic development, transportation, planning, and the provision of public services. Another aim of the work group was to improve the usability of the data, through development of content guidelines and consistent metadata documentation, and the efficiency with which the data sharing is distributed.GIS Layer Boundary Geometry:GIS Format Data Files: Ideally, Tax Year Parcel data should be provided in a shapefile (please include the .shp, .shx, .dbf, .prj, and .xml component files) or file geodatabase format. An empty shapefile and file geodatabase schema are available for download at:At the request of a county, AGRC will provide technical assistance to counties to extract, transform, and load parcel and assessment information into the GIS layer format.Geographic Coverage: Tax year parcel polygons should cover the area of each county for which assessment information is created and digital parcels are available. Full coverage may not be available yet for each county. The county may provide parcels that have been adjusted to remove gaps and overlaps for administrative tax purposes or parcels that retain these expected discrepancies that take their source from the legally described boundary or the process of digital conversion. The diversity of topological approaches will be noted in the metadata.One Tax Parcel Record Per Unique Tax Notice: Some counties produce an annual tax year parcel GIS layer with one parcel polygon per tax notice. In some cases, adjacent parcel polygons that compose a single taxed property must be merged into a single polygon. This is the goal for the statewide layer but may not be possible in all counties. AGRC will provide technical support to counties, where needed, to merge GIS parcel boundaries into the best format to match with the annual assessment information.Standard Coordinate System: Parcels will be loaded into Utah’s statewide coordinate system, Universal Transverse Mercator coordinates (NAD83, Zone 12 North). However, boundaries stored in other industry standard coordinate systems will be accepted if they are both defined within the data file(s) and documented in the metadata (see below).Descriptive Attributes:Database Field/Column Definitions: The table below indicates the field names and definitions for attributes requested for each Tax Parcel Polygon record.FIELD NAME FIELD TYPE LENGTH DESCRIPTION EXAMPLE SHAPE (expected) Geometry n/a The boundary of an individual parcel or merged parcels that corresponds with a single county tax notice ex. polygon boundary in UTM NAD83 Zone 12 N or other industry standard coordinates including state plane systemsCOUNTY_NAME Text 20 - County name including spaces ex. BOX ELDERCOUNTY_ID (expected) Text 2 - County ID Number ex. Beaver = 1, Box Elder = 2, Cache = 3,..., Weber = 29ASSESSOR_SRC (expected) Text 100 - Website URL, will be to County Assessor in most all cases ex. webercounty.org/assessorBOUNDARY_SRC (expected) Text 100 - Website URL, will be to County Recorder in most all cases ex. webercounty.org/recorderDISCLAIMER (added by State) Text 50 - Disclaimer URL ex. gis.utah.gov...CURRENT_ASOF (expected) Date - Parcels current as of date ex. 01/01/2016PARCEL_ID (expected) Text 50 - County designated Unique ID number for individual parcels ex. 15034520070000PARCEL_ADD (expected, where available) Text 100 - Parcel’s street address location. Usually the address at recordation ex. 810 S 900 E #304 (example for a condo)TAXEXEMPT_TYPE (expected) Text 100 - Primary category of granted tax exemption ex. None, Religious, Government, Agriculture, Conservation Easement, Other Open Space, OtherSalt Lake County Tax Exempt codes below:AE - Airport - ExemptCC - Commercial Common AreaCE - Conservation EasementCM - CemeteryEC - Exempt CharitableEE - Exempt EducationER - Exempt ReligiousGB - GreenbeltHE - Homeowners Assoc ExemptIL - In LieuIR - Irrigation CompanyMC - Master CardOE - Owner ExemptPE - Part ExemptPR - Pro-RatedPT - Privilege TaxPY - Privilege Tax on a YieldSA - State AssessedSC - State and Cnty AssessedSE - Special - ExemptSU - Salt Lake - Utah CntyTD - Divided Tax DistrictUI - Undivided_Interest TAX_DISTRICT (expected, where applicable) Text 10 - The coding the county uses to identify a unique combination of property tax levying entities ex. 17ATOTAL_MKT_VALUE (expected) Decimal - Total market value of parcel's land, structures, and other improvements as determined by the Assessor for the most current tax year ex. 332000LAND _MKT_VALUE (expected) Decimal - The market value of the parcel's land as determined by the Assessor for the most current tax year ex. 80600PARCEL_ACRES (expected) Decimal - Parcel size in acres ex. 20.360PROP_CLASS (expected) Text 100 - Residential, Commercial, Industrial, Mixed, Agricultural, Vacant, Open Space, Other ex. ResidentialSalt Lake County Property Class codes below:R - Residential / CondoC - CommercialI - IndustrialRE - RecreationalA - AgriculturalMH - Multi HousingMore information about the PROP_CLASS and PROP_TYPE for Salt Lake County can be found at http://slco.org/assessor/new/queryproptyp.cfmPROP_TYPE (expected) Text 100 - Single Family Res.,Townhome, CondoPRIMARY_RES (expected) Text 1 - Is the property a primary residence(s): Y'(es), 'N'(o), or 'U'(nknown) ex. YHOUSING_CNT (expected, where applicable) Text 10 - Number of housing units, can be single number or range like '5-10' ex. 1SUBDIV_NAME (optional) Text 100 - Subdivision name if applicable ex. Highland Manor SubdivisionBLDG_SQFT (expected, where applicable) Integer - Square footage of primary bldg(s) ex. 2816BLDG_SQFT_INFO (expected, where applicable) Text 100 - Note for how building square footage is counted by the County ex. Only finished above and below grade areas are counted.FLOORS_CNT (expected, where applicable) Decimal - Number of floors as reported in county records ex. 2FLOORS_INFO (expected, where applicable) Text 100 - Note for how floors are counted by the County ex. Only above grade floors are countedBUILT_YR (expected, where applicable) Short - Estimated year of initial construction of primary buildings ex. 1968EFFBUILT_YR (optional, where applicable) Short - The 'effective' year built' of primary buildings that factors in updates after construction ex. 1980CONST_MATERIAL (optional, where applicable) Text 100 - Construction Material Types, Values for this field are expected to vary greatly by county ex. Wood Frame, Brick, etc Contact: Sean Fernandez, Cadastral Manager (email: sfernandez@utah.gov; office phone: 801-209-9359)

Update information can be found within the layer’s attributes and in a table on the Utah Parcel Data webpage under LIR Parcels.In Spring of 2016, the Land Information Records work group, an informal committee organized by the Governor’s Office of Management and Budget’s State Planning Coordinator, produced recommendations for expanding the sharing of GIS-based parcel information. Participants in the LIR work group included representatives from county, regional, and state government, including the Utah Association of Counties (County Assessors and County Recorders), Wasatch Front Regional Council, Mountainland and Bear River AOGs, Utah League of Cities and Towns, UDOT, DNR, AGRC, the Division of Emergency Management, Blue Stakes, economic developers, and academic researchers. The LIR work group’s recommendations set the stage for voluntary sharing of additional objective/quantitative parcel GIS data, primarily around tax assessment-related information. Specifically the recommendations document establishes objectives, principles (including the role of local and state government), data content items, expected users, and a general process for data aggregation and publishing. An important realization made by the group was that ‘parcel data’ or ‘parcel record’ products have a different meaning to different users and data stewards. The LIR group focused, specifically, on defining a data sharing recommendation around a tax year parcel GIS data product, aligned with the finalization of the property tax roll by County Assessors on May 22nd of each year. The LIR recommendations do not impact the periodic sharing of basic parcel GIS data (boundary, ID, address) from the County Recorders to AGRC per 63F-1-506 (3.b.vi). Both the tax year parcel and the basic parcel GIS layers are designed for general purpose uses, and are not substitutes for researching and obtaining the most current, legal land records information on file in County records. This document, below, proposes a schedule, guidelines, and process for assembling county parcel and assessment data into an annual, statewide tax parcel GIS layer. gis.utah.gov/data/sgid-cadastre/ It is hoped that this new expanded parcel GIS layer will be put to immediate use supporting the best possible outcomes in public safety, economic development, transportation, planning, and the provision of public services. Another aim of the work group was to improve the usability of the data, through development of content guidelines and consistent metadata documentation, and the efficiency with which the data sharing is distributed.GIS Layer Boundary Geometry:GIS Format Data Files: Ideally, Tax Year Parcel data should be provided in a shapefile (please include the .shp, .shx, .dbf, .prj, and .xml component files) or file geodatabase format. An empty shapefile and file geodatabase schema are available for download at:At the request of a county, AGRC will provide technical assistance to counties to extract, transform, and load parcel and assessment information into the GIS layer format.Geographic Coverage: Tax year parcel polygons should cover the area of each county for which assessment information is created and digital parcels are available. Full coverage may not be available yet for each county. The county may provide parcels that have been adjusted to remove gaps and overlaps for administrative tax purposes or parcels that retain these expected discrepancies that take their source from the legally described boundary or the process of digital conversion. The diversity of topological approaches will be noted in the metadata.One Tax Parcel Record Per Unique Tax Notice: Some counties produce an annual tax year parcel GIS layer with one parcel polygon per tax notice. In some cases, adjacent parcel polygons that compose a single taxed property must be merged into a single polygon. This is the goal for the statewide layer but may not be possible in all counties. AGRC will provide technical support to counties, where needed, to merge GIS parcel boundaries into the best format to match with the annual assessment information.Standard Coordinate System: Parcels will be loaded into Utah’s statewide coordinate system, Universal Transverse Mercator coordinates (NAD83, Zone 12 North). However, boundaries stored in other industry standard coordinate systems will be accepted if they are both defined within the data file(s) and documented in the metadata (see below).Descriptive Attributes:Database Field/Column Definitions: The table below indicates the field names and definitions for attributes requested for each Tax Parcel Polygon record.FIELD NAME FIELD TYPE LENGTH DESCRIPTION EXAMPLE SHAPE (expected) Geometry n/a The boundary of an individual parcel or merged parcels that corresponds with a single county tax notice ex. polygon boundary in UTM NAD83 Zone 12 N or other industry standard coordinates including state plane systemsCOUNTY_NAME Text 20 - County name including spaces ex. BOX ELDERCOUNTY_ID (expected) Text 2 - County ID Number ex. Beaver = 1, Box Elder = 2, Cache = 3,..., Weber = 29ASSESSOR_SRC (expected) Text 100 - Website URL, will be to County Assessor in most all cases ex. webercounty.org/assessorBOUNDARY_SRC (expected) Text 100 - Website URL, will be to County Recorder in most all cases ex. webercounty.org/recorderDISCLAIMER (added by State) Text 50 - Disclaimer URL ex. gis.utah.gov...CURRENT_ASOF (expected) Date - Parcels current as of date ex. 01/01/2016PARCEL_ID (expected) Text 50 - County designated Unique ID number for individual parcels ex. 15034520070000PARCEL_ADD (expected, where available) Text 100 - Parcel’s street address location. Usually the address at recordation ex. 810 S 900 E #304 (example for a condo)TAXEXEMPT_TYPE (expected) Text 100 - Primary category of granted tax exemption ex. None, Religious, Government, Agriculture, Conservation Easement, Other Open Space, OtherTAX_DISTRICT (expected, where applicable) Text 10 - The coding the county uses to identify a unique combination of property tax levying entities ex. 17ATOTAL_MKT_VALUE (expected) Decimal - Total market value of parcel's land, structures, and other improvements as determined by the Assessor for the most current tax year ex. 332000LAND _MKT_VALUE (expected) Decimal - The market value of the parcel's land as determined by the Assessor for the most current tax year ex. 80600PARCEL_ACRES (expected) Decimal - Parcel size in acres ex. 20.360PROP_CLASS (expected) Text 100 - Residential, Commercial, Industrial, Mixed, Agricultural, Vacant, Open Space, Other ex. ResidentialPRIMARY_RES (expected) Text 1 - Is the property a primary residence(s): Y'(es), 'N'(o), or 'U'(nknown) ex. YHOUSING_CNT (expected, where applicable) Text 10 - Number of housing units, can be single number or range like '5-10' ex. 1SUBDIV_NAME (optional) Text 100 - Subdivision name if applicable ex. Highland Manor SubdivisionBLDG_SQFT (expected, where applicable) Integer - Square footage of primary bldg(s) ex. 2816BLDG_SQFT_INFO (expected, where applicable) Text 100 - Note for how building square footage is counted by the County ex. Only finished above and below grade areas are counted.FLOORS_CNT (expected, where applicable) Decimal - Number of floors as reported in county records ex. 2FLOORS_INFO (expected, where applicable) Text 100 - Note for how floors are counted by the County ex. Only above grade floors are countedBUILT_YR (expected, where applicable) Short - Estimated year of initial construction of primary buildings ex. 1968EFFBUILT_YR (optional, where applicable) Short - The 'effective' year built' of primary buildings that factors in updates after construction ex. 1980CONST_MATERIAL (optional, where applicable) Text 100 - Construction Material Types, Values for this field are expected to vary greatly by county ex. Wood Frame, Brick, etc Contact: Sean Fernandez, Cadastral Manager (email: sfernandez@utah.gov; office phone: 801-209-9359)

Update information can be found within the layer’s attributes and in a table on the Utah Parcel Data webpage under LIR Parcels.In Spring of 2016, the Land Information Records work group, an informal committee organized by the Governor’s Office of Management and Budget’s State Planning Coordinator, produced recommendations for expanding the sharing of GIS-based parcel information. Participants in the LIR work group included representatives from county, regional, and state government, including the Utah Association of Counties (County Assessors and County Recorders), Wasatch Front Regional Council, Mountainland and Bear River AOGs, Utah League of Cities and Towns, UDOT, DNR, AGRC, the Division of Emergency Management, Blue Stakes, economic developers, and academic researchers. The LIR work group’s recommendations set the stage for voluntary sharing of additional objective/quantitative parcel GIS data, primarily around tax assessment-related information. Specifically the recommendations document establishes objectives, principles (including the role of local and state government), data content items, expected users, and a general process for data aggregation and publishing. An important realization made by the group was that ‘parcel data’ or ‘parcel record’ products have a different meaning to different users and data stewards. The LIR group focused, specifically, on defining a data sharing recommendation around a tax year parcel GIS data product, aligned with the finalization of the property tax roll by County Assessors on May 22nd of each year. The LIR recommendations do not impact the periodic sharing of basic parcel GIS data (boundary, ID, address) from the County Recorders to AGRC per 63F-1-506 (3.b.vi). Both the tax year parcel and the basic parcel GIS layers are designed for general purpose uses, and are not substitutes for researching and obtaining the most current, legal land records information on file in County records. This document, below, proposes a schedule, guidelines, and process for assembling county parcel and assessment data into an annual, statewide tax parcel GIS layer. gis.utah.gov/data/sgid-cadastre/ It is hoped that this new expanded parcel GIS layer will be put to immediate use supporting the best possible outcomes in public safety, economic development, transportation, planning, and the provision of public services. Another aim of the work group was to improve the usability of the data, through development of content guidelines and consistent metadata documentation, and the efficiency with which the data sharing is distributed.GIS Layer Boundary Geometry:GIS Format Data Files: Ideally, Tax Year Parcel data should be provided in a shapefile (please include the .shp, .shx, .dbf, .prj, and .xml component files) or file geodatabase format. An empty shapefile and file geodatabase schema are available for download at:At the request of a county, AGRC will provide technical assistance to counties to extract, transform, and load parcel and assessment information into the GIS layer format.Geographic Coverage: Tax year parcel polygons should cover the area of each county for which assessment information is created and digital parcels are available. Full coverage may not be available yet for each county. The county may provide parcels that have been adjusted to remove gaps and overlaps for administrative tax purposes or parcels that retain these expected discrepancies that take their source from the legally described boundary or the process of digital conversion. The diversity of topological approaches will be noted in the metadata.One Tax Parcel Record Per Unique Tax Notice: Some counties produce an annual tax year parcel GIS layer with one parcel polygon per tax notice. In some cases, adjacent parcel polygons that compose a single taxed property must be merged into a single polygon. This is the goal for the statewide layer but may not be possible in all counties. AGRC will provide technical support to counties, where needed, to merge GIS parcel boundaries into the best format to match with the annual assessment information.Standard Coordinate System: Parcels will be loaded into Utah’s statewide coordinate system, Universal Transverse Mercator coordinates (NAD83, Zone 12 North). However, boundaries stored in other industry standard coordinate systems will be accepted if they are both defined within the data file(s) and documented in the metadata (see below).Descriptive Attributes:Database Field/Column Definitions: The table below indicates the field names and definitions for attributes requested for each Tax Parcel Polygon record.FIELD NAME FIELD TYPE LENGTH DESCRIPTION EXAMPLE SHAPE (expected) Geometry n/a The boundary of an individual parcel or merged parcels that corresponds with a single county tax notice ex. polygon boundary in UTM NAD83 Zone 12 N or other industry standard coordinates including state plane systemsCOUNTY_NAME Text 20 - County name including spaces ex. BOX ELDERCOUNTY_ID (expected) Text 2 - County ID Number ex. Beaver = 1, Box Elder = 2, Cache = 3,..., Weber = 29ASSESSOR_SRC (expected) Text 100 - Website URL, will be to County Assessor in most all cases ex. webercounty.org/assessorBOUNDARY_SRC (expected) Text 100 - Website URL, will be to County Recorder in most all cases ex. webercounty.org/recorderDISCLAIMER (added by State) Text 50 - Disclaimer URL ex. gis.utah.gov...CURRENT_ASOF (expected) Date - Parcels current as of date ex. 01/01/2016PARCEL_ID (expected) Text 50 - County designated Unique ID number for individual parcels ex. 15034520070000PARCEL_ADD (expected, where available) Text 100 - Parcel’s street address location. Usually the address at recordation ex. 810 S 900 E #304 (example for a condo)TAXEXEMPT_TYPE (expected) Text 100 - Primary category of granted tax exemption ex. None, Religious, Government, Agriculture, Conservation Easement, Other Open Space, OtherTAX_DISTRICT (expected, where applicable) Text 10 - The coding the county uses to identify a unique combination of property tax levying entities ex. 17ATOTAL_MKT_VALUE (expected) Decimal - Total market value of parcel's land, structures, and other improvements as determined by the Assessor for the most current tax year ex. 332000LAND _MKT_VALUE (expected) Decimal - The market value of the parcel's land as determined by the Assessor for the most current tax year ex. 80600PARCEL_ACRES (expected) Decimal - Parcel size in acres ex. 20.360PROP_CLASS (expected) Text 100 - Residential, Commercial, Industrial, Mixed, Agricultural, Vacant, Open Space, Other ex. ResidentialPRIMARY_RES (expected) Text 1 - Is the property a primary residence(s): Y'(es), 'N'(o), or 'U'(nknown) ex. YHOUSING_CNT (expected, where applicable) Text 10 - Number of housing units, can be single number or range like '5-10' ex. 1SUBDIV_NAME (optional) Text 100 - Subdivision name if applicable ex. Highland Manor SubdivisionBLDG_SQFT (expected, where applicable) Integer - Square footage of primary bldg(s) ex. 2816BLDG_SQFT_INFO (expected, where applicable) Text 100 - Note for how building square footage is counted by the County ex. Only finished above and below grade areas are counted.FLOORS_CNT (expected, where applicable) Decimal - Number of floors as reported in county records ex. 2FLOORS_INFO (expected, where applicable) Text 100 - Note for how floors are counted by the County ex. Only above grade floors are countedBUILT_YR (expected, where applicable) Short - Estimated year of initial construction of primary buildings ex. 1968EFFBUILT_YR (optional, where applicable) Short - The 'effective' year built' of primary buildings that factors in updates after construction ex. 1980CONST_MATERIAL (optional, where applicable) Text 100 - Construction Material Types, Values for this field are expected to vary greatly by county ex. Wood Frame, Brick, etc Contact: Sean Fernandez, Cadastral Manager (email: sfernandez@utah.gov; office phone: 801-209-9359)

The Forest Practices Abandoned Roads (ROPA.FPTRANS_ABANDONED_RDS) data layer, an ArcSDE read-only data layer, represents only officially abandoned and orphaned roads existing within the state of Washington. All active roads are now updated and maintained in the DNR's Proprietary Roads (ROPA.ROADS) data layer. The original data layer, TRANS_ROAD_RTE_SV, which originally joined the TRANS spatial data to both the TRANS_ROAD table (road characteristics) using the TRANS_ARC_NO field, and to the TRANS_RTE table using the TRANS_RTE_REF_NO field, has now been split into two data layers. One data layer (ROPA.FPTRANS_ABANDONED_RDS) consists of all abandoned and orphaned roads; the other (ROPA.FPTRANS_OTHER_RTS) consists of trails, railroads, railroad grades, and ferry crossings.Roads abandoned using the official Forest Practices approval process and Roads Orphaned prior to 1975ROPA.FPTRANS_ABANDONED_RDS OBJECTID Internal feature number.

Internal feature number.

TRANS_ID Unique identifier for each arc. Used as a relate item to relate the Roads Table to the TRANS spatial data.

Unique identifier for each arc. Used as a relate item to relate the Roads Table to the TRANS spatial data.data. TRANS_RTE_TY_CD Type of transportation route the linear feature represents. Classification of a transportation route is based on the primary mode of transportation on the route.

Type of transportation route the linear feature represents. Classification of a transportation route is based on the primary mode of transportation on the route. Orphaned Road

Orphaned RoadType of transportation route the linear feature represents. Classification of a transportation route is based on the primary mode of transportation on the route.TRANS_RTE_TY_LABEL_NM The type of transportation route the linear feature represents written out in English as opposed to a code. Classification of a transportation route is based on the primary mode of transportation on the route.

The type of transportation route the linear feature represents written out in English as opposed to a code. Classification of a transportation route is based on the primary mode of transportation on the route.Abandoned Road Roads abandoned using the official Forest Practices approval process

Roads abandoned using the official Forest Practices approval processOrphaned Road Roads orphaned using the official Forest Practices approval process

Roads orphaned using the official Forest Practices approval processThe type of transportation route the linear feature represents written out in english as opposed to a code. Classification of a transportation route is based on the primary mode of transportation on the route. TRANS_RTE_ID Transportation route identifier in common use.

Transportation route identifier in common use.Alphanumeric characters representing an abbreviation of the road name or number, for example, "I-5". (Allow NULL Values, NON-REQUIRED) TRANS_RTE_NM Full textual name of transportation route.

Full textual name of transportation route.Alphanumeric characters representing the road name, for example, "NORTH CASCADES HWY". (Allow NULL Values, NON-REQUIRED) ABANDONMENT_ACCEPTANCE_DT Date when the official road abandonment documentation is approved by the DNR Region Forest Practices official.

Date when the official road abandonment documentation is approved by the DNR Region Forest Practices official.Date when the official road abandonment documentation is approved by the DNR Region Forest Practices official.(Allow NULL Values, NON-REQUIRED) ABANDONMENT_FPA_NO The Forest Practices Application Number (FPAN) that pertains to the particular road abandonment(s).

The Forest Practices Application Number (FPAN) that pertains to the particular road abandonment(s).The Forest Practices Application Number (FPAN) that pertains to the particular road abandonment(s). (Allow NULL Values, NON-REQUIRED) SHAPE_SOURCE_ACCURACY_CD The codes that explain how the data was input into the database.

The codes that explain how the data was input into the database.10 Photogrammetrically derived

Photogrammetrically derived20 Machine scanned 30 Contractor digitized from USGS 7.5' separate

Contractor digitized from USGS 7.5' separate31 Contractor digitized from USGS 7.5' separate

Contractor digitized from USGS 7.5' separate32 Contractor digitized from USGS 7.5' separate

Contractor digitized from USGS 7.5' separate33 Contractor digitized from USGS 7.5' separate

Contractor digitized from USGS 7.5' separate34 Contractor digitized from USGS 7.5' separate

Contractor digitized from USGS 7.5' separate35 Contractor digitized from USGS 7.5' separate

Contractor digitized from USGS 7.5' separate36 Contractor digitized from USGS 7.5' separate

Contractor digitized from USGS 7.5' separate37 Contractor digitized from USGS 7.5' separate

Contractor digitized from USGS 7.5' separate38 DNR digitized from DNR Water Type Maps

DNR digitized from DNR Water Type Maps39 DNR digitized from National Wetlands Inventory

DNR digitized from National Wetlands Inventory40 DNR digitized from National Wetlands Inventory

DNR digitized from National Wetlands Inventory99 DNR digitized from National Wetlands Inventory

DNR digitized from National Wetlands InventoryThe codes that explain how the data was input into the database. (Allow NULL Values, NON-REQUIRED) SHAPE_SOURCE_ACCURACY_LBL The label names that describe in English the codes that explain how the data was input into the database.

The label names that describe in English the codes that explain how the data was input into the database.The label names that describe in english the codes that explain how the data was input into the database. SHAPE System generated field. Coordinates defining the features. SHAPE.LEN System generated field.

Update information can be found within the layer’s attributes and in a table on the Utah Parcel Data webpage under LIR Parcels.In Spring of 2016, the Land Information Records work group, an informal committee organized by the Governor’s Office of Management and Budget’s State Planning Coordinator, produced recommendations for expanding the sharing of GIS-based parcel information. Participants in the LIR work group included representatives from county, regional, and state government, including the Utah Association of Counties (County Assessors and County Recorders), Wasatch Front Regional Council, Mountainland and Bear River AOGs, Utah League of Cities and Towns, UDOT, DNR, AGRC, the Division of Emergency Management, Blue Stakes, economic developers, and academic researchers. The LIR work group’s recommendations set the stage for voluntary sharing of additional objective/quantitative parcel GIS data, primarily around tax assessment-related information. Specifically the recommendations document establishes objectives, principles (including the role of local and state government), data content items, expected users, and a general process for data aggregation and publishing. An important realization made by the group was that ‘parcel data’ or ‘parcel record’ products have a different meaning to different users and data stewards. The LIR group focused, specifically, on defining a data sharing recommendation around a tax year parcel GIS data product, aligned with the finalization of the property tax roll by County Assessors on May 22nd of each year. The LIR recommendations do not impact the periodic sharing of basic parcel GIS data (boundary, ID, address) from the County Recorders to AGRC per 63F-1-506 (3.b.vi). Both the tax year parcel and the basic parcel GIS layers are designed for general purpose uses, and are not substitutes for researching and obtaining the most current, legal land records information on file in County records. This document, below, proposes a schedule, guidelines, and process for assembling county parcel and assessment data into an annual, statewide tax parcel GIS layer. gis.utah.gov/data/sgid-cadastre/It is hoped that this new expanded parcel GIS layer will be put to immediate use supporting the best possible outcomes in public safety, economic development, transportation, planning, and the provision of public services. Another aim of the work group was to improve the usability of the data, through development of content guidelines and consistent metadata documentation, and the efficiency with which the data sharing is distributed.GIS Layer Boundary Geometry:GIS Format Data Files: Ideally, Tax Year Parcel data should be provided in a shapefile (please include the .shp, .shx, .dbf, .prj, and .xml component files) or file geodatabase format. An empty shapefile and file geodatabase schema are available for download at:At the request of a county, AGRC will provide technical assistance to counties to extract, transform, and load parcel and assessment information into the GIS layer format.Geographic Coverage: Tax year parcel polygons should cover the area of each county for which assessment information is created and digital parcels are available. Full coverage may not be available yet for each county. The county may provide parcels that have been adjusted to remove gaps and overlaps for administrative tax purposes or parcels that retain these expected discrepancies that take their source from the legally described boundary or the process of digital conversion. The diversity of topological approaches will be noted in the metadata.One Tax Parcel Record Per Unique Tax Notice: Some counties produce an annual tax year parcel GIS layer with one parcel polygon per tax notice. In some cases, adjacent parcel polygons that compose a single taxed property must be merged into a single polygon. This is the goal for the statewide layer but may not be possible in all counties. AGRC will provide technical support to counties, where needed, to merge GIS parcel boundaries into the best format to match with the annual assessment information.Standard Coordinate System: Parcels will be loaded into Utah’s statewide coordinate system, Universal Transverse Mercator coordinates (NAD83, Zone 12 North). However, boundaries stored in other industry standard coordinate systems will be accepted if they are both defined within the data file(s) and documented in the metadata (see below).Descriptive Attributes:Database Field/Column Definitions: The table below indicates the field names and definitions for attributes requested for each Tax Parcel Polygon record.FIELD NAME FIELD TYPE LENGTH DESCRIPTION EXAMPLE SHAPE (expected) Geometry n/a The boundary of an individual parcel or merged parcels that corresponds with a single county tax notice ex. polygon boundary in UTM NAD83 Zone 12 N or other industry standard coordinates including state plane systemsCOUNTY_NAME Text 20 - County name including spaces ex. BOX ELDERCOUNTY_ID (expected) Text 2 - County ID Number ex. Beaver = 1, Box Elder = 2, Cache = 3,..., Weber = 29ASSESSOR_SRC (expected) Text 100 - Website URL, will be to County Assessor in most all cases ex. webercounty.org/assessorBOUNDARY_SRC (expected) Text 100 - Website URL, will be to County Recorder in most all cases ex. webercounty.org/recorderDISCLAIMER (added by State) Text 50 - Disclaimer URL ex. gis.utah.gov...CURRENT_ASOF (expected) Date - Parcels current as of date ex. 01/01/2016PARCEL_ID (expected) Text 50 - County designated Unique ID number for individual parcels ex. 15034520070000PARCEL_ADD (expected, where available) Text 100 - Parcel’s street address location. Usually the address at recordation ex. 810 S 900 E #304 (example for a condo)TAXEXEMPT_TYPE (expected) Text 100 - Primary category of granted tax exemption ex. None, Religious, Government, Agriculture, Conservation Easement, Other Open Space, OtherTAX_DISTRICT (expected, where applicable) Text 10 - The coding the county uses to identify a unique combination of property tax levying entities ex. 17ATOTAL_MKT_VALUE (expected) Decimal - Total market value of parcel's land, structures, and other improvements as determined by the Assessor for the most current tax year ex. 332000LAND _MKT_VALUE (expected) Decimal - The market value of the parcel's land as determined by the Assessor for the most current tax year ex. 80600PARCEL_ACRES (expected) Decimal - Parcel size in acres ex. 20.360PROP_CLASS (expected) Text 100 - Residential, Commercial, Industrial, Mixed, Agricultural, Vacant, Open Space, Other ex. ResidentialPRIMARY_RES (expected) Text 1 - Is the property a primary residence(s): Y'(es), 'N'(o), or 'U'(nknown) ex. YHOUSING_CNT (expected, where applicable) Text 10 - Number of housing units, can be single number or range like '5-10' ex. 1SUBDIV_NAME (optional) Text 100 - Subdivision name if applicable ex. Highland Manor SubdivisionBLDG_SQFT (expected, where applicable) Integer - Square footage of primary bldg(s) ex. 2816BLDG_SQFT_INFO (expected, where applicable) Text 100 - Note for how building square footage is counted by the County ex. Only finished above and below grade areas are counted.FLOORS_CNT (expected, where applicable) Decimal - Number of floors as reported in county records ex. 2FLOORS_INFO (expected, where applicable) Text 100 - Note for how floors are counted by the County ex. Only above grade floors are countedBUILT_YR (expected, where applicable) Short - Estimated year of initial construction of primary buildings ex. 1968EFFBUILT_YR (optional, where applicable) Short - The 'effective' year built' of primary buildings that factors in updates after construction ex. 1980CONST_MATERIAL (optional, where applicable) Text 100 - Construction Material Types, Values for this field are expected to vary greatly by county ex. Wood Frame, Brick, etc Contact: Sean Fernandez, Cadastral Manager (email: sfernandez@utah.gov; office phone: 801-209-9359)