The Residential Schools Locations Dataset in Geodatabase format (IRS_Locations.gbd) contains a feature layer "IRS_Locations" that contains the locations (latitude and longitude) of Residential Schools and student hostels operated by the federal government in Canada. All the residential schools and hostels that are listed in the Residential Schools Settlement Agreement are included in this dataset, as well as several Industrial schools and residential schools that were not part of the IRRSA. This version of the dataset doesn’t include the five schools under the Newfoundland and Labrador Residential Schools Settlement Agreement. The original school location data was created by the Truth and Reconciliation Commission, and was provided to the researcher (Rosa Orlandini) by the National Centre for Truth and Reconciliation in April 2017. The dataset was created by Rosa Orlandini, and builds upon and enhances the previous work of the Truth and Reconcilation Commission, Morgan Hite (creator of the Atlas of Indian Residential Schools in Canada that was produced for the Tk'emlups First Nation and Justice for Day Scholar's Initiative, and Stephanie Pyne (project lead for the Residential Schools Interactive Map). Each individual school location in this dataset is attributed either to RSIM, Morgan Hite, NCTR or Rosa Orlandini. Many schools/hostels had several locations throughout the history of the institution. If the school/hostel moved from its’ original location to another property, then the school is considered to have two unique locations in this dataset,the original location and the new location. For example, Lejac Indian Residential School had two locations while it was operating, Stuart Lake and Fraser Lake. If a new school building was constructed on the same property as the original school building, it isn't considered to be a new location, as is the case of Girouard Indian Residential School.When the precise location is known, the coordinates of the main building are provided, and when the precise location of the building isn’t known, an approximate location is provided. For each residential school institution location, the following information is provided: official names, alternative name, dates of operation, religious affiliation, latitude and longitude coordinates, community location, Indigenous community name, contributor (of the location coordinates), school/institution photo (when available), location point precision, type of school (hostel or residential school) and list of references used to determine the location of the main buildings or sites. Access Instructions: there are 47 files in this data package. Please download the entire data package by selecting all the 47 files and click on download. Two files will be downloaded, IRS_Locations.gbd.zip and IRS_LocFields.csv. Uncompress the IRS_Locations.gbd.zip. Use QGIS, ArcGIS Pro, and ArcMap to open the feature layer IRS_Locations that is contained within the IRS_Locations.gbd data package. The feature layer is in WGS 1984 coordinate system. There is also detailed file level metadata included in this feature layer file. The IRS_locations.csv provides the full description of the fields and codes used in this dataset.

Crowther_Nature_Files.zip This description pertains to the original download. Details on revised (newer) versions of the datasets are listed below. When more than one version of a file exists in Figshare, the original DOI will take users to the latest version, though each version technically has its own DOI. -- Two global maps (raster files) of tree density. These maps highlight how the number of trees varies across the world. One map was generated using biome-level models of tree density, and applied at the biome scale. The other map was generated using ecoregion-level models of tree density, and applied at the ecoregion scale. For this reason, transitions between biomes or between ecoregions may be unrealistically harsh, but large-scale estimates are robust (see Crowther et al 2015 and Glick et al 2016). At the outset, this study was intended to generate reliable estimates at broad spatial scales, which inherently comes at the cost of fine-scale precision. For this reason, country-scale (or larger) estimates are generally more robust than individual pixel-level estimates. Additionally, due to data limitations, estimates for Mangroves and Tropical coniferous forest (as identified by WWF and TNC) were generated using models constructed from Topical moist broadleaf forest data and Temperate coniferous forest data, respectively. Because we used ecological analogy, the estimates for these two biomes should be considered less reliable than those of other biomes . These two maps initially appeared in Crowther et al (2015), with the biome map being featured more prominently. Explicit publication of the data is associated with Glick et al (2016). As they are produced, updated versions of these datasets, as well as alternative formats, will be made available under Additional Versions (see below).

Methods: We collected over 420,000 ground-sources estimates of tree density from around the world. We then constructed linear regression models using vegetative, climatic, topographic, and anthropogenic variables to produce forest tree density estimates for all locations globally. All modeling was done in R. Mapping was done using R and ArcGIS 10.1.

Viewing Instructions: Load the files into an appropriate geographic information system (GIS). For the original download (ArcGIS geodatabase files), load the files into ArcGIS to view or export the data to other formats. Because these datasets are large and have a unique coordinate system that is not read by many GIS, we suggest loading them into an ArcGIS dataframe whose coordinate system matches that of the data (see File Format). For GeoTiff files (see Additional Versions), load them into any compatible GIS or image management program.

Comments: The original download provides a zipped folder that contains (1) an ArcGIS File Geodatabase (.gdb) containing one raster file for each of the two global models of tree density – one based on biomes and one based on ecoregions; (2) a layer file (.lyr) for each of the global models with the symbology used for each respective model in Crowther et al (2015); and an ArcGIS Map Document (.mxd) that contains the layers and symbology for each map in the paper. The data is delivered in the Goode homolosine interrupted projected coordinate system that was used to compute biome, ecoregion, and global estimates of the number and density of trees presented in Crowther et al (2015). To obtain maps like those presented in the official publication, raster files will need to be reprojected to the Eckert III projected coordinate system. Details on subsequent revisions and alternative file formats are list below under Additional Versions.----------

Additional Versions: Crowther_Nature_Files_Revision_01.zip contains tree density predictions for small islands that are not included in the data available in the original dataset. These predictions were not taken into consideration in production of maps and figures presented in Crowther et al (2015), with the exception of the values presented in Supplemental Table 2. The file structure follows that of the original data and includes both biome- and ecoregion-level models.

Crowther_Nature_Files_Revision_01_WGS84_GeoTiff.zip contains Revision_01 of the biome-level model, but stored in WGS84 and GeoTiff format. This file was produced by reprojecting the original Goode homolosine files to WGS84 using nearest neighbor resampling in ArcMap. All areal computations presented in the manuscript were computed using the Goode homolosine projection. This means that comparable computations made with projected versions of this WGS84 data are likely to differ (substantially at greater latitudes) as a product of the resampling. Included in this .zip file are the primary .tif and its visualization support files.

References:

Crowther, T. W., Glick, H. B., Covey, K. R., Bettigole, C., Maynard, D. S., Thomas, S. M., Smith, J. R., Hintler, G., Duguid, M. C., Amatulli, G., Tuanmu, M. N., Jetz, W., Salas, C., Stam, C., Piotto, D., Tavani, R., Green, S., Bruce, G., Williams, S. J., Wiser, S. K., Huber, M. O., Hengeveld, G. M., Nabuurs, G. J., Tikhonova, E., Borchardt, P., Li, C. F., Powrie, L. W., Fischer, M., Hemp, A., Homeier, J., Cho, P., Vibrans, A. C., Umunay, P. M., Piao, S. L., Rowe, C. W., Ashton, M. S., Crane, P. R., and Bradford, M. A. 2015. Mapping tree density at a global scale. Nature, 525(7568): 201-205. DOI: http://doi.org/10.1038/nature14967Glick, H. B., Bettigole, C. B., Maynard, D. S., Covey, K. R., Smith, J. R., and Crowther, T. W. 2016. Spatially explicit models of global tree density. Scientific Data, 3(160069), doi:10.1038/sdata.2016.69.

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

This downloadable zip file contains an ESRI File Geodatabase (FGDB) that is compatible with most versions of ArcGIS Pro, ArcMap, and AutoCAD Map 3D or Civil 3D. To view the geodatabase’s contents, please download the zip file to a local directory and extract its contents. This zipped geodatabase will require approximately 1.38 GB of disc space (1.49 GB extracted). Due to its size, the zip file may take some time to download.This downloadable file geodataase (FGDB) includes Topographic Countours and Spot Elevations derived from LiDAR collected in spring of 2024 by Dewberry Engineers in coordination with Tallahassee - Leon County GIS. The contours were extracted at a 2 foot interval with index contours every 10 feet. Lidar Acquisition Executive SummaryThe primary purpose of this project was to develop a consistent and accurate surface elevation dataset derived from high-accuracy Light Detection and Ranging (lidar) technology for the Tallahassee Leon County Project Area. The lidar data were processed and classified according to project specifications. Detailed breaklines and bare-earth Digital Elevation Models (DEMs) were produced for the project area. Data was formatted according to tiles with each tile covering an area of 5000 ft by 5000 ft. A total of 876 tiles were produced for the project encompassing an area of approximately 785.55 sq. miles. The dataset was created by TLCGIS from lidar data acquired by a Riegl CQ-1560i lidar system from January 14, 2024 through January 19, 2024.ORIGINAL COORDINATE REFERENCE SYSTEMData produced for the project were delivered in the following reference system.Horizontal Datum: The horizontal datum for the project is North American Datum of 1983 with the 2011 Adjustment (NAD 83 (2011))Vertical Datum: The Vertical datum for the project is North American Vertical Datum of 1988 (NAVD88)Coordinate System: NAD83 (2011) State Plane Florida North (US survey feet)Units: Horizontal units are in U.S. Survey Feet, Vertical units are in U.S. Survey Feet.Geiod Model: Geoid12B (Geoid 12B) was used to convert ellipsoid heights to orthometric heights).

This intersection points feature class represents current intersections in the City of Los Angeles. Few intersection points, named pseudo nodes, are used to split the street centerline at a point that is not a true intersection at the ground level. The Mapping and Land Records Division of the Bureau of Engineering, Department of Public Works provides the most current geographic information of the public right of way. The right of way information is available on NavigateLA, a website hosted by the Bureau of Engineering, Department of Public Works.Intersection layer was created in geographical information systems (GIS) software to display intersection points. Intersection points are placed where street line features join or cross each other and where freeway off- and on-ramp line features join street line features. The intersection points layer is a feature class in the LACityCenterlineData.gdb Geodatabase dataset. The layer consists of spatial data as a point feature class and attribute data for the features. The intersection points relates to the intersection attribute table, which contains data describing the limits of the street segment, by the CL_NODE_ID field. The layer shows the location of the intersection points on map products and web mapping applications, and the Department of Transportation, LADOT, uses the intersection points in their GIS system. The intersection attributes are used in the Intersection search function on BOE's web mapping application NavigateLA. The intersection spatial data and related attribute data are maintained in the Intersection layer using Street Centerline Editing application. The City of Los Angeles Municipal code states, all public right-of-ways (roads, alleys, etc) are streets, thus all of them have intersections. List of Fields:Y: This field captures the georeferenced location along the vertical plane of the point in the data layer that is projected in Stateplane Coordinate System NAD83. For example, Y = in the record of a point, while the X = .CL_NODE_ID: This field value is entered as new point features are added to the edit layer, during Street Centerline application editing process. The values are assigned automatically and consecutively by the ArcGIS software first to the street centerline spatial data layer, then the intersections point spatial data layer, and then the intersections point attribute data during the creation of new intersection points. Each intersection identification number is a unique value. The value relates to the street centerline layer attributes, to the INT_ID_FROM and INT_ID_TO fields. One or more street centerline features intersect the intersection point feature. For example, if a street centerline segment ends at a cul-de-sac, then the point feature intersects only one street centerline segment.X: This field captures the georeferenced location along the horizontal plane of the point in the data layer that is projected in Stateplane Coordinate System NAD83. For example, X = in the record of a point, while the Y = .ASSETID: User-defined feature autonumber.USER_ID: The name of the user carrying out the edits.SHAPE: Feature geometry.LST_MODF_DT: Last modification date of the polygon feature.LAT: This field captures the Latitude in deciaml degrees units of the point in the data layer that is projected in Geographic Coordinate System GCS_North_American_1983.OBJECTID: Internal feature number.CRTN_DT: Creation date of the polygon feature.TYPE: This field captures a value for intersection point features that are psuedo nodes or outside of the City. A pseudo node, or point, does not signify a true intersection of two or more different street centerline features. The point is there to split the line feature into two segments. A pseudo node may be needed if for example, the Bureau of Street Services (BSS) has assigned different SECT_ID values for those segments. Values: • S - Feature is a pseudo node and not a true intersection. • null - Feature is an intersection point. • O - Intersection point is outside of the City of LA boundary.LON: This field captures the Longitude in deciaml degrees units of the point in the data layer that is projected in Geographic Coordinate System GCS_North_American_1983.

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.

This data set is one of many developed in support of The High Plains Groundwater Availability Project and the U.S. Geological Survey Data Series Report: Geodatabase Compilation of Hydrogeologic, Remote Sensing, and Water-Budget-Component data for the High Plains aquifer, 2011 (DS 777). The creation of the model grid is an important first step in developing a groundwater-flow model, because all model inputs including hydraulic properties, wells, and boundary conditions are assigned to the model cells. The northern High Plains groundwater-flow model boundary feature dataset contains three feature classes; the model grid cells for the northern High Plains groundwater-flow model in both polygon (cell) and point (centroid) format and the external boundary of the model. The model grid contains 449,175 cells, 565 rows and 795 columns. Each cell is 1,000 feet per side. The model grid is not rotated. The external boundary includes the active and inactive areas of the model. The projection for the model grid and all feature classes in all geodatabases for this study are Albers Equal-Area Conic coordinate system, North American Datum 1983.

This downloadable zip file contains an ESRI File Geodatabase (FGDB) that is compatible with most versions of ArcGIS Pro, ArcMap, and AutoCAD Map 3D or Civil 3D. To view the geodatabase’s contents, please download the zip file to a local directory and extract its contents. This zipped geodatabase will require approximately 2.85 GB of disc space (3.09 GB extracted). Due to its size, the zip file may take some time to download.This topographic contour layer was derived from LiDAR collected in spring of 2018 by Dewberry Engineers in coordination with Tallahassee - Leon County GIS. The contours were extracted at a 2 foot interval with index contours every 10 feet. Lidar Acquisition Executive SummaryThe primary purpose of this project was to develop a consistent and accurate surface elevation dataset derived from high-accuracy Light Detection and Ranging (lidar) technology for the Tallahassee Leon County Project Area. The lidar data were processed and classified according to project specifications. Detailed breaklines and bare-earth Digital Elevation Models (DEMs) were produced for the project area. Data was formatted according to tiles with each tile covering an area of 5000 ft by 5000 ft. A total of 876 tiles were produced for the project encompassing an area of approximately 785.55 sq. miles.THE PROJECT TEAMDewberry served as the prime contractor for the project. In addition to project management, Dewberry was responsible for LAS classification, all lidar products, breakline production, Digital Elevation Model (DEM) production, and quality assurance. Dewberry’s Frederick C. Rankin completed ground surveying for the project and delivered surveyed checkpoints. His task was to acquire surveyed checkpoints for the project to use in independent testing of the vertical accuracy of the lidar-derived surface model. He also verified the GPS base station coordinates used during lidar data acquisition to ensure that the base station coordinates were accurate. Please see Appendix A to view the separate Survey Report that was created for this portion of the project. Digital Aerial Solutions, LLC completed lidar data acquisition and data calibration for the project area.SURVEY AREAThe project area addressed by this report falls within the Florida county of Leon.DATE OF SURVEYThe lidar aerial acquisition was conducted from February 05, 2018 thru April 25, 2018.ORIGINAL COORDINATE REFERENCE SYSTEMData produced for the project were delivered in the following reference system.Horizontal Datum: The horizontal datum for the project is North American Datum of 1983 with the 2011 Adjustment (NAD 83 (2011))Vertical Datum: The Vertical datum for the project is North American Vertical Datum of 1988 (NAVD88)Coordinate System: NAD83 (2011) State Plane Florida North (US survey feet)Units: Horizontal units are in U.S. Survey Feet, Vertical units are in U.S. Survey Feet.Geiod Model: Geoid12B (Geoid 12B) was used to convert ellipsoid heights to orthometric heights).

This data contains general information about Pedestrian Network in Hong Kong. Pedestrian Network is a set of 3D line features derived from road features and road furniture from Lands Department and Transport Department. A number of attributes are associated with the pedestrian network such as spatially related street names. Besides, the pedestrian network includes information like wheelchair accessibility and obstacles to facilitate the digital inclusion for the needy. Please refer to this video to learn how to use 3D Pedestrian Network Dataset in ArcGIS Pro to facilitate your transportation analysis.The data was provided in the formats of JSON, GML and GDB by Lands Department and downloaded via GEODATA.GOV.HK website.

The original data files were processed and converted into an Esri file geodatabase. Wheelchair accessibility, escalator/lift, staircase walking speed and street gradient were used to create and build a network dataset in order to demonstrate basic functions for pedestrian network and routing analysis in ArcMap and ArcGIS Pro. There are other tables and feature classes in the file geodatabase but they are not included in the network dataset, users have to consider the use of information based on their requirements and make necessary configurations. The coordinate system of this dataset is Hong Kong 1980 Grid.

The objectives of uploading the network dataset to ArcGIS Online platform are to facilitate our Hong Kong ArcGIS users to utilize the data in a spatial ready format and save their data conversion effort.

For details about the schema and information about the content and relationship of the data, please refer to the data dictionary provided by Lands Department at https://geodata.gov.hk/gs/download-datadict/201eaaee-47d6-42d0-ac81-19a430f63952.

For details about the data, source format and terms of conditions of usage, please refer to the website of GEODATA STORE at https://geodata.gov.hk.Dataset last updated on: 2022 Oct

description: This layer is geographically based on Bureau of Land Management (BLM) and U.S. General Land Office Geographic Coordinate Data Base (GCDB) 1:24,000-scale Land survey Information System Data Base (LSIS) data for the states of Nevada and Utah sourced from the U.S. Geological Survey (USGS) Digital Line Graph (DLG) dataset. Tabular data is derived from the Nevada Division of Water Resources (NDWR) Crop Inventory Data. NDWR inventories irrigated acreage for Newark and Steptoe Valleys on an annual basis. Estimates of irrigated acreage are developed from observations made during field work performed primarily during the August through December time period and are reported annually in a series of crop inventories. The Newark Valley inventory includes irrigation in the northern part of Little Smoky Valley. NDWR crop inventories identify and define irrigated acreage by township, range, section, quarter section, and quarter-quarter section. Only NDWR crop inventories for 2000, 2002, and 2005 are stored in the geodatabase.; abstract: This layer is geographically based on Bureau of Land Management (BLM) and U.S. General Land Office Geographic Coordinate Data Base (GCDB) 1:24,000-scale Land survey Information System Data Base (LSIS) data for the states of Nevada and Utah sourced from the U.S. Geological Survey (USGS) Digital Line Graph (DLG) dataset. Tabular data is derived from the Nevada Division of Water Resources (NDWR) Crop Inventory Data. NDWR inventories irrigated acreage for Newark and Steptoe Valleys on an annual basis. Estimates of irrigated acreage are developed from observations made during field work performed primarily during the August through December time period and are reported annually in a series of crop inventories. The Newark Valley inventory includes irrigation in the northern part of Little Smoky Valley. NDWR crop inventories identify and define irrigated acreage by township, range, section, quarter section, and quarter-quarter section. Only NDWR crop inventories for 2000, 2002, and 2005 are stored in the geodatabase.

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

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)

Treasure County Cadastral Data ResourcesA snapshot of property and parcel data for June 2022.Department of Revenue Orion SQL property record database provided as both an SQL database and as tables in a file geodatabase.File Geodatabase and Shapefile options for parcel polygon GIS data.Visit the Montana State Library Cadastral MSDI page for more information on cadastral data and Orion property database : MSDI Cadastral (mt.gov)The Montana Cadastral Framework shows the taxable parcels and tax-exempt parcels for most of Montana. The parcels contain selected information such as owner names, property and owner addresses, assessed value, agricultural use, and tax district information that were copied from the Montana Department of Revenue's ORION tax appraisal database. The data are maintained by the MT Department of Revenue, except for Ravalli, Silver Bow, Missoula, Flathead and Yellowstone counties that are maintained by the individual counties. The Revenue and county data are integrated by Montana State Library staff. Each parcel contains an attribute called ParcelID (geocode) that is the parcel identifier. View a pdf map of the counties that were updated this month here: https://ftpgeoinfo.msl.mt.gov/Data/Spatial/MSDI/Cadastral/Parcels/Statewide/MonthlyCadastralUpdateMap.pdf The parcel boundaries were aligned to fit with the Bureau of Land Management Geographic Coordinate Database (GCDB) of public land survey coordinates. Parcels whose legal descriptions consisted of aliquot parts of the public land survey system were created from the GCDB coordinates by selecting and, when necessary, subdividing public land survey entities. Other parcels were digitized from paper maps and the data from each map were transformed to fit with the appropriate GCDB boundaries.

Park County Cadastral Data ResourcesA snapshot of property and parcel data for June 2022.Department of Revenue Orion SQL property record database provided as both an SQL database and as tables in a file geodatabase.File Geodatabase and Shapefile options for parcel polygon GIS data.Visit the Montana State Library Cadastral MSDI page for more information on cadastral data and Orion property database : MSDI Cadastral (mt.gov)The Montana Cadastral Framework shows the taxable parcels and tax-exempt parcels for most of Montana. The parcels contain selected information such as owner names, property and owner addresses, assessed value, agricultural use, and tax district information that were copied from the Montana Department of Revenue's ORION tax appraisal database. The data are maintained by the MT Department of Revenue, except for Ravalli, Silver Bow, Missoula, Flathead and Yellowstone counties that are maintained by the individual counties. The Revenue and county data are integrated by Montana State Library staff. Each parcel contains an attribute called ParcelID (geocode) that is the parcel identifier. View a pdf map of the counties that were updated this month here: https://ftpgeoinfo.msl.mt.gov/Data/Spatial/MSDI/Cadastral/Parcels/Statewide/MonthlyCadastralUpdateMap.pdf The parcel boundaries were aligned to fit with the Bureau of Land Management Geographic Coordinate Database (GCDB) of public land survey coordinates. Parcels whose legal descriptions consisted of aliquot parts of the public land survey system were created from the GCDB coordinates by selecting and, when necessary, subdividing public land survey entities. Other parcels were digitized from paper maps and the data from each map were transformed to fit with the appropriate GCDB boundaries.

Carbon County Cadastral Data ResourcesA snapshot of property and parcel data for June 2022.Department of Revenue Orion SQL property record database provided as both an SQL database and as tables in a file geodatabase.File Geodatabase and Shapefile options for parcel polygon GIS data.Visit the Montana State Library Cadastral MSDI page for more information on cadastral data and Orion property database : MSDI Cadastral (mt.gov)The Montana Cadastral Framework shows the taxable parcels and tax-exempt parcels for most of Montana. The parcels contain selected information such as owner names, property and owner addresses, assessed value, agricultural use, and tax district information that were copied from the Montana Department of Revenue's ORION tax appraisal database. The data are maintained by the MT Department of Revenue, except for Ravalli, Silver Bow, Missoula, Flathead and Yellowstone counties that are maintained by the individual counties. The Revenue and county data are integrated by Montana State Library staff. Each parcel contains an attribute called ParcelID (geocode) that is the parcel identifier. View a pdf map of the counties that were updated this month here: https://ftpgeoinfo.msl.mt.gov/Data/Spatial/MSDI/Cadastral/Parcels/Statewide/MonthlyCadastralUpdateMap.pdf The parcel boundaries were aligned to fit with the Bureau of Land Management Geographic Coordinate Database (GCDB) of public land survey coordinates. Parcels whose legal descriptions consisted of aliquot parts of the public land survey system were created from the GCDB coordinates by selecting and, when necessary, subdividing public land survey entities. Other parcels were digitized from paper maps and the data from each map were transformed to fit with the appropriate GCDB boundaries.

Missoula County Cadastral Data ResourcesA snapshot of property and parcel data for July 2022.Department of Revenue Orion SQL property record database provided as both an SQL database and as tables in a file geodatabase.File Geodatabase and Shapefile options for parcel polygon GIS data.Visit the Montana State Library Cadastral MSDI page for more information on cadastral data and Orion property database : MSDI Cadastral (mt.gov)The Montana Cadastral Framework shows the taxable parcels and tax-exempt parcels for most of Montana. The parcels contain selected information such as owner names, property and owner addresses, assessed value, agricultural use, and tax district information that were copied from the Montana Department of Revenue's ORION tax appraisal database. The data are maintained by the MT Department of Revenue, except for Ravalli, Silver Bow, Missoula, Flathead and Yellowstone counties that are maintained by the individual counties. The Revenue and county data are integrated by Montana State Library staff. Each parcel contains an attribute called ParcelID (geocode) that is the parcel identifier. View a pdf map of the counties that were updated this month here: https://ftpgeoinfo.msl.mt.gov/Data/Spatial/MSDI/Cadastral/Parcels/Statewide/MonthlyCadastralUpdateMap.pdf The parcel boundaries were aligned to fit with the Bureau of Land Management Geographic Coordinate Database (GCDB) of public land survey coordinates. Parcels whose legal descriptions consisted of aliquot parts of the public land survey system were created from the GCDB coordinates by selecting and, when necessary, subdividing public land survey entities. Other parcels were digitized from paper maps and the data from each map were transformed to fit with the appropriate GCDB boundaries.