The National Marine Fisheries Service (NMFS) developed this geodatabase to standardize its Endangered Species Act (ESA) critical habitat spatial data. The spatial data represent critical habitat locations; however, the complete description and official boundaries of critical habitat proposed or designated by NMFS are provided in proposed rules, final rules, and the Code of Federal Regulations (50 CFR 226). Official critical habitat boundaries may include regulatory text that modifies or clarifies maps and spatial data. Proposed rules, final rules, and the CFR also describe any areas that are excluded from critical habitat or otherwise not part of critical habitat (e.g., ineligible areas), some of which have not been clipped out of the spatial data.Geodatabase feature classes are organized by ESA listed entities. A listed entity can be a species, subspecies, distinct population segment (DPS), or evolutionarily significant unit (ESU). NMFS and the U.S. Fish and Wildlife Service share jurisdiction of some listed entities; this geodatabase only contains spatial data for NMFS critical habitat. Critical habitat has not been designated for all listed entities.Generally, each listed entity has one feature class. However, a listed entity may have critical habitat locations represented by both lines and polygons. In these instances, "_poly" and "_line" are appended to the feature class names to differentiate between the spatial data types. Lines represent rivers, streams, or beaches and polygons represent waterbodies, marine areas, estuaries, marshes, or watersheds. The 8 digit date (YYYYMMDD) in each feature class name is the publication date of the proposed or final rule in the Federal Register. Both proposed and designated critical habitat are included in this geodatabase. To differentiate between these categories, all proposed critical habitat feature classes begin with "Proposed_". Proposed critical habitat will be replaced by final designations soon after a final rule is published in the Federal Register. This geodatabase version may not include spatial data for recently proposed, modified, or designated critical habitat. Additionally, spatial data are not available for the designated critical habitat of the Southern Oregon/Northern California Coast coho salmon ESU and the Snake River spring/summer-run Chinook salmon ESU. NMFS will add these spatial data when they become available. In the meantime, please consult the final rules or CFR. NMFS may periodically update existing lines or polygons if better information becomes available, such as higher resolution bathymetric surveys. The "All_critical_habitat" feature dataset includes merged line and polygon feature classes that contain all available spatial data for critical habitat proposed or designated by NMFS; therefore, these feature classes contain overlapping features. The "All_critical_habitat_line_YYYYMMDD" and "All_critical_habitat_poly_YYYYMMDD" feature classes should be used together to represent all available spatial data. The date appended to the feature class names is the date the geoprocessing (merge) occured. Features in this geodatabase were compiled from previously developed spatial data. The methods and sources used to create these spatial data are NOT standardized. Coastlines, bathymetric contours, and river lines, for example, were all derived from a variety of sources, using many different geoprocessing techniques, over the span of decades. If information was available on source data and/or processing steps, it was documented in the metadata lineage. Metadata descriptions and the "Notes" field describe line and boundary definitions. Line and boundary definitions are specific to each proposed or designated critical habitat dataset. For example, depending on the listed entity, a coastline could represent the Mean Higher High Water (MHHW) line in one designation and the Mean Lower Low Water (MLLW) line in another designation. Metadata for each feature class is a combination of standardized and unique content. Standardized content includes the field and value definitions, spatial reference (WGS 84 geographic coordinate system), and metadata style (ISO 19139). All other metadata content is unique to each feature class. eCFR official ESA listeCFR official NMFS critical habitat designationsNMFS critical habitat websiteNMFS maps and GIS data directoryNMFS ESA threatened and endangered species directoryNMFS ESA regulations and actions directory

The establishment of a BES Multi-User Geodatabase (BES-MUG) allows for the storage, management, and distribution of geospatial data associated with the Baltimore Ecosystem Study. At present, BES data is distributed over the internet via the BES website. While having geospatial data available for download is a vast improvement over having the data housed at individual research institutions, it still suffers from some limitations. BES-MUG overcomes these limitations; improving the quality of the geospatial data available to BES researches, thereby leading to more informed decision-making.

   BES-MUG builds on Environmental Systems Research Institute's (ESRI) ArcGIS and ArcSDE technology. ESRI was selected because its geospatial software offers robust capabilities. ArcGIS is implemented agency-wide within the USDA and is the predominant geospatial software package used by collaborating institutions.


   Commercially available enterprise database packages (DB2, Oracle, SQL) provide an efficient means to store, manage, and share large datasets. However, standard database capabilities are limited with respect to geographic datasets because they lack the ability to deal with complex spatial relationships. By using ESRI's ArcSDE (Spatial Database Engine) in conjunction with database software, geospatial data can be handled much more effectively through the implementation of the Geodatabase model. Through ArcSDE and the Geodatabase model the database's capabilities are expanded, allowing for multiuser editing, intelligent feature types, and the establishment of rules and relationships. ArcSDE also allows users to connect to the database using ArcGIS software without being burdened by the intricacies of the database itself.


   For an example of how BES-MUG will help improve the quality and timeless of BES geospatial data consider a census block group layer that is in need of updating. Rather than the researcher downloading the dataset, editing it, and resubmitting to through ORS, access rules will allow the authorized user to edit the dataset over the network. Established rules will ensure that the attribute and topological integrity is maintained, so that key fields are not left blank and that the block group boundaries stay within tract boundaries. Metadata will automatically be updated showing who edited the dataset and when they did in the event any questions arise.


   Currently, a functioning prototype Multi-User Database has been developed for BES at the University of Vermont Spatial Analysis Lab, using Arc SDE and IBM's DB2 Enterprise Database as a back end architecture. This database, which is currently only accessible to those on the UVM campus network, will shortly be migrated to a Linux server where it will be accessible for database connections over the Internet. Passwords can then be handed out to all interested researchers on the project, who will be able to make a database connection through the Geographic Information Systems software interface on their desktop computer. 


   This database will include a very large number of thematic layers. Those layers are currently divided into biophysical, socio-economic and imagery categories. Biophysical includes data on topography, soils, forest cover, habitat areas, hydrology and toxics. Socio-economics includes political and administrative boundaries, transportation and infrastructure networks, property data, census data, household survey data, parks, protected areas, land use/land cover, zoning, public health and historic land use change. Imagery includes a variety of aerial and satellite imagery.


   See the readme: http://96.56.36.108/geodatabase_SAL/readme.txt


   See the file listing: http://96.56.36.108/geodatabase_SAL/diroutput.txt

NOTE: This geodatabase is depreciated. To view most recent version, go to the following link.The National Marine Fisheries Service (NMFS) developed this geodatabase to standardize its Endangered Species Act (ESA) critical habitat spatial data. The spatial data represent critical habitat locations; however, the complete description and official boundaries of critical habitat proposed or designated by NMFS are provided in proposed rules, final rules, and the Code of Federal Regulations (50 CFR 226). Official critical habitat boundaries may include regulatory text that modifies or clarifies maps and spatial data. Proposed rules, final rules, and the CFR also describe any areas that are excluded from critical habitat or otherwise not part of critical habitat (e.g., ineligible areas), some of which have not been clipped out of the spatial data.Geodatabase feature classes are organized by ESA listed entities. A listed entity can be a species, subspecies, distinct population segment (DPS), or evolutionarily significant unit (ESU). NMFS and the U.S. Fish and Wildlife Service share jurisdiction of some listed entities; this geodatabase only contains spatial data for NMFS critical habitat. Critical habitat has not been designated for all listed entities.Generally, each listed entity has one feature class. However, a listed entity may have critical habitat locations represented by both lines and polygons. In these instances, "_poly" and "_line" are appended to the feature class names to differentiate between the spatial data types. Lines represent rivers, streams, or beaches and polygons represent waterbodies, marine areas, estuaries, marshes, or watersheds. The 8 digit date (YYYYMMDD) in each feature class name is the publication date of the proposed or final rule in the Federal Register. Both proposed and designated critical habitat are included in this geodatabase. To differentiate between these categories, all proposed critical habitat feature classes begin with "Proposed_". Proposed critical habitat will be replaced by final designations soon after a final rule is published in the Federal Register. This geodatabase version may not include spatial data for recently proposed, modified, or designated critical habitat. Additionally, spatial data are not available for the designated critical habitat of the Southern Oregon/Northern California Coast coho salmon ESU and the Snake River spring/summer-run Chinook salmon ESU. NMFS will add these spatial data when they become available. In the meantime, please consult the final rules or CFR. NMFS may periodically update existing lines or polygons if better information becomes available, such as higher resolution bathymetric surveys. The "All_critical_habitat" feature dataset includes merged line and polygon feature classes that contain all available spatial data for critical habitat proposed or designated by NMFS; therefore, these feature classes contain overlapping features. The "All_critical_habitat_line_YYYYMMDD" and "All_critical_habitat_poly_YYYYMMDD" feature classes should be used together to represent all available spatial data. The date appended to the feature class names is the date the geoprocessing (merge) occured. Features in this geodatabase were compiled from previously developed spatial data. The methods and sources used to create these spatial data are NOT standardized. Coastlines, bathymetric contours, and river lines, for example, were all derived from a variety of sources, using many different geoprocessing techniques, over the span of decades. If information was available on source data and/or processing steps, it was documented in the metadata lineage. Metadata descriptions and the "Notes" field describe line and boundary definitions. Line and boundary definitions are specific to each proposed or designated critical habitat dataset. For example, depending on the listed entity, a coastline could represent the Mean Higher High Water (MHHW) line in one designation and the Mean Lower Low Water (MLLW) line in another designation. Metadata for each feature class is a combination of standardized and unique content. Standardized content includes the field and value definitions, spatial reference (WGS 84 geographic coordinate system), and metadata style (ISO 19139). All other metadata content is unique to each feature class. eCFR official ESA listeCFR official NMFS critical habitat designationsNMFS critical habitat websiteNMFS maps and GIS data directoryNMFS ESA threatened and endangered species directoryNMFS ESA regulations and actions directory

This dataset is a compilation of county parcel data from Minnesota counties that have opted-in for their parcel data to be included in this dataset.

It includes the following 55 counties that have opted-in as of the publication date of this dataset: Aitkin, Anoka, Becker, Benton, Big Stone, Carlton, Carver, Cass, Chippewa, Chisago, Clay, Clearwater, Cook, Crow Wing, Dakota, Douglas, Fillmore, Grant, Hennepin, Houston, Isanti, Itasca, Jackson, Koochiching, Lac qui Parle, Lake, Lyon, Marshall, McLeod, Mille Lacs, Morrison, Mower, Murray, Norman, Olmsted, Otter Tail, Pennington, Pipestone, Polk, Pope, Ramsey, Renville, Rice, Saint Louis, Scott, Sherburne, Stearns, Stevens, Traverse, Waseca, Washington, Wilkin, Winona, Wright, and Yellow Medicine.

If you represent a county not included in this dataset and would like to opt-in, please contact Heather Albrecht (Heather.Albrecht@hennepin.us), co-chair of the Minnesota Geospatial Advisory Council (GAC)’s Parcels and Land Records Committee's Open Data Subcommittee. County parcel data does not need to be in the GAC parcel data standard to be included. MnGeo will map the county fields to the GAC standard.

County parcel data records have been assembled into a single dataset with a common coordinate system (UTM Zone 15) and common attribute schema. The county parcel data attributes have been mapped to the GAC parcel data standard for Minnesota: https://www.mngeo.state.mn.us/committee/standards/parcel_attrib/parcel_attrib.html

This compiled parcel dataset was created using Python code developed by Minnesota state agency GIS professionals, and represents a best effort to map individual county source file attributes into the common attribute schema of the GAC parcel data standard. The attributes from counties are mapped to the most appropriate destination column. In some cases, the county source files included attributes that were not mapped to the GAC standard. Additionally, some county attribute fields were parsed and mapped to multiple GAC standard fields, such as a single line address. Each quarter, MnGeo provides a text file to counties that shows how county fields are mapped to the GAC standard. Additionally, this text file shows the fields that are not mapped to the standard and those that are parsed. If a county shares changes to how their data should be mapped, MnGeo updates the compilation. If you represent a county and would like to update how MnGeo is mapping your county attribute fields to this compiled dataset, please contact us.

This dataset is a snapshot of parcel data, and the source date of the county data may vary. Users should consult County websites to see the most up-to-date and complete parcel data.

There have been recent changes in date/time fields, and their processing, introduced by our software vendor. In some cases, this has resulted in date fields being empty. We are aware of the issue and are working to correct it for future parcel data releases.

The State of Minnesota makes no representation or warranties, express or implied, with respect to the use or reuse of data provided herewith, regardless of its format or the means of its transmission. THE DATA IS PROVIDED “AS IS” WITH NO GUARANTEE OR REPRESENTATION ABOUT THE ACCURACY, CURRENCY, SUITABILITY, PERFORMANCE, MECHANTABILITY, RELIABILITY OR FITINESS OF THIS DATA FOR ANY PARTICULAR PURPOSE. This dataset is NOT suitable for accurate boundary determination. Contact a licensed land surveyor if you have questions about boundary determinations.

DOWNLOAD NOTES: This dataset is only provided in Esri File Geodatabase and OGC GeoPackage formats. A shapefile is not available because the size of the dataset exceeds the limit for that format. The distribution version of the fgdb is compressed to help reduce the data footprint. QGIS users should consider using the Geopackage format for better results.

Abstract

This dataset was supplied to the Bioregional Assessment Programme by a third party and is presented here as originally supplied. Metadata was not provided and has been compiled by the Bioregional Assessment Programme based on known details at the time of acquisition.

This dataset includes the works details from with surface water licences from NSW in the Gloucester & Hunter region. The short guide to NSW Office of Water's licensing data has been provided to accompany the dataset (both the spatial locations and the associated licence details).

A SHORT GUIDE TO NSW OFFICE OF WATER'S LICENSING DATA

Methodology

1. Using the supplied polygons a spatial select was taken for each polygon area for the Surface and Groundwater Approved Work locations. These Work Location points were exported to an ArcGIS 10.0 File Geodatabase for each polygon area. These work locations have a "Status" of either "Active" (under the Water Act) or "Current" (under the Water Management Act).

2. The Approved License number attached to each Work was then used to query the Office of Water's Water Licensing System (WLS) to extract details on each Approved license including any linked Water Access Licenses (WAL) if the Work was now under the Water Management Act (WMA). These files end in *_WLS-EXTRACT_n.xls.

3. If found the linked WAL number is used to re-query using WLS to extract details on each linked WAL. These files end in *_WLS-EXTRACT_n_WALs_volume.xls.

4. It should be noted that due to query size constraints in WLS the output files for each polygon area may be split into a number of subset files ("n" being the number of the subset).

5. The field headings are as per the WLS Extract report. They include some characters (e.g. "") that may cause problems if loaded into ArcGIS. Not knowing how the data is to be used I have not amended them.

Understanding Licensing data

1. A Licensed Work Approval may have more than work (and therefore work location, i.e. point) associated with it. If the Licensed Work Approval is under the old Water Act it may have associated with it an "Entitlement" volume (if on a Regulated River) or an "Allocation" volume in an unregulated area. Please note that these volumes are for the whole licensed approval distributed amongst the related works but not against any particular one.

2. A Licensed Work Approval, if under the newer Water Management Act may have more than one linked WAL. Each WAL may have a "Share Component" volume associated with it. This will nee to be summed against each linked Licensed Work Approval to get the total WAL volume. Please note again that these volumes are for the whole licensed approval distributed amongst the related works but not against any particular one.

3. It is important to note that under the WMA it is possible for WALs not to have a linked Licensed Work Approval (to support Water Trading). This means a spatial select with not find these WALs and the volumes associated with them. The WAL is still related to a particular Water Source and can be re-associated with a different Licensed Work Approval at a later date.

This dataset has been provided to the BA Programme for use within the programme only. Third parties may request a copy of the data from DPI Water (previously known as the NSW Office of Water) at http://www.water.nsw.gov.au/.

Dataset History

This dataset was extracted from the NSW Office of Water's licensing system. Work Location points were exported to an ArcGIS 10.0 File Geodatabase for each polygon area supplied by the Bioregional Assessment project teams for each area. Corresponding work locations found with each polygon were exported from the licensing system.

Dataset Citation

NSW Office of Water (2013) NSW Office of Water Surface Water Offtakes - Hunter v1 24102013. Bioregional Assessment Source Dataset. Viewed 13 March 2019, http://data.bioregionalassessments.gov.au/dataset/d94064ab-6d03-4a40-9484-1579afa9269b.

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)

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)

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)

Abstract

The dataset was derived by the Bioregional Assessment Programme from multiple source datasets. The source datasets are identified in the Lineage field in this metadata statement. The processes undertaken to produce this derived dataset are described in the History field in this metadata statement.

This database is an initial Asset database for the Central West subregion on 29 April 2015. This dataset contains the spatial and non-spatial (attribute) components of the Central West subregion Asset List as one .mdb files, which is readable as an MS Access database and a personal geodatabase. Under the BA program, a spatial assets database is developed for each defined bioregional assessment project. The spatial elements that underpin the identification of water dependent assets are identified in the first instance by regional NRM organisations (via the WAIT tool) and supplemented with additional elements from national and state/territory government datasets. All reports received associated with the WAIT process for Central West are included in the zip file as part of this dataset. Elements are initially included in the preliminary assets database if they are partly or wholly within the subregion's preliminary assessment extent (Materiality Test 1, M1). Elements are then grouped into assets which are evaluated by project teams to determine whether they meet the second Materiality Test (M2). Assets meeting both Materiality Tests comprise the water dependent asset list. Descriptions of the assets identified in the Central West subregion are found in the "AssetList" table of the database. In this version of the database only M1 has been assessed. Assets are the spatial features used by project teams to model scenarios under the BA program. Detailed attribution does not exist at the asset level. Asset attribution includes only the core set of BA-derived attributes reflecting the BA classification hierarchy, as described in Appendix A of "CEN_asset_database_doc_20150429.doc ", located in the zip file as part of this dataset. The "Element_to_Asset" table contains the relationships and identifies the elements that were grouped to create each asset. Detailed information describing the database structure and content can be found in the document "CEN_asset_database_doc_20150429.doc" located in the zip file. Some of the source data used in the compilation of this dataset is restricted.

Dataset History

This is initial asset database.

The Bioregional Assessments methodology (Barrett et al., 2013) defines a water-dependent asset as a spatially distinct, geo-referenced entity contained within a bioregion with characteristics having a defined cultural indigenous, economic or environmental value, and that can be linked directly or indirectly to a dependency on water quantity and/or quality.

Under the BA program, a spatial assets database is developed for each defined bioregional assessment project. The spatial elements that underpin the identification of water dependent assets are identified in the first instance by regional NRM organisations (via the WAIT tool) and supplemented with additional elements from national and state/territory government datasets. Elements are initially included in database if they are partly or wholly within the subregion's preliminary assessment extent (Materiality Test 1, M1). Elements are then grouped into assets which are evaluated by project teams to determine whether they meet materiality test 2 (M2) - assets considered to be water dependent.

Elements may be represented by a single, discrete spatial unit (polygon, line or point), or a number of spatial units occurring at more than one location (multipart polygons/lines or multipoints). Spatial features representing elements are not clipped to the preliminary assessment extent - features that extend beyond the boundary of the assessment extent have been included in full. To assist with an assessment of the relative importance of elements, area statements have been included as an attribute of the spatial data. Detailed attribute tables contain descriptions of the geographic features at the element level. Tables are organised by data source and can be joined to the spatial data on the "ElementID" field

Elements are grouped into Assets, which are the objects used by project teams to model scenarios under the BA program. Detailed attribution does not exist at the asset level. Asset attribution includes only the core set of BA-derived attributes reflecting the BA classification hierarchy.

The "Element_to_asset" table contains the relationships and identifies the elements that were grouped to create each asset.

Following delivery of the first pass asset list, project teams make a determination as to whether an asset (comprised of one or more elements) is water dependent, as assessed against the materiality tests detailed in the BA Methodology. These decisions are provided to ERIN by the project team leader and incorporated into the Assetlist table in the Asset database. The Asset database is then re-registered into the BA repository.

The Asset database dataset (which is registered to the BA repository) contains separate spatial and non-spatial databases.

Non-spatial (tabular data) is provided in an ESRI personal geodatabase (.mdb - doubling as a MS Access database) to store, query, and manage non-spatial data. This database can be accessed using either MS Access or ESRI GIS products. Non-spatial data has been provided in the Access database to simplify the querying process for BA project teams. Source datasets are highly variable and have different attributes, so separate tables are maintained in the Access database to enable the querying of thematic source layers.

Spatial data is provided as an ESRI file geodatabase (.gdb), and can only be used in an ESRI GIS environment. Spatial data is represented as a series of spatial feature classes (point, line and polygon layers). Non-spatial attribution can be joined from the Access database using the AID and ElementID fields, which are common to both the spatial and non-spatial datasets. Spatial layers containing all the point, line and polygon - derived elements and assets have been created to simplify management of the Elementlist and Assetlist tables, which list all the elements and assets, regardless of the spatial data geometry type. i.e. the total number of features in the combined spatial layers (points, lines, polygons) for assets (and elements) is equal to the total number of non-spatial records of all the individual data sources.

Dataset Citation

Department of the Environment (2013) Asset database for the Central West subregion on 29 April 2015. Bioregional Assessment Derived Dataset. Viewed 08 February 2017, http://data.bioregionalassessments.gov.au/dataset/5c3f9a56-7a48-4c26-a617-a186c2de5bf7.

Dataset Ancestors

• Derived From Macquarie Marshes Vegetation 1991-2008 VIS_ID 3920

• Derived From NSW Office of Water GW licence extract linked to spatial locations NIC v2 (28 February 2014)

• Derived From NSW Office of Water Surface Water Entitlements Locations v1_Oct2013

• Derived From Travelling Stock Route Conservation Values

• Derived From NSW Wetlands

• Derived From Communities of National Environmental Significance Database - RESTRICTED - Metadata only

• Derived From National Groundwater Dependent Ecosystems (GDE) Atlas

• Derived From Birds Australia - Important Bird Areas (IBA) 2009

• Derived From Environmental Asset Database - Commonwealth Environmental Water Office

• Derived From NSW Office of Water Surface Water Offtakes - NIC v1 20131024

• Derived From National Groundwater Dependent Ecosystems (GDE) Atlas (including WA)

• Derived From Species Profile and Threats Database (SPRAT) - Australia - Species of National Environmental Significance Database (BA subset - RESTRICTED - Metadata only)

• Derived From Ramsar Wetlands of Australia

• Derived From Native Vegetation Management (NVM) - Manage Benefits

• Derived From Key Environmental Assets - KEA - of the Murray Darling Basin

• Derived From National Heritage List Spatial Database (NHL) (v2.1)

• Derived From Climate Change Corridors (Dry Habitat) for North East NSW

• Derived From Great Artesian Basin and Laura Basin groundwater recharge areas

• Derived From NSW Office of Water combined geodatabase of regulated rivers and water sharing plan regions

• Derived From [New South Wales NSW Regional CMA Water Asset

OPEN Data View service. The Wildland Fire Risk Assessment project was developed by the National Park Service's Fire and Aviation Management program as a response to the devastating 2011 wildfire season. This project developed a consistent assessment method that has been applied to NPS units nationwide regardless of variations in climate, fuels, and topography.The assessment, based on Firewise® assessment forms, evaluates access, surrounding environment, construction design and materials, and resources available to protect facilities from wildland fire. The data collected during the assessment process can be used for:Identifying, planning, prioritizing and tracking fuels treatments at unit, regional and national levels, and Developing incident response plans for facilities and communities within NPS units.The original spatial data for the assessments comes from a variety of sources including the NPS Buildings Enterprise Dataset, WFDSS, NPMap Edits, manually digitized points using Esri basemaps as a reference at various scales, and GPS collection using a multitude of consumer and professional grade GPS devices. The facilities that have been assessed and assigned a facility risk rating have been ground-truthed and field verified. (In some rare occasions, facilities have been verified during remote assessments. Those that have been remotely assessed are marked as such). The resulting data is stored in a centralized geodatabase, and this publicly available feature layer allows the user to view that data.The NPS Facilities feature layer includes the following layers and related tables:Facility - A facility is defined by the NPS as an asset that the NPS desires to track and manage as a distinct identifiable entity. In the case of wildland fire risk assessments, a facility is most often a structure but in special instances, a park unit may wish to identify and assess other at-risk features such as a historic wooden bridge or an interpretive display. The facilities are assessed based on access, the surrounding environment, construction design, and protection resources and limitations, resulting in a numerical score and risk adjective rating for each facility. These ratings designate the likelihood of ignition during a wildland fire. The facilities are symbolized by their respective risk rating.Community - A community is a group of five or more facilities, a majority of which are within 600 feet of each other, that share common access and protection attributes. The community concept was developed to facilitate data collection and entry in areas with multiple facilities and where it made sense to apply treatments and tactics at a scale larger than individual facilities. Most of the community polygons are created using models in ArcMap, but some may have been created or edited in the field using a Trimble GPS unit. *The NPS Facilities layer is updated continually as new wildfire risk assessments are conducted and the Wildland Fire Risk Assessment project progresses. The assessment data contained here is the most current data available.*More information about the NPS Wildland Fire Risk Assessment Project, and the NPS Facilities data itself, can be found at the New Wildland Fire Risk Assessments website. This site provides information on the data collection process, additional ways to access the data, and how to conduct assessments yourself (for both NPS and non-NPS facilities).FACILITY ATTRIBUTES
Unit_ID NWCG Unit ID, Two letter state code and three letter unit abbreviation, for example UTZIP for Zion National Park in Utah.

Fire_Bldg_ID User maintained unique ID for Facility layer.

Building ID Unique Id from the NPS Enterprise Buildings dataset.

FMSS ID Unique ID for the facility in the NPS FMSS database.

Community ID Unique ID linking facility to a community

Assess Scale Indicates if the facility is part of a community/ will be included in a community assessment. Communities are pre-defined by regional GIS staff and visible in this map as a blue perimeter.
Answer "Yes" if you are adding a facility point within a predefined community.

Common Name Name of the structure. In most cases, the name comes from the NPS FMSS database.

Map Label Numerical label used for mapping purposes.

Owner Indicates who owns the structure being assessed.

Facilty Type Indicates the facility type OR if the facility has been REMOVED, DESTROYED, has NO WILDLAND RISK, is PRIVATE - NO SURVEY REQUIRED or DOES NOT REQUIRE A SURVEY (because it is planned for removal).

Facility Use What is the primary use of the facility?

Building Occupied Is the building occupied?

Community Name Name of the community the facility is located within, if any.

Field Crew Field crew completing the assessment.

Last Site Visit Date Date which the facility was visited and assessment data reviewed/updated.

Location General location within the unit – may use FMUs, watersheds, or other identifier. One location may contain multiple communities and individual facilities. Locations are used to filter data for reports and map products.

PrimaryAccess Primary method of accessing the facility.

IngressEgress Number of routes into and away from the facility.

AccessWidth Width of the road or driveway used to access the facility.

AccessCond Grade and surface material of the road or driveway used to access the facility.

BridgeCond Condition, based on load limits and construction.

Turnaround Describes how close can a fire apparatus drive to the facility and once there, whether it can turnaround.

BldgNum Is the facility clearly signed or numbered?

FuelLoad Fuel loading within 300 ft of the facility (see appendix D of the Wildfire Risk Assessment User Guide)

FuelType Predominant fuel type within 300 ft of the facility.

DefensibleSpace Amount of defensible space around the facility, see criteria for evaluating defensible space in the Wildfire Risk Assessment User Guide.

Topography Predominant slope within 300 ft of facility.

RoofMat Roofing material used on the facility.

SidingMat Siding material used on the facility.

Foundation Describes the facility’s foundation.

Fencing Indicates presence of any wooden attachments, fencing, decking, pergola, etc. and fuels clearance around those attachments.

Firewood Firewood distance from facility.

Propane Inidicates if a propane tank exists within 200 feet of a structure and if there is any fuels clearance around the propane tank(s).

Hazmat List of hazmat existing on the site.

WaterSupply Water supply available to the facility.

OverheadHaz Identifies the presence of overhead hazards that will limit aerial firefighting efforts.

SafetyZone Identifies the presence of any potential safety zones.

SZRadius Radius of any potential safety zones.

Obstacles Additional obstacles, not already included in assessment, that will limit firefighting efforts- to include items such as UXO, hazmat,etc. If there are additional obstacles, be sure to comment in Assessment Comments or Tactic descriptions where appropriate.

TriageCategory Refer to IRPG for descriptions of each category. This information will be displayed in the NIFS Structure Triage layer for incident response.

Score Sum of attribute values for all assessment elements including access, environment, structure and protection portions of the assessment.

Rating Wildland fire risk rating based on score. Ratings are No Wildland Risk, Low, Moderate and High. Rating indicates likelihood if facility igniting if a wildland fire occurs.

ProtectionLevel Inidcates structures which are priority for protection during a wildfire. For Alaska Region data, indicates identified protection level for structure. For lower 48, enter ‘Unknown’ unless specified by local unit.

ProtLevelApprovalName Name of person who designated Protection Level

ProtLevelApprovalDate Date Protection Level Designated

ResourcesOfConcern Indicates if it is necessary to contact park staff before engaging in suppression activities because special resources (natural, cultural, historic) of concern are present?

AssessComments Explain any aspects of the assessment that require extra detail.

RegionCode NPS Region Code - AKR, IMR, NER, NCR, MWR, PWR or SER

UnitCode

NPS Unit Code

ReasonIncluded Why is the point in the dataset – NPS owned, Treatment Planning, Protection Responsibility, Planning (other than treatments). Intent of the dataset is to document wildfire risk for NPS owned structures. Other structures or facilities may be included at the discretion of the unit's fire management staff.

Restriction How can the data be shared – Unrestricted, Restricted - No Third Party Release, Restricted – Originating Agency Concurrence, Restricted – Affected Cultural Group Concurrence, Restricted - No Release, Unknown. Only unrestricted data is included in this dataset.

Local_ID Field which can be used to store unique ids linking back to any local datasets.

RevisitInterval How many years will it take for the fuels to change significantly enough to change the score and rating for this facility?

IsVisited Use this field to keep track of what you have done during a field session. Filter on this field to see what has been assessed and what still needs visited during a field data collection session.

DeleteThis Users enter yes if this is this a duplicate or was no facility found.
If you know the facility was REMOVED or DESTROYED, go back to Facility Type and enter that information there.

Data_Source

FirewiseZone1 List of treatments needed to

Abstract

This dataset and its metadata statement were supplied to the Bioregional Assessment Programme by a third party and are presented here as originally supplied.

This dataset includes the works details from with surface water licences from NSW in the North and South Sydney region. The short guide to NSW Office of Water's licensing data has been provided to accompany the dataset (both the spatial locations and the associated licence details).

A SHORT GUIDE TO NSW OFFICE OF WATER'S LICENSING DATA

Methodology

1. Using the supplied polygons a spatial select was taken for each polygon area for the Surface and Groundwater Approved Work locations. These Work Location points were exported to an ArcGIS 10.0 File Geodatabase for each polygon area. These work locations have a "Status" of either "Active" (under the Water Act) or "Current" (under the Water Management Act).

2. The Approved License number attached to each Work was then used to query the Office of Water's Water Licensing System (WLS) to extract details on each Approved license including any linked Water Access Licenses (WAL) if the Work was now under the Water Management Act (WMA). These files end in *_WLS-EXTRACT_n.xls.

3. If found the linked WAL number is used to re-query using WLS to extract details on each linked WAL. These files end in *_WLS-EXTRACT_n_WALs_volume.xls.

4. It should be noted that due to query size constraints in WLS the output files for each polygon area may be split into a number of subset files ("n" being the number of the subset).

5. The field headings are as per the WLS Extract report. They include some characters (e.g. "") that may cause problems if loaded into ArcGIS. Not knowing how the data is to be used I have not amended them.

Understanding Licensing data

1. A Licensed Work Approval may have more than work (and therefore work location, i.e. point) associated with it. If the Licensed Work Approval is under the old Water Act it may have associated with it an "Entitlement" volume (if on a Regulated River) or an "Allocation" volume in an unregulated area. Please note that these volumes are for the whole licensed approval distributed amongst the related works but not against any particular one.

2. A Licensed Work Approval, if under the newer Water Management Act may have more than one linked WAL. Each WAL may have a "Share Component" volume associated with it. This will nee to be summed against each linked Licensed Work Approval to get the total WAL volume. Please note again that these volumes are for the whole licensed approval distributed amongst the related works but not against any particular one.

3. It is important to note that under the WMA it is possible for WALs not to have a linked Licensed Work Approval (to support Water Trading). This means a spatial select with not find these WALs and the volumes associated with them. The WAL is still related to a particular Water Source and can be re-associated with a different Licensed Work Approval at a later date.

This dataset has been provided to the BA Programme for use within the programme only. Third parties may request a copy of the data from DPI Water (previously known as the NSW Office of Water) at http://www.water.nsw.gov.au/.

Dataset History

This dataset was extracted from the NSW Office of Water's licensing system. Work Location points were exported to an ArcGIS 10.0 File Geodatabase for each polygon area supplied by the Bioregional Assessment project teams for each area. Corresponding work locations found with each polygon were exported from the licensing system.

Dataset Citation

NSW Office of Water (2013) NSW Office of Water Surface Water Offtakes - North & South Sydney v1 24102013. Bioregional Assessment Source Dataset. Viewed 18 June 2018, http://data.bioregionalassessments.gov.au/dataset/4d69c8af-07cd-4dd0-b090-40060e09b35d.

Abstract

The dataset was derived by the Bioregional Assessment Programme from multiple source datasets. The source datasets are identified in the Lineage field in this metadata statement. The processes undertaken to produce this derived dataset are described in the History field in this metadata statement.

This dataset contains v8 of the Asset database (GLO_asset_database_20150916.mdb), a Geodatabase version for GIS mapping purposes (GLO_asset_database_20150916_GISOnly.gdb), the draft Receptor Register spreadsheet (BA-NSB-GLO-140-ReceptorRegister-v20150916.xlsx), a data dictionary (GLO_asset_database_doc_20150916.doc) and a folder (NRM_DOC) containing documentation associated with the WAIT process as outlined below.

The Gloucester Asset database v8 supersedes the previous version of the GLO Asset database in Receptor relevant tables/ feature class only (i.e. ReceptorList, tbl_Receptors_GDE, tbl_Receptors_GW, tbl_Receptors_SW, tbl_Receptors_SW_Catchment_Ref_Only and GM_GLO_ReceptorList_pt). The location of Receptor is from GDA 94 datum.

The Asset database is registered to the BA repository as an ESRI personal goedatabase (.mdb - doubling as a MS Access database) that can store, query, and manage non-spatial data while the spatial data is in a separated file geodatabase joined by AID/Element ID. Under the BA program, a spatial assets database is developed for each defined bioregional assessment project. The spatial elements that underpin the identification of water dependent assets are identified in the first instance by regional NRM organisations (via the WAIT tool) and supplemented with additional elements from national and state/territory government datasets. All reports received associated with the WAIT process for Gloucester are included in the zip file as part of this dataset. Elements are initially included in the preliminary assets database if they are partly or wholly within the subregion's preliminary assessment extent (Materiality Test 1, M1). Elements are then grouped into assets which are evaluated by project teams to determine whether they meet the second Materiality Test (M2). Assets meeting both Materiality Tests comprise the water dependent asset list. Descriptions of the assets identified in the Gloucester subregion are found in the "AssetList" table of the database. In this version of the database only M1 has been assessed. Assets are the spatial features used by project teams to model scenarios under the BA program. Detailed attribution does not exist at the asset level. Asset attribution includes only the core set of BA-derived attributes reflecting the BA classification hierarchy, as described in Appendix A of "GLO_asset_database_doc_20150916.doc ", located in the zip file as part of this dataset. The "Element_to_Asset" table contains the relationships and identifies the elements that were grouped to create each asset. Detailed information describing the database structure and content can be found in the document "GLO_asset_database_doc_0150916.doc" located in the zip file. Some of the source data used in the compilation of this dataset is restricted.

Dataset History

VersionID Date Notes

1.0 17/03/2014 Initial database

1.01 19/03/2014 Update classification using latest one

2.0 23/05/2014 Update asset area for some assets

3.0 9/07/2014 Updated to include new assets and elements identified by community.

4.0 29/08/2014 Updated assets and elements from WSP

5.0 4/09/2014 Table AssetDecisions is added to record decision making process and decisions about M2 are also added in table asset list

6.0 8/04/2015 195/9 Groundwater economic point elements/assets were added in while 81/7 Groundwater economic point elements/assets were turned off

7.0 27/05/2015 The receptor data ( tables: ReceptorList, tbl_Receptors_GDE, tbl_Receptors_GW, tbl_Receptors_SW and tbl_Receptors_SW_Catchment_Ref_Only; and spatial data:

              GM_GLO_ReceptorList_pt) is added

7.1 21/08/2015 (1) Delete (a) line 26 from tab "Description" and (b) column E from tab "Receptor register" about "Depth" parameters in BA-NSB-GLO-140-ReceptorRegister-v20150821.xlsx

              (2) Delete field of "Depth" from table "ReceptorList" in GLO_asset_database_20150821.mdb

              (3) Add two fields of "InRegister" and "Registered Date" to table "ReceptorList" in GLO_asset_database_20150821.mdb for the consistency with other subregions in the future"

8 16/09/2015 (1) (a) Update Latitude, Longitude, LandscapeClass using the latest data from GLO project team and update the values for RegisteredDate, and Group using "GDE", "SW" and "GW" in table

              ReceptorList in GLO_asset_database_20150916.mdb; (b) Create draft BA-NSB-GLO-140-ReceptorRegister-v20150916.xlsx

              (2) Update tbl_Receptors_GDE, tbl_Receptors_GW and tbl_Receptors_SW in GLO_asset_database_20150916.mdb, using the latest data from GLO project team.

              (3) Update GM_GLO_ReceptorList_pt in GLO_asset_database_20150916_GISOnly.gdb, using the latest data from GLO project team"

Dataset Citation

Bioregional Assessment Programme (2014) Asset database for the Gloucester subregion on 16 September 2015. Bioregional Assessment Derived Dataset. Viewed 18 July 2018, http://data.bioregionalassessments.gov.au/dataset/480d6775-35eb-4eb2-9e2b-d27f0798d4bc.

Dataset Ancestors

• Derived From Standard Instrument Local Environmental Plan (LEP) - Heritage (HER) (NSW)

• Derived From NSW Office of Water GW licence extract linked to spatial locations - GLO v5 UID elements 27032014

• Derived From Groundwater Economic Assets GLO 20150326

• Derived From Gloucester digitised coal mine boundaries

• Derived From Groundwater Dependent Ecosystems supplied by the NSW Office of Water on 13/05/2014

• Derived From NSW Office of Water GW licence extract linked to spatial locations GLOv4 UID 14032014

• Derived From Communities of National Environmental Significance Database - RESTRICTED - Metadata only

• Derived From National Groundwater Dependent Ecosystems (GDE) Atlas

• Derived From Asset database for the Gloucester subregion on 12 September 2014

• Derived From GEODATA 9 second DEM and D8: Digital Elevation Model Version 3 and Flow Direction Grid 2008

• Derived From National Groundwater Information System (NGIS) v1.1

• Derived From Groundwater Entitlement Data GLO NSW Office of Water 20150320 PersRemoved

• Derived From Geofabric Surface Cartography - V2.1

• Derived From Groundwater Entitlement Data Gloucester - NSW Office of Water 20150320

• Derived From Collaborative Australian Protected Areas Database (CAPAD) 2010 - External Restricted

• Derived From National Groundwater Dependent Ecosystems (GDE) Atlas (including WA)

• Derived From EIS Gloucester Coal 2010

• Derived From Species Profile and Threats Database (SPRAT) - Australia - Species of National Environmental Significance Database (BA subset - RESTRICTED - Metadata only)

• Derived From Asset database for the Gloucester subregion on 28 May 2015

• Derived From NSW Office of Water GW licence extract linked to spatial locations GLOv3 12032014

• Derived From EIS for Rocky Hill Coal Project 2013

• Derived From National Heritage List Spatial Database (NHL) (v2.1)

• Derived From Asset database for the Gloucester subregion on 8 April 2015

• Derived From Gloucester - Additional assets from local councils

• Derived From NSW Office of Water combined geodatabase of regulated rivers and water sharing plan regions

• Derived From Asset database for the Gloucester subregion on 29 August 2014

• Derived From Asset database for the Gloucester subregion on 21 August 2015

• Derived From New South Wales NSW Regional CMA Water Asset Information WAIT tool databases, RESTRICTED Includes ALL Reports

*

Abstract

This dataset was supplied to the Bioregional Assessment Programme by a third party and is presented here as originally supplied. Metadata was not provided and has been compiled by the Bioregional Assessment Programme based on the known details at the time of acquisition.

This dataset includes the spatial location of all works associated with surface water licences from NSW in the BA regions. The short guide to NSW Office of Water's licensing data has been provided to accompany the dataset (both the spatial locations and the associated licence details).

A SHORT GUIDE TO NSW OFFICE OF WATER'S LICENSING DATA

Methodology

1. Using the supplied polygons a spatial select was taken for each polygon area for the Surface and Groundwater Approved Work locations. These Work Location points were exported to an ArcGIS 10.0 File Geodatabase for each polygon area. These work locations have a "Status" of either "Active" (under the Water Act) or "Current" (under the Water Management Act).

2. The Approved License number attached to each Work was then used to query the Office of Water's Water Licensing System (WLS) to extract details on each Approved license including any linked Water Access Licenses (WAL) if the Work was now under the Water Management Act (WMA). These files end in *_WLS-EXTRACT_n.xls.

3. If found the linked WAL number is used to re-query using WLS to extract details on each linked WAL. These files end in *_WLS-EXTRACT_n_WALs_volume.xls.

4. It should be noted that due to query size constraints in WLS the output files for each polygon area may be split into a number of subset files ("n" being the number of the subset).

5. The field headings are as per the WLS Extract report. They include some characters (e.g. "") that may cause problems if loaded into ArcGIS. Not knowing how the data is to be used I have not amended them.

Understanding Licensing data

1. A Licensed Work Approval may have more than work (and therefore work location, i.e. point) associated with it. If the Licensed Work Approval is under the old Water Act it may have associated with it an "Entitlement" volume (if on a Regulated River) or an "Allocation" volume in an unregulated area. Please note that these volumes are for the whole licensed approval distributed amongst the related works but not against any particular one.

2. A Licensed Work Approval, if under the newer Water Management Act may have more than one linked WAL. Each WAL may have a "Share Component" volume associated with it. This will nee to be summed against each linked Licensed Work Approval to get the total WAL volume. Please note again that these volumes are for the whole licensed approval distributed amongst the related works but not against any particular one.

3. It is important to note that under the WMA it is possible for WALs not to have a linked Licensed Work Approval (to support Water Trading). This means a spatial select with not find these WALs and the volumes associated with them. The WAL is still related to a particular Water Source and can be re-associated with a different Licensed Work Approval at a later date.

This dataset has been provided to the BA Programme for use within the programme only. Third parties may request a copy of the data from DPI Water (previously known as the NSW Office of Water) at http://www.water.nsw.gov.au/.

Dataset History

This dataset was extracted from the NSW Office of Water's licensing system. Work Location points were exported to an ArcGIS 10.0 File Geodatabase for each polygon area supplied by the Bioregional Assessment project teams for each area.

Dataset Citation

NSW Office of Water (2013) NSW Office of Water Surface Water Entitlements Locations v1_Oct2013. Bioregional Assessment Source Dataset. Viewed 13 March 2019, http://data.bioregionalassessments.gov.au/dataset/fc872710-998e-4c76-8b98-1df383c53de6.

This data was collected by the U.S. Bureau of Land Management (BLM) in New Mexico at both the New Mexico State Office and at the various field offices. This dataset is meant to depict the surface owner or manager of the land parcels. In the vast majority of land parcels, they will be one and the same. However, there are instances where the owner and manager of the land surface are not the same. When this occurs, the manager of the land is usually indicated. BLM's Master Title Plats are the official land records of the federal government and serve as the primary data source for depiction of all federal lands. Information from State of New Mexico is the primary source for the depiction of all state lands. Auxilliary source are referenced, as well, for the depiction of all lands. Collection of this dataset began in the 1980's using the BLM's ADS software to digitize information at the 1:24,000 scale. In the mid to late 1990's the data was converted from ADS to ArcInfo software and merged into tiles of one degree of longitude by one half degree of latitude. These tiles were regularly updated. The tiles were merged into a statewide coverage. The source geodatabase for this shapefile was created by loading the merged ArcInfo coverage into a personal geodatabase. The geodatabase data were snapped to a more accurate GCDB derived land network, where available. In areas where GCDB was not available the data were snapped to digitized PLSS. In 2006, the personal geodatabase was loaded into an enterprise geodatabase (SDE). This shapefile has been created by exporting the feature class from SDE.

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)